* 2.6.33-rc3-git3: Reported regressions from 2.6.32 @ 2010-01-10 22:27 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:27 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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 ---------------------------------------- 2010-01-10 55 33 21 2009-12-29 36 34 27 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 Submitter : Soeren Sonnenburg <sonne@debian.org> Date : 2010-01-10 20:09 (1 days old) References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 Subject : Pagemap endless read loop with LTP Submitter : Andi Kleen <andi@firstfloor.org> Date : 2010-01-10 2:09 (1 days old) References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15038 Subject : drm/ksm: fbdev blanking regression Submitter : Johan Hovold <jhovold@gmail.com> Date : 2010-01-06 17:00 (5 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=731b5a15a3b1474a41c2ca29b4c32b0f21bc852e References : http://marc.info/?l=linux-kernel&m=126279726418748&w=4 Handled-By : James Simmons <jsimmons@infradead.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036 Subject : soft lockup in dmesg after suspend/resume Submitter : ykzhao <yakui.zhao@intel.com> Date : 2010-01-04 5:36 (7 days old) References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15035 Subject : BUG: unable to handle kernel paging request in rs600_gart_set_page() Submitter : Xiaotian Feng <dfeng@redhat.com> Date : 2010-01-05 19:10 (6 days old) References : http://lkml.org/lkml/2010/1/5/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 Subject : drm: gem_object_free without struct_mutex Submitter : Hugh Dickins <hugh.dickins@tiscali.co.uk> Date : 2009-12-30 19:45 (12 days old) References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15032 Subject : Oops in uart_resume_port() on resume Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2010-01-04 15:47 (7 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba15ab0e8de0d4439a91342ad52d55ca9e313f3d References : http://marc.info/?l=linux-kernel&m=126262008815689&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14976 Subject : No sound on snd_hda_codec_via in 2.6.33-rc2 Submitter : Mark Rosenstand <rosenstand@gmail.com> Date : 2010-01-02 08:27 (9 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14954 Subject : warning from alloc_pages_nodemask on boot -- caused by commit 78f1699659963fff97975df44db6d5dbe7218e55 Submitter : Stephen Hemminger <shemminger@linux-foundation.org> Date : 2009-12-29 19:57 (13 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78f1699659963fff97975df44db6d5dbe7218e55 Handled-By : Alex Chiang <achiang@hp.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950 Subject : tbench regression with 2.6.33-rc1 Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2009-12-25 11:11 (17 days old) References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:45 (16 days old) References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 Subject : EHCI resume sysfs duplicates Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:36 (16 days old) References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce@blueyonder.co.uk> Date : 2009-12-23 16:55 (19 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937 Subject : WARNING: at kernel/lockdep.c:2830 Submitter : Grant Wilson <grant.wilson@zen.co.uk> Date : 2009-12-27 13:35 (15 days old) References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14934 Subject : kernel crash during boot Submitter : werner <w.landgraf@ru.ru> Date : 2009-12-25 5:37 (17 days old) References : http://marc.info/?l=linux-kernel&m=126171951030608&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14925 Subject : sky2 panic under load Submitter : Berck E. Nash <flyboy@gmail.com> Date : 2009-12-21 23:52 (21 days old) References : http://marc.info/?l=linux-kernel&m=126143955730347&w=4 http://marc.info/?l=linux-kernel&m=126160893126548&w=4 Handled-By : Stephen Hemminger <shemminger@vyatta.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14924 Subject : Weird hard hangs when rendering 'some' web-sites in Firefox Submitter : David <david@unsolicited.net> Date : 2009-12-21 21:53 (21 days old) References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14860 Subject : No DP-DVI output when laptop is docked Submitter : Pär Andersson <paran@lysator.liu.se> Date : 2009-12-21 21:02 (21 days old) Handled-By : ykzhao <yakui.zhao@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 Subject : System timer firing too much without cause Submitter : Shawn Starr <shawn.starr@rogers.com> Date : 2009-12-21 19:16 (21 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792 Subject : Misdetection of the TV output Submitter : Santi <santi@agolina.net> Date : 2009-12-12 13:28 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 Subject : Something has been broken in the network stack this week Submitter : Delete This Account <speedyboyinovator@hotmail.com> Date : 2009-12-12 13:06 (30 days old) Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15039 Subject : leds_alix2: can't allocate I/O for GPIO Submitter : Arnd Hannemann <hannemann@nets.rwth-aachen.de> Date : 2010-01-07 10:26 (4 days old) References : http://marc.info/?l=linux-kernel&m=126286001106257&w=4 Handled-By : Daniel Mack <daniel@caiaq.de> Patch : http://patchwork.kernel.org/patch/72006/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15037 Subject : BUG during shutdown - bisected to commit e2912009 Submitter : Marc Dionne <marc.c.dionne@gmail.com> Date : 2010-01-02 0:27 (9 days old) References : http://marc.info/?l=linux-kernel&m=126239207631034&w=4 Handled-By : Xiaotian Feng <dfeng@redhat.com> Patch : http://patchwork.kernel.org/patch/71537/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15034 Subject : volano ~30% regression Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2010-01-04 8:15 (7 days old) References : http://marc.info/?l=linux-kernel&m=126259391411982&w=4 Handled-By : Mike Galbraith <efault@gmx.de> Patch : http://patchwork.kernel.org/patch/70623/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15031 Subject : bug in fs/btrfs/ordered-data.c:672 Submitter : Carlos R. Mafra <crmafra2@gmail.com> Date : 2010-01-02 11:32 (9 days old) References : http://lkml.org/lkml/2010/1/2/17 Handled-By : Yan, Zheng <yanzheng@21cn.com> Patch : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03686.html Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15026 Subject : i915: Resume regression on MSI Wind U100 w/o KMS Submitter : Rafael J. Wysocki <rjw@sisk.pl> Date : 2010-01-08 23:45 (3 days old) References : http://marc.info/?l=linux-kernel&m=126299433427673&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Patch : http://patchwork.kernel.org/patch/71887/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14974 Subject : tg3 does not resume from hibernation properly on BCM5787M Submitter : Chow Loong Jin <hyperair@ubuntu.com> Date : 2010-01-02 05:30 (9 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=87668d352aa8d135bd695a050f18bbfc7b50b506 Handled-By : Matt Carlson <mcarlson@broadcom.com> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=14974#c12 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14957 Subject : Blank screen with KMS enabled Submitter : Philipp Kohlbecher <xt28@gmx.de> Date : 2009-12-30 00:08 (12 days old) Handled-By : Zhao Yakui <yakui.zhao@intel.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24476 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14944 Subject : 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine Submitter : fengxiangjun <fengxiangjun@neusoft.com> Date : 2009-12-21 11:12 (21 days old) References : http://marc.info/?l=linux-kernel&m=126139442328314&w=4 Handled-By : Tejun Heo <tj@kernel.org> Patch : http://patchwork.kernel.org/patch/69746/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 Subject : gkrellm no longer shows all the temperatures on thinkpad x60 Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-12-27 21:57 (15 days old) References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Patch : http://patchwork.kernel.org/patch/69809/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 Subject : Commit "kbuild: fix bzImage build for x86" breaks build Submitter : Oliver Hartkopp <oliver@hartkopp.net> Date : 2009-12-19 19:21 (23 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 http://marc.info/?l=linux-kernel&m=126114565103300&w=4 http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 Handled-By : Jonathan Nieder <jrnieder@gmail.com> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 http://patchwork.kernel.org/patch/71957/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 Subject : reiserfs: inconsistent lock state Submitter : Alexander Beregalov <a.beregalov@gmail.com> Date : 2009-12-11 22:06 (31 days old) References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 Handled-By : Frederic Weisbecker <fweisbec@gmail.com> Patch : http://patchwork.kernel.org/patch/67256/ http://patchwork.kernel.org/patch/67257/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 Submitter : Joshua Covington <joshuacov@googlemail.com> Date : 2009-12-25 00:49 (17 days old) Handled-By : Luis R. Rodriguez <mcgrof@gmail.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 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 from 2.6.32, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=14885 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* 2.6.33-rc3-git3: Reported regressions from 2.6.32 @ 2010-01-10 22:27 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:27 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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 ---------------------------------------- 2010-01-10 55 33 21 2009-12-29 36 34 27 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 Submitter : Soeren Sonnenburg <sonne@debian.org> Date : 2010-01-10 20:09 (1 days old) References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 Subject : Pagemap endless read loop with LTP Submitter : Andi Kleen <andi@firstfloor.org> Date : 2010-01-10 2:09 (1 days old) References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15038 Subject : drm/ksm: fbdev blanking regression Submitter : Johan Hovold <jhovold@gmail.com> Date : 2010-01-06 17:00 (5 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=731b5a15a3b1474a41c2ca29b4c32b0f21bc852e References : http://marc.info/?l=linux-kernel&m=126279726418748&w=4 Handled-By : James Simmons <jsimmons@infradead.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036 Subject : soft lockup in dmesg after suspend/resume Submitter : ykzhao <yakui.zhao@intel.com> Date : 2010-01-04 5:36 (7 days old) References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15035 Subject : BUG: unable to handle kernel paging request in rs600_gart_set_page() Submitter : Xiaotian Feng <dfeng@redhat.com> Date : 2010-01-05 19:10 (6 days old) References : http://lkml.org/lkml/2010/1/5/95 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 Subject : drm: gem_object_free without struct_mutex Submitter : Hugh Dickins <hugh.dickins@tiscali.co.uk> Date : 2009-12-30 19:45 (12 days old) References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15032 Subject : Oops in uart_resume_port() on resume Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2010-01-04 15:47 (7 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba15ab0e8de0d4439a91342ad52d55ca9e313f3d References : http://marc.info/?l=linux-kernel&m=126262008815689&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14976 Subject : No sound on snd_hda_codec_via in 2.6.33-rc2 Submitter : Mark Rosenstand <rosenstand@gmail.com> Date : 2010-01-02 08:27 (9 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14954 Subject : warning from alloc_pages_nodemask on boot -- caused by commit 78f1699659963fff97975df44db6d5dbe7218e55 Submitter : Stephen Hemminger <shemminger@linux-foundation.org> Date : 2009-12-29 19:57 (13 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78f1699659963fff97975df44db6d5dbe7218e55 Handled-By : Alex Chiang <achiang@hp.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950 Subject : tbench regression with 2.6.33-rc1 Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2009-12-25 11:11 (17 days old) References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:45 (16 days old) References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 Subject : EHCI resume sysfs duplicates Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:36 (16 days old) References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce@blueyonder.co.uk> Date : 2009-12-23 16:55 (19 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937 Subject : WARNING: at kernel/lockdep.c:2830 Submitter : Grant Wilson <grant.wilson@zen.co.uk> Date : 2009-12-27 13:35 (15 days old) References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14934 Subject : kernel crash during boot Submitter : werner <w.landgraf@ru.ru> Date : 2009-12-25 5:37 (17 days old) References : http://marc.info/?l=linux-kernel&m=126171951030608&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14925 Subject : sky2 panic under load Submitter : Berck E. Nash <flyboy@gmail.com> Date : 2009-12-21 23:52 (21 days old) References : http://marc.info/?l=linux-kernel&m=126143955730347&w=4 http://marc.info/?l=linux-kernel&m=126160893126548&w=4 Handled-By : Stephen Hemminger <shemminger@vyatta.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14924 Subject : Weird hard hangs when rendering 'some' web-sites in Firefox Submitter : David <david@unsolicited.net> Date : 2009-12-21 21:53 (21 days old) References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14860 Subject : No DP-DVI output when laptop is docked Submitter : Pär Andersson <paran@lysator.liu.se> Date : 2009-12-21 21:02 (21 days old) Handled-By : ykzhao <yakui.zhao@intel.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 Subject : System timer firing too much without cause Submitter : Shawn Starr <shawn.starr@rogers.com> Date : 2009-12-21 19:16 (21 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792 Subject : Misdetection of the TV output Submitter : Santi <santi@agolina.net> Date : 2009-12-12 13:28 (30 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 Subject : Something has been broken in the network stack this week Submitter : Delete This Account <speedyboyinovator@hotmail.com> Date : 2009-12-12 13:06 (30 days old) Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15039 Subject : leds_alix2: can't allocate I/O for GPIO Submitter : Arnd Hannemann <hannemann@nets.rwth-aachen.de> Date : 2010-01-07 10:26 (4 days old) References : http://marc.info/?l=linux-kernel&m=126286001106257&w=4 Handled-By : Daniel Mack <daniel@caiaq.de> Patch : http://patchwork.kernel.org/patch/72006/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15037 Subject : BUG during shutdown - bisected to commit e2912009 Submitter : Marc Dionne <marc.c.dionne@gmail.com> Date : 2010-01-02 0:27 (9 days old) References : http://marc.info/?l=linux-kernel&m=126239207631034&w=4 Handled-By : Xiaotian Feng <dfeng@redhat.com> Patch : http://patchwork.kernel.org/patch/71537/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15034 Subject : volano ~30% regression Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2010-01-04 8:15 (7 days old) References : http://marc.info/?l=linux-kernel&m=126259391411982&w=4 Handled-By : Mike Galbraith <efault@gmx.de> Patch : http://patchwork.kernel.org/patch/70623/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15031 Subject : bug in fs/btrfs/ordered-data.c:672 Submitter : Carlos R. Mafra <crmafra2@gmail.com> Date : 2010-01-02 11:32 (9 days old) References : http://lkml.org/lkml/2010/1/2/17 Handled-By : Yan, Zheng <yanzheng@21cn.com> Patch : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03686.html Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15026 Subject : i915: Resume regression on MSI Wind U100 w/o KMS Submitter : Rafael J. Wysocki <rjw@sisk.pl> Date : 2010-01-08 23:45 (3 days old) References : http://marc.info/?l=linux-kernel&m=126299433427673&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Patch : http://patchwork.kernel.org/patch/71887/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14974 Subject : tg3 does not resume from hibernation properly on BCM5787M Submitter : Chow Loong Jin <hyperair@ubuntu.com> Date : 2010-01-02 05:30 (9 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=87668d352aa8d135bd695a050f18bbfc7b50b506 Handled-By : Matt Carlson <mcarlson@broadcom.com> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=14974#c12 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14957 Subject : Blank screen with KMS enabled Submitter : Philipp Kohlbecher <xt28@gmx.de> Date : 2009-12-30 00:08 (12 days old) Handled-By : Zhao Yakui <yakui.zhao@intel.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24476 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14944 Subject : 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine Submitter : fengxiangjun <fengxiangjun@neusoft.com> Date : 2009-12-21 11:12 (21 days old) References : http://marc.info/?l=linux-kernel&m=126139442328314&w=4 Handled-By : Tejun Heo <tj@kernel.org> Patch : http://patchwork.kernel.org/patch/69746/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 Subject : gkrellm no longer shows all the temperatures on thinkpad x60 Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-12-27 21:57 (15 days old) References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Patch : http://patchwork.kernel.org/patch/69809/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 Subject : Commit "kbuild: fix bzImage build for x86" breaks build Submitter : Oliver Hartkopp <oliver@hartkopp.net> Date : 2009-12-19 19:21 (23 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 http://marc.info/?l=linux-kernel&m=126114565103300&w=4 http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 Handled-By : Jonathan Nieder <jrnieder@gmail.com> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 http://patchwork.kernel.org/patch/71957/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 Subject : reiserfs: inconsistent lock state Submitter : Alexander Beregalov <a.beregalov@gmail.com> Date : 2009-12-11 22:06 (31 days old) References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 Handled-By : Frederic Weisbecker <fweisbec@gmail.com> Patch : http://patchwork.kernel.org/patch/67256/ http://patchwork.kernel.org/patch/67257/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 Submitter : Joshua Covington <joshuacov@googlemail.com> Date : 2009-12-25 00:49 (17 days old) Handled-By : Luis R. Rodriguez <mcgrof@gmail.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 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 from 2.6.32, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=14885 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14791] Something has been broken in the network stack this week 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:27 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:27 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Ben Hutchings, David S. Miller, Delete This Account This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 Subject : Something has been broken in the network stack this week Submitter : Delete This Account <speedyboyinovator@hotmail.com> Date : 2009-12-12 13:06 (30 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14791] Something has been broken in the network stack this week @ 2010-01-10 22:27 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:27 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Ben Hutchings, David S. Miller, Delete This Account This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 Subject : Something has been broken in the network stack this week Submitter : Delete This Account <speedyboyinovator-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> Date : 2009-12-12 13:06 (30 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14791] Something has been broken in the network stack this week 2010-01-10 22:27 ` Rafael J. Wysocki (?) @ 2010-01-10 22:46 ` Ben Hutchings 2010-01-10 22:58 ` Rafael J. Wysocki -1 siblings, 1 reply; 248+ messages in thread From: Ben Hutchings @ 2010-01-10 22:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller [-- Attachment #1: Type: text/plain, Size: 1452 bytes --] On Sun, 2010-01-10 at 23:27 +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 > Subject : Something has been broken in the network stack this week > Submitter : Delete This Account <speedyboyinovator@hotmail.com> > Date : 2009-12-12 13:06 (30 days old) You can mark this as Handled-by me, but I'm waiting for someone (anyone!) to verify that this can be solved by reverting changes to this driver made by commit 37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71. The submitter has disappeared. The patch is trivial: --- a/drivers/net/usb/cdc_ether.c +++ b/drivers/net/usb/cdc_ether.c @@ -419,7 +419,7 @@ static const struct driver_info cdc_info = { .description = "CDC Ethernet Device", - .flags = FLAG_ETHER | FLAG_LINK_INTR, + .flags = FLAG_ETHER, // .check_connect = cdc_check_connect, .bind = cdc_bind, .unbind = usbnet_cdc_unbind, --- END --- Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14791] Something has been broken in the network stack this week 2010-01-10 22:46 ` Ben Hutchings @ 2010-01-10 22:58 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:58 UTC (permalink / raw) To: Ben Hutchings Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller On Sunday 10 January 2010, Ben Hutchings wrote: > On Sun, 2010-01-10 at 23:27 +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 > > Subject : Something has been broken in the network stack this week > > Submitter : Delete This Account <speedyboyinovator@hotmail.com> > > Date : 2009-12-12 13:06 (30 days old) > > You can mark this as Handled-by me, but I'm waiting for someone > (anyone!) to verify that this can be solved by reverting changes to this > driver made by commit 37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71. The > submitter has disappeared. > > The patch is trivial: > > --- a/drivers/net/usb/cdc_ether.c > +++ b/drivers/net/usb/cdc_ether.c > @@ -419,7 +419,7 @@ > > static const struct driver_info cdc_info = { > .description = "CDC Ethernet Device", > - .flags = FLAG_ETHER | FLAG_LINK_INTR, > + .flags = FLAG_ETHER, > // .check_connect = cdc_check_connect, > .bind = cdc_bind, > .unbind = usbnet_cdc_unbind, > --- END --- Thanks, bug entry updated. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14791] Something has been broken in the network stack this week @ 2010-01-10 22:58 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:58 UTC (permalink / raw) To: Ben Hutchings Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller On Sunday 10 January 2010, Ben Hutchings wrote: > On Sun, 2010-01-10 at 23:27 +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 > > Subject : Something has been broken in the network stack this week > > Submitter : Delete This Account <speedyboyinovator-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> > > Date : 2009-12-12 13:06 (30 days old) > > You can mark this as Handled-by me, but I'm waiting for someone > (anyone!) to verify that this can be solved by reverting changes to this > driver made by commit 37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71. The > submitter has disappeared. > > The patch is trivial: > > --- a/drivers/net/usb/cdc_ether.c > +++ b/drivers/net/usb/cdc_ether.c > @@ -419,7 +419,7 @@ > > static const struct driver_info cdc_info = { > .description = "CDC Ethernet Device", > - .flags = FLAG_ETHER | FLAG_LINK_INTR, > + .flags = FLAG_ETHER, > // .check_connect = cdc_check_connect, > .bind = cdc_bind, > .unbind = usbnet_cdc_unbind, > --- END --- Thanks, bug entry updated. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [PATCH net-2.6] cdc_ether: Partially revert "usbnet: Set link down initially ..." 2010-01-10 22:27 ` Rafael J. Wysocki (?) (?) @ 2010-01-28 23:18 ` Ben Hutchings 2010-01-29 5:37 ` David Miller -1 siblings, 1 reply; 248+ messages in thread From: Ben Hutchings @ 2010-01-28 23:18 UTC (permalink / raw) To: David S. Miller; +Cc: netdev, avi.rozen Commit 37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71 ("usbnet: Set link down initially for drivers that update link state") changed the initial link state in cdc_ether and other drivers based on the understanding that the devices they support generate link change interrupts. However, this is optional in the CDC Ethernet protocol, and two users have reported in <http://bugzilla.kernel.org/show_bug.cgi?id=14791> that the link state for their devices remains down. Therefore, revert the change in cdc_ether. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Tested-by: Avi Rozen <avi.rozen@gmail.com> --- --- a/drivers/net/usb/cdc_ether.c +++ b/drivers/net/usb/cdc_ether.c @@ -419,7 +419,7 @@ static const struct driver_info cdc_info = { .description = "CDC Ethernet Device", - .flags = FLAG_ETHER | FLAG_LINK_INTR, + .flags = FLAG_ETHER, // .check_connect = cdc_check_connect, .bind = cdc_bind, .unbind = usbnet_cdc_unbind, -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH net-2.6] cdc_ether: Partially revert "usbnet: Set link down initially ..." 2010-01-28 23:18 ` [PATCH net-2.6] cdc_ether: Partially revert "usbnet: Set link down initially ..." Ben Hutchings @ 2010-01-29 5:37 ` David Miller 0 siblings, 0 replies; 248+ messages in thread From: David Miller @ 2010-01-29 5:37 UTC (permalink / raw) To: ben; +Cc: netdev, avi.rozen From: Ben Hutchings <ben@decadent.org.uk> Date: Thu, 28 Jan 2010 23:18:44 +0000 > Commit 37e8273cd30592d3a82bcb70cbb1bdc4eaeb6b71 ("usbnet: Set link down > initially for drivers that update link state") changed the initial link > state in cdc_ether and other drivers based on the understanding that the > devices they support generate link change interrupts. However, this is > optional in the CDC Ethernet protocol, and two users have reported in > <http://bugzilla.kernel.org/show_bug.cgi?id=14791> that the link state > for their devices remains down. Therefore, revert the change in > cdc_ether. > > Signed-off-by: Ben Hutchings <ben@decadent.org.uk> > Tested-by: Avi Rozen <avi.rozen@gmail.com> Applied, thanks a lot Ben. ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14792] Misdetection of the TV output 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Adam Jackson, Eric Anholt, Santi, Zhao Yakui This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792 Subject : Misdetection of the TV output Submitter : Santi <santi@agolina.net> Date : 2009-12-12 13:28 (30 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14792] Misdetection of the TV output @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Adam Jackson, Eric Anholt, Santi, Zhao Yakui This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792 Subject : Misdetection of the TV output Submitter : Santi <santi-wpr36wD7VxHR7s880joybQ@public.gmane.org> Date : 2009-12-12 13:28 (30 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14860] No DP-DVI output when laptop is docked 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Eric Anholt, Pär Andersson, ykzhao, Zhao Yakui This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14860 Subject : No DP-DVI output when laptop is docked Submitter : Pär Andersson <paran@lysator.liu.se> Date : 2009-12-21 21:02 (21 days old) Handled-By : ykzhao <yakui.zhao@intel.com> ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14860] No DP-DVI output when laptop is docked @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Eric Anholt, Pär Andersson, ykzhao, Zhao Yakui This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14860 Subject : No DP-DVI output when laptop is docked Submitter : Pär Andersson <paran-SamgB31n2u5IcsJQ0EH25Q@public.gmane.org> Date : 2009-12-21 21:02 (21 days old) Handled-By : ykzhao <yakui.zhao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14860] No DP-DVI output when laptop is docked 2010-01-10 22:32 ` Rafael J. Wysocki @ 2010-01-12 16:14 ` Pär Andersson -1 siblings, 0 replies; 248+ messages in thread From: Pär Andersson @ 2010-01-12 16:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Anholt, ykzhao [-- Attachment #1: Type: text/plain, Size: 390 bytes --] "Rafael J. Wysocki" <rjw@sisk.pl> writes: > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). It should still be listed. I was without Internet connection last week, but that have been fixed now so I will test the patch from ykzhao ASAP. Regards, Pär Andersson [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --] ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14860] No DP-DVI output when laptop is docked @ 2010-01-12 16:14 ` Pär Andersson 0 siblings, 0 replies; 248+ messages in thread From: Pär Andersson @ 2010-01-12 16:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Anholt, ykzhao [-- Attachment #1: Type: text/plain, Size: 411 bytes --] "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes: > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). It should still be listed. I was without Internet connection last week, but that have been fixed now so I will test the patch from ykzhao ASAP. Regards, Pär Andersson [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --] ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14860] No DP-DVI output when laptop is docked @ 2010-01-12 22:03 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-12 22:03 UTC (permalink / raw) To: Pär Andersson Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Anholt, ykzhao On Tuesday 12 January 2010, Pär Andersson wrote: > "Rafael J. Wysocki" <rjw@sisk.pl> writes: > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > It should still be listed. > > I was without Internet connection last week, but that have been fixed > now so I will test the patch from ykzhao ASAP. Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14860] No DP-DVI output when laptop is docked @ 2010-01-12 22:03 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-12 22:03 UTC (permalink / raw) To: Pär Andersson Cc: Linux Kernel Mailing List, Kernel Testers List, Eric Anholt, ykzhao On Tuesday 12 January 2010, Pär Andersson wrote: > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes: > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > It should still be listed. > > I was without Internet connection last week, but that have been fixed > now so I will test the patch from ykzhao ASAP. Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 2010-01-10 22:27 ` Rafael J. Wysocki ` (3 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 15:05 ` Luis R. Rodriguez -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Joshua Covington, Luis R. Rodriguez This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 Submitter : Joshua Covington <joshuacov@googlemail.com> Date : 2009-12-25 00:49 (17 days old) Handled-By : Luis R. Rodriguez <mcgrof@gmail.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 2010-01-10 22:32 ` [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 Rafael J. Wysocki @ 2010-01-11 15:05 ` Luis R. Rodriguez 0 siblings, 0 replies; 248+ messages in thread From: Luis R. Rodriguez @ 2010-01-11 15:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Joshua Covington On Sun, Jan 10, 2010 at 2:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). This should be closed now. > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 > Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 > Submitter : Joshua Covington <joshuacov@googlemail.com> > Date : 2009-12-25 00:49 (17 days old) > Handled-By : Luis R. Rodriguez <mcgrof@gmail.com> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 > > > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 @ 2010-01-11 15:05 ` Luis R. Rodriguez 0 siblings, 0 replies; 248+ messages in thread From: Luis R. Rodriguez @ 2010-01-11 15:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Joshua Covington On Sun, Jan 10, 2010 at 2:32 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). This should be closed now. > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 > Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 > Submitter : Joshua Covington <joshuacov@googlemail.com> > Date : 2009-12-25 00:49 (17 days old) > Handled-By : Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 > > > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 @ 2010-01-11 20:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:01 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Linux Kernel Mailing List, Kernel Testers List, Joshua Covington On Monday 11 January 2010, Luis R. Rodriguez wrote: > On Sun, Jan 10, 2010 at 2:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > This should be closed now. The patch linked below is not present in the Linus' tree at the moment AFAICS. Has it been fixed in a different way? Rafael > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 > > Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 > > Submitter : Joshua Covington <joshuacov@googlemail.com> > > Date : 2009-12-25 00:49 (17 days old) > > Handled-By : Luis R. Rodriguez <mcgrof@gmail.com> > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 @ 2010-01-11 20:01 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:01 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Linux Kernel Mailing List, Kernel Testers List, Joshua Covington On Monday 11 January 2010, Luis R. Rodriguez wrote: > On Sun, Jan 10, 2010 at 2:32 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > This should be closed now. The patch linked below is not present in the Linus' tree at the moment AFAICS. Has it been fixed in a different way? Rafael > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 > > Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 > > Submitter : Joshua Covington <joshuacov-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > Date : 2009-12-25 00:49 (17 days old) > > Handled-By : Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 @ 2010-01-11 20:05 ` Luis R. Rodriguez 0 siblings, 0 replies; 248+ messages in thread From: Luis R. Rodriguez @ 2010-01-11 20:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Joshua Covington On Mon, Jan 11, 2010 at 12:01 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Monday 11 January 2010, Luis R. Rodriguez wrote: >> On Sun, Jan 10, 2010 at 2:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: >> > This message has been generated automatically as a part of a report >> > of recent regressions. >> > >> > The following bug entry is on the current list of known regressions >> > from 2.6.32. Please verify if it still should be listed and let me know >> > (either way). >> >> This should be closed now. > > The patch linked below is not present in the Linus' tree at the moment AFAICS. > Has it been fixed in a different way? That patch is just a debug patch Michael worked on to actually get some message from ath5k as to what is happening instead of it dying without notice. A patch that actually fixes the issue would still be needed, and that remains to be determined. Luis ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 @ 2010-01-11 20:05 ` Luis R. Rodriguez 0 siblings, 0 replies; 248+ messages in thread From: Luis R. Rodriguez @ 2010-01-11 20:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Joshua Covington On Mon, Jan 11, 2010 at 12:01 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > On Monday 11 January 2010, Luis R. Rodriguez wrote: >> On Sun, Jan 10, 2010 at 2:32 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: >> > This message has been generated automatically as a part of a report >> > of recent regressions. >> > >> > The following bug entry is on the current list of known regressions >> > from 2.6.32. Â Please verify if it still should be listed and let me know >> > (either way). >> >> This should be closed now. > > The patch linked below is not present in the Linus' tree at the moment AFAICS. > Has it been fixed in a different way? That patch is just a debug patch Michael worked on to actually get some message from ath5k as to what is happening instead of it dying without notice. A patch that actually fixes the issue would still be needed, and that remains to be determined. Luis ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14899] reiserfs: inconsistent lock state 2010-01-10 22:27 ` Rafael J. Wysocki ` (4 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-10 22:49 ` Frederic Weisbecker -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alexander Beregalov, Frederic Weisbecker This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 Subject : reiserfs: inconsistent lock state Submitter : Alexander Beregalov <a.beregalov@gmail.com> Date : 2009-12-11 22:06 (31 days old) References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 Handled-By : Frederic Weisbecker <fweisbec@gmail.com> Patch : http://patchwork.kernel.org/patch/67256/ http://patchwork.kernel.org/patch/67257/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14899] reiserfs: inconsistent lock state 2010-01-10 22:32 ` [Bug #14899] reiserfs: inconsistent lock state Rafael J. Wysocki @ 2010-01-10 22:49 ` Frederic Weisbecker 0 siblings, 0 replies; 248+ messages in thread From: Frederic Weisbecker @ 2010-01-10 22:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Beregalov On Sun, Jan 10, 2010 at 11:32:53PM +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 > Subject : reiserfs: inconsistent lock state > Submitter : Alexander Beregalov <a.beregalov@gmail.com> > Date : 2009-12-11 22:06 (31 days old) > References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 > Handled-By : Frederic Weisbecker <fweisbec@gmail.com> > Patch : http://patchwork.kernel.org/patch/67256/ > http://patchwork.kernel.org/patch/67257/ The fix have been pulled upstream. Would be nice to have Alexander confirmation that it's really fixed though. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14899] reiserfs: inconsistent lock state @ 2010-01-10 22:49 ` Frederic Weisbecker 0 siblings, 0 replies; 248+ messages in thread From: Frederic Weisbecker @ 2010-01-10 22:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Beregalov On Sun, Jan 10, 2010 at 11:32:53PM +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 > Subject : reiserfs: inconsistent lock state > Submitter : Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2009-12-11 22:06 (31 days old) > References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 > Handled-By : Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Patch : http://patchwork.kernel.org/patch/67256/ > http://patchwork.kernel.org/patch/67257/ The fix have been pulled upstream. Would be nice to have Alexander confirmation that it's really fixed though. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14899] reiserfs: inconsistent lock state 2010-01-10 22:49 ` Frederic Weisbecker @ 2010-01-10 23:02 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 23:02 UTC (permalink / raw) To: Frederic Weisbecker Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Beregalov On Sunday 10 January 2010, Frederic Weisbecker wrote: > On Sun, Jan 10, 2010 at 11:32:53PM +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 > > Subject : reiserfs: inconsistent lock state > > Submitter : Alexander Beregalov <a.beregalov@gmail.com> > > Date : 2009-12-11 22:06 (31 days old) > > References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 > > Handled-By : Frederic Weisbecker <fweisbec@gmail.com> > > Patch : http://patchwork.kernel.org/patch/67256/ > > http://patchwork.kernel.org/patch/67257/ > > > > The fix have been pulled upstream. Would be nice to have Alexander > confirmation that it's really fixed though. Well, I guess he can reopen the bug if the problem is still there. Closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14899] reiserfs: inconsistent lock state @ 2010-01-10 23:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 23:02 UTC (permalink / raw) To: Frederic Weisbecker Cc: Linux Kernel Mailing List, Kernel Testers List, Alexander Beregalov On Sunday 10 January 2010, Frederic Weisbecker wrote: > On Sun, Jan 10, 2010 at 11:32:53PM +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 > > Subject : reiserfs: inconsistent lock state > > Submitter : Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Date : 2009-12-11 22:06 (31 days old) > > References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 > > Handled-By : Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Patch : http://patchwork.kernel.org/patch/67256/ > > http://patchwork.kernel.org/patch/67257/ > > > > The fix have been pulled upstream. Would be nice to have Alexander > confirmation that it's really fixed though. Well, I guess he can reopen the bug if the problem is still there. Closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14899] reiserfs: inconsistent lock state 2010-01-10 22:49 ` Frederic Weisbecker @ 2010-01-10 23:16 ` Alexander Beregalov -1 siblings, 0 replies; 248+ messages in thread From: Alexander Beregalov @ 2010-01-10 23:16 UTC (permalink / raw) To: Frederic Weisbecker Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List 2010/1/11 Frederic Weisbecker <fweisbec@gmail.com>: > On Sun, Jan 10, 2010 at 11:32:53PM +0100, Rafael J. Wysocki wrote: >> This message has been generated automatically as a part of a report >> of recent regressions. >> >> The following bug entry is on the current list of known regressions >> from 2.6.32. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 >> Subject : reiserfs: inconsistent lock state >> Submitter : Alexander Beregalov <a.beregalov@gmail.com> >> Date : 2009-12-11 22:06 (31 days old) >> References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 >> Handled-By : Frederic Weisbecker <fweisbec@gmail.com> >> Patch : http://patchwork.kernel.org/patch/67256/ >> http://patchwork.kernel.org/patch/67257/ > > > > The fix have been pulled upstream. Would be nice to have Alexander > confirmation that it's really fixed though. Yes, all warnings have disappeared. Thanks a lot. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14899] reiserfs: inconsistent lock state @ 2010-01-10 23:16 ` Alexander Beregalov 0 siblings, 0 replies; 248+ messages in thread From: Alexander Beregalov @ 2010-01-10 23:16 UTC (permalink / raw) To: Frederic Weisbecker Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List 2010/1/11 Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: > On Sun, Jan 10, 2010 at 11:32:53PM +0100, Rafael J. Wysocki wrote: >> This message has been generated automatically as a part of a report >> of recent regressions. >> >> The following bug entry is on the current list of known regressions >> from 2.6.32. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 >> Subject : reiserfs: inconsistent lock state >> Submitter : Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> Date : 2009-12-11 22:06 (31 days old) >> References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 >> Handled-By : Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> Patch : http://patchwork.kernel.org/patch/67256/ >> http://patchwork.kernel.org/patch/67257/ > > > > The fix have been pulled upstream. Would be nice to have Alexander > confirmation that it's really fixed though. Yes, all warnings have disappeared. Thanks a lot. ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14859] System timer firing too much without cause 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Shawn Starr This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 Subject : System timer firing too much without cause Submitter : Shawn Starr <shawn.starr@rogers.com> Date : 2009-12-21 19:16 (21 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14859] System timer firing too much without cause @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Shawn Starr This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 Subject : System timer firing too much without cause Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> Date : 2009-12-21 19:16 (21 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14859] System timer firing too much without cause 2010-01-10 22:32 ` Rafael J. Wysocki (?) @ 2010-01-11 3:22 ` Shawn Starr [not found] ` <201001102222.19700.shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> -1 siblings, 1 reply; 248+ messages in thread From: Shawn Starr @ 2010-01-11 3:22 UTC (permalink / raw) To: Rafael J. Wysocki, Kernel Testers List On Sunday 10 January 2010 17:32:53 Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 > Subject : System timer firing too much without cause > Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> > Date : 2009-12-21 19:16 (21 days old) Yes please keep on regression list. Thanks, Shawn. ^ permalink raw reply [flat|nested] 248+ messages in thread
[parent not found: <201001102222.19700.shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org>]
* Re: [Bug #14859] System timer firing too much without cause [not found] ` <201001102222.19700.shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> @ 2010-01-11 19:59 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 19:59 UTC (permalink / raw) To: Shawn Starr; +Cc: Kernel Testers List On Monday 11 January 2010, Shawn Starr wrote: > On Sunday 10 January 2010 17:32:53 Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 > > Subject : System timer firing too much without cause > > Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> > > Date : 2009-12-21 19:16 (21 days old) > > Yes please keep on regression list. OK, thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14859] System timer firing too much without cause 2010-01-10 22:32 ` Rafael J. Wysocki (?) (?) @ 2010-01-11 3:28 ` Shawn Starr -1 siblings, 0 replies; 248+ messages in thread From: Shawn Starr @ 2010-01-11 3:28 UTC (permalink / raw) To: Rafael J. Wysocki, Kernel Testers List On Sunday 10 January 2010 17:32:53 Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 > Subject : System timer firing too much without cause > Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> > Date : 2009-12-21 19:16 (21 days old) Yes please keep on regression list. Thanks, Shawn. ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14924] Weird hard hangs when rendering 'some' web-sites in Firefox 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, David This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14924 Subject : Weird hard hangs when rendering 'some' web-sites in Firefox Submitter : David <david@unsolicited.net> Date : 2009-12-21 21:53 (21 days old) References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14924] Weird hard hangs when rendering 'some' web-sites in Firefox @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, David This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14924 Subject : Weird hard hangs when rendering 'some' web-sites in Firefox Submitter : David <david-Os2QIKb4eqJd3aXB8m+yKQ@public.gmane.org> Date : 2009-12-21 21:53 (21 days old) References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build 2010-01-10 22:27 ` Rafael J. Wysocki ` (7 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 1:36 ` Jonathan Nieder -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Jonathan Nieder, Michael Tokarev, Michal Marek, Oliver Hartkopp, Sam Ravnborg This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 Subject : Commit "kbuild: fix bzImage build for x86" breaks build Submitter : Oliver Hartkopp <oliver@hartkopp.net> Date : 2009-12-19 19:21 (23 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 http://marc.info/?l=linux-kernel&m=126114565103300&w=4 http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 Handled-By : Jonathan Nieder <jrnieder@gmail.com> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 http://patchwork.kernel.org/patch/71957/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build 2010-01-10 22:32 ` [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build Rafael J. Wysocki @ 2010-01-11 1:36 ` Jonathan Nieder 0 siblings, 0 replies; 248+ messages in thread From: Jonathan Nieder @ 2010-01-11 1:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Michal Marek, Oliver Hartkopp, Sam Ravnborg Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 > Subject : Commit "kbuild: fix bzImage build for x86" breaks build > Submitter : Oliver Hartkopp <oliver@hartkopp.net> > Date : 2009-12-19 19:21 (23 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 > References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 > http://marc.info/?l=linux-kernel&m=126114565103300&w=4 > http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 > Handled-By : Jonathan Nieder <jrnieder@gmail.com> > Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 > http://patchwork.kernel.org/patch/71957/ I am using the patch without problems, but it is not in the mainline as of v2.6.33-rc3-git3. So please do keep the bug listed. Thanks, Jonathan ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-11 1:36 ` Jonathan Nieder 0 siblings, 0 replies; 248+ messages in thread From: Jonathan Nieder @ 2010-01-11 1:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Michal Marek, Oliver Hartkopp, Sam Ravnborg Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 > Subject : Commit "kbuild: fix bzImage build for x86" breaks build > Submitter : Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> > Date : 2009-12-19 19:21 (23 days old) > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 > References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 > http://marc.info/?l=linux-kernel&m=126114565103300&w=4 > http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 > Handled-By : Jonathan Nieder <jrnieder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 > http://patchwork.kernel.org/patch/71957/ I am using the patch without problems, but it is not in the mainline as of v2.6.33-rc3-git3. So please do keep the bug listed. Thanks, Jonathan ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-11 20:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:02 UTC (permalink / raw) To: Jonathan Nieder Cc: Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Michal Marek, Oliver Hartkopp, Sam Ravnborg On Monday 11 January 2010, Jonathan Nieder wrote: > Rafael J. Wysocki wrote: > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 > > Subject : Commit "kbuild: fix bzImage build for x86" breaks build > > Submitter : Oliver Hartkopp <oliver@hartkopp.net> > > Date : 2009-12-19 19:21 (23 days old) > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 > > References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 > > http://marc.info/?l=linux-kernel&m=126114565103300&w=4 > > http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 > > Handled-By : Jonathan Nieder <jrnieder@gmail.com> > > Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 > > http://patchwork.kernel.org/patch/71957/ > > I am using the patch without problems, but it is not in the mainline > as of v2.6.33-rc3-git3. So please do keep the bug listed. I will, thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-11 20:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:02 UTC (permalink / raw) To: Jonathan Nieder Cc: Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Michal Marek, Oliver Hartkopp, Sam Ravnborg On Monday 11 January 2010, Jonathan Nieder wrote: > Rafael J. Wysocki wrote: > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 > > Subject : Commit "kbuild: fix bzImage build for x86" breaks build > > Submitter : Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> > > Date : 2009-12-19 19:21 (23 days old) > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 > > References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 > > http://marc.info/?l=linux-kernel&m=126114565103300&w=4 > > http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 > > Handled-By : Jonathan Nieder <jrnieder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 > > http://patchwork.kernel.org/patch/71957/ > > I am using the patch without problems, but it is not in the mainline > as of v2.6.33-rc3-git3. So please do keep the bug listed. I will, thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build 2010-01-11 20:02 ` Rafael J. Wysocki (?) @ 2010-01-12 9:01 ` Oliver Hartkopp -1 siblings, 0 replies; 248+ messages in thread From: Oliver Hartkopp @ 2010-01-12 9:01 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jonathan Nieder, Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Michal Marek, Sam Ravnborg Rafael J. Wysocki wrote: > On Monday 11 January 2010, Jonathan Nieder wrote: >> Rafael J. Wysocki wrote: >> >>> The following bug entry is on the current list of known regressions >>> from 2.6.32. Please verify if it still should be listed and let me know >>> (either way). >>> >>> >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 >>> Subject : Commit "kbuild: fix bzImage build for x86" breaks build >>> Submitter : Oliver Hartkopp <oliver@hartkopp.net> >>> Date : 2009-12-19 19:21 (23 days old) >>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 >>> References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 >>> http://marc.info/?l=linux-kernel&m=126114565103300&w=4 >>> http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 >>> Handled-By : Jonathan Nieder <jrnieder@gmail.com> >>> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 >>> http://patchwork.kernel.org/patch/71957/ >> I am using the patch without problems, but it is not in the mainline >> as of v2.6.33-rc3-git3. So please do keep the bug listed. > > I will, thanks for the update. I just tested the patch again - and it fixes the problem. You can add my Tested-by: Oliver Hartkopp <oliver@hartkopp.net> if you like. Thanks, Oliver ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-13 12:33 ` Michal Marek 0 siblings, 0 replies; 248+ messages in thread From: Michal Marek @ 2010-01-13 12:33 UTC (permalink / raw) To: Jonathan Nieder Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Oliver Hartkopp, Sam Ravnborg On 11.1.2010 02:36, Jonathan Nieder wrote: > Rafael J. Wysocki wrote: > >> The following bug entry is on the current list of known regressions >> from 2.6.32. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 >> Subject : Commit "kbuild: fix bzImage build for x86" breaks build >> Submitter : Oliver Hartkopp <oliver@hartkopp.net> >> Date : 2009-12-19 19:21 (23 days old) >> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 >> References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 >> http://marc.info/?l=linux-kernel&m=126114565103300&w=4 >> http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 >> Handled-By : Jonathan Nieder <jrnieder@gmail.com> >> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 >> http://patchwork.kernel.org/patch/71957/ > > I am using the patch without problems, but it is not in the mainline > as of v2.6.33-rc3-git3. So please do keep the bug listed. I resent the pull request (http://lkml.org/lkml/2010/1/13/194), let's see. Michal ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-13 12:33 ` Michal Marek 0 siblings, 0 replies; 248+ messages in thread From: Michal Marek @ 2010-01-13 12:33 UTC (permalink / raw) To: Jonathan Nieder Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Oliver Hartkopp, Sam Ravnborg On 11.1.2010 02:36, Jonathan Nieder wrote: > Rafael J. Wysocki wrote: > >> The following bug entry is on the current list of known regressions >> from 2.6.32. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 >> Subject : Commit "kbuild: fix bzImage build for x86" breaks build >> Submitter : Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> >> Date : 2009-12-19 19:21 (23 days old) >> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 >> References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 >> http://marc.info/?l=linux-kernel&m=126114565103300&w=4 >> http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 >> Handled-By : Jonathan Nieder <jrnieder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 >> http://patchwork.kernel.org/patch/71957/ > > I am using the patch without problems, but it is not in the mainline > as of v2.6.33-rc3-git3. So please do keep the bug listed. I resent the pull request (http://lkml.org/lkml/2010/1/13/194), let's see. Michal ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-14 11:05 ` Michal Marek 0 siblings, 0 replies; 248+ messages in thread From: Michal Marek @ 2010-01-14 11:05 UTC (permalink / raw) To: Jonathan Nieder Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Oliver Hartkopp, Sam Ravnborg On 13.1.2010 13:33, Michal Marek wrote: > On 11.1.2010 02:36, Jonathan Nieder wrote: >> Rafael J. Wysocki wrote: >> >>> The following bug entry is on the current list of known regressions >>> from 2.6.32. Please verify if it still should be listed and let me know >>> (either way). >>> >>> >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 >>> Subject : Commit "kbuild: fix bzImage build for x86" breaks build >>> Submitter : Oliver Hartkopp <oliver@hartkopp.net> >>> Date : 2009-12-19 19:21 (23 days old) >>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 >>> References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 >>> http://marc.info/?l=linux-kernel&m=126114565103300&w=4 >>> http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 >>> Handled-By : Jonathan Nieder <jrnieder@gmail.com> >>> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 >>> http://patchwork.kernel.org/patch/71957/ >> >> I am using the patch without problems, but it is not in the mainline >> as of v2.6.33-rc3-git3. So please do keep the bug listed. > > I resent the pull request (http://lkml.org/lkml/2010/1/13/194), let's see. FYI: commit 04e9e5c7659ee07f0387ddb663913fadcca88d5f Merge: cedabed 0710520 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Jan 13 16:09:59 2010 -0800 Merge branch 'for-33' of git://repo.or.cz/linux-kbuild * 'for-33' of git://repo.or.cz/linux-kbuild: Makefile: do not override LC_CTYPE kbuild: really fix bzImage build with non-bash sh Michal ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-14 11:05 ` Michal Marek 0 siblings, 0 replies; 248+ messages in thread From: Michal Marek @ 2010-01-14 11:05 UTC (permalink / raw) To: Jonathan Nieder Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Oliver Hartkopp, Sam Ravnborg On 13.1.2010 13:33, Michal Marek wrote: > On 11.1.2010 02:36, Jonathan Nieder wrote: >> Rafael J. Wysocki wrote: >> >>> The following bug entry is on the current list of known regressions >>> from 2.6.32. Please verify if it still should be listed and let me know >>> (either way). >>> >>> >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 >>> Subject : Commit "kbuild: fix bzImage build for x86" breaks build >>> Submitter : Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> >>> Date : 2009-12-19 19:21 (23 days old) >>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 >>> References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 >>> http://marc.info/?l=linux-kernel&m=126114565103300&w=4 >>> http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 >>> Handled-By : Jonathan Nieder <jrnieder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >>> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 >>> http://patchwork.kernel.org/patch/71957/ >> >> I am using the patch without problems, but it is not in the mainline >> as of v2.6.33-rc3-git3. So please do keep the bug listed. > > I resent the pull request (http://lkml.org/lkml/2010/1/13/194), let's see. FYI: commit 04e9e5c7659ee07f0387ddb663913fadcca88d5f Merge: cedabed 0710520 Author: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Date: Wed Jan 13 16:09:59 2010 -0800 Merge branch 'for-33' of git://repo.or.cz/linux-kbuild * 'for-33' of git://repo.or.cz/linux-kbuild: Makefile: do not override LC_CTYPE kbuild: really fix bzImage build with non-bash sh Michal ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-14 20:35 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-14 20:35 UTC (permalink / raw) To: Michal Marek Cc: Jonathan Nieder, Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Oliver Hartkopp, Sam Ravnborg On Thursday 14 January 2010, Michal Marek wrote: > On 13.1.2010 13:33, Michal Marek wrote: > > On 11.1.2010 02:36, Jonathan Nieder wrote: > >> Rafael J. Wysocki wrote: > >> > >>> The following bug entry is on the current list of known regressions > >>> from 2.6.32. Please verify if it still should be listed and let me know > >>> (either way). > >>> > >>> > >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 > >>> Subject : Commit "kbuild: fix bzImage build for x86" breaks build > >>> Submitter : Oliver Hartkopp <oliver@hartkopp.net> > >>> Date : 2009-12-19 19:21 (23 days old) > >>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 > >>> References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 > >>> http://marc.info/?l=linux-kernel&m=126114565103300&w=4 > >>> http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 > >>> Handled-By : Jonathan Nieder <jrnieder@gmail.com> > >>> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 > >>> http://patchwork.kernel.org/patch/71957/ > >> > >> I am using the patch without problems, but it is not in the mainline > >> as of v2.6.33-rc3-git3. So please do keep the bug listed. > > > > I resent the pull request (http://lkml.org/lkml/2010/1/13/194), let's see. > > FYI: > commit 04e9e5c7659ee07f0387ddb663913fadcca88d5f > Merge: cedabed 0710520 > Author: Linus Torvalds <torvalds@linux-foundation.org> > Date: Wed Jan 13 16:09:59 2010 -0800 > > Merge branch 'for-33' of git://repo.or.cz/linux-kbuild > > * 'for-33' of git://repo.or.cz/linux-kbuild: > Makefile: do not override LC_CTYPE > kbuild: really fix bzImage build with non-bash sh Thanks, closing. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build @ 2010-01-14 20:35 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-14 20:35 UTC (permalink / raw) To: Michal Marek Cc: Jonathan Nieder, Linux Kernel Mailing List, Kernel Testers List, Michael Tokarev, Oliver Hartkopp, Sam Ravnborg On Thursday 14 January 2010, Michal Marek wrote: > On 13.1.2010 13:33, Michal Marek wrote: > > On 11.1.2010 02:36, Jonathan Nieder wrote: > >> Rafael J. Wysocki wrote: > >> > >>> The following bug entry is on the current list of known regressions > >>> from 2.6.32. Please verify if it still should be listed and let me know > >>> (either way). > >>> > >>> > >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 > >>> Subject : Commit "kbuild: fix bzImage build for x86" breaks build > >>> Submitter : Oliver Hartkopp <oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> > >>> Date : 2009-12-19 19:21 (23 days old) > >>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 > >>> References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 > >>> http://marc.info/?l=linux-kernel&m=126114565103300&w=4 > >>> http://marc.info/?l=linux-kbuild&m=126202819526623&w=2 > >>> Handled-By : Jonathan Nieder <jrnieder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > >>> Patch : http://thread.gmane.org/gmane.linux.kbuild.devel/4313/focus=4319 > >>> http://patchwork.kernel.org/patch/71957/ > >> > >> I am using the patch without problems, but it is not in the mainline > >> as of v2.6.33-rc3-git3. So please do keep the bug listed. > > > > I resent the pull request (http://lkml.org/lkml/2010/1/13/194), let's see. > > FYI: > commit 04e9e5c7659ee07f0387ddb663913fadcca88d5f > Merge: cedabed 0710520 > Author: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > Date: Wed Jan 13 16:09:59 2010 -0800 > > Merge branch 'for-33' of git://repo.or.cz/linux-kbuild > > * 'for-33' of git://repo.or.cz/linux-kbuild: > Makefile: do not override LC_CTYPE > kbuild: really fix bzImage build with non-bash sh Thanks, closing. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14934] kernel crash during boot 2010-01-10 22:27 ` Rafael J. Wysocki ` (8 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, werner This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14934 Subject : kernel crash during boot Submitter : werner <w.landgraf@ru.ru> Date : 2009-12-25 5:37 (17 days old) References : http://marc.info/?l=linux-kernel&m=126171951030608&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14937] WARNING: at kernel/lockdep.c:2830 2010-01-10 22:27 ` Rafael J. Wysocki ` (9 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Grant Wilson This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937 Subject : WARNING: at kernel/lockdep.c:2830 Submitter : Grant Wilson <grant.wilson@zen.co.uk> Date : 2009-12-27 13:35 (15 days old) References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14925] sky2 panic under load 2010-01-10 22:27 ` Rafael J. Wysocki ` (10 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 0:36 ` Berck E. Nash -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Berck E. Nash, Berck Nash, Daniel Hazelton, Michael Breuer, netdev@vger.kernel.org, Stephen Hemminger This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14925 Subject : sky2 panic under load Submitter : Berck E. Nash <flyboy@gmail.com> Date : 2009-12-21 23:52 (21 days old) References : http://marc.info/?l=linux-kernel&m=126143955730347&w=4 http://marc.info/?l=linux-kernel&m=126160893126548&w=4 Handled-By : Stephen Hemminger <shemminger@vyatta.com> ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-10 22:32 ` [Bug #14925] sky2 panic under load Rafael J. Wysocki @ 2010-01-11 0:36 ` Berck E. Nash 2010-01-11 13:26 ` Jarek Poplawski 2010-01-11 14:03 ` Mike McCormack 0 siblings, 2 replies; 248+ messages in thread From: Berck E. Nash @ 2010-01-11 0:36 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: netdev, Jarek Poplawski Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14925 > Subject : sky2 panic under load > Submitter : Berck E. Nash <flyboy@gmail.com> > Date : 2009-12-21 23:52 (21 days old) > References : http://marc.info/?l=linux-kernel&m=126143955730347&w=4 > http://marc.info/?l=linux-kernel&m=126160893126548&w=4 > Handled-By : Stephen Hemminger <shemminger@vyatta.com> The patch attached to the bug report did not fix the problem, but I'm fairly certain that this one from Jarek P. did: During TX timeout procedure dev could be awoken too early, e.g. by sky2_complete_tx() called from sky2_down(). Then sky2_xmit_frame() can run while buffers are freed causing an oops. This patch fixes it by adding netif_device_present() test in sky2_tx_complete(). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14925 With debugging by: Mike McCormack <mikem@ring3k.org> Reported-by: Berck E. Nash <flyboy@gmail.com> Tested-by: Berck E. Nash <flyboy@gmail.com> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> --- drivers/net/sky2.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index 1c01b96..7650f73 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -1844,7 +1844,8 @@ static void sky2_tx_complete(struct sky2_port *sky2, u16 done) sky2->tx_cons = idx; smp_mb(); - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) + /* Wake unless it's detached, and called e.g. from sky2_down() */ + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4 && netif_device_present(dev)) netif_wake_queue(dev); } ^ permalink raw reply related [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 0:36 ` Berck E. Nash @ 2010-01-11 13:26 ` Jarek Poplawski 2010-01-11 19:32 ` Rafael J. Wysocki 2010-01-11 14:03 ` Mike McCormack 1 sibling, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-11 13:26 UTC (permalink / raw) To: Berck E. Nash; +Cc: Rafael J. Wysocki, netdev On Sun, Jan 10, 2010 at 05:36:46PM -0700, Berck E. Nash wrote: > Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). BTW, I don't know why Berck didn't experience such a panic before 2.6.32, but seems not a regression to me. There might be new/more sky2 TX timeouts which trigger this panic and would make a real regression. Cheers, Jarek P. > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14925 > > Subject : sky2 panic under load > > Submitter : Berck E. Nash <flyboy@gmail.com> > > Date : 2009-12-21 23:52 (21 days old) > > References : http://marc.info/?l=linux-kernel&m=126143955730347&w=4 > > http://marc.info/?l=linux-kernel&m=126160893126548&w=4 > > Handled-By : Stephen Hemminger <shemminger@vyatta.com> > > The patch attached to the bug report did not fix the problem, but I'm > fairly certain that this one from Jarek P. did: > > During TX timeout procedure dev could be awoken too early, e.g. by > sky2_complete_tx() called from sky2_down(). Then sky2_xmit_frame() > can run while buffers are freed causing an oops. This patch fixes it > by adding netif_device_present() test in sky2_tx_complete(). > > Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14925 > > With debugging by: Mike McCormack <mikem@ring3k.org> > > Reported-by: Berck E. Nash <flyboy@gmail.com> > Tested-by: Berck E. Nash <flyboy@gmail.com> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> > > --- > > drivers/net/sky2.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c > index 1c01b96..7650f73 100644 > --- a/drivers/net/sky2.c > +++ b/drivers/net/sky2.c > @@ -1844,7 +1844,8 @@ static void sky2_tx_complete(struct sky2_port > *sky2, u16 done) > sky2->tx_cons = idx; > smp_mb(); > > - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > + /* Wake unless it's detached, and called e.g. from sky2_down() */ > + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4 && netif_device_present(dev)) > netif_wake_queue(dev); > } > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 13:26 ` Jarek Poplawski @ 2010-01-11 19:32 ` Rafael J. Wysocki 2010-01-11 20:31 ` Jarek Poplawski 0 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 19:32 UTC (permalink / raw) To: Jarek Poplawski; +Cc: Berck E. Nash, netdev On Monday 11 January 2010, Jarek Poplawski wrote: > On Sun, Jan 10, 2010 at 05:36:46PM -0700, Berck E. Nash wrote: > > Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > BTW, I don't know why Berck didn't experience such a panic before > 2.6.32, but seems not a regression to me. There might be new/more sky2 > TX timeouts which trigger this panic and would make a real regression. Even if the code has always been broken, but it's only become visible after 2.6.32, that still counts as a regression IMO, because now the users are affected who weren't before. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 19:32 ` Rafael J. Wysocki @ 2010-01-11 20:31 ` Jarek Poplawski 2010-01-11 20:50 ` Rafael J. Wysocki 2010-01-11 21:02 ` Berck E. Nash 0 siblings, 2 replies; 248+ messages in thread From: Jarek Poplawski @ 2010-01-11 20:31 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Berck E. Nash, netdev On Mon, Jan 11, 2010 at 08:32:24PM +0100, Rafael J. Wysocki wrote: > On Monday 11 January 2010, Jarek Poplawski wrote: > > On Sun, Jan 10, 2010 at 05:36:46PM -0700, Berck E. Nash wrote: > > > Rafael J. Wysocki wrote: > > > > This message has been generated automatically as a part of a report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > (either way). > > > > BTW, I don't know why Berck didn't experience such a panic before > > 2.6.32, but seems not a regression to me. There might be new/more sky2 > > TX timeouts which trigger this panic and would make a real regression. > > Even if the code has always been broken, but it's only become visible after > 2.6.32, that still counts as a regression IMO, because now the users are > affected who weren't before. Right, but: 1) someone with a similar but older problem might be mislead a fix is not for them; 2) someone with exactly this one problem (i.e. Berck ;-) might be mislead "no oops" is enough, while their linux might be still worse than before. (So I intended Berck to re-consider or even re-check this problem wrt. 2.6.31, and maybe even reporting another regression.) Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 20:31 ` Jarek Poplawski @ 2010-01-11 20:50 ` Rafael J. Wysocki 2010-01-11 21:02 ` Berck E. Nash 1 sibling, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:50 UTC (permalink / raw) To: Jarek Poplawski; +Cc: Berck E. Nash, netdev On Monday 11 January 2010, Jarek Poplawski wrote: > On Mon, Jan 11, 2010 at 08:32:24PM +0100, Rafael J. Wysocki wrote: > > On Monday 11 January 2010, Jarek Poplawski wrote: > > > On Sun, Jan 10, 2010 at 05:36:46PM -0700, Berck E. Nash wrote: > > > > Rafael J. Wysocki wrote: > > > > > This message has been generated automatically as a part of a report > > > > > of recent regressions. > > > > > > > > > > The following bug entry is on the current list of known regressions > > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > > (either way). > > > > > > BTW, I don't know why Berck didn't experience such a panic before > > > 2.6.32, but seems not a regression to me. There might be new/more sky2 > > > TX timeouts which trigger this panic and would make a real regression. > > > > Even if the code has always been broken, but it's only become visible after > > 2.6.32, that still counts as a regression IMO, because now the users are > > affected who weren't before. > > Right, but: > 1) someone with a similar but older problem might be mislead a fix is > not for them; Not if the fix changelog mentions the older kernels explicitly. > 2) someone with exactly this one problem (i.e. Berck ;-) might be > mislead "no oops" is enough, while their linux might be still worse > than before. (So I intended Berck to re-consider or even re-check > this problem wrt. 2.6.31, and maybe even reporting another > regression.) Yes, rechecking the problem with 2.6.31 would be useful. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 20:31 ` Jarek Poplawski 2010-01-11 20:50 ` Rafael J. Wysocki @ 2010-01-11 21:02 ` Berck E. Nash 2010-01-11 21:47 ` Jarek Poplawski 1 sibling, 1 reply; 248+ messages in thread From: Berck E. Nash @ 2010-01-11 21:02 UTC (permalink / raw) To: Jarek Poplawski; +Cc: Rafael J. Wysocki, netdev Jarek Poplawski wrote: > On Mon, Jan 11, 2010 at 08:32:24PM +0100, Rafael J. Wysocki wrote: >> On Monday 11 January 2010, Jarek Poplawski wrote: >>> On Sun, Jan 10, 2010 at 05:36:46PM -0700, Berck E. Nash wrote: >>>> Rafael J. Wysocki wrote: >>>>> This message has been generated automatically as a part of a report >>>>> of recent regressions. >>>>> >>>>> The following bug entry is on the current list of known regressions >>>>> from 2.6.32. Please verify if it still should be listed and let me know >>>>> (either way). >>> BTW, I don't know why Berck didn't experience such a panic before >>> 2.6.32, but seems not a regression to me. There might be new/more sky2 >>> TX timeouts which trigger this panic and would make a real regression. >> Even if the code has always been broken, but it's only become visible after >> 2.6.32, that still counts as a regression IMO, because now the users are >> affected who weren't before. > > Right, but: > 1) someone with a similar but older problem might be mislead a fix is > not for them; > 2) someone with exactly this one problem (i.e. Berck ;-) might be > mislead "no oops" is enough, while their linux might be still worse > than before. (So I intended Berck to re-consider or even re-check > this problem wrt. 2.6.31, and maybe even reporting another > regression.) Well, the problem with this bug is how hard it is for me to reproduce. I'm willing to admit that just because I never got it before 2.6.32 isn't proof that it wasn't there in 2.6.31. But it's a regression somewhere along the line, since I've been using this hardware for over 3 years now. There were lots of bugs in the sky2 driver years ago, but for the last 2+ years or so, I haven't had any trouble at all until now. The bug only shows up for me with bittorrent traffic. I also use the same adapter to transfer backups over the network from several computers, and that doesn't trigger it... I used 2.6.31 for however long it was the current stable, and I never got a crash with it. After I got several crashes in 2.6.32, I reverted to 2.6.31 until Jarek sent this patch that seems to have fixed it. I've never gotten it to crash in 2.6.31, so I'm pretty sure it's a 2.6.32 regression, but I can't prove it. I would love to do more testing, but since I can't reproduce the bug at will, I'm not really sure what to offer? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 21:02 ` Berck E. Nash @ 2010-01-11 21:47 ` Jarek Poplawski 0 siblings, 0 replies; 248+ messages in thread From: Jarek Poplawski @ 2010-01-11 21:47 UTC (permalink / raw) To: Berck E. Nash; +Cc: Rafael J. Wysocki, netdev On Mon, Jan 11, 2010 at 02:02:40PM -0700, Berck E. Nash wrote: > Jarek Poplawski wrote: > > 2) someone with exactly this one problem (i.e. Berck ;-) might be > > mislead "no oops" is enough, while their linux might be still worse > > than before. (So I intended Berck to re-consider or even re-check > > this problem wrt. 2.6.31, and maybe even reporting another > > regression.) > > Well, the problem with this bug is how hard it is for me to reproduce. > I'm willing to admit that just because I never got it before 2.6.32 > isn't proof that it wasn't there in 2.6.31. But it's a regression > somewhere along the line, since I've been using this hardware for over 3 > years now. There were lots of bugs in the sky2 driver years ago, but > for the last 2+ years or so, I haven't had any trouble at all until now. > > The bug only shows up for me with bittorrent traffic. I also use the > same adapter to transfer backups over the network from several > computers, and that doesn't trigger it... > > I used 2.6.31 for however long it was the current stable, and I never > got a crash with it. After I got several crashes in 2.6.32, I reverted > to 2.6.31 until Jarek sent this patch that seems to have fixed it. I've > never gotten it to crash in 2.6.31, so I'm pretty sure it's a 2.6.32 > regression, but I can't prove it. > > I would love to do more testing, but since I can't reproduce the bug at > will, I'm not really sure what to offer? I mainly thought about looking at the logs during such bittorrent to compare if there is any visible change in "sky2 eth0: disabling interface"/"sky2 eth0: enabling interface" etc. frequency between 2.6.31 and 2.6.32. Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 0:36 ` Berck E. Nash 2010-01-11 13:26 ` Jarek Poplawski @ 2010-01-11 14:03 ` Mike McCormack 2010-01-11 16:45 ` Stephen Hemminger 1 sibling, 1 reply; 248+ messages in thread From: Mike McCormack @ 2010-01-11 14:03 UTC (permalink / raw) To: Berck E. Nash Cc: Rafael J. Wysocki, netdev, Jarek Poplawski, Stephen Hemminger Berck E. Nash wrote: > > During TX timeout procedure dev could be awoken too early, e.g. by > sky2_complete_tx() called from sky2_down(). Then sky2_xmit_frame() > can run while buffers are freed causing an oops. This patch fixes it > by adding netif_device_present() test in sky2_tx_complete(). > > Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14925 > > With debugging by: Mike McCormack <mikem@ring3k.org> > > Reported-by: Berck E. Nash <flyboy@gmail.com> > Tested-by: Berck E. Nash <flyboy@gmail.com> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> > > --- > > drivers/net/sky2.c | 3 ++- Perhaps only sky2_tx_done should wake the queue? Does the patch below fix the problem too? thanks, Mike Subject: [PATCH] sky2: Don't wake queue in sky2_tx_complete() We should only wake the tx queue on completion of transmits, not after cleaning the tx ring. Signed-off-by: Mike McCormack <mikem@ring3k.org> --- drivers/net/sky2.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index 93d9635..6d9111d 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -1843,9 +1843,6 @@ static void sky2_tx_complete(struct sky2_port *sky2, u16 done) sky2->tx_cons = idx; smp_mb(); - - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) - netif_wake_queue(dev); } static void sky2_tx_reset(struct sky2_hw *hw, unsigned port) @@ -2416,8 +2413,11 @@ static inline void sky2_tx_done(struct net_device *dev, u16 last) { struct sky2_port *sky2 = netdev_priv(dev); - if (netif_running(dev)) + if (netif_running(dev)) { sky2_tx_complete(sky2, last); + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) + netif_wake_queue(dev); + } } static inline void sky2_skb_rx(const struct sky2_port *sky2, -- 1.5.6.5 ^ permalink raw reply related [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 14:03 ` Mike McCormack @ 2010-01-11 16:45 ` Stephen Hemminger 2010-01-11 22:07 ` Jarek Poplawski 2010-01-11 22:31 ` [Bug #14925] sky2 panic under load Jarek Poplawski 0 siblings, 2 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-11 16:45 UTC (permalink / raw) To: Mike McCormack; +Cc: Berck E. Nash, Rafael J. Wysocki, netdev, Jarek Poplawski On Mon, 11 Jan 2010 23:03:41 +0900 Mike McCormack <mikem@ring3k.org> wrote: > Perhaps only sky2_tx_done should wake the queue? > Does the patch below fix the problem too? > > thanks, > > Mike The idea is good, but what if transmit queue was full (stopped), and TX FIFO gets stuck. Then Transmit timeout happens and the reset logic clears the queue. What will start the queue? Something like this: ----------------------------------------------------------- --- a/drivers/net/sky2.c 2010-01-11 08:36:42.617426300 -0800 +++ b/drivers/net/sky2.c 2010-01-11 08:42:51.295237661 -0800 @@ -1843,9 +1843,6 @@ static void sky2_tx_complete(struct sky2 sky2->tx_cons = idx; smp_mb(); - - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) - netif_wake_queue(dev); } static void sky2_tx_reset(struct sky2_hw *hw, unsigned port) @@ -2416,8 +2413,12 @@ static inline void sky2_tx_done(struct n { struct sky2_port *sky2 = netdev_priv(dev); - if (netif_running(dev)) + if (netif_running(dev) && netif_device_present(dev)) { sky2_tx_complete(sky2, last); + + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) + netif_wake_queue(dev); + } } static inline void sky2_skb_rx(const struct sky2_port *sky2, @@ -3197,6 +3198,7 @@ static int sky2_reattach(struct net_devi } else { netif_device_attach(dev); sky2_set_multicast(dev); + netif_start_queue(dev); } } -- ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 16:45 ` Stephen Hemminger @ 2010-01-11 22:07 ` Jarek Poplawski 2010-01-12 0:14 ` David Miller 2010-01-11 22:31 ` [Bug #14925] sky2 panic under load Jarek Poplawski 1 sibling, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-11 22:07 UTC (permalink / raw) To: Stephen Hemminger Cc: Mike McCormack, Berck E. Nash, Rafael J. Wysocki, netdev On Mon, Jan 11, 2010 at 08:45:04AM -0800, Stephen Hemminger wrote: > On Mon, 11 Jan 2010 23:03:41 +0900 > Mike McCormack <mikem@ring3k.org> wrote: > > > Perhaps only sky2_tx_done should wake the queue? > > Does the patch below fix the problem too? > > > > thanks, > > > > Mike > > The idea is good, I don't agree: you both try to make this check more specific. Actually, since this problem is quite tricky, I wondered about making it more genaral and visible for other maintainers by adding something like netif_wake_queue_present() with the check and some comment. Jarek P. > but what if transmit queue was full (stopped), > and TX FIFO gets stuck. Then Transmit timeout happens and > the reset logic clears the queue. What will start the queue? > > Something like this: > ----------------------------------------------------------- > > > > --- a/drivers/net/sky2.c 2010-01-11 08:36:42.617426300 -0800 > +++ b/drivers/net/sky2.c 2010-01-11 08:42:51.295237661 -0800 > @@ -1843,9 +1843,6 @@ static void sky2_tx_complete(struct sky2 > > sky2->tx_cons = idx; > smp_mb(); > - > - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > - netif_wake_queue(dev); > } > > static void sky2_tx_reset(struct sky2_hw *hw, unsigned port) > @@ -2416,8 +2413,12 @@ static inline void sky2_tx_done(struct n > { > struct sky2_port *sky2 = netdev_priv(dev); > > - if (netif_running(dev)) > + if (netif_running(dev) && netif_device_present(dev)) { > sky2_tx_complete(sky2, last); > + > + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > + netif_wake_queue(dev); > + } > } > > static inline void sky2_skb_rx(const struct sky2_port *sky2, > @@ -3197,6 +3198,7 @@ static int sky2_reattach(struct net_devi > } else { > netif_device_attach(dev); > sky2_set_multicast(dev); > + netif_start_queue(dev); > } > } > > > -- ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 22:07 ` Jarek Poplawski @ 2010-01-12 0:14 ` David Miller 2010-01-12 7:50 ` Jarek Poplawski 0 siblings, 1 reply; 248+ messages in thread From: David Miller @ 2010-01-12 0:14 UTC (permalink / raw) To: jarkao2; +Cc: shemminger, mikem, flyboy, rjw, netdev From: Jarek Poplawski <jarkao2@gmail.com> Date: Mon, 11 Jan 2010 23:07:54 +0100 > I don't agree: you both try to make this check more specific. > Actually, since this problem is quite tricky, I wondered about > making it more genaral and visible for other maintainers by > adding something like netif_wake_queue_present() with the > check and some comment. This detracts from the real problem. The issue is that we have a code path bringing a device down, which uses helper routines which are meant to be executed when the device is up and functioning normally. That's the bug. No other driver does silly things like call helper routines which wake the TX queue when taking the chip down. Fix that, not the immediate symptoms. Write a routine that unconditionally clears the TX queue, frees the packets, etc. and has none of the wake logic. That's what most other driver do, and those that don't should be fixed similarly. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 0:14 ` David Miller @ 2010-01-12 7:50 ` Jarek Poplawski 2010-01-12 8:08 ` David Miller 0 siblings, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 7:50 UTC (permalink / raw) To: David Miller; +Cc: shemminger, mikem, flyboy, rjw, netdev On Mon, Jan 11, 2010 at 04:14:19PM -0800, David Miller wrote: > From: Jarek Poplawski <jarkao2@gmail.com> > Date: Mon, 11 Jan 2010 23:07:54 +0100 > > > I don't agree: you both try to make this check more specific. > > Actually, since this problem is quite tricky, I wondered about > > making it more genaral and visible for other maintainers by > > adding something like netif_wake_queue_present() with the > > check and some comment. > > This detracts from the real problem. > > The issue is that we have a code path bringing a device down, which > uses helper routines which are meant to be executed when the device is > up and functioning normally. > > That's the bug. > > No other driver does silly things like call helper routines which wake > the TX queue when taking the chip down. > > Fix that, not the immediate symptoms. Write a routine that > unconditionally clears the TX queue, frees the packets, etc. and > has none of the wake logic. > > That's what most other driver do, and those that don't should be > fixed similarly. As I wrote it's tricky and could be hard to track even if you "heard" about it, e.g. Mike moves netif_wake_queue() to another place in his last proposal, but it still can run after netif_device_detach() until napi_synchronize() in sky2_down(). I think, I can see similar problems e.g. in gianfar or netxen, where napi_disable() is done after netif_device_detach(), especially in suspend procedures (there might be less severe (than oops) effects yet). IMHO, it all looks simply error prone (sometime you have to know a driver well to track all possible paths to say it's really safe). In the meantime users are endangered with known oopses or at least suspend problems, while we know the reasons, can fix it (even temporarily) with one-liners, but wait for the right fixes. (Btw, such fixes might require a significant rewrite, risking inserting new bugs, so I doubt they are "right" for -stable.) Anyway, I'm OK with this (I hope what should be done will be done, and I don't have sky2 ;-) Cheers, Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 7:50 ` Jarek Poplawski @ 2010-01-12 8:08 ` David Miller 2010-01-12 8:56 ` Jarek Poplawski 0 siblings, 1 reply; 248+ messages in thread From: David Miller @ 2010-01-12 8:08 UTC (permalink / raw) To: jarkao2; +Cc: shemminger, mikem, flyboy, rjw, netdev From: Jarek Poplawski <jarkao2@gmail.com> Date: Tue, 12 Jan 2010 07:50:59 +0000 > I think, I can see similar problems e.g. in gianfar or netxen, where > napi_disable() is done after netif_device_detach(), especially in > suspend procedures (there might be less severe (than oops) effects > yet). IMHO, it all looks simply error prone (sometime you have to > know a driver well to track all possible paths to say it's really > safe). Then that's an even larger bug. Until you do napi_disable(), the device can be touched. Asynchronous paths outside of the driver's control, even with interrupts disabled, can call back into the driver and touch the chip. F.e. netpoll via netconsole output on another cpu So it therefore must be done before doing the actual work of bringing the device down or suspending it. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 8:08 ` David Miller @ 2010-01-12 8:56 ` Jarek Poplawski 2010-01-12 9:42 ` David Miller 0 siblings, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 8:56 UTC (permalink / raw) To: David Miller; +Cc: shemminger, mikem, flyboy, rjw, netdev, Michael Breuer On Tue, Jan 12, 2010 at 12:08:04AM -0800, David Miller wrote: > From: Jarek Poplawski <jarkao2@gmail.com> > Date: Tue, 12 Jan 2010 07:50:59 +0000 > > > I think, I can see similar problems e.g. in gianfar or netxen, where > > napi_disable() is done after netif_device_detach(), especially in > > suspend procedures (there might be less severe (than oops) effects > > yet). IMHO, it all looks simply error prone (sometime you have to > > know a driver well to track all possible paths to say it's really > > safe). > > Then that's an even larger bug. > > Until you do napi_disable(), the device can be touched. > > Asynchronous paths outside of the driver's control, even > with interrupts disabled, can call back into the driver > and touch the chip. > > F.e. netpoll via netconsole output on another cpu > > So it therefore must be done before doing the actual work of bringing > the device down or suspending it. Maybe I miss something, but once more: this patch mentioned by Berck Nash has been tested by at least two users, Berck himself, and probably even more intensively by Michael Breuer, during af_packet debugging. Both guys acknowledged it helped, so it can't be that bad. Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 8:56 ` Jarek Poplawski @ 2010-01-12 9:42 ` David Miller 2010-01-12 10:31 ` Jarek Poplawski 2010-01-12 10:56 ` David Miller 0 siblings, 2 replies; 248+ messages in thread From: David Miller @ 2010-01-12 9:42 UTC (permalink / raw) To: jarkao2; +Cc: shemminger, mikem, flyboy, rjw, netdev, mbreuer From: Jarek Poplawski <jarkao2@gmail.com> Date: Tue, 12 Jan 2010 08:56:34 +0000 > Maybe I miss something, but once more: this patch mentioned by Berck > Nash has been tested by at least two users, Berck himself, and > probably even more intensively by Michael Breuer, during af_packet > debugging. Both guys acknowledged it helped, so it can't be that bad. I agree, as a short term fix, this patch is fine. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 9:42 ` David Miller @ 2010-01-12 10:31 ` Jarek Poplawski 2010-01-12 10:56 ` David Miller 1 sibling, 0 replies; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 10:31 UTC (permalink / raw) To: David Miller; +Cc: shemminger, mikem, flyboy, rjw, netdev, mbreuer On Tue, Jan 12, 2010 at 01:42:18AM -0800, David Miller wrote: > From: Jarek Poplawski <jarkao2@gmail.com> > Date: Tue, 12 Jan 2010 08:56:34 +0000 > > > Maybe I miss something, but once more: this patch mentioned by Berck > > Nash has been tested by at least two users, Berck himself, and > > probably even more intensively by Michael Breuer, during af_packet > > debugging. Both guys acknowledged it helped, so it can't be that bad. > > I agree, as a short term fix, this patch is fine. And I agree real problems might be deeper. Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 9:42 ` David Miller 2010-01-12 10:31 ` Jarek Poplawski @ 2010-01-12 10:56 ` David Miller 2010-01-12 11:04 ` Jarek Poplawski ` (2 more replies) 1 sibling, 3 replies; 248+ messages in thread From: David Miller @ 2010-01-12 10:56 UTC (permalink / raw) To: jarkao2; +Cc: shemminger, mikem, flyboy, rjw, netdev, mbreuer From: David Miller <davem@davemloft.net> Date: Tue, 12 Jan 2010 01:42:18 -0800 (PST) > From: Jarek Poplawski <jarkao2@gmail.com> > Date: Tue, 12 Jan 2010 08:56:34 +0000 > >> Maybe I miss something, but once more: this patch mentioned by Berck >> Nash has been tested by at least two users, Berck himself, and >> probably even more intensively by Michael Breuer, during af_packet >> debugging. Both guys acknowledged it helped, so it can't be that bad. > > I agree, as a short term fix, this patch is fine. In case it isn't painfully obvious, I'm applying Jarek's "v2" fix and will also queue that up for -stable. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 10:56 ` David Miller @ 2010-01-12 11:04 ` Jarek Poplawski 2010-01-12 15:39 ` Stephen Hemminger 2010-01-12 16:15 ` [PATCH] sky2: safer transmit ring cleaning Stephen Hemminger 2 siblings, 0 replies; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 11:04 UTC (permalink / raw) To: David Miller; +Cc: shemminger, mikem, flyboy, rjw, netdev, mbreuer On Tue, Jan 12, 2010 at 02:56:20AM -0800, David Miller wrote: > From: David Miller <davem@davemloft.net> > Date: Tue, 12 Jan 2010 01:42:18 -0800 (PST) > > > From: Jarek Poplawski <jarkao2@gmail.com> > > Date: Tue, 12 Jan 2010 08:56:34 +0000 > > > >> Maybe I miss something, but once more: this patch mentioned by Berck > >> Nash has been tested by at least two users, Berck himself, and > >> probably even more intensively by Michael Breuer, during af_packet > >> debugging. Both guys acknowledged it helped, so it can't be that bad. > > > > I agree, as a short term fix, this patch is fine. > > In case it isn't painfully obvious, I'm applying Jarek's "v2" > fix and will also queue that up for -stable. > Thanks! Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-12 10:56 ` David Miller 2010-01-12 11:04 ` Jarek Poplawski @ 2010-01-12 15:39 ` Stephen Hemminger 2010-01-12 16:15 ` [PATCH] sky2: safer transmit ring cleaning Stephen Hemminger 2 siblings, 0 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-12 15:39 UTC (permalink / raw) To: David Miller; +Cc: mikem, flyboy, rjw, netdev, mbreuer, jarkao2 Please hold off applying anything. I am testing a cleaner solution ^ permalink raw reply [flat|nested] 248+ messages in thread
* [PATCH] sky2: safer transmit ring cleaning 2010-01-12 10:56 ` David Miller 2010-01-12 11:04 ` Jarek Poplawski 2010-01-12 15:39 ` Stephen Hemminger @ 2010-01-12 16:15 ` Stephen Hemminger 2010-01-12 16:32 ` Michael Breuer ` (2 more replies) 2 siblings, 3 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-12 16:15 UTC (permalink / raw) To: David Miller; +Cc: jarkao2, mikem, flyboy, rjw, netdev, mbreuer This code makes transmit path and transmit reset safer by: * adding memory barrier before checking available ring slots * reseting state of tx ring elements after free * seperate cleanup function from ring done function * removing mostly unused tx_next element Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- Please apply this instead of the various bits and pieces flying around labeled as sky2 panic under load --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 +++ b/drivers/net/sky2.c 2010-01-11 17:36:22.027429875 -0800 @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct /* Number of list elements available for next tx */ static inline int tx_avail(const struct sky2_port *sky2) { + /* Makes sure update of tx_prod from start_xmit and + tx_cons from tx_done are seen. */ + smp_mb(); return sky2->tx_pending - tx_inuse(sky2); } @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s return count; } -static void sky2_tx_unmap(struct pci_dev *pdev, - const struct tx_ring_info *re) +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) { if (re->flags & TX_MAP_SINGLE) pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), pci_unmap_len(re, maplen), PCI_DMA_TODEVICE); + re->flags = 0; } /* @@ -1804,7 +1807,8 @@ mapping_error: } /* - * Free ring elements from starting at tx_cons until "done" + * Transmit complete processing + * Free ring elements from starting at tx_cons until done index * * NB: * 1. The hardware will tell us about partial completion of multi-part @@ -1813,9 +1817,9 @@ mapping_error: * looks at the tail of the queue of FIFO (tx_cons), not * the head (tx_prod) */ -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) +static void sky2_tx_done(struct net_device *dev, u16 done) { - struct net_device *dev = sky2->netdev; + struct sky2_port *sky2 = netdev_priv(dev); unsigned idx; BUG_ON(done >= sky2->tx_ring_size); @@ -1828,6 +1832,8 @@ static void sky2_tx_complete(struct sky2 sky2_tx_unmap(sky2->hw->pdev, re); if (skb) { + re->skb = NULL; + if (unlikely(netif_msg_tx_done(sky2))) printk(KERN_DEBUG "%s: tx done %u\n", dev->name, idx); @@ -1836,13 +1842,10 @@ static void sky2_tx_complete(struct sky2 dev->stats.tx_bytes += skb->len; dev_kfree_skb_any(skb); - - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); } } sky2->tx_cons = idx; - smp_mb(); if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) netif_wake_queue(dev); @@ -1870,6 +1873,21 @@ static void sky2_tx_reset(struct sky2_hw sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); } +static void sky2_tx_clean(struct sky2_port *sky2) +{ + u16 idx; + + for (idx = 0; idx < sky2->tx_ring_size; idx++) { + struct tx_ring_info *re = sky2->tx_ring + idx; + + sky2_tx_unmap(sky2->hw->pdev, re); + if (re->skb) { + dev_kfree_skb_any(re->skb); + re->skb = NULL; + } + } +} + /* Network shutdown */ static int sky2_down(struct net_device *dev) { @@ -1933,8 +1951,7 @@ static int sky2_down(struct net_device * sky2_tx_reset(hw, port); /* Free any pending frames stuck in HW queue */ - sky2_tx_complete(sky2, sky2->tx_prod); - + sky2_tx_clean(sky2); sky2_rx_clean(sky2); sky2_free_buffers(sky2); @@ -2411,15 +2428,6 @@ error: goto resubmit; } -/* Transmit complete */ -static inline void sky2_tx_done(struct net_device *dev, u16 last) -{ - struct sky2_port *sky2 = netdev_priv(dev); - - if (netif_running(dev)) - sky2_tx_complete(sky2, last); -} - static inline void sky2_skb_rx(const struct sky2_port *sky2, u32 status, struct sk_buff *skb) { @@ -4201,7 +4209,7 @@ static int sky2_debug_show(struct seq_fi /* Dump contents of tx ring */ sop = 1; - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; idx = RING_NEXT(idx, sky2->tx_ring_size)) { const struct sky2_tx_le *le = sky2->tx_le + idx; u32 a = le32_to_cpu(le->addr); --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 @@ -2187,7 +2187,6 @@ struct sky2_port { u16 tx_ring_size; u16 tx_cons; /* next le to check */ u16 tx_prod; /* next le to use */ - u16 tx_next; /* debug only */ u16 tx_pending; u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 16:15 ` [PATCH] sky2: safer transmit ring cleaning Stephen Hemminger @ 2010-01-12 16:32 ` Michael Breuer 2010-01-12 17:02 ` Stephen Hemminger 2010-01-12 18:04 ` Jarek Poplawski 2010-01-12 18:35 ` [PATCH] sky2: safer transmit ring cleaning Michael Breuer 2 siblings, 1 reply; 248+ messages in thread From: Michael Breuer @ 2010-01-12 16:32 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On 01/12/2010 11:15 AM, Stephen Hemminger wrote: > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > > > Stephen, Just want to confirm that this supersedes both of the patches I'm currently running with: 1. skb_may_pull 2. Nash patch -- Mike ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 16:32 ` Michael Breuer @ 2010-01-12 17:02 ` Stephen Hemminger 0 siblings, 0 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-12 17:02 UTC (permalink / raw) To: Michael Breuer; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On Tue, 12 Jan 2010 11:32:45 -0500 Michael Breuer <mbreuer@majjas.com> wrote: > On 01/12/2010 11:15 AM, Stephen Hemminger wrote: > > This code makes transmit path and transmit reset safer by: > > * adding memory barrier before checking available ring slots > > * reseting state of tx ring elements after free > > * seperate cleanup function from ring done function > > * removing mostly unused tx_next element > > > > > > > Stephen, > > Just want to confirm that this supersedes both of the patches I'm > currently running with: > > 1. skb_may_pull > 2. Nash patch You want: 1. AF_PACKET patch that makes sure skb is not modified after send 2. This patch. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 16:15 ` [PATCH] sky2: safer transmit ring cleaning Stephen Hemminger 2010-01-12 16:32 ` Michael Breuer @ 2010-01-12 18:04 ` Jarek Poplawski 2010-01-12 18:13 ` Stephen Hemminger 2010-01-12 18:35 ` [PATCH] sky2: safer transmit ring cleaning Michael Breuer 2 siblings, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 18:04 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, mikem, flyboy, rjw, netdev, mbreuer On Tue, Jan 12, 2010 at 08:15:13AM -0800, Stephen Hemminger wrote: > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element Does this patch prevent re-enabling tx after netif_device_detach(), e.g. when sky2_detach() and sky2_tx_done() run at the same time on different cpus? Jarek P. > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> > > --- > Please apply this instead of the various bits and pieces flying > around labeled as sky2 panic under load > > > --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 > +++ b/drivers/net/sky2.c 2010-01-11 17:36:22.027429875 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags & TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,9 +1817,9 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > BUG_ON(done >= sky2->tx_ring_size); > @@ -1828,6 +1832,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,13 +1842,10 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > @@ -1870,6 +1873,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx < sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1933,8 +1951,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2411,15 +2428,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -4201,7 +4209,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 > +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 18:04 ` Jarek Poplawski @ 2010-01-12 18:13 ` Stephen Hemminger 2010-01-12 18:24 ` Jarek Poplawski 0 siblings, 1 reply; 248+ messages in thread From: Stephen Hemminger @ 2010-01-12 18:13 UTC (permalink / raw) To: Jarek Poplawski; +Cc: David Miller, mikem, flyboy, rjw, netdev, mbreuer On Tue, 12 Jan 2010 19:04:30 +0100 Jarek Poplawski <jarkao2@gmail.com> wrote: > On Tue, Jan 12, 2010 at 08:15:13AM -0800, Stephen Hemminger wrote: > > This code makes transmit path and transmit reset safer by: > > * adding memory barrier before checking available ring slots > > * reseting state of tx ring elements after free > > * seperate cleanup function from ring done function > > * removing mostly unused tx_next element > > Does this patch prevent re-enabling tx after netif_device_detach(), > e.g. when sky2_detach() and sky2_tx_done() run at the same time on > different cpus? > Yes. The napi is disabled during the detach so transmit completion can not be done during that period. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 18:13 ` Stephen Hemminger @ 2010-01-12 18:24 ` Jarek Poplawski 2010-01-12 18:49 ` [PATCH] sky2: safer transmit ring cleaning (v2) Stephen Hemminger 0 siblings, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 18:24 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, mikem, flyboy, rjw, netdev, mbreuer On Tue, Jan 12, 2010 at 10:13:06AM -0800, Stephen Hemminger wrote: > On Tue, 12 Jan 2010 19:04:30 +0100 > Jarek Poplawski <jarkao2@gmail.com> wrote: > > > On Tue, Jan 12, 2010 at 08:15:13AM -0800, Stephen Hemminger wrote: > > > This code makes transmit path and transmit reset safer by: > > > * adding memory barrier before checking available ring slots > > > * reseting state of tx ring elements after free > > > * seperate cleanup function from ring done function > > > * removing mostly unused tx_next element > > > > Does this patch prevent re-enabling tx after netif_device_detach(), > > e.g. when sky2_detach() and sky2_tx_done() run at the same time on > > different cpus? > > > > Yes. > The napi is disabled during the detach so transmit completion can > not be done during that period. Could you point me where exactly the napi is disabled, probably I missed this? Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* [PATCH] sky2: safer transmit ring cleaning (v2) 2010-01-12 18:24 ` Jarek Poplawski @ 2010-01-12 18:49 ` Stephen Hemminger 2010-01-12 19:16 ` Jarek Poplawski 2010-01-12 19:34 ` Michael Breuer 0 siblings, 2 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-12 18:49 UTC (permalink / raw) To: Jarek Poplawski, David Miller; +Cc: mikem, flyboy, rjw, netdev, mbreuer This code makes transmit path and transmit reset safer by: * adding memory barrier before checking available ring slots * reseting state of tx ring elements after free * seperate cleanup function from ring done function * removing mostly unused tx_next element Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- What is supposed to happen: * restart sky2_restart calls napi_disable while cleaning * dev_close we can't call napi_disable() because of two ports sharing same NAPI, so napi_synchronize() is used to make sure that any NAPI running on other CPU has completed. * if status is reported by chip for down device, then tx_done should ignore But, last patch was missing last step --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 +++ b/drivers/net/sky2.c 2010-01-12 10:44:56.068391575 -0800 @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct /* Number of list elements available for next tx */ static inline int tx_avail(const struct sky2_port *sky2) { + /* Makes sure update of tx_prod from start_xmit and + tx_cons from tx_done are seen. */ + smp_mb(); return sky2->tx_pending - tx_inuse(sky2); } @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s return count; } -static void sky2_tx_unmap(struct pci_dev *pdev, - const struct tx_ring_info *re) +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) { if (re->flags & TX_MAP_SINGLE) pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), pci_unmap_len(re, maplen), PCI_DMA_TODEVICE); + re->flags = 0; } /* @@ -1804,7 +1807,8 @@ mapping_error: } /* - * Free ring elements from starting at tx_cons until "done" + * Transmit complete processing + * Free ring elements from starting at tx_cons until done index * * NB: * 1. The hardware will tell us about partial completion of multi-part @@ -1813,11 +1817,14 @@ mapping_error: * looks at the tail of the queue of FIFO (tx_cons), not * the head (tx_prod) */ -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) +static void sky2_tx_done(struct net_device *dev, u16 done) { - struct net_device *dev = sky2->netdev; + struct sky2_port *sky2 = netdev_priv(dev); unsigned idx; + if (unlikely(!netif_running(dev))) + return; + BUG_ON(done >= sky2->tx_ring_size); for (idx = sky2->tx_cons; idx != done; @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 sky2_tx_unmap(sky2->hw->pdev, re); if (skb) { + re->skb = NULL; + if (unlikely(netif_msg_tx_done(sky2))) printk(KERN_DEBUG "%s: tx done %u\n", dev->name, idx); @@ -1836,13 +1845,10 @@ static void sky2_tx_complete(struct sky2 dev->stats.tx_bytes += skb->len; dev_kfree_skb_any(skb); - - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); } } sky2->tx_cons = idx; - smp_mb(); if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) netif_wake_queue(dev); @@ -1870,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); } +static void sky2_tx_clean(struct sky2_port *sky2) +{ + u16 idx; + + for (idx = 0; idx < sky2->tx_ring_size; idx++) { + struct tx_ring_info *re = sky2->tx_ring + idx; + + sky2_tx_unmap(sky2->hw->pdev, re); + if (re->skb) { + dev_kfree_skb_any(re->skb); + re->skb = NULL; + } + } +} + /* Network shutdown */ static int sky2_down(struct net_device *dev) { @@ -1933,8 +1954,7 @@ static int sky2_down(struct net_device * sky2_tx_reset(hw, port); /* Free any pending frames stuck in HW queue */ - sky2_tx_complete(sky2, sky2->tx_prod); - + sky2_tx_clean(sky2); sky2_rx_clean(sky2); sky2_free_buffers(sky2); @@ -2411,15 +2431,6 @@ error: goto resubmit; } -/* Transmit complete */ -static inline void sky2_tx_done(struct net_device *dev, u16 last) -{ - struct sky2_port *sky2 = netdev_priv(dev); - - if (netif_running(dev)) - sky2_tx_complete(sky2, last); -} - static inline void sky2_skb_rx(const struct sky2_port *sky2, u32 status, struct sk_buff *skb) { @@ -4201,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi /* Dump contents of tx ring */ sop = 1; - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; idx = RING_NEXT(idx, sky2->tx_ring_size)) { const struct sky2_tx_le *le = sky2->tx_le + idx; u32 a = le32_to_cpu(le->addr); --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 @@ -2187,7 +2187,6 @@ struct sky2_port { u16 tx_ring_size; u16 tx_cons; /* next le to check */ u16 tx_prod; /* next le to use */ - u16 tx_next; /* debug only */ u16 tx_pending; u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v2) 2010-01-12 18:49 ` [PATCH] sky2: safer transmit ring cleaning (v2) Stephen Hemminger @ 2010-01-12 19:16 ` Jarek Poplawski 2010-01-12 19:23 ` Stephen Hemminger 2010-01-12 19:34 ` Michael Breuer 1 sibling, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 19:16 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, mikem, flyboy, rjw, netdev, mbreuer On Tue, Jan 12, 2010 at 10:49:45AM -0800, Stephen Hemminger wrote: > > > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> > > --- > > What is supposed to happen: > * restart sky2_restart calls napi_disable while cleaning Yes, but it's after the detach; similarly to sky2_suspend(). (I'm not sure how safe vs such re-enabling is sky2_set_ringparam().) > * dev_close we can't call napi_disable() because of two ports > sharing same NAPI, so napi_synchronize() is used to make sure that > any NAPI running on other CPU has completed. So it seems still endangered. > * if status is reported by chip for down device, then tx_done should ignore > > But, last patch was missing last step > > --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 > +++ b/drivers/net/sky2.c 2010-01-12 10:44:56.068391575 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags & TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,11 +1817,14 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > + if (unlikely(!netif_running(dev))) > + return; > + > BUG_ON(done >= sky2->tx_ring_size); > > for (idx = sky2->tx_cons; idx != done; > @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,13 +1845,10 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > @@ -1870,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx < sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1933,8 +1954,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2411,15 +2431,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -4201,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 > +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v2) 2010-01-12 19:16 ` Jarek Poplawski @ 2010-01-12 19:23 ` Stephen Hemminger 2010-01-12 19:50 ` Jarek Poplawski 0 siblings, 1 reply; 248+ messages in thread From: Stephen Hemminger @ 2010-01-12 19:23 UTC (permalink / raw) To: Jarek Poplawski; +Cc: David Miller, mikem, flyboy, rjw, netdev, mbreuer On Tue, 12 Jan 2010 20:16:11 +0100 Jarek Poplawski <jarkao2@gmail.com> wrote: > > > > What is supposed to happen: > > * restart sky2_restart calls napi_disable while cleaning > > Yes, but it's after the detach; similarly to sky2_suspend(). > (I'm not sure how safe vs such re-enabling is sky2_set_ringparam(). set_ringparam happens under rtnl_lock() so reset and ringparams can't conflict. > > > * dev_close we can't call napi_disable() because of two ports > > sharing same NAPI, so napi_synchronize() is used to make sure that > > any NAPI running on other CPU has completed. > > So it seems still endangered. It was but not in revised v2 patch. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v2) 2010-01-12 19:23 ` Stephen Hemminger @ 2010-01-12 19:50 ` Jarek Poplawski 2010-01-13 1:23 ` Stephen Hemminger 0 siblings, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-12 19:50 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, mikem, flyboy, rjw, netdev, mbreuer On Tue, Jan 12, 2010 at 11:23:14AM -0800, Stephen Hemminger wrote: > On Tue, 12 Jan 2010 20:16:11 +0100 > Jarek Poplawski <jarkao2@gmail.com> wrote: > > > > > > > What is supposed to happen: > > > * restart sky2_restart calls napi_disable while cleaning > > > > Yes, but it's after the detach; similarly to sky2_suspend(). > > (I'm not sure how safe vs such re-enabling is sky2_set_ringparam(). > > set_ringparam happens under rtnl_lock() so reset and ringparams can't > conflict. I didn't mean reset. I meant tx (dev_queue_xmit()) during ringparams. > > > > > > * dev_close we can't call napi_disable() because of two ports > > > sharing same NAPI, so napi_synchronize() is used to make sure that > > > any NAPI running on other CPU has completed. > > > > So it seems still endangered. > > It was but not in revised v2 patch. Sorry, I meant sky2_down() (except in dev_close()). Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v2) 2010-01-12 19:50 ` Jarek Poplawski @ 2010-01-13 1:23 ` Stephen Hemminger 0 siblings, 0 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-13 1:23 UTC (permalink / raw) To: Jarek Poplawski; +Cc: David Miller, mikem, flyboy, rjw, netdev, mbreuer On Tue, 12 Jan 2010 20:50:04 +0100 Jarek Poplawski <jarkao2@gmail.com> wrote: > On Tue, Jan 12, 2010 at 11:23:14AM -0800, Stephen Hemminger wrote: > > On Tue, 12 Jan 2010 20:16:11 +0100 > > Jarek Poplawski <jarkao2@gmail.com> wrote: > > > > > > > > > > What is supposed to happen: > > > > * restart sky2_restart calls napi_disable while cleaning > > > > > > Yes, but it's after the detach; similarly to sky2_suspend(). > > > (I'm not sure how safe vs such re-enabling is sky2_set_ringparam(). > > > > set_ringparam happens under rtnl_lock() so reset and ringparams can't > > conflict. > > I didn't mean reset. I meant tx (dev_queue_xmit()) during ringparams. sky2_detach does tx_lock netif_detach() -- stops the queue tx_unlock So if another CPU was about to send, it will have to wait behind the tx_global_lock, and then it will see the queue as frozen. BUT, you prod me to look harder and there is a race with softirq (bottom half) here that needs to be fixed. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v2) 2010-01-12 18:49 ` [PATCH] sky2: safer transmit ring cleaning (v2) Stephen Hemminger 2010-01-12 19:16 ` Jarek Poplawski @ 2010-01-12 19:34 ` Michael Breuer 1 sibling, 0 replies; 248+ messages in thread From: Michael Breuer @ 2010-01-12 19:34 UTC (permalink / raw) To: Stephen Hemminger Cc: Jarek Poplawski, David Miller, mikem, flyboy, rjw, netdev On 1/12/2010 1:49 PM, Stephen Hemminger wrote: > > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > > Signed-off-by: Stephen Hemminger<shemminger@vyatta.com> > > --- > > What is supposed to happen: > * restart sky2_restart calls napi_disable while cleaning > * dev_close we can't call napi_disable() because of two ports > sharing same NAPI, so napi_synchronize() is used to make sure that > any NAPI running on other CPU has completed. > * if status is reported by chip for down device, then tx_done should ignore > > But, last patch was missing last step > > --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 > +++ b/drivers/net/sky2.c 2010-01-12 10:44:56.068391575 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags& TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,11 +1817,14 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > + if (unlikely(!netif_running(dev))) > + return; > + > BUG_ON(done>= sky2->tx_ring_size); > > for (idx = sky2->tx_cons; idx != done; > @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,13 +1845,10 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > if (tx_avail(sky2)> MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > @@ -1870,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx< sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1933,8 +1954,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2411,15 +2431,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -4201,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 > +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; > Testing observation: This makes no sense to me, but the DHCP multiple request/inform issue I noted with V1 of this patch is gone with V2 (this is a repeatable test). I don't see how this patch could make the difference as the device should never be down during this test. What am I missing? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 16:15 ` [PATCH] sky2: safer transmit ring cleaning Stephen Hemminger 2010-01-12 16:32 ` Michael Breuer 2010-01-12 18:04 ` Jarek Poplawski @ 2010-01-12 18:35 ` Michael Breuer 2010-01-12 18:42 ` Michael Breuer 2 siblings, 1 reply; 248+ messages in thread From: Michael Breuer @ 2010-01-12 18:35 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On 1/12/2010 11:15 AM, Stephen Hemminger wrote: > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > > Signed-off-by: Stephen Hemminger<shemminger@vyatta.com> > > --- > Please apply this instead of the various bits and pieces flying > around labeled as sky2 panic under load > > > --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 > +++ b/drivers/net/sky2.c 2010-01-11 17:36:22.027429875 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags& TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,9 +1817,9 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > BUG_ON(done>= sky2->tx_ring_size); > @@ -1828,6 +1832,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,13 +1842,10 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > if (tx_avail(sky2)> MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > @@ -1870,6 +1873,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx< sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1933,8 +1951,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2411,15 +2428,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -4201,7 +4209,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 > +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; > Test observations: 1. DHCP request/response sequence having some issues... can't confirm that it's a result of this patch, but I don't see this with the prior patch. Prior to this patch, if I connect a new device (Blackberry in this case) I see DHCPDISCOVER;DHCPOFFER;DHCPREQUEST;DHCPACK (just the four messages). With this patch I'm seeing repeated attempts - i.e., DISCOVER/OFFER 6 times before the REQUEST/ACK. This is repeatable and happening whether or not under load. As my original problem started with DHCP packets, this seems interesting. I don't see any errors logged (dmesg, messages, etc.). 2. Probably not related to this patch, but perhaps to the driver - I've finally tracked the source of my dropped RX packets. It's happening when a sending data to a CIFS client on a MacOS system. The RX drop rate seems proportional to the TX rate for SMB to that client - at a tx rate of about 200Kb/s I see about 20 dropped RX packets/sec - at 400 I see about 40. I'm thinking therefore it's ACKs being dropped on RX. Why? no idea (yet). Nothing reported by ethtool or netstat -s remotely correlates to the number of dropped RX packets. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 18:35 ` [PATCH] sky2: safer transmit ring cleaning Michael Breuer @ 2010-01-12 18:42 ` Michael Breuer 2010-01-12 20:31 ` Michael Breuer 0 siblings, 1 reply; 248+ messages in thread From: Michael Breuer @ 2010-01-12 18:42 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On 1/12/2010 1:35 PM, Michael Breuer wrote: > On 1/12/2010 11:15 AM, Stephen Hemminger wrote: >> This code makes transmit path and transmit reset safer by: >> * adding memory barrier before checking available ring slots >> * reseting state of tx ring elements after free >> * seperate cleanup function from ring done function >> * removing mostly unused tx_next element >> >> Signed-off-by: Stephen Hemminger<shemminger@vyatta.com> >> >> --- >> Please apply this instead of the various bits and pieces flying >> around labeled as sky2 panic under load >> >> >> --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 >> +++ b/drivers/net/sky2.c 2010-01-11 17:36:22.027429875 -0800 >> @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct >> /* Number of list elements available for next tx */ >> static inline int tx_avail(const struct sky2_port *sky2) >> { >> + /* Makes sure update of tx_prod from start_xmit and >> + tx_cons from tx_done are seen. */ >> + smp_mb(); >> return sky2->tx_pending - tx_inuse(sky2); >> } >> >> @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s >> return count; >> } >> >> -static void sky2_tx_unmap(struct pci_dev *pdev, >> - const struct tx_ring_info *re) >> +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info >> *re) >> { >> if (re->flags& TX_MAP_SINGLE) >> pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), >> @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev >> pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), >> pci_unmap_len(re, maplen), >> PCI_DMA_TODEVICE); >> + re->flags = 0; >> } >> >> /* >> @@ -1804,7 +1807,8 @@ mapping_error: >> } >> >> /* >> - * Free ring elements from starting at tx_cons until "done" >> + * Transmit complete processing >> + * Free ring elements from starting at tx_cons until done index >> * >> * NB: >> * 1. The hardware will tell us about partial completion of >> multi-part >> @@ -1813,9 +1817,9 @@ mapping_error: >> * looks at the tail of the queue of FIFO (tx_cons), not >> * the head (tx_prod) >> */ >> -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) >> +static void sky2_tx_done(struct net_device *dev, u16 done) >> { >> - struct net_device *dev = sky2->netdev; >> + struct sky2_port *sky2 = netdev_priv(dev); >> unsigned idx; >> >> BUG_ON(done>= sky2->tx_ring_size); >> @@ -1828,6 +1832,8 @@ static void sky2_tx_complete(struct sky2 >> sky2_tx_unmap(sky2->hw->pdev, re); >> >> if (skb) { >> + re->skb = NULL; >> + >> if (unlikely(netif_msg_tx_done(sky2))) >> printk(KERN_DEBUG "%s: tx done %u\n", >> dev->name, idx); >> @@ -1836,13 +1842,10 @@ static void sky2_tx_complete(struct sky2 >> dev->stats.tx_bytes += skb->len; >> >> dev_kfree_skb_any(skb); >> - >> - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); >> } >> } >> >> sky2->tx_cons = idx; >> - smp_mb(); >> >> if (tx_avail(sky2)> MAX_SKB_TX_LE + 4) >> netif_wake_queue(dev); >> @@ -1870,6 +1873,21 @@ static void sky2_tx_reset(struct sky2_hw >> sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); >> } >> >> +static void sky2_tx_clean(struct sky2_port *sky2) >> +{ >> + u16 idx; >> + >> + for (idx = 0; idx< sky2->tx_ring_size; idx++) { >> + struct tx_ring_info *re = sky2->tx_ring + idx; >> + >> + sky2_tx_unmap(sky2->hw->pdev, re); >> + if (re->skb) { >> + dev_kfree_skb_any(re->skb); >> + re->skb = NULL; >> + } >> + } >> +} >> + >> /* Network shutdown */ >> static int sky2_down(struct net_device *dev) >> { >> @@ -1933,8 +1951,7 @@ static int sky2_down(struct net_device * >> sky2_tx_reset(hw, port); >> >> /* Free any pending frames stuck in HW queue */ >> - sky2_tx_complete(sky2, sky2->tx_prod); >> - >> + sky2_tx_clean(sky2); >> sky2_rx_clean(sky2); >> >> sky2_free_buffers(sky2); >> @@ -2411,15 +2428,6 @@ error: >> goto resubmit; >> } >> >> -/* Transmit complete */ >> -static inline void sky2_tx_done(struct net_device *dev, u16 last) >> -{ >> - struct sky2_port *sky2 = netdev_priv(dev); >> - >> - if (netif_running(dev)) >> - sky2_tx_complete(sky2, last); >> -} >> - >> static inline void sky2_skb_rx(const struct sky2_port *sky2, >> u32 status, struct sk_buff *skb) >> { >> @@ -4201,7 +4209,7 @@ static int sky2_debug_show(struct seq_fi >> >> /* Dump contents of tx ring */ >> sop = 1; >> - for (idx = sky2->tx_next; idx != sky2->tx_prod&& idx< >> sky2->tx_ring_size; >> + for (idx = sky2->tx_cons; idx != sky2->tx_prod&& idx< >> sky2->tx_ring_size; >> idx = RING_NEXT(idx, sky2->tx_ring_size)) { >> const struct sky2_tx_le *le = sky2->tx_le + idx; >> u32 a = le32_to_cpu(le->addr); >> --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 >> +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 >> @@ -2187,7 +2187,6 @@ struct sky2_port { >> u16 tx_ring_size; >> u16 tx_cons; /* next le to check */ >> u16 tx_prod; /* next le to use */ >> - u16 tx_next; /* debug only */ >> >> u16 tx_pending; >> u16 tx_last_mss; > Test observations: > > 1. DHCP request/response sequence having some issues... can't confirm > that it's a result of this patch, but I don't see this with the prior > patch. Prior to this patch, if I connect a new device (Blackberry in > this case) I see DHCPDISCOVER;DHCPOFFER;DHCPREQUEST;DHCPACK (just the > four messages). With this patch I'm seeing repeated attempts - i.e., > DISCOVER/OFFER 6 times before the REQUEST/ACK. This is repeatable and > happening whether or not under load. As my original problem started > with DHCP packets, this seems interesting. I don't see any errors > logged (dmesg, messages, etc.). > 2. Probably not related to this patch, but perhaps to the driver - > I've finally tracked the source of my dropped RX packets. It's > happening when a sending data to a CIFS client on a MacOS system. The > RX drop rate seems proportional to the TX rate for SMB to that client > - at a tx rate of about 200Kb/s I see about 20 dropped RX packets/sec > - at 400 I see about 40. I'm thinking therefore it's ACKs being > dropped on RX. Why? no idea (yet). Nothing reported by ethtool or > netstat -s remotely correlates to the number of dropped RX packets. > > Let me add: the CIFS client from which the packets are dropped is connected via a dd-wrt router (on wifi) connected to the sky2 1G port. A Windows client connected directly to the 1G port does not exhibit the same symptoms (. I'll try later the Mac directly connected & a Wintel box over wifi if possible. The DD-WRT router (linksys wrt54g-tm) is bridged (wifi clients on same subnet as wired & serviced by DHCPD running on the linux box). This is also the source of the aforementioned perhaps-flaky DHCP connections. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning 2010-01-12 18:42 ` Michael Breuer @ 2010-01-12 20:31 ` Michael Breuer 2010-01-13 4:10 ` [PATCH] sky2: safer transmit ring cleaning (v3) Stephen Hemminger 0 siblings, 1 reply; 248+ messages in thread From: Michael Breuer @ 2010-01-12 20:31 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On 1/12/2010 1:42 PM, Michael Breuer wrote: > On 1/12/2010 1:35 PM, Michael Breuer wrote: >> On 1/12/2010 11:15 AM, Stephen Hemminger wrote: >>> This code makes transmit path and transmit reset safer by: >>> * adding memory barrier before checking available ring slots >>> * reseting state of tx ring elements after free >>> * seperate cleanup function from ring done function >>> * removing mostly unused tx_next element >>> >>> Signed-off-by: Stephen Hemminger<shemminger@vyatta.com> >>> >>> --- >>> Please apply this instead of the various bits and pieces flying >>> around labeled as sky2 panic under load >>> >>> >>> --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 >>> +++ b/drivers/net/sky2.c 2010-01-11 17:36:22.027429875 -0800 >>> @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct >>> /* Number of list elements available for next tx */ >>> static inline int tx_avail(const struct sky2_port *sky2) >>> { >>> + /* Makes sure update of tx_prod from start_xmit and >>> + tx_cons from tx_done are seen. */ >>> + smp_mb(); >>> return sky2->tx_pending - tx_inuse(sky2); >>> } >>> >>> @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s >>> return count; >>> } >>> >>> -static void sky2_tx_unmap(struct pci_dev *pdev, >>> - const struct tx_ring_info *re) >>> +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info >>> *re) >>> { >>> if (re->flags& TX_MAP_SINGLE) >>> pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), >>> @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev >>> pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), >>> pci_unmap_len(re, maplen), >>> PCI_DMA_TODEVICE); >>> + re->flags = 0; >>> } >>> >>> /* >>> @@ -1804,7 +1807,8 @@ mapping_error: >>> } >>> >>> /* >>> - * Free ring elements from starting at tx_cons until "done" >>> + * Transmit complete processing >>> + * Free ring elements from starting at tx_cons until done index >>> * >>> * NB: >>> * 1. The hardware will tell us about partial completion of >>> multi-part >>> @@ -1813,9 +1817,9 @@ mapping_error: >>> * looks at the tail of the queue of FIFO (tx_cons), not >>> * the head (tx_prod) >>> */ >>> -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) >>> +static void sky2_tx_done(struct net_device *dev, u16 done) >>> { >>> - struct net_device *dev = sky2->netdev; >>> + struct sky2_port *sky2 = netdev_priv(dev); >>> unsigned idx; >>> >>> BUG_ON(done>= sky2->tx_ring_size); >>> @@ -1828,6 +1832,8 @@ static void sky2_tx_complete(struct sky2 >>> sky2_tx_unmap(sky2->hw->pdev, re); >>> >>> if (skb) { >>> + re->skb = NULL; >>> + >>> if (unlikely(netif_msg_tx_done(sky2))) >>> printk(KERN_DEBUG "%s: tx done %u\n", >>> dev->name, idx); >>> @@ -1836,13 +1842,10 @@ static void sky2_tx_complete(struct sky2 >>> dev->stats.tx_bytes += skb->len; >>> >>> dev_kfree_skb_any(skb); >>> - >>> - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); >>> } >>> } >>> >>> sky2->tx_cons = idx; >>> - smp_mb(); >>> >>> if (tx_avail(sky2)> MAX_SKB_TX_LE + 4) >>> netif_wake_queue(dev); >>> @@ -1870,6 +1873,21 @@ static void sky2_tx_reset(struct sky2_hw >>> sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); >>> } >>> >>> +static void sky2_tx_clean(struct sky2_port *sky2) >>> +{ >>> + u16 idx; >>> + >>> + for (idx = 0; idx< sky2->tx_ring_size; idx++) { >>> + struct tx_ring_info *re = sky2->tx_ring + idx; >>> + >>> + sky2_tx_unmap(sky2->hw->pdev, re); >>> + if (re->skb) { >>> + dev_kfree_skb_any(re->skb); >>> + re->skb = NULL; >>> + } >>> + } >>> +} >>> + >>> /* Network shutdown */ >>> static int sky2_down(struct net_device *dev) >>> { >>> @@ -1933,8 +1951,7 @@ static int sky2_down(struct net_device * >>> sky2_tx_reset(hw, port); >>> >>> /* Free any pending frames stuck in HW queue */ >>> - sky2_tx_complete(sky2, sky2->tx_prod); >>> - >>> + sky2_tx_clean(sky2); >>> sky2_rx_clean(sky2); >>> >>> sky2_free_buffers(sky2); >>> @@ -2411,15 +2428,6 @@ error: >>> goto resubmit; >>> } >>> >>> -/* Transmit complete */ >>> -static inline void sky2_tx_done(struct net_device *dev, u16 last) >>> -{ >>> - struct sky2_port *sky2 = netdev_priv(dev); >>> - >>> - if (netif_running(dev)) >>> - sky2_tx_complete(sky2, last); >>> -} >>> - >>> static inline void sky2_skb_rx(const struct sky2_port *sky2, >>> u32 status, struct sk_buff *skb) >>> { >>> @@ -4201,7 +4209,7 @@ static int sky2_debug_show(struct seq_fi >>> >>> /* Dump contents of tx ring */ >>> sop = 1; >>> - for (idx = sky2->tx_next; idx != sky2->tx_prod&& idx< >>> sky2->tx_ring_size; >>> + for (idx = sky2->tx_cons; idx != sky2->tx_prod&& idx< >>> sky2->tx_ring_size; >>> idx = RING_NEXT(idx, sky2->tx_ring_size)) { >>> const struct sky2_tx_le *le = sky2->tx_le + idx; >>> u32 a = le32_to_cpu(le->addr); >>> --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 >>> +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 >>> @@ -2187,7 +2187,6 @@ struct sky2_port { >>> u16 tx_ring_size; >>> u16 tx_cons; /* next le to check */ >>> u16 tx_prod; /* next le to use */ >>> - u16 tx_next; /* debug only */ >>> >>> u16 tx_pending; >>> u16 tx_last_mss; >> Test observations: >> >> 1. DHCP request/response sequence having some issues... can't confirm >> that it's a result of this patch, but I don't see this with the prior >> patch. Prior to this patch, if I connect a new device (Blackberry in >> this case) I see DHCPDISCOVER;DHCPOFFER;DHCPREQUEST;DHCPACK (just the >> four messages). With this patch I'm seeing repeated attempts - i.e., >> DISCOVER/OFFER 6 times before the REQUEST/ACK. This is repeatable >> and happening whether or not under load. As my original problem >> started with DHCP packets, this seems interesting. I don't see any >> errors logged (dmesg, messages, etc.). >> 2. Probably not related to this patch, but perhaps to the driver - >> I've finally tracked the source of my dropped RX packets. It's >> happening when a sending data to a CIFS client on a MacOS system. The >> RX drop rate seems proportional to the TX rate for SMB to that client >> - at a tx rate of about 200Kb/s I see about 20 dropped RX packets/sec >> - at 400 I see about 40. I'm thinking therefore it's ACKs being >> dropped on RX. Why? no idea (yet). Nothing reported by ethtool or >> netstat -s remotely correlates to the number of dropped RX packets. >> >> > Let me add: the CIFS client from which the packets are dropped is > connected via a dd-wrt router (on wifi) connected to the sky2 1G port. > A Windows client connected directly to the 1G port does not exhibit > the same symptoms (. I'll try later the Mac directly connected & a > Wintel box over wifi if possible. The DD-WRT router (linksys > wrt54g-tm) is bridged (wifi clients on same subnet as wired & serviced > by DHCPD running on the linux box). This is also the source of the > aforementioned perhaps-flaky DHCP connections. Ok - a little more on the dropped packets - only happens when connected through the wifi router - but happens using a wired connection as well (via the router's ethernet port). From sniffer traces: I see large frames outbound (even though MTU=1500). I see the fragmented result arriving on the remote side. I see ACK's for each of the fragmented frames outbound from the Mac, but not received on the Linux side. I also don't see any retransmissions or duplicate ACKS on either sniffer trace. I'm wondering whether there is fragmentation offload to the Yukon2, and whether the individual fragment acks are what's showing up dropped. If so, I don't understand why it would only happen with the wifi router vs. switch in the middle. Maybe the router is doing something to the packets which is causing the Yukon to forward the acks up differently? The router MTU is also 1500 on all ports, and does not show dropped packets or errors corresponding to what I'm seeing on the sky2 adapter. ^ permalink raw reply [flat|nested] 248+ messages in thread
* [PATCH] sky2: safer transmit ring cleaning (v3) 2010-01-12 20:31 ` Michael Breuer @ 2010-01-13 4:10 ` Stephen Hemminger 2010-01-13 4:31 ` Michael Breuer ` (2 more replies) 0 siblings, 3 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-13 4:10 UTC (permalink / raw) To: Michael Breuer, David Miller; +Cc: jarkao2, mikem, flyboy, rjw, netdev Subject: sky2: safer transmit cleanup This code makes transmit path and transmit reset safer by: * adding memory barrier before checking available ring slots * reseting state of tx ring elements after free * seperate cleanup function from ring done function * removing mostly unused tx_next element Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- This version adds missing _bh to sky2_detach --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 +++ b/drivers/net/sky2.c 2010-01-12 17:21:58.415268802 -0800 @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct /* Number of list elements available for next tx */ static inline int tx_avail(const struct sky2_port *sky2) { + /* Makes sure update of tx_prod from start_xmit and + tx_cons from tx_done are seen. */ + smp_mb(); return sky2->tx_pending - tx_inuse(sky2); } @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s return count; } -static void sky2_tx_unmap(struct pci_dev *pdev, - const struct tx_ring_info *re) +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) { if (re->flags & TX_MAP_SINGLE) pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), pci_unmap_len(re, maplen), PCI_DMA_TODEVICE); + re->flags = 0; } /* @@ -1804,7 +1807,8 @@ mapping_error: } /* - * Free ring elements from starting at tx_cons until "done" + * Transmit complete processing + * Free ring elements from starting at tx_cons until done index * * NB: * 1. The hardware will tell us about partial completion of multi-part @@ -1813,11 +1817,14 @@ mapping_error: * looks at the tail of the queue of FIFO (tx_cons), not * the head (tx_prod) */ -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) +static void sky2_tx_done(struct net_device *dev, u16 done) { - struct net_device *dev = sky2->netdev; + struct sky2_port *sky2 = netdev_priv(dev); unsigned idx; + if (unlikely(!netif_running(dev))) + return; + BUG_ON(done >= sky2->tx_ring_size); for (idx = sky2->tx_cons; idx != done; @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 sky2_tx_unmap(sky2->hw->pdev, re); if (skb) { + re->skb = NULL; + if (unlikely(netif_msg_tx_done(sky2))) printk(KERN_DEBUG "%s: tx done %u\n", dev->name, idx); @@ -1836,13 +1845,10 @@ static void sky2_tx_complete(struct sky2 dev->stats.tx_bytes += skb->len; dev_kfree_skb_any(skb); - - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); } } sky2->tx_cons = idx; - smp_mb(); if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) netif_wake_queue(dev); @@ -1870,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); } +static void sky2_tx_clean(struct sky2_port *sky2) +{ + u16 idx; + + for (idx = 0; idx < sky2->tx_ring_size; idx++) { + struct tx_ring_info *re = sky2->tx_ring + idx; + + sky2_tx_unmap(sky2->hw->pdev, re); + if (re->skb) { + dev_kfree_skb_any(re->skb); + re->skb = NULL; + } + } +} + /* Network shutdown */ static int sky2_down(struct net_device *dev) { @@ -1933,8 +1954,7 @@ static int sky2_down(struct net_device * sky2_tx_reset(hw, port); /* Free any pending frames stuck in HW queue */ - sky2_tx_complete(sky2, sky2->tx_prod); - + sky2_tx_clean(sky2); sky2_rx_clean(sky2); sky2_free_buffers(sky2); @@ -2411,15 +2431,6 @@ error: goto resubmit; } -/* Transmit complete */ -static inline void sky2_tx_done(struct net_device *dev, u16 last) -{ - struct sky2_port *sky2 = netdev_priv(dev); - - if (netif_running(dev)) - sky2_tx_complete(sky2, last); -} - static inline void sky2_skb_rx(const struct sky2_port *sky2, u32 status, struct sk_buff *skb) { @@ -3176,9 +3187,9 @@ static void sky2_reset(struct sky2_hw *h static void sky2_detach(struct net_device *dev) { if (netif_running(dev)) { - netif_tx_lock(dev); + netif_tx_lock_bh(dev); netif_device_detach(dev); /* stop txq */ - netif_tx_unlock(dev); + netif_tx_unlock_bh(dev); sky2_down(dev); } } @@ -4201,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi /* Dump contents of tx ring */ sop = 1; - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; idx = RING_NEXT(idx, sky2->tx_ring_size)) { const struct sky2_tx_le *le = sky2->tx_le + idx; u32 a = le32_to_cpu(le->addr); --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 @@ -2187,7 +2187,6 @@ struct sky2_port { u16 tx_ring_size; u16 tx_cons; /* next le to check */ u16 tx_prod; /* next le to use */ - u16 tx_next; /* debug only */ u16 tx_pending; u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v3) 2010-01-13 4:10 ` [PATCH] sky2: safer transmit ring cleaning (v3) Stephen Hemminger @ 2010-01-13 4:31 ` Michael Breuer 2010-01-13 7:35 ` Jarek Poplawski 2010-01-13 16:04 ` Michael Breuer 2 siblings, 0 replies; 248+ messages in thread From: Michael Breuer @ 2010-01-13 4:31 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On 01/12/2010 11:10 PM, Stephen Hemminger wrote: > Subject: sky2: safer transmit cleanup > > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > > Signed-off-by: Stephen Hemminger<shemminger@vyatta.com> > > --- > This version adds missing _bh to sky2_detach > > > --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 > +++ b/drivers/net/sky2.c 2010-01-12 17:21:58.415268802 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags& TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,11 +1817,14 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > + if (unlikely(!netif_running(dev))) > + return; > + > BUG_ON(done>= sky2->tx_ring_size); > > for (idx = sky2->tx_cons; idx != done; > @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,13 +1845,10 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > if (tx_avail(sky2)> MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > @@ -1870,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx< sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1933,8 +1954,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2411,15 +2431,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -3176,9 +3187,9 @@ static void sky2_reset(struct sky2_hw *h > static void sky2_detach(struct net_device *dev) > { > if (netif_running(dev)) { > - netif_tx_lock(dev); > + netif_tx_lock_bh(dev); > netif_device_detach(dev); /* stop txq */ > - netif_tx_unlock(dev); > + netif_tx_unlock_bh(dev); > sky2_down(dev); > } > } > @@ -4201,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 > +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; > Will test later - just an FYI - hunk 11 depends on an earlier patch which added the netif_tx_lock(dev). I don't think that was committed. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v3) 2010-01-13 4:10 ` [PATCH] sky2: safer transmit ring cleaning (v3) Stephen Hemminger 2010-01-13 4:31 ` Michael Breuer @ 2010-01-13 7:35 ` Jarek Poplawski 2010-01-13 16:04 ` Michael Breuer 2 siblings, 0 replies; 248+ messages in thread From: Jarek Poplawski @ 2010-01-13 7:35 UTC (permalink / raw) To: Stephen Hemminger Cc: Michael Breuer, David Miller, mikem, flyboy, rjw, netdev On Tue, Jan 12, 2010 at 08:10:12PM -0800, Stephen Hemminger wrote: > Subject: sky2: safer transmit cleanup > > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element I agree this patch makes it safer, but still not really safe, at least compared with the "sky2: Fix oops in sky2_xmit_frame() after TX timeout" patch. Btw, I'm not sure adding netif_running() test to protect dev_close() is really needed, because it's after dev_deactivate(), so re-enabled tx doesn't probably matter. > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> > > --- > This version adds missing _bh to sky2_detach As I wrote before, I doubt adding tx lock alone at this place is the proper fix for anything (the rx (napi) race is the real problem), but without this _bh it's a bug. Jarek P. > > > --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 > +++ b/drivers/net/sky2.c 2010-01-12 17:21:58.415268802 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags & TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,11 +1817,14 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > + if (unlikely(!netif_running(dev))) > + return; > + > BUG_ON(done >= sky2->tx_ring_size); > > for (idx = sky2->tx_cons; idx != done; > @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,13 +1845,10 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > @@ -1870,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx < sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1933,8 +1954,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2411,15 +2431,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -3176,9 +3187,9 @@ static void sky2_reset(struct sky2_hw *h > static void sky2_detach(struct net_device *dev) > { > if (netif_running(dev)) { > - netif_tx_lock(dev); > + netif_tx_lock_bh(dev); > netif_device_detach(dev); /* stop txq */ > - netif_tx_unlock(dev); > + netif_tx_unlock_bh(dev); > sky2_down(dev); > } > } > @@ -4201,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 > +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v3) 2010-01-13 4:10 ` [PATCH] sky2: safer transmit ring cleaning (v3) Stephen Hemminger 2010-01-13 4:31 ` Michael Breuer 2010-01-13 7:35 ` Jarek Poplawski @ 2010-01-13 16:04 ` Michael Breuer 2010-01-14 3:41 ` [PATCH] sky2: safer transmit ring cleaning (v4) Stephen Hemminger 2 siblings, 1 reply; 248+ messages in thread From: Michael Breuer @ 2010-01-13 16:04 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On 1/12/2010 11:10 PM, Stephen Hemminger wrote: > Subject: sky2: safer transmit cleanup > > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > > Signed-off-by: Stephen Hemminger<shemminger@vyatta.com> > > --- > This version adds missing _bh to sky2_detach > > > --- a/drivers/net/sky2.c 2010-01-11 10:49:50.907113126 -0800 > +++ b/drivers/net/sky2.c 2010-01-12 17:21:58.415268802 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags& TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,11 +1817,14 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > + if (unlikely(!netif_running(dev))) > + return; > + > BUG_ON(done>= sky2->tx_ring_size); > > for (idx = sky2->tx_cons; idx != done; > @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,13 +1845,10 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > if (tx_avail(sky2)> MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > @@ -1870,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx< sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1933,8 +1954,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2411,15 +2431,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -3176,9 +3187,9 @@ static void sky2_reset(struct sky2_hw *h > static void sky2_detach(struct net_device *dev) > { > if (netif_running(dev)) { > - netif_tx_lock(dev); > + netif_tx_lock_bh(dev); > netif_device_detach(dev); /* stop txq */ > - netif_tx_unlock(dev); > + netif_tx_unlock_bh(dev); > sky2_down(dev); > } > } > @@ -4201,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-11 17:29:22.817088617 -0800 > +++ b/drivers/net/sky2.h 2010-01-11 17:29:28.197120484 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; > Not sure why, but with this version my system is running hot (literally - higher MB temp & fan speed). This is happening at low throughput. CPU utilization is low - no apparent change from prior versions. The only indication of something amiss is seen using powertop. With older versions, I never noticed (except under load) sky2 interrupt as the main source of system activity. With this version, I see: Top causes for wakeups: 22.9% (525.4) <kernel IPI> : Rescheduling interrupts 20.9% (480.0) <interrupt> : sky2@pci:0000:04:00.0 19.2% (439.2) <interrupt> : extra timer interrupt 18.9% (432.8) <interrupt> : sky2@pci:0000:06:00.0 10.4% (237.4) <kernel core> : hrtimer_start_range_ns (tick_sched_timer) 1.7% ( 38.8) <kernel core> : hrtimer_start (tick_sched_timer) This is pretty consistent, btw regardless of what's going on. 4:00 is the external (100M) interface. Total network activity while this is going on is about 70KB/sec - mostly internal. I'm using msi interrupt (or think I am, anyway). Also - I'm seeing what appears to be increased packet latency (not surprising) and slightly decreased throughput. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-13 16:04 ` Michael Breuer @ 2010-01-14 3:41 ` Stephen Hemminger 2010-01-14 10:14 ` Jarek Poplawski 2010-01-14 15:46 ` [PATCH] sky2: safer transmit ring cleaning (v4) Michael Breuer 0 siblings, 2 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-14 3:41 UTC (permalink / raw) To: Michael Breuer, David Miller; +Cc: jarkao2, mikem, flyboy, rjw, netdev Subject: sky2: safer transmit cleanup This code makes transmit path and transmit reset safer by: * adding memory barrier before checking available ring slots * reseting state of tx ring elements after free * seperate cleanup function from ring done function * removing mostly unused tx_next element * ignoring transmit completion if device is offline Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- This patch is against the current net-next-2.6 tree. This version handles the case of dual port shared transmit status and other cases where it is possible for tx_done to be called when device is being changed. --- a/drivers/net/sky2.c 2010-01-13 08:32:51.360161158 -0800 +++ b/drivers/net/sky2.c 2010-01-13 08:35:37.685531490 -0800 @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct /* Number of list elements available for next tx */ static inline int tx_avail(const struct sky2_port *sky2) { + /* Makes sure update of tx_prod from start_xmit and + tx_cons from tx_done are seen. */ + smp_mb(); return sky2->tx_pending - tx_inuse(sky2); } @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s return count; } -static void sky2_tx_unmap(struct pci_dev *pdev, - const struct tx_ring_info *re) +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) { if (re->flags & TX_MAP_SINGLE) pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), pci_unmap_len(re, maplen), PCI_DMA_TODEVICE); + re->flags = 0; } /* @@ -1804,7 +1807,8 @@ mapping_error: } /* - * Free ring elements from starting at tx_cons until "done" + * Transmit complete processing + * Free ring elements from starting at tx_cons until done index * * NB: * 1. The hardware will tell us about partial completion of multi-part @@ -1813,11 +1817,14 @@ mapping_error: * looks at the tail of the queue of FIFO (tx_cons), not * the head (tx_prod) */ -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) +static void sky2_tx_done(struct net_device *dev, u16 done) { - struct net_device *dev = sky2->netdev; + struct sky2_port *sky2 = netdev_priv(dev); unsigned idx; + if (!(netif_running(dev) & netif_device_present(dev))) + return; + BUG_ON(done >= sky2->tx_ring_size); for (idx = sky2->tx_cons; idx != done; @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 sky2_tx_unmap(sky2->hw->pdev, re); if (skb) { + re->skb = NULL; + if (unlikely(netif_msg_tx_done(sky2))) printk(KERN_DEBUG "%s: tx done %u\n", dev->name, idx); @@ -1836,16 +1845,12 @@ static void sky2_tx_complete(struct sky2 dev->stats.tx_bytes += skb->len; dev_kfree_skb_any(skb); - - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); } } sky2->tx_cons = idx; - smp_mb(); - /* Wake unless it's detached, and called e.g. from sky2_down() */ - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4 && netif_device_present(dev)) + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) netif_wake_queue(dev); } @@ -1871,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); } +static void sky2_tx_clean(struct sky2_port *sky2) +{ + u16 idx; + + for (idx = 0; idx < sky2->tx_ring_size; idx++) { + struct tx_ring_info *re = sky2->tx_ring + idx; + + sky2_tx_unmap(sky2->hw->pdev, re); + if (re->skb) { + dev_kfree_skb_any(re->skb); + re->skb = NULL; + } + } +} + /* Network shutdown */ static int sky2_down(struct net_device *dev) { @@ -1934,8 +1954,7 @@ static int sky2_down(struct net_device * sky2_tx_reset(hw, port); /* Free any pending frames stuck in HW queue */ - sky2_tx_complete(sky2, sky2->tx_prod); - + sky2_tx_clean(sky2); sky2_rx_clean(sky2); sky2_free_buffers(sky2); @@ -2412,15 +2431,6 @@ error: goto resubmit; } -/* Transmit complete */ -static inline void sky2_tx_done(struct net_device *dev, u16 last) -{ - struct sky2_port *sky2 = netdev_priv(dev); - - if (netif_running(dev)) - sky2_tx_complete(sky2, last); -} - static inline void sky2_skb_rx(const struct sky2_port *sky2, u32 status, struct sk_buff *skb) { @@ -3177,9 +3187,9 @@ static void sky2_reset(struct sky2_hw *h static void sky2_detach(struct net_device *dev) { if (netif_running(dev)) { - netif_tx_lock(dev); + netif_tx_lock_bh(dev); netif_device_detach(dev); /* stop txq */ - netif_tx_unlock(dev); + netif_tx_unlock_bh(dev); sky2_down(dev); } } @@ -4202,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi /* Dump contents of tx ring */ sop = 1; - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; idx = RING_NEXT(idx, sky2->tx_ring_size)) { const struct sky2_tx_le *le = sky2->tx_le + idx; u32 a = le32_to_cpu(le->addr); --- a/drivers/net/sky2.h 2010-01-13 08:32:27.919849429 -0800 +++ b/drivers/net/sky2.h 2010-01-13 08:33:03.410162026 -0800 @@ -2187,7 +2187,6 @@ struct sky2_port { u16 tx_ring_size; u16 tx_cons; /* next le to check */ u16 tx_prod; /* next le to use */ - u16 tx_next; /* debug only */ u16 tx_pending; u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 3:41 ` [PATCH] sky2: safer transmit ring cleaning (v4) Stephen Hemminger @ 2010-01-14 10:14 ` Jarek Poplawski 2010-01-14 11:16 ` Jarek Poplawski 2010-01-14 17:52 ` Stephen Hemminger 2010-01-14 15:46 ` [PATCH] sky2: safer transmit ring cleaning (v4) Michael Breuer 1 sibling, 2 replies; 248+ messages in thread From: Jarek Poplawski @ 2010-01-14 10:14 UTC (permalink / raw) To: Stephen Hemminger Cc: Michael Breuer, David Miller, mikem, flyboy, rjw, netdev On Wed, Jan 13, 2010 at 07:41:48PM -0800, Stephen Hemminger wrote: > Subject: sky2: safer transmit cleanup > > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > * ignoring transmit completion if device is offline > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> > > --- > This patch is against the current net-next-2.6 tree. > This version handles the case of dual port shared transmit status > and other cases where it is possible for tx_done to be called when > device is being changed. > > --- a/drivers/net/sky2.c 2010-01-13 08:32:51.360161158 -0800 > +++ b/drivers/net/sky2.c 2010-01-13 08:35:37.685531490 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags & TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,11 +1817,14 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > + if (!(netif_running(dev) & netif_device_present(dev))) This makes it safe, but it still resembles the "short term fix" according do David's opinion. This change seems to affect dev->stats too. Since they are not updated in sky2_tx_clean(). Btw, I hope "&" is some optimization because it's less readable than "&&". Jarek P. > + return; > + > BUG_ON(done >= sky2->tx_ring_size); > > for (idx = sky2->tx_cons; idx != done; > @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,16 +1845,12 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > - /* Wake unless it's detached, and called e.g. from sky2_down() */ > - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4 && netif_device_present(dev)) > + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > } > > @@ -1871,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx < sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1934,8 +1954,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2412,15 +2431,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -3177,9 +3187,9 @@ static void sky2_reset(struct sky2_hw *h > static void sky2_detach(struct net_device *dev) > { > if (netif_running(dev)) { > - netif_tx_lock(dev); > + netif_tx_lock_bh(dev); > netif_device_detach(dev); /* stop txq */ > - netif_tx_unlock(dev); > + netif_tx_unlock_bh(dev); > sky2_down(dev); > } > } > @@ -4202,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod && idx < sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-13 08:32:27.919849429 -0800 > +++ b/drivers/net/sky2.h 2010-01-13 08:33:03.410162026 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 10:14 ` Jarek Poplawski @ 2010-01-14 11:16 ` Jarek Poplawski 2010-01-14 11:20 ` David Miller 2010-01-14 17:52 ` Stephen Hemminger 1 sibling, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-14 11:16 UTC (permalink / raw) To: Stephen Hemminger Cc: Michael Breuer, David Miller, mikem, flyboy, rjw, netdev On Thu, Jan 14, 2010 at 10:14:45AM +0000, Jarek Poplawski wrote: > On Wed, Jan 13, 2010 at 07:41:48PM -0800, Stephen Hemminger wrote: > > Subject: sky2: safer transmit cleanup ... > > + if (!(netif_running(dev) & netif_device_present(dev))) > > This makes it safe, but it still resembles the "short term fix" > according do David's opinion. Hmm... Actually, it's not safe, but still safer again. It looks like David was right (this time ;-). Since netif_device_present() isn't protected by a lock here, this is still racy against napi, since the flag can be set between the test and the wakeup. Btw, there is even no barrier, and in your patch this dangerous distance is made much wider. So, now I really ;-) agree with David: this needs a proper fix. Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 11:16 ` Jarek Poplawski @ 2010-01-14 11:20 ` David Miller 2010-01-14 11:26 ` Jarek Poplawski 0 siblings, 1 reply; 248+ messages in thread From: David Miller @ 2010-01-14 11:20 UTC (permalink / raw) To: jarkao2; +Cc: shemminger, mbreuer, mikem, flyboy, rjw, netdev From: Jarek Poplawski <jarkao2@gmail.com> Date: Thu, 14 Jan 2010 11:16:36 +0000 > So, now I really ;-) agree with David: this needs a proper fix. Now Jarek, do you now see my dirty little secret? When people disagree with me, I just silently sit around waiting for them to eventually change their mind. Isn't it brilliant? -) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 11:20 ` David Miller @ 2010-01-14 11:26 ` Jarek Poplawski 2010-01-14 13:19 ` Mike McCormack 0 siblings, 1 reply; 248+ messages in thread From: Jarek Poplawski @ 2010-01-14 11:26 UTC (permalink / raw) To: David Miller; +Cc: shemminger, mbreuer, mikem, flyboy, rjw, netdev On Thu, Jan 14, 2010 at 03:20:09AM -0800, David Miller wrote: > From: Jarek Poplawski <jarkao2@gmail.com> > Date: Thu, 14 Jan 2010 11:16:36 +0000 > > > So, now I really ;-) agree with David: this needs a proper fix. > > Now Jarek, do you now see my dirty little secret? > > When people disagree with me, I just silently sit around waiting for > them to eventually change their mind. > > Isn't it brilliant? -) If it were that easy... (it never works for me :-() Probably, there is something more... ;-) Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 11:26 ` Jarek Poplawski @ 2010-01-14 13:19 ` Mike McCormack 2010-01-14 15:43 ` Michael Breuer ` (2 more replies) 0 siblings, 3 replies; 248+ messages in thread From: Mike McCormack @ 2010-01-14 13:19 UTC (permalink / raw) To: Jarek Poplawski; +Cc: David Miller, shemminger, mbreuer, flyboy, rjw, netdev Jarek Poplawski wrote: > On Thu, Jan 14, 2010 at 03:20:09AM -0800, David Miller wrote: >> From: Jarek Poplawski <jarkao2@gmail.com> >> Date: Thu, 14 Jan 2010 11:16:36 +0000 >> >>> So, now I really ;-) agree with David: this needs a proper fix. >> Now Jarek, do you now see my dirty little secret? >> >> When people disagree with me, I just silently sit around waiting for >> them to eventually change their mind. >> >> Isn't it brilliant? -) > > If it were that easy... (it never works for me :-() > > Probably, there is something more... ;-) Here's what was sitting in my tree... Subject: [PATCH] sky2: Don't detach device when restarting Block the tx queue from transmitting when restarting rather than trying to take the device offline. Signed-off-by: Mike McCormack <mikem@ring3k.org> --- drivers/net/sky2.c | 13 +++++++++---- 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index d76d907..061f6f2 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -1580,6 +1580,8 @@ static int sky2_up(struct net_device *dev) if (netif_msg_ifup(sky2)) printk(KERN_INFO PFX "%s: enabling interface\n", dev->name); + netif_start_queue(dev); + return 0; err_out: @@ -1596,6 +1598,8 @@ static inline int tx_inuse(const struct sky2_port *sky2) /* Number of list elements available for next tx */ static inline int tx_avail(const struct sky2_port *sky2) { + if (unlikely(!sky2->tx_ring)) + return 0; return sky2->tx_pending - tx_inuse(sky2); } @@ -1925,7 +1929,9 @@ static int sky2_down(struct net_device *dev) sky2_read32(hw, B0_IMSK); synchronize_irq(hw->pdev->irq); - napi_synchronize(&hw->napi); + netif_tx_lock_bh(dev); + napi_disable(&hw->napi); + netif_stop_queue(dev); spin_lock_bh(&sky2->phy_lock); sky2_phy_power_down(hw, port); @@ -1939,6 +1945,8 @@ static int sky2_down(struct net_device *dev) sky2_rx_clean(sky2); sky2_free_buffers(sky2); + napi_enable(&hw->napi); + netif_tx_unlock_bh(dev); return 0; } @@ -3177,9 +3185,6 @@ static void sky2_reset(struct sky2_hw *hw) static void sky2_detach(struct net_device *dev) { if (netif_running(dev)) { - netif_tx_lock_bh(dev); - netif_device_detach(dev); /* stop txq */ - netif_tx_unlock_bh(dev); sky2_down(dev); } } -- 1.5.6.5 ^ permalink raw reply related [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 13:19 ` Mike McCormack @ 2010-01-14 15:43 ` Michael Breuer 2010-01-14 16:46 ` Michael Breuer 2010-01-14 17:51 ` Stephen Hemminger 2 siblings, 0 replies; 248+ messages in thread From: Michael Breuer @ 2010-01-14 15:43 UTC (permalink / raw) To: Mike McCormack Cc: Jarek Poplawski, David Miller, shemminger, flyboy, rjw, netdev On 1/14/2010 8:19 AM, Mike McCormack wrote: > Here's what was sitting in my tree... > ... > err_out: > @@ -1596,6 +1598,8 @@ static inline int tx_inuse(const struct sky2_port *sky2) > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + if (unlikely(!sky2->tx_ring)) > + return 0; > return sky2->tx_pending - tx_inuse(sky2); > } > This hunk (patch) conflicts with the v4 patch Stephen sent out last night. He added an smp_mb in front of the return. I'm going to give this a go with the smb_mb before the unlikely test. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 13:19 ` Mike McCormack 2010-01-14 15:43 ` Michael Breuer @ 2010-01-14 16:46 ` Michael Breuer 2010-01-14 17:51 ` Stephen Hemminger 2 siblings, 0 replies; 248+ messages in thread From: Michael Breuer @ 2010-01-14 16:46 UTC (permalink / raw) To: Mike McCormack Cc: Jarek Poplawski, David Miller, shemminger, flyboy, rjw, netdev On 1/14/2010 8:19 AM, Mike McCormack wrote: > Jarek Poplawski wrote: > >> On Thu, Jan 14, 2010 at 03:20:09AM -0800, David Miller wrote: >> >>> From: Jarek Poplawski<jarkao2@gmail.com> >>> Date: Thu, 14 Jan 2010 11:16:36 +0000 >>> >>> >>>> So, now I really ;-) agree with David: this needs a proper fix. >>>> >>> Now Jarek, do you now see my dirty little secret? >>> >>> When people disagree with me, I just silently sit around waiting for >>> them to eventually change their mind. >>> >>> Isn't it brilliant? -) >>> >> If it were that easy... (it never works for me :-() >> >> Probably, there is something more... ;-) >> > Here's what was sitting in my tree... > > > Subject: [PATCH] sky2: Don't detach device when restarting > > Block the tx queue from transmitting when restarting > rather than trying to take the device offline. > > Signed-off-by: Mike McCormack<mikem@ring3k.org> > --- > drivers/net/sky2.c | 13 +++++++++---- > 1 files changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c > index d76d907..061f6f2 100644 > --- a/drivers/net/sky2.c > +++ b/drivers/net/sky2.c > @@ -1580,6 +1580,8 @@ static int sky2_up(struct net_device *dev) > if (netif_msg_ifup(sky2)) > printk(KERN_INFO PFX "%s: enabling interface\n", dev->name); > > + netif_start_queue(dev); > + > return 0; > > err_out: > @@ -1596,6 +1598,8 @@ static inline int tx_inuse(const struct sky2_port *sky2) > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + if (unlikely(!sky2->tx_ring)) > + return 0; > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1925,7 +1929,9 @@ static int sky2_down(struct net_device *dev) > sky2_read32(hw, B0_IMSK); > > synchronize_irq(hw->pdev->irq); > - napi_synchronize(&hw->napi); > + netif_tx_lock_bh(dev); > + napi_disable(&hw->napi); > + netif_stop_queue(dev); > > spin_lock_bh(&sky2->phy_lock); > sky2_phy_power_down(hw, port); > @@ -1939,6 +1945,8 @@ static int sky2_down(struct net_device *dev) > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > + napi_enable(&hw->napi); > + netif_tx_unlock_bh(dev); > > return 0; > } > @@ -3177,9 +3185,6 @@ static void sky2_reset(struct sky2_hw *hw) > static void sky2_detach(struct net_device *dev) > { > if (netif_running(dev)) { > - netif_tx_lock_bh(dev); > - netif_device_detach(dev); /* stop txq */ > - netif_tx_unlock_bh(dev); > sky2_down(dev); > } > } > -- 1.5.6.5 > Ok - no obvious difference with this patch + Stephen's. I still see: No reported errors; decent throughput; earlier issues with IRQ resolved. But... still seeing DHCP DISCOVER/OFFER (no REQUEST/ACK) while under load. I can try to sniff this... but given that it's under load, I'd probably have to filter out non DHCP stuff and might miss whatever is really going on. Again - main point here is that absent these patches I don't see this issue. It's also possible that these two patches allow the load to be heavier thus actually causing a different problem. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 13:19 ` Mike McCormack 2010-01-14 15:43 ` Michael Breuer 2010-01-14 16:46 ` Michael Breuer @ 2010-01-14 17:51 ` Stephen Hemminger 2 siblings, 0 replies; 248+ messages in thread From: Stephen Hemminger @ 2010-01-14 17:51 UTC (permalink / raw) To: Mike McCormack Cc: Jarek Poplawski, David Miller, mbreuer, flyboy, rjw, netdev On Thu, 14 Jan 2010 22:19:39 +0900 Mike McCormack <mikem@ring3k.org> wrote: > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + if (unlikely(!sky2->tx_ring)) > + return 0; > return sky2->tx_pending - tx_inuse(sky2); > } > Breaks in detach case > @@ -1925,7 +1929,9 @@ static int sky2_down(struct net_device *dev) > sky2_read32(hw, B0_IMSK); > > synchronize_irq(hw->pdev->irq); > - napi_synchronize(&hw->napi); > + netif_tx_lock_bh(dev); > + napi_disable(&hw->napi); > + netif_stop_queue(dev); > > spin_lock_bh(&sky2->phy_lock); > sky2_phy_power_down(hw, port); > @@ -1939,6 +1945,8 @@ static int sky2_down(struct net_device *dev) > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > + napi_enable(&hw->napi); > + netif_tx_unlock_bh(dev); > > return 0; Breaks on dual ported boards ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 10:14 ` Jarek Poplawski 2010-01-14 11:16 ` Jarek Poplawski @ 2010-01-14 17:52 ` Stephen Hemminger 2010-01-14 23:51 ` Michael Breuer 1 sibling, 1 reply; 248+ messages in thread From: Stephen Hemminger @ 2010-01-14 17:52 UTC (permalink / raw) To: Jarek Poplawski; +Cc: Michael Breuer, David Miller, mikem, flyboy, rjw, netdev On Thu, 14 Jan 2010 10:14:45 +0000 Jarek Poplawski <jarkao2@gmail.com> wrote: > This makes it safe, but it still resembles the "short term fix" > according do David's opinion. > > This change seems to affect dev->stats too. Since they are not > updated in sky2_tx_clean(). Btw, I hope "&" is some optimization > because it's less readable than "&&". Stats don't matter for packets flushed during device reset. The & is because in the most common case device is up, and we don't want the additional conditional branch. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 17:52 ` Stephen Hemminger @ 2010-01-14 23:51 ` Michael Breuer 2010-01-16 18:35 ` sky2 DHCPOFFER packet loss under load (Was Re: [PATCH] sky2: safer transmit ring cleaning (v4)) Michael Breuer 0 siblings, 1 reply; 248+ messages in thread From: Michael Breuer @ 2010-01-14 23:51 UTC (permalink / raw) To: Stephen Hemminger Cc: Jarek Poplawski, David Miller, mikem, flyboy, rjw, netdev On 1/14/2010 12:52 PM, Stephen Hemminger wrote: > On Thu, 14 Jan 2010 10:14:45 +0000 > Jarek Poplawski<jarkao2@gmail.com> wrote: > > >> This makes it safe, but it still resembles the "short term fix" >> according do David's opinion. >> >> This change seems to affect dev->stats too. Since they are not >> updated in sky2_tx_clean(). Btw, I hope "&" is some optimization >> because it's less readable than "&&". >> > Stats don't matter for packets flushed during device reset. > > The& is because in the most common case device is up, > and we don't want the additional conditional branch. > I've been looking at what might explain the dhcp stuff - as well as the dropped packets only when there's an extra hop. I came across one path that seems suspect - although I'm really not familiar with the network stack code... that said, I'm wondering about neigh_compat_output (and eth_rebuild_header and arp_find). If I'm following things correctly (or perhaps mostly correctly), the only time anything goes this route (pun intentional) is when the packet was routed to this box. I'm guessing that bridging makes this more likely. So my dhcp stuff would all be going through here, as would the smb stuff that seemed flaky. The race I'm seeing (maybe) is that when the arp table is being rebuilt, there's a possibility that arp_find frees the skb. There's some other locking and stuff going on that seems maybe races with sky2.c in places on both the rx and tx path. I *think* it's right from looking at it, but test results suggest otherwise. Aside from the potential race, I think there's also a corner case where neigh_compat_output can return either with or without freeing the skb depending on the return from dev_hard_header... this may also be part of the race. Maybe I've missed something... but as far as I can see, this is just about the only difference in code path taken between stuff that is working and stuff that is occasionally not. ^ permalink raw reply [flat|nested] 248+ messages in thread
* sky2 DHCPOFFER packet loss under load (Was Re: [PATCH] sky2: safer transmit ring cleaning (v4)) 2010-01-14 23:51 ` Michael Breuer @ 2010-01-16 18:35 ` Michael Breuer 0 siblings, 0 replies; 248+ messages in thread From: Michael Breuer @ 2010-01-16 18:35 UTC (permalink / raw) To: Stephen Hemminger Cc: Jarek Poplawski, David Miller, mikem, flyboy, rjw, netdev On 1/14/2010 6:51 PM, Michael Breuer wrote: > On 1/14/2010 12:52 PM, Stephen Hemminger wrote: >> On Thu, 14 Jan 2010 10:14:45 +0000 >> Jarek Poplawski<jarkao2@gmail.com> wrote: >> >>> This makes it safe, but it still resembles the "short term fix" >>> according do David's opinion. >>> >>> This change seems to affect dev->stats too. Since they are not >>> updated in sky2_tx_clean(). Btw, I hope "&" is some optimization >>> because it's less readable than "&&". >> Stats don't matter for packets flushed during device reset. >> >> The& is because in the most common case device is up, >> and we don't want the additional conditional branch. > I've been looking at what might explain the dhcp stuff - as well as > the dropped packets only when there's an extra hop. I came across one > path that seems suspect - although I'm really not familiar with the > network stack code... that said, I'm wondering about > neigh_compat_output (and eth_rebuild_header and arp_find). If I'm > following things correctly (or perhaps mostly correctly), the only > time anything goes this route (pun intentional) is when the packet was > routed to this box. I'm guessing that bridging makes this more likely. > So my dhcp stuff would all be going through here, as would the smb > stuff that seemed flaky. The race I'm seeing (maybe) is that when the > arp table is being rebuilt, there's a possibility that arp_find frees > the skb. There's some other locking and stuff going on that seems > maybe races with sky2.c in places on both the rx and tx path. I > *think* it's right from looking at it, but test results suggest > otherwise. Aside from the potential race, I think there's also a > corner case where neigh_compat_output can return either with or > without freeing the skb depending on the return from > dev_hard_header... this may also be part of the race. > > Maybe I've missed something... but as far as I can see, this is just > about the only difference in code path taken between stuff that is > working and stuff that is occasionally not. Ok - brief update. I've confirmed that under load, outgoing DHCPOFFER packets are being silently dropped. I don't know yet where. Test scenario, what I do know, etc.: Scenario: Two systems; one Gb switch; one wifi router; one Blackberry client. System A: Linux host; Asus P6T Deluxe V2/Sky2. eth1-> internet eth0-> internal (10.0.0.1/24). Switch: HP Procurve unmanaged - one port connected to System A; another to the wifi router; another to System B. System B: Win7; Asus M2N Deluxe SLI/ Nforce 5 (10.0.0.11) Router: Wrt54g-tm (dd-wrt) Connected to switch & various wifi clients including a Blackberry. WEP enabled. (10.0.0.60) Blackberry Curve 8320 (wifi enabled). (10.0.0.56 via dhcp lease) Test that causes packet loss: 1. Turn off BB wifi. 2. Start copy of large files (4GB) from System B to an CIFS share on System A. 3. Start nethogs on system A. 4. Start tcpdump on the wifi router (interface br0 - wired 10.0.0.60 connection) 5. Start wireshark on System A 6. tail system A /var/log/messages - watching for DHCP activity 7. When smb traffic load (incoming) exceeds 40,000KBPS (nethogs) - enable wifi on the blackberry. 8. Stop test after multiple DHCPDISCOVER/OFFER observed without REQUEST/ACK. Results: 1. It seems that the problem occurs intermittently below 40,000KBPS, and consistently over that number as reported by nethogs. Lots of fluctuation, so figure that the 40k is approximate. 2. wireshark (system A) shows DHCPOFFER traffic outgoing. 3. tcpdump (wifi - wired incoming interface) does NOT show DHCPOFFER traffic when this problem occurs. 4. Both traces show arp activity during the DISCOVER/OFFER sequence. 5. There is no evidence of tx errors or packet drops, in any statistics I can find. Thoughts: I still think there's a race happening between the arp neighbor update and sky2. Might be higher up, but as I'm seeing the outgoing packets when sniffing eth0, can't be too much higher up. This problem seems to be exacerbated by the more recent patches, however I believe that this is a result of the higher throughput achievable with these patches. With the older set, I saw this problem less frequently, but found it much harder to get over the 40K RX number. I am also seeing (as previously reported - but haven't sniffed yet) SMB ACK dropped packets, but only when traversing the wifi router. Not sure if this is related, but hey, you never know. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [PATCH] sky2: safer transmit ring cleaning (v4) 2010-01-14 3:41 ` [PATCH] sky2: safer transmit ring cleaning (v4) Stephen Hemminger 2010-01-14 10:14 ` Jarek Poplawski @ 2010-01-14 15:46 ` Michael Breuer 1 sibling, 0 replies; 248+ messages in thread From: Michael Breuer @ 2010-01-14 15:46 UTC (permalink / raw) To: Stephen Hemminger; +Cc: David Miller, jarkao2, mikem, flyboy, rjw, netdev On 1/13/2010 10:41 PM, Stephen Hemminger wrote: > Subject: sky2: safer transmit cleanup > > This code makes transmit path and transmit reset safer by: > * adding memory barrier before checking available ring slots > * reseting state of tx ring elements after free > * seperate cleanup function from ring done function > * removing mostly unused tx_next element > * ignoring transmit completion if device is offline > > Signed-off-by: Stephen Hemminger<shemminger@vyatta.com> > > --- > This patch is against the current net-next-2.6 tree. > This version handles the case of dual port shared transmit status > and other cases where it is possible for tx_done to be called when > device is being changed. > > --- a/drivers/net/sky2.c 2010-01-13 08:32:51.360161158 -0800 > +++ b/drivers/net/sky2.c 2010-01-13 08:35:37.685531490 -0800 > @@ -1596,6 +1596,9 @@ static inline int tx_inuse(const struct > /* Number of list elements available for next tx */ > static inline int tx_avail(const struct sky2_port *sky2) > { > + /* Makes sure update of tx_prod from start_xmit and > + tx_cons from tx_done are seen. */ > + smp_mb(); > return sky2->tx_pending - tx_inuse(sky2); > } > > @@ -1618,8 +1621,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags& TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1629,6 +1631,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1804,7 +1807,8 @@ mapping_error: > } > > /* > - * Free ring elements from starting at tx_cons until "done" > + * Transmit complete processing > + * Free ring elements from starting at tx_cons until done index > * > * NB: > * 1. The hardware will tell us about partial completion of multi-part > @@ -1813,11 +1817,14 @@ mapping_error: > * looks at the tail of the queue of FIFO (tx_cons), not > * the head (tx_prod) > */ > -static void sky2_tx_complete(struct sky2_port *sky2, u16 done) > +static void sky2_tx_done(struct net_device *dev, u16 done) > { > - struct net_device *dev = sky2->netdev; > + struct sky2_port *sky2 = netdev_priv(dev); > unsigned idx; > > + if (!(netif_running(dev)& netif_device_present(dev))) > + return; > + > BUG_ON(done>= sky2->tx_ring_size); > > for (idx = sky2->tx_cons; idx != done; > @@ -1828,6 +1835,8 @@ static void sky2_tx_complete(struct sky2 > sky2_tx_unmap(sky2->hw->pdev, re); > > if (skb) { > + re->skb = NULL; > + > if (unlikely(netif_msg_tx_done(sky2))) > printk(KERN_DEBUG "%s: tx done %u\n", > dev->name, idx); > @@ -1836,16 +1845,12 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_bytes += skb->len; > > dev_kfree_skb_any(skb); > - > - sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > } > } > > sky2->tx_cons = idx; > - smp_mb(); > > - /* Wake unless it's detached, and called e.g. from sky2_down() */ > - if (tx_avail(sky2)> MAX_SKB_TX_LE + 4&& netif_device_present(dev)) > + if (tx_avail(sky2)> MAX_SKB_TX_LE + 4) > netif_wake_queue(dev); > } > > @@ -1871,6 +1876,21 @@ static void sky2_tx_reset(struct sky2_hw > sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_RST_SET); > } > > +static void sky2_tx_clean(struct sky2_port *sky2) > +{ > + u16 idx; > + > + for (idx = 0; idx< sky2->tx_ring_size; idx++) { > + struct tx_ring_info *re = sky2->tx_ring + idx; > + > + sky2_tx_unmap(sky2->hw->pdev, re); > + if (re->skb) { > + dev_kfree_skb_any(re->skb); > + re->skb = NULL; > + } > + } > +} > + > /* Network shutdown */ > static int sky2_down(struct net_device *dev) > { > @@ -1934,8 +1954,7 @@ static int sky2_down(struct net_device * > sky2_tx_reset(hw, port); > > /* Free any pending frames stuck in HW queue */ > - sky2_tx_complete(sky2, sky2->tx_prod); > - > + sky2_tx_clean(sky2); > sky2_rx_clean(sky2); > > sky2_free_buffers(sky2); > @@ -2412,15 +2431,6 @@ error: > goto resubmit; > } > > -/* Transmit complete */ > -static inline void sky2_tx_done(struct net_device *dev, u16 last) > -{ > - struct sky2_port *sky2 = netdev_priv(dev); > - > - if (netif_running(dev)) > - sky2_tx_complete(sky2, last); > -} > - > static inline void sky2_skb_rx(const struct sky2_port *sky2, > u32 status, struct sk_buff *skb) > { > @@ -3177,9 +3187,9 @@ static void sky2_reset(struct sky2_hw *h > static void sky2_detach(struct net_device *dev) > { > if (netif_running(dev)) { > - netif_tx_lock(dev); > + netif_tx_lock_bh(dev); > netif_device_detach(dev); /* stop txq */ > - netif_tx_unlock(dev); > + netif_tx_unlock_bh(dev); > sky2_down(dev); > } > } > @@ -4202,7 +4212,7 @@ static int sky2_debug_show(struct seq_fi > > /* Dump contents of tx ring */ > sop = 1; > - for (idx = sky2->tx_next; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > + for (idx = sky2->tx_cons; idx != sky2->tx_prod&& idx< sky2->tx_ring_size; > idx = RING_NEXT(idx, sky2->tx_ring_size)) { > const struct sky2_tx_le *le = sky2->tx_le + idx; > u32 a = le32_to_cpu(le->addr); > --- a/drivers/net/sky2.h 2010-01-13 08:32:27.919849429 -0800 > +++ b/drivers/net/sky2.h 2010-01-13 08:33:03.410162026 -0800 > @@ -2187,7 +2187,6 @@ struct sky2_port { > u16 tx_ring_size; > u16 tx_cons; /* next le to check */ > u16 tx_prod; /* next le to use */ > - u16 tx_next; /* debug only */ > > u16 tx_pending; > u16 tx_last_mss; > Tested this a bit (w/o Mike's patch from this morning). Overall, works (vs. v3), but still something flaky going on WRT dhcp traffic: Under load (and only under load) I'm seeing mutliple failed dhcp client requests - 4-6 discover/offer sequences before I see request/ack. I don't see errors, dropped packets, etc., at the time this is happening. I'd blow it off to load, but I don't see this with the earlier (pskb_may_pull) patch. Going to rebuild with the inclusion of Mike's patch and see what happens. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14925] sky2 panic under load 2010-01-11 16:45 ` Stephen Hemminger 2010-01-11 22:07 ` Jarek Poplawski @ 2010-01-11 22:31 ` Jarek Poplawski 1 sibling, 0 replies; 248+ messages in thread From: Jarek Poplawski @ 2010-01-11 22:31 UTC (permalink / raw) To: Stephen Hemminger Cc: Mike McCormack, Berck E. Nash, Rafael J. Wysocki, netdev On Mon, Jan 11, 2010 at 08:45:04AM -0800, Stephen Hemminger wrote: > On Mon, 11 Jan 2010 23:03:41 +0900 > Mike McCormack <mikem@ring3k.org> wrote: > > > Perhaps only sky2_tx_done should wake the queue? > > Does the patch below fix the problem too? > > > > thanks, > > > > Mike > > The idea is good, but what if transmit queue was full (stopped), > and TX FIFO gets stuck. Then Transmit timeout happens and > the reset logic clears the queue. What will start the queue? > > Something like this: > ----------------------------------------------------------- > > > > --- a/drivers/net/sky2.c 2010-01-11 08:36:42.617426300 -0800 > +++ b/drivers/net/sky2.c 2010-01-11 08:42:51.295237661 -0800 > @@ -1843,9 +1843,6 @@ static void sky2_tx_complete(struct sky2 > > sky2->tx_cons = idx; > smp_mb(); > - > - if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > - netif_wake_queue(dev); > } > > static void sky2_tx_reset(struct sky2_hw *hw, unsigned port) > @@ -2416,8 +2413,12 @@ static inline void sky2_tx_done(struct n > { > struct sky2_port *sky2 = netdev_priv(dev); > > - if (netif_running(dev)) > + if (netif_running(dev) && netif_device_present(dev)) { > sky2_tx_complete(sky2, last); > + > + if (tx_avail(sky2) > MAX_SKB_TX_LE + 4) > + netif_wake_queue(dev); > + } > } > > static inline void sky2_skb_rx(const struct sky2_port *sky2, > @@ -3197,6 +3198,7 @@ static int sky2_reattach(struct net_devi > } else { > netif_device_attach(dev); > sky2_set_multicast(dev); > + netif_start_queue(dev); Why netif_device_attach() is not enough? Jarek P. ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU 2010-01-10 22:27 ` Rafael J. Wysocki ` (11 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 3:39 ` Sid Boyce -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Sid Boyce This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce@blueyonder.co.uk> Date : 2009-12-23 16:55 (19 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU 2010-01-10 22:32 ` [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU Rafael J. Wysocki @ 2010-01-11 3:39 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-11 3:39 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 1661 bytes --] On 10/01/10 22:32, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 > Subject : All kernels after 2.6.32-git10 show only 1 CPU > Submitter : Sid Boyce <sboyce@blueyonder.co.uk> > Date : 2009-12-23 16:55 (19 days old) > References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 > > > > With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its locking up solid at this part of the boot process as usual. ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) -> IRQ 22. With acpi=noirq (2 CPU's) ================ kvm: Nested Virtualization enabled. IT8716 Super IO detected Parport_PC 00:0a: reported by plug and Play ACPI Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] parport: irq 7 in use, resorting to polled operation HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 With acpi=ht (1 CPU) ============= Hangs at:- Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for vector (irq -1) With acpi=off (2 CPU's) ======================== Hangs at same point as with acpi=noirq. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks [-- Attachment #2: config_2.6.33-rc3-git3-tindog --] [-- Type: text/plain, Size: 51981 bytes --] CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" 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_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y 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=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y 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_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_TRAMPOLINE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-smp" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_KERNEL_GZIP=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_TREE_RCU=y CONFIG_RCU_FANOUT=64 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUPS=y CONFIG_CGROUP_NS=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_MM_OWNER=y CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_EVENT_PROFILE=y CONFIG_PERF_COUNTERS=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y CONFIG_SLUB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=m CONFIG_OPROFILE_EVENT_MULTIPLEX=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_SLOW_WORK=y CONFIG_SLOW_WORK_DEBUG=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y CONFIG_INLINE_SPIN_UNLOCK=y CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_FREEZER=y CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_MPPARSE=y CONFIG_X86_EXTENDED_PLATFORM=y CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT_GUEST=y CONFIG_XEN=y CONFIG_XEN_MAX_DOMAIN_MEMORY=32 CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_CLOCK=y CONFIG_PARAVIRT_DEBUG=y CONFIG_MEMTEST=y CONFIG_GENERIC_CPU=y CONFIG_X86_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=7 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_WP_WORKS_OK=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=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y CONFIG_AMD_IOMMU=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_API=y CONFIG_NR_CPUS=128 CONFIG_SCHED_MC=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_CPU_DEBUG=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y CONFIG_NODES_SHIFT=9 CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y CONFIG_HWPOISON_INJECT=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y CONFIG_X86_RESERVE_LOW_64K=y CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_EFI=y CONFIG_SECCOMP=y CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_KEXEC_JUMP=y CONFIG_PHYSICAL_START=0x200000 CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_PM=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATION_NVS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_RUNTIME=y CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_POWER_METER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_NUMA=y CONFIG_ACPI_CUSTOM_DSDT_FILE="" CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_PCI_SLOT=m CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K8=m CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y CONFIG_PCIEAER_INJECT=m CONFIG_PCIEASPM=y CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y CONFIG_HT_IRQ=y CONFIG_PCI_IOV=y CONFIG_PCI_IOAPIC=y CONFIG_ISA_DMA_API=y CONFIG_K8_NB=y CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y 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=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=y CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m CONFIG_DEFAULT_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=m CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_SUBTREES=y CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_DCCP=m CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_HL=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_HL=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_NETFILTER_XT_MATCH_OSF=m CONFIG_IP_VS=m CONFIG_IP_VS_TAB_BITS=12 CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_DCCP=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_RAW=m CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_IP6=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_BRIDGE_EBT_NFLOG=m CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m CONFIG_IP_DCCP_CCID3=y CONFIG_IP_DCCP_CCID3_RTO=100 CONFIG_IP_DCCP_TFRC_LIB=y CONFIG_IP_SCTP=m CONFIG_SCTP_HMAC_MD5=y CONFIG_RDS=m CONFIG_RDS_TCP=m CONFIG_STP=m CONFIG_GARP=m CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m CONFIG_VLAN_8021Q_GVRP=y CONFIG_LLC=m CONFIG_LLC2=m CONFIG_IPX=m CONFIG_IPX_INTERN=y CONFIG_IEEE802154=m CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_DRR=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_FLOW=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m CONFIG_NET_SCH_FIFO=y CONFIG_NET_PKTGEN=m CONFIG_NET_TCPPROBE=m CONFIG_HAMRADIO=y CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_YAM=m CONFIG_IRDA=m CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRTTY_SIR=m CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_TOIM3232_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m CONFIG_KINGSUN_DONGLE=m CONFIG_KSDAZZLE_DONGLE=m CONFIG_KS959_DONGLE=m CONFIG_USB_IRDA=m CONFIG_SIGMATEL_FIR=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m CONFIG_MCS_FIR=m CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTSDIO=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m CONFIG_BT_MRVL=m CONFIG_BT_MRVL_SDIO=m CONFIG_AF_RXRPC=m CONFIG_RXKAD=m CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211=m CONFIG_CFG80211_REG_DEBUG=y CONFIG_CFG80211_DEFAULT_PS=y CONFIG_CFG80211_DEBUGFS=y CONFIG_CFG80211_WEXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_LIB80211=m CONFIG_LIB80211_CRYPT_WEP=m CONFIG_LIB80211_CRYPT_CCMP=m CONFIG_LIB80211_CRYPT_TKIP=m CONFIG_MAC80211=m CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUGFS=y CONFIG_WIMAX=m CONFIG_WIMAX_DEBUG_LEVEL=8 CONFIG_RFKILL=m CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y CONFIG_UEVENT_HELPER_PATH="" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_SYS_HYPERVISOR=y CONFIG_CONNECTOR=m CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y CONFIG_PARPORT_AX88796=m CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_SX8=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=128000 CONFIG_BLK_DEV_XIP=y CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_CDROM_PKTCDVD_WCACHE=y CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_VIRTIO_BLK=m CONFIG_MISC_DEVICES=y CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m CONFIG_ENCLOSURE_SERVICES=m CONFIG_DS1682=m CONFIG_EEPROM_AT24=m CONFIG_EEPROM_LEGACY=m CONFIG_EEPROM_MAX6875=m CONFIG_EEPROM_93CX6=m CONFIG_CB710_CORE=m CONFIG_CB710_DEBUG_ASSUMPTIONS=y CONFIG_HAVE_IDE=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y CONFIG_SCSI_SAS_LIBSAS_DEBUG=y CONFIG_SCSI_SRP_ATTRS=m CONFIG_SCSI_SRP_TGT_ATTRS=y CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_SCSI_BNX2_ISCSI=m CONFIG_SCSI_MVSAS=m CONFIG_SCSI_MVSAS_DEBUG=y CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_SCSI_DH=m CONFIG_ATA=m CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y CONFIG_SATA_AHCI=m CONFIG_ATA_SFF=y CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SX4=m CONFIG_SATA_VIA=m CONFIG_PATA_ACPI=m CONFIG_PATA_AMD=m CONFIG_PATA_ATP867X=m CONFIG_ATA_GENERIC=m CONFIG_PATA_JMICRON=m CONFIG_PATA_MARVELL=m CONFIG_PATA_PDC2027X=m CONFIG_PATA_VIA=m CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MULTICORE_RAID456=y CONFIG_MD_RAID6_PQ=m CONFIG_ASYNC_RAID6_TEST=m CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_QL=m CONFIG_DM_MULTIPATH_ST=m CONFIG_DM_DELAY=m CONFIG_DM_UEVENT=y CONFIG_IEEE1394=m CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_DV1394=m CONFIG_NETDEVICES=y CONFIG_IFB=m CONFIG_BONDING=m CONFIG_MACVLAN=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_PHYLIB=m CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_BROADCOM_PHY=m CONFIG_REALTEK_PHY=m CONFIG_NATIONAL_PHY=m CONFIG_STE10XP=m CONFIG_LSI_ET1011C_PHY=m CONFIG_NET_ETHERNET=y CONFIG_MII=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_ADAPTEC_STARFIRE=m CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_FORCEDETH=m CONFIG_FORCEDETH_NAPI=y CONFIG_E100=m CONFIG_8139CP=m CONFIG_8139TOO=m CONFIG_8139TOO_8129=y CONFIG_NETDEV_1000=y CONFIG_E1000=m CONFIG_E1000E=m CONFIG_R8169=m CONFIG_R8169_VLAN=y CONFIG_SKY2=m CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=m CONFIG_BNX2=m CONFIG_CNIC=m CONFIG_JME=m CONFIG_WLAN=y CONFIG_LIBERTAS_THINFIRM=m CONFIG_LIBERTAS_THINFIRM_USB=m CONFIG_AIRO=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m CONFIG_AT76C50X_USB=m CONFIG_PRISM54=m CONFIG_USB_ZD1201=m CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_RTL8180=m CONFIG_RTL8187=m CONFIG_RTL8187_LEDS=y CONFIG_ADM8211=m CONFIG_MAC80211_HWSIM=m CONFIG_MWL8K=m CONFIG_ATH_COMMON=m CONFIG_ATH5K=m CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K=m CONFIG_B43=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_SDIO=y CONFIG_B43_PIO=y CONFIG_B43_PHY_LP=y CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_PCI=m CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y CONFIG_LIBIPW=m CONFIG_IWLWIFI=m CONFIG_IWLAGN=m CONFIG_IWL4965=y CONFIG_IWL5000=y CONFIG_IWL3945=m CONFIG_IWL3945_SPECTRUM_MEASUREMENT=y CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m CONFIG_HERMES=m CONFIG_HERMES_CACHE_FW_ON_INIT=y CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_NORTEL_HERMES=m CONFIG_PCI_HERMES=m CONFIG_P54_COMMON=m CONFIG_P54_USB=m CONFIG_P54_PCI=m CONFIG_P54_LEDS=y CONFIG_RT2X00=m CONFIG_RT2400PCI=m CONFIG_RT2500PCI=m CONFIG_RT61PCI=m CONFIG_RT2800PCI_PCI=m CONFIG_RT2800PCI=m CONFIG_RT2500USB=m CONFIG_RT73USB=m CONFIG_RT2800USB=m CONFIG_RT2800_LIB=m CONFIG_RT2X00_LIB_PCI=m CONFIG_RT2X00_LIB_USB=m CONFIG_RT2X00_LIB=m CONFIG_RT2X00_LIB_HT=y CONFIG_RT2X00_LIB_FIRMWARE=y CONFIG_RT2X00_LIB_CRYPTO=y CONFIG_RT2X00_LIB_LEDS=y CONFIG_ZD1211RW=m CONFIG_WIMAX_I2400M=m CONFIG_WIMAX_I2400M_USB=m CONFIG_WIMAX_I2400M_SDIO=m CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8 CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_USB_HSO=m CONFIG_IEEE802154_DRIVERS=m CONFIG_XEN_NETDEV_FRONTEND=y CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOL2TP=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLHC=m CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y CONFIG_VIRTIO_NET=m CONFIG_VMXNET3=m CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_POLLDEV=m CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=y CONFIG_XEN_KBDDEV_FRONTEND=y CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_NEWTON=m CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y 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_SERIAL=m CONFIG_INPUT_JOYSTICK=y CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=m CONFIG_TABLET_USB_AIPTEK=m CONFIG_TABLET_USB_GTCO=m CONFIG_TABLET_USB_KBTAB=m CONFIG_TABLET_USB_WACOM=m CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=8 CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=0 CONFIG_PRINTER=m CONFIG_PPDEV=m CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_VIRTIO_CONSOLE=m CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_TIMERIOMEM=y CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_VIA=y CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=y CONFIG_PC8736x_GPIO=m CONFIG_NSC_GPIO=m CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=4096 CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=m CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=m CONFIG_I2C_TINY_USB=m CONFIG_PPS=m CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_POWER_SUPPLY=y CONFIG_POWER_SUPPLY_DEBUG=y CONFIG_PDA_POWER=m CONFIG_HWMON=y CONFIG_HWMON_VID=m CONFIG_SENSORS_ABITUGURU=m CONFIG_SENSORS_ABITUGURU3=m CONFIG_SENSORS_AD7414=m CONFIG_SENSORS_AD7418=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m CONFIG_SENSORS_ADT7462=m CONFIG_SENSORS_ADT7470=m CONFIG_SENSORS_ADT7473=m CONFIG_SENSORS_ADT7475=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_I5K_AMB=m CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_F71882FG=m CONFIG_SENSORS_F75375S=m CONFIG_SENSORS_FSCHMD=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_CORETEMP=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m CONFIG_SENSORS_LM93=m CONFIG_SENSORS_LTC4215=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_MAX6650=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_DME1737=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_ADS7828=m CONFIG_SENSORS_THMC50=m CONFIG_SENSORS_TMP421=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83L786NG=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_HDAPS=m CONFIG_SENSORS_APPLESMC=m CONFIG_SENSORS_ATK0110=m CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=y CONFIG_WATCHDOG=y CONFIG_SOFT_WATCHDOG=m CONFIG_IT87_WDT=y CONFIG_SSB_POSSIBLE=y CONFIG_SSB=m CONFIG_SSB_SPROM=y CONFIG_SSB_BLOCKIO=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_SDIOHOST_POSSIBLE=y CONFIG_SSB_SDIOHOST=y CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_MEDIA_SUPPORT=m CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_DVB_CORE=m CONFIG_VIDEO_MEDIA=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_IR_CORE=m CONFIG_VIDEO_IR=m CONFIG_MEDIA_ATTACH=y CONFIG_MEDIA_TUNER=m CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2266=m CONFIG_MEDIA_TUNER_MT2131=m CONFIG_MEDIA_TUNER_QT1010=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m CONFIG_MEDIA_TUNER_MC44S803=m CONFIG_VIDEO_V4L2=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_TVEEPROM=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_CAPTURE_DRIVERS=y CONFIG_VIDEO_FIXED_MINOR_RANGES=y CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_IR_I2C=m CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_M52790=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m CONFIG_VIDEO_SAA6588=m CONFIG_VIDEO_BT819=m CONFIG_VIDEO_BT856=m CONFIG_VIDEO_BT866=m CONFIG_VIDEO_KS0127=m CONFIG_VIDEO_OV7670=m CONFIG_VIDEO_MT9V011=m CONFIG_VIDEO_SAA7110=m CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_VPX3220=m CONFIG_VIDEO_CX25840=m CONFIG_VIDEO_CX2341X=m CONFIG_VIDEO_SAA7127=m CONFIG_VIDEO_SAA7185=m CONFIG_VIDEO_ADV7170=m CONFIG_VIDEO_ADV7175=m CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m CONFIG_VIDEO_VIVI=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_ZR36060=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_ZORAN_AVS6EYES=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=m CONFIG_VIDEO_CX88_VP3054=m CONFIG_VIDEO_CX23885=m CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_IVTV=m CONFIG_VIDEO_FB_IVTV=m CONFIG_VIDEO_CX18=m CONFIG_VIDEO_SAA7164=m CONFIG_VIDEO_CAFE_CCIC=m CONFIG_SOC_CAMERA=m CONFIG_SOC_CAMERA_MT9M001=m CONFIG_SOC_CAMERA_MT9M111=m CONFIG_SOC_CAMERA_MT9T031=m CONFIG_SOC_CAMERA_MT9V022=m CONFIG_SOC_CAMERA_TW9910=m CONFIG_SOC_CAMERA_PLATFORM=m CONFIG_SOC_CAMERA_OV772X=m CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=m CONFIG_USB_M5602=m CONFIG_USB_STV06XX=m CONFIG_USB_GL860=m CONFIG_USB_GSPCA_MR97310A=m CONFIG_USB_GSPCA_OV519=m CONFIG_USB_GSPCA_OV534=m CONFIG_USB_GSPCA_SN9C20X=m CONFIG_USB_GSPCA_SN9C20X_EVDEV=y CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_SONIXJ=m CONFIG_USB_GSPCA_SPCA500=m CONFIG_USB_GSPCA_SPCA501=m CONFIG_USB_GSPCA_SPCA505=m CONFIG_USB_GSPCA_SPCA506=m CONFIG_USB_GSPCA_SPCA508=m CONFIG_USB_GSPCA_SPCA561=m CONFIG_USB_GSPCA_SQ905=m CONFIG_USB_GSPCA_SQ905C=m CONFIG_USB_GSPCA_STK014=m CONFIG_USB_GSPCA_SUNPLUS=m CONFIG_USB_GSPCA_T613=m CONFIG_USB_GSPCA_TV8532=m CONFIG_USB_GSPCA_VC032X=m CONFIG_USB_GSPCA_ZC3XX=m CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y CONFIG_VIDEO_HDPVR=m CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_EM28XX_ALSA=m CONFIG_VIDEO_EM28XX_DVB=m CONFIG_VIDEO_CX231XX=m CONFIG_VIDEO_CX231XX_ALSA=m CONFIG_VIDEO_CX231XX_DVB=m CONFIG_VIDEO_USBVISION=m CONFIG_USB_ET61X251=m CONFIG_USB_SN9C102=m CONFIG_USB_ZC0301=m CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_USB_ZR364XX=m CONFIG_USB_STKWEBCAM=m CONFIG_USB_S2255=m CONFIG_DVB_MAX_ADAPTERS=8 CONFIG_DVB_CAPTURE_DRIVERS=y CONFIG_TTPCI_EEPROM=m CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET_CORE=m CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m CONFIG_DVB_USB=m CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m CONFIG_DVB_USB_DW2102=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_DVB_USB_ANYSEE=m CONFIG_DVB_USB_DTV5100=m CONFIG_DVB_USB_AF9015=m CONFIG_DVB_USB_CE6230=m CONFIG_DVB_USB_FRIIO=m CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_SMS_SIANO_MDTV=m CONFIG_SMS_USB_DRV=m CONFIG_SMS_SDIO_DRV=m CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m CONFIG_DVB_BT8XX=m CONFIG_DVB_PLUTO2=m CONFIG_DVB_FIREDTV=m CONFIG_DVB_FIREDTV_IEEE1394=y CONFIG_DVB_FIREDTV_INPUT=y CONFIG_DVB_PT1=m CONFIG_DVB_STB0899=m CONFIG_DVB_STB6100=m CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_MT312=m CONFIG_DVB_ZL10036=m CONFIG_DVB_ZL10039=m CONFIG_DVB_S5H1420=m CONFIG_DVB_STV0288=m CONFIG_DVB_STB6000=m CONFIG_DVB_STV0299=m CONFIG_DVB_STV6110=m CONFIG_DVB_STV0900=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_TDA8261=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TUNER_ITD1000=m CONFIG_DVB_TUNER_CX24113=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m CONFIG_DVB_SI21XX=m CONFIG_DVB_DS3000=m CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_TDA10048=m CONFIG_DVB_AF9013=m CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_LGDT3305=m CONFIG_DVB_S5H1409=m CONFIG_DVB_AU8522=m CONFIG_DVB_S5H1411=m CONFIG_DVB_DIB8000=m CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6405=m CONFIG_DVB_ISL6421=m CONFIG_DVB_LGS8GL5=m CONFIG_DAB=y CONFIG_USB_DABUSB=m CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_VIA=m CONFIG_VGA_ARB=y CONFIG_DRM=m CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_TTM=m CONFIG_DRM_RADEON=m CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=m CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y CONFIG_FB_SYS_FOPS=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_VGA16=m CONFIG_FB_UVESA=m CONFIG_FB_VESA=y CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_XEN_FBDEV_FRONTEND=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_LCD_PLATFORM=m CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_DISPLAY_SUPPORT=m CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SOUND_OSS_CORE_PRECLAIM=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_VMASTER=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_RAWMIDI_SEQ=m CONFIG_SND_EMU10K1_SEQ=m CONFIG_SND_MPU401_UART=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 CONFIG_SND_PCI=y CONFIG_SND_BT87X=m CONFIG_SND_CA0106=m CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_EMU10K1=m CONFIG_SND_HDA_INTEL=m CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_RECONFIG=y CONFIG_SND_HDA_INPUT_JACK=y CONFIG_SND_HDA_PATCH_LOADER=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_NVHDMI=y CONFIG_SND_HDA_CODEC_INTELHDMI=y CONFIG_SND_HDA_ELD=y CONFIG_SND_HDA_CODEC_CIRRUS=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CA0110=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_INTEL8X0=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y CONFIG_SND_USB_US122L=m CONFIG_SOUND_PRIME=m CONFIG_SOUND_OSS=m CONFIG_SOUND_TRACEINIT=y CONFIG_SOUND_DMAP=y CONFIG_SOUND_VMIDI=m CONFIG_SOUND_MPU401=m CONFIG_SOUND_PAS=m CONFIG_SOUND_PSS=m CONFIG_PSS_MIXER=y CONFIG_SOUND_SB=m CONFIG_SOUND_YM3812=m CONFIG_SOUND_UART6850=m CONFIG_SOUND_KAHLUA=m CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=m CONFIG_HIDRAW=y CONFIG_USB_HID=m CONFIG_USB_HIDDEV=y CONFIG_HID_A4TECH=m CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m CONFIG_HID_DRAGONRISE=m CONFIG_HID_EZKEY=m CONFIG_HID_KYE=m CONFIG_HID_GYRATION=m CONFIG_HID_TWINHAN=m CONFIG_HID_KENSINGTON=m CONFIG_HID_LOGITECH=m CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m CONFIG_HID_NTRIG=m CONFIG_HID_PANTHERLORD=m CONFIG_HID_PETALYNX=m CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m CONFIG_HID_SUNPLUS=m CONFIG_HID_GREENASIA=m CONFIG_HID_SMARTJOYPLUS=m CONFIG_HID_TOPSEED=m CONFIG_HID_THRUSTMASTER=m CONFIG_HID_WACOM=m CONFIG_HID_ZEROPLUS=m CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=m CONFIG_USB_WUSB=m CONFIG_USB_WUSB_CBAF=m CONFIG_USB_WUSB_CBAF_DEBUG=y CONFIG_USB_C67X00_HCD=m CONFIG_USB_XHCI_HCD=m CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_OHCI_HCD=m CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m CONFIG_USB_WHCI_HCD=m CONFIG_USB_HWA_HCD=m CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DATAFAB=m CONFIG_USB_STORAGE_FREECOM=m CONFIG_USB_STORAGE_ISD200=m CONFIG_USB_STORAGE_USBAT=m CONFIG_USB_STORAGE_SDDR09=m CONFIG_USB_STORAGE_SDDR55=m CONFIG_USB_STORAGE_JUMPSHOT=m CONFIG_USB_STORAGE_ALAUDA=m CONFIG_USB_STORAGE_ONETOUCH=m CONFIG_USB_STORAGE_KARMA=m CONFIG_USB_STORAGE_CYPRESS_ATACB=m CONFIG_USB_SERIAL=m CONFIG_USB_EZUSB=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP210X=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IUU=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_MOTOROLA=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m CONFIG_USB_SERIAL_SPCP8X5=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIEMENS_MPI=m CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_DEBUG=m CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_TEST=m CONFIG_USB_ISIGHTFW=m CONFIG_USB_GADGET=m CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_SELECTED=y CONFIG_USB_GADGET_CI13XXX=y CONFIG_USB_CI13XXX=m CONFIG_USB_GADGET_DUALSPEED=y CONFIG_USB_AUDIO=m CONFIG_USB_GADGETFS=m CONFIG_UWB=m CONFIG_UWB_HWA=m CONFIG_UWB_WHCI=m CONFIG_UWB_WLP=m CONFIG_UWB_I1480U=m CONFIG_UWB_I1480U_WLP=m CONFIG_MMC=m CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m CONFIG_MMC_TEST=m CONFIG_MMC_SDHCI=m CONFIG_MMC_SDHCI_PCI=m CONFIG_MMC_RICOH_MMC=m CONFIG_MMC_SDHCI_PLTFM=m CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m CONFIG_MMC_CB710=m CONFIG_MMC_VIA_SDMMC=m CONFIG_MEMSTICK=m CONFIG_MSPRO_BLOCK=m CONFIG_MEMSTICK_TIFM_MS=m CONFIG_MEMSTICK_JMICRON_38X=m CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m CONFIG_LEDS_PCA9532=m CONFIG_LEDS_CLEVO_MAIL=m CONFIG_LEDS_PCA955X=m CONFIG_LEDS_BD2802=m CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_LEDS_TRIGGER_DEFAULT_ON=m CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y CONFIG_RTC_DRV_TEST=m CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m CONFIG_RTC_DRV_M41T80_WDT=y CONFIG_RTC_DRV_CMOS=m CONFIG_RTC_DRV_DS1286=m CONFIG_RTC_DRV_DS1511=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1742=m CONFIG_UIO=m CONFIG_UIO_PDRV=m CONFIG_UIO_PDRV_GENIRQ=m CONFIG_UIO_PCI_GENERIC=m CONFIG_XEN_BALLOON=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=y CONFIG_XENFS=y CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_X86_PLATFORM_DEVICES=y CONFIG_ACPI_WMI=m CONFIG_ACPI_TOSHIBA=m CONFIG_EDD=m CONFIG_FIRMWARE_MEMMAP=y CONFIG_EFI_VARS=m CONFIG_DMIID=y CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=m CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_JBD=m CONFIG_JBD_DEBUG=y CONFIG_JBD2=m CONFIG_JBD2_DEBUG=y CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y CONFIG_BTRFS_FS=m CONFIG_BTRFS_FS_POSIX_ACL=y CONFIG_NILFS2_FS=m CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y CONFIG_PRINT_QUOTA_WARNING=y CONFIG_QUOTA_TREE=m CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_CUSE=m CONFIG_GENERIC_ACL=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y 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=m CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=m CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 CONFIG_UFS_FS=m CONFIG_UFS_FS_WRITE=y CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_V4_1=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m CONFIG_CIFS=m CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_EXPERIMENTAL=y CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m CONFIG_AFS_FS=m CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y CONFIG_SUN_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y CONFIG_STRIP_ASM_SYMS=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400 CONFIG_DEBUG_KMEMLEAK_TEST=m CONFIG_STACKTRACE=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_VIRTUAL=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y CONFIG_RCU_TORTURE_TEST=m CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y CONFIG_LKDTM=m CONFIG_LATENCYTOP=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FTRACE_NMI_ENTER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_RING_BUFFER=y CONFIG_FTRACE_NMI_ENTER=y CONFIG_EVENT_TRACING=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_SYSPROF_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_BRANCH_PROFILE_NONE=y CONFIG_POWER_TRACER=y CONFIG_KMEMTRACE=y CONFIG_WORKQUEUE_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FTRACE_MCOUNT_RECORD=y CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y CONFIG_KGDB_TESTS_ON_BOOT=y CONFIG_KGDB_TESTS_BOOT_STRING="V1F100" CONFIG_HAVE_ARCH_KMEMCHECK=y CONFIG_STRICT_DEVMEM=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_RODATA=y CONFIG_HAVE_MMIOTRACE_SUPPORT=y 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_DEFAULT_IO_DELAY_TYPE=0 CONFIG_CPA_DEBUG=y CONFIG_KEYS=y CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_DEFAULT_SECURITY="" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y 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_PCOMP=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_FPU=m CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=y CONFIG_CRYPTO_LZO=m CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_AMD=m CONFIG_VIRTIO=m CONFIG_VIRTIO_RING=m CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m CONFIG_BINARY_PRINTF=y CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_FIND_LAST_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=m CONFIG_LZO_DECOMPRESS=m CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_NLATTR=y ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU @ 2010-01-11 3:39 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-11 3:39 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 1684 bytes --] On 10/01/10 22:32, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 > Subject : All kernels after 2.6.32-git10 show only 1 CPU > Submitter : Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org> > Date : 2009-12-23 16:55 (19 days old) > References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 > > > > With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its locking up solid at this part of the boot process as usual. ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) -> IRQ 22. With acpi=noirq (2 CPU's) ================ kvm: Nested Virtualization enabled. IT8716 Super IO detected Parport_PC 00:0a: reported by plug and Play ACPI Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] parport: irq 7 in use, resorting to polled operation HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 With acpi=ht (1 CPU) ============= Hangs at:- Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for vector (irq -1) With acpi=off (2 CPU's) ======================== Hangs at same point as with acpi=noirq. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks [-- Attachment #2: config_2.6.33-rc3-git3-tindog --] [-- Type: text/plain, Size: 51981 bytes --] CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" 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_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y 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=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y 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_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_TRAMPOLINE=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-smp" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_KERNEL_GZIP=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_TREE_RCU=y CONFIG_RCU_FANOUT=64 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUPS=y CONFIG_CGROUP_NS=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_MM_OWNER=y CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_EVENT_PROFILE=y CONFIG_PERF_COUNTERS=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y CONFIG_SLUB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_OPROFILE=m CONFIG_OPROFILE_EVENT_MULTIPLEX=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_USER_RETURN_NOTIFIER=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_SLOW_WORK=y CONFIG_SLOW_WORK_DEBUG=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_PREEMPT_NOTIFIERS=y CONFIG_INLINE_SPIN_UNLOCK=y CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_FREEZER=y CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_MPPARSE=y CONFIG_X86_EXTENDED_PLATFORM=y CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_PARAVIRT_GUEST=y CONFIG_XEN=y CONFIG_XEN_MAX_DOMAIN_MEMORY=32 CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_CLOCK=y CONFIG_PARAVIRT_DEBUG=y CONFIG_MEMTEST=y CONFIG_GENERIC_CPU=y CONFIG_X86_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=7 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_WP_WORKS_OK=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=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y CONFIG_AMD_IOMMU=y CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_API=y CONFIG_NR_CPUS=128 CONFIG_SCHED_MC=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_CPU_DEBUG=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y CONFIG_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y CONFIG_NODES_SHIFT=9 CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y CONFIG_MEMORY_FAILURE=y CONFIG_HWPOISON_INJECT=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y CONFIG_X86_RESERVE_LOW_64K=y CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_EFI=y CONFIG_SECCOMP=y CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_KEXEC_JUMP=y CONFIG_PHYSICAL_START=0x200000 CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_PM=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATION_NVS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_RUNTIME=y CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_POWER_METER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_NUMA=y CONFIG_ACPI_CUSTOM_DSDT_FILE="" CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_PCI_SLOT=m CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K8=m CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y CONFIG_PCIE_ECRC=y CONFIG_PCIEAER_INJECT=m CONFIG_PCIEASPM=y CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y CONFIG_HT_IRQ=y CONFIG_PCI_IOV=y CONFIG_PCI_IOAPIC=y CONFIG_ISA_DMA_API=y CONFIG_K8_NB=y CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_NET=y CONFIG_COMPAT_NETLINK_MESSAGES=y CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y 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=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=y CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m CONFIG_DEFAULT_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=m CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_SUBTREES=y CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_DCCP=m CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_HL=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_HL=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_NETFILTER_XT_MATCH_OSF=m CONFIG_IP_VS=m CONFIG_IP_VS_TAB_BITS=12 CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_DCCP=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_RAW=m CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_IP6=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_BRIDGE_EBT_NFLOG=m CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m CONFIG_IP_DCCP_CCID3=y CONFIG_IP_DCCP_CCID3_RTO=100 CONFIG_IP_DCCP_TFRC_LIB=y CONFIG_IP_SCTP=m CONFIG_SCTP_HMAC_MD5=y CONFIG_RDS=m CONFIG_RDS_TCP=m CONFIG_STP=m CONFIG_GARP=m CONFIG_BRIDGE=m CONFIG_VLAN_8021Q=m CONFIG_VLAN_8021Q_GVRP=y CONFIG_LLC=m CONFIG_LLC2=m CONFIG_IPX=m CONFIG_IPX_INTERN=y CONFIG_IEEE802154=m CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_DRR=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_FLOW=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m CONFIG_NET_SCH_FIFO=y CONFIG_NET_PKTGEN=m CONFIG_NET_TCPPROBE=m CONFIG_HAMRADIO=y CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_YAM=m CONFIG_IRDA=m CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRTTY_SIR=m CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_TOIM3232_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m CONFIG_KINGSUN_DONGLE=m CONFIG_KSDAZZLE_DONGLE=m CONFIG_KS959_DONGLE=m CONFIG_USB_IRDA=m CONFIG_SIGMATEL_FIR=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m CONFIG_MCS_FIR=m CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m CONFIG_BT_HCIBTUSB=m CONFIG_BT_HCIBTSDIO=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_LL=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m CONFIG_BT_MRVL=m CONFIG_BT_MRVL_SDIO=m CONFIG_AF_RXRPC=m CONFIG_RXKAD=m CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211=m CONFIG_CFG80211_REG_DEBUG=y CONFIG_CFG80211_DEFAULT_PS=y CONFIG_CFG80211_DEBUGFS=y CONFIG_CFG80211_WEXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_LIB80211=m CONFIG_LIB80211_CRYPT_WEP=m CONFIG_LIB80211_CRYPT_CCMP=m CONFIG_LIB80211_CRYPT_TKIP=m CONFIG_MAC80211=m CONFIG_MAC80211_RC_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel" CONFIG_MAC80211_MESH=y CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUGFS=y CONFIG_WIMAX=m CONFIG_WIMAX_DEBUG_LEVEL=8 CONFIG_RFKILL=m CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y CONFIG_UEVENT_HELPER_PATH="" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_SYS_HYPERVISOR=y CONFIG_CONNECTOR=m CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y CONFIG_PARPORT_AX88796=m CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_SX8=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=128000 CONFIG_BLK_DEV_XIP=y CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_CDROM_PKTCDVD_WCACHE=y CONFIG_XEN_BLKDEV_FRONTEND=y CONFIG_VIRTIO_BLK=m CONFIG_MISC_DEVICES=y CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m CONFIG_ENCLOSURE_SERVICES=m CONFIG_DS1682=m CONFIG_EEPROM_AT24=m CONFIG_EEPROM_LEGACY=m CONFIG_EEPROM_MAX6875=m CONFIG_EEPROM_93CX6=m CONFIG_CB710_CORE=m CONFIG_CB710_DEBUG_ASSUMPTIONS=y CONFIG_HAVE_IDE=y CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_SAS_HOST_SMP=y CONFIG_SCSI_SAS_LIBSAS_DEBUG=y CONFIG_SCSI_SRP_ATTRS=m CONFIG_SCSI_SRP_TGT_ATTRS=y CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_SCSI_BNX2_ISCSI=m CONFIG_SCSI_MVSAS=m CONFIG_SCSI_MVSAS_DEBUG=y CONFIG_LIBFC=m CONFIG_LIBFCOE=m CONFIG_SCSI_DH=m CONFIG_ATA=m CONFIG_ATA_VERBOSE_ERROR=y CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y CONFIG_SATA_AHCI=m CONFIG_ATA_SFF=y CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SX4=m CONFIG_SATA_VIA=m CONFIG_PATA_ACPI=m CONFIG_PATA_AMD=m CONFIG_PATA_ATP867X=m CONFIG_ATA_GENERIC=m CONFIG_PATA_JMICRON=m CONFIG_PATA_MARVELL=m CONFIG_PATA_PDC2027X=m CONFIG_PATA_VIA=m CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MULTICORE_RAID456=y CONFIG_MD_RAID6_PQ=m CONFIG_ASYNC_RAID6_TEST=m CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_QL=m CONFIG_DM_MULTIPATH_ST=m CONFIG_DM_DELAY=m CONFIG_DM_UEVENT=y CONFIG_IEEE1394=m CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_DV1394=m CONFIG_NETDEVICES=y CONFIG_IFB=m CONFIG_BONDING=m CONFIG_MACVLAN=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_PHYLIB=m CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_BROADCOM_PHY=m CONFIG_REALTEK_PHY=m CONFIG_NATIONAL_PHY=m CONFIG_STE10XP=m CONFIG_LSI_ET1011C_PHY=m CONFIG_NET_ETHERNET=y CONFIG_MII=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_ADAPTEC_STARFIRE=m CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_FORCEDETH=m CONFIG_FORCEDETH_NAPI=y CONFIG_E100=m CONFIG_8139CP=m CONFIG_8139TOO=m CONFIG_8139TOO_8129=y CONFIG_NETDEV_1000=y CONFIG_E1000=m CONFIG_E1000E=m CONFIG_R8169=m CONFIG_R8169_VLAN=y CONFIG_SKY2=m CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=m CONFIG_BNX2=m CONFIG_CNIC=m CONFIG_JME=m CONFIG_WLAN=y CONFIG_LIBERTAS_THINFIRM=m CONFIG_LIBERTAS_THINFIRM_USB=m CONFIG_AIRO=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m CONFIG_AT76C50X_USB=m CONFIG_PRISM54=m CONFIG_USB_ZD1201=m CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_RTL8180=m CONFIG_RTL8187=m CONFIG_RTL8187_LEDS=y CONFIG_ADM8211=m CONFIG_MAC80211_HWSIM=m CONFIG_MWL8K=m CONFIG_ATH_COMMON=m CONFIG_ATH5K=m CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K=m CONFIG_B43=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_SDIO=y CONFIG_B43_PIO=y CONFIG_B43_PHY_LP=y CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_PCI=m CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y CONFIG_LIBIPW=m CONFIG_IWLWIFI=m CONFIG_IWLAGN=m CONFIG_IWL4965=y CONFIG_IWL5000=y CONFIG_IWL3945=m CONFIG_IWL3945_SPECTRUM_MEASUREMENT=y CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m CONFIG_HERMES=m CONFIG_HERMES_CACHE_FW_ON_INIT=y CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_NORTEL_HERMES=m CONFIG_PCI_HERMES=m CONFIG_P54_COMMON=m CONFIG_P54_USB=m CONFIG_P54_PCI=m CONFIG_P54_LEDS=y CONFIG_RT2X00=m CONFIG_RT2400PCI=m CONFIG_RT2500PCI=m CONFIG_RT61PCI=m CONFIG_RT2800PCI_PCI=m CONFIG_RT2800PCI=m CONFIG_RT2500USB=m CONFIG_RT73USB=m CONFIG_RT2800USB=m CONFIG_RT2800_LIB=m CONFIG_RT2X00_LIB_PCI=m CONFIG_RT2X00_LIB_USB=m CONFIG_RT2X00_LIB=m CONFIG_RT2X00_LIB_HT=y CONFIG_RT2X00_LIB_FIRMWARE=y CONFIG_RT2X00_LIB_CRYPTO=y CONFIG_RT2X00_LIB_LEDS=y CONFIG_ZD1211RW=m CONFIG_WIMAX_I2400M=m CONFIG_WIMAX_I2400M_USB=m CONFIG_WIMAX_I2400M_SDIO=m CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8 CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m CONFIG_USB_HSO=m CONFIG_IEEE802154_DRIVERS=m CONFIG_XEN_NETDEV_FRONTEND=y CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOL2TP=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLHC=m CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y CONFIG_VIRTIO_NET=m CONFIG_VMXNET3=m CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_POLLDEV=m CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=y CONFIG_XEN_KBDDEV_FRONTEND=y CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_NEWTON=m CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y 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_SERIAL=m CONFIG_INPUT_JOYSTICK=y CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=m CONFIG_TABLET_USB_AIPTEK=m CONFIG_TABLET_USB_GTCO=m CONFIG_TABLET_USB_KBTAB=m CONFIG_TABLET_USB_WACOM=m CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=8 CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=0 CONFIG_PRINTER=m CONFIG_PPDEV=m CONFIG_HVC_DRIVER=y CONFIG_HVC_IRQ=y CONFIG_HVC_XEN=y CONFIG_VIRTIO_CONSOLE=m CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_TIMERIOMEM=y CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_VIA=y CONFIG_HW_RANDOM_VIRTIO=m CONFIG_NVRAM=y CONFIG_PC8736x_GPIO=m CONFIG_NSC_GPIO=m CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=4096 CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y CONFIG_I2C_CHARDEV=m CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=m CONFIG_I2C_TINY_USB=m CONFIG_PPS=m CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_POWER_SUPPLY=y CONFIG_POWER_SUPPLY_DEBUG=y CONFIG_PDA_POWER=m CONFIG_HWMON=y CONFIG_HWMON_VID=m CONFIG_SENSORS_ABITUGURU=m CONFIG_SENSORS_ABITUGURU3=m CONFIG_SENSORS_AD7414=m CONFIG_SENSORS_AD7418=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m CONFIG_SENSORS_ADT7462=m CONFIG_SENSORS_ADT7470=m CONFIG_SENSORS_ADT7473=m CONFIG_SENSORS_ADT7475=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_I5K_AMB=m CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_F71882FG=m CONFIG_SENSORS_F75375S=m CONFIG_SENSORS_FSCHMD=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_CORETEMP=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m CONFIG_SENSORS_LM93=m CONFIG_SENSORS_LTC4215=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_MAX6650=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_DME1737=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_ADS7828=m CONFIG_SENSORS_THMC50=m CONFIG_SENSORS_TMP421=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83L786NG=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_HDAPS=m CONFIG_SENSORS_APPLESMC=m CONFIG_SENSORS_ATK0110=m CONFIG_THERMAL=y CONFIG_THERMAL_HWMON=y CONFIG_WATCHDOG=y CONFIG_SOFT_WATCHDOG=m CONFIG_IT87_WDT=y CONFIG_SSB_POSSIBLE=y CONFIG_SSB=m CONFIG_SSB_SPROM=y CONFIG_SSB_BLOCKIO=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_SDIOHOST_POSSIBLE=y CONFIG_SSB_SDIOHOST=y CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y CONFIG_MEDIA_SUPPORT=m CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_DVB_CORE=m CONFIG_VIDEO_MEDIA=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_IR_CORE=m CONFIG_VIDEO_IR=m CONFIG_MEDIA_ATTACH=y CONFIG_MEDIA_TUNER=m CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2266=m CONFIG_MEDIA_TUNER_MT2131=m CONFIG_MEDIA_TUNER_QT1010=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m CONFIG_MEDIA_TUNER_MC44S803=m CONFIG_VIDEO_V4L2=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_TVEEPROM=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_CAPTURE_DRIVERS=y CONFIG_VIDEO_FIXED_MINOR_RANGES=y CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_IR_I2C=m CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_M52790=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m CONFIG_VIDEO_SAA6588=m CONFIG_VIDEO_BT819=m CONFIG_VIDEO_BT856=m CONFIG_VIDEO_BT866=m CONFIG_VIDEO_KS0127=m CONFIG_VIDEO_OV7670=m CONFIG_VIDEO_MT9V011=m CONFIG_VIDEO_SAA7110=m CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_VPX3220=m CONFIG_VIDEO_CX25840=m CONFIG_VIDEO_CX2341X=m CONFIG_VIDEO_SAA7127=m CONFIG_VIDEO_SAA7185=m CONFIG_VIDEO_ADV7170=m CONFIG_VIDEO_ADV7175=m CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m CONFIG_VIDEO_VIVI=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_ZR36060=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_ZORAN_AVS6EYES=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=m CONFIG_VIDEO_CX88_VP3054=m CONFIG_VIDEO_CX23885=m CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_IVTV=m CONFIG_VIDEO_FB_IVTV=m CONFIG_VIDEO_CX18=m CONFIG_VIDEO_SAA7164=m CONFIG_VIDEO_CAFE_CCIC=m CONFIG_SOC_CAMERA=m CONFIG_SOC_CAMERA_MT9M001=m CONFIG_SOC_CAMERA_MT9M111=m CONFIG_SOC_CAMERA_MT9T031=m CONFIG_SOC_CAMERA_MT9V022=m CONFIG_SOC_CAMERA_TW9910=m CONFIG_SOC_CAMERA_PLATFORM=m CONFIG_SOC_CAMERA_OV772X=m CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_GSPCA=m CONFIG_USB_M5602=m CONFIG_USB_STV06XX=m CONFIG_USB_GL860=m CONFIG_USB_GSPCA_MR97310A=m CONFIG_USB_GSPCA_OV519=m CONFIG_USB_GSPCA_OV534=m CONFIG_USB_GSPCA_SN9C20X=m CONFIG_USB_GSPCA_SN9C20X_EVDEV=y CONFIG_USB_GSPCA_SONIXB=m CONFIG_USB_GSPCA_SONIXJ=m CONFIG_USB_GSPCA_SPCA500=m CONFIG_USB_GSPCA_SPCA501=m CONFIG_USB_GSPCA_SPCA505=m CONFIG_USB_GSPCA_SPCA506=m CONFIG_USB_GSPCA_SPCA508=m CONFIG_USB_GSPCA_SPCA561=m CONFIG_USB_GSPCA_SQ905=m CONFIG_USB_GSPCA_SQ905C=m CONFIG_USB_GSPCA_STK014=m CONFIG_USB_GSPCA_SUNPLUS=m CONFIG_USB_GSPCA_T613=m CONFIG_USB_GSPCA_TV8532=m CONFIG_USB_GSPCA_VC032X=m CONFIG_USB_GSPCA_ZC3XX=m CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y CONFIG_VIDEO_HDPVR=m CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_EM28XX_ALSA=m CONFIG_VIDEO_EM28XX_DVB=m CONFIG_VIDEO_CX231XX=m CONFIG_VIDEO_CX231XX_ALSA=m CONFIG_VIDEO_CX231XX_DVB=m CONFIG_VIDEO_USBVISION=m CONFIG_USB_ET61X251=m CONFIG_USB_SN9C102=m CONFIG_USB_ZC0301=m CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_USB_ZR364XX=m CONFIG_USB_STKWEBCAM=m CONFIG_USB_S2255=m CONFIG_DVB_MAX_ADAPTERS=8 CONFIG_DVB_CAPTURE_DRIVERS=y CONFIG_TTPCI_EEPROM=m CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET_CORE=m CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m CONFIG_DVB_USB=m CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m CONFIG_DVB_USB_DW2102=m CONFIG_DVB_USB_CINERGY_T2=m CONFIG_DVB_USB_ANYSEE=m CONFIG_DVB_USB_DTV5100=m CONFIG_DVB_USB_AF9015=m CONFIG_DVB_USB_CE6230=m CONFIG_DVB_USB_FRIIO=m CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_SMS_SIANO_MDTV=m CONFIG_SMS_USB_DRV=m CONFIG_SMS_SDIO_DRV=m CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m CONFIG_DVB_BT8XX=m CONFIG_DVB_PLUTO2=m CONFIG_DVB_FIREDTV=m CONFIG_DVB_FIREDTV_IEEE1394=y CONFIG_DVB_FIREDTV_INPUT=y CONFIG_DVB_PT1=m CONFIG_DVB_STB0899=m CONFIG_DVB_STB6100=m CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_MT312=m CONFIG_DVB_ZL10036=m CONFIG_DVB_ZL10039=m CONFIG_DVB_S5H1420=m CONFIG_DVB_STV0288=m CONFIG_DVB_STB6000=m CONFIG_DVB_STV0299=m CONFIG_DVB_STV6110=m CONFIG_DVB_STV0900=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_TDA8261=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TUNER_ITD1000=m CONFIG_DVB_TUNER_CX24113=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m CONFIG_DVB_SI21XX=m CONFIG_DVB_DS3000=m CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_TDA10048=m CONFIG_DVB_AF9013=m CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_LGDT3305=m CONFIG_DVB_S5H1409=m CONFIG_DVB_AU8522=m CONFIG_DVB_S5H1411=m CONFIG_DVB_DIB8000=m CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6405=m CONFIG_DVB_ISL6421=m CONFIG_DVB_LGS8GL5=m CONFIG_DAB=y CONFIG_USB_DABUSB=m CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_VIA=m CONFIG_VGA_ARB=y CONFIG_DRM=m CONFIG_DRM_KMS_HELPER=m CONFIG_DRM_TTM=m CONFIG_DRM_RADEON=m CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=m CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SYS_FILLRECT=y CONFIG_FB_SYS_COPYAREA=y CONFIG_FB_SYS_IMAGEBLIT=y CONFIG_FB_SYS_FOPS=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_VGA16=m CONFIG_FB_UVESA=m CONFIG_FB_VESA=y CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_XEN_FBDEV_FRONTEND=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_LCD_PLATFORM=m CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_DISPLAY_SUPPORT=m CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SOUND_OSS_CORE_PRECLAIM=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_VMASTER=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_RAWMIDI_SEQ=m CONFIG_SND_EMU10K1_SEQ=m CONFIG_SND_MPU401_UART=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 CONFIG_SND_PCI=y CONFIG_SND_BT87X=m CONFIG_SND_CA0106=m CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_EMU10K1=m CONFIG_SND_HDA_INTEL=m CONFIG_SND_HDA_HWDEP=y CONFIG_SND_HDA_RECONFIG=y CONFIG_SND_HDA_INPUT_JACK=y CONFIG_SND_HDA_PATCH_LOADER=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_NVHDMI=y CONFIG_SND_HDA_CODEC_INTELHDMI=y CONFIG_SND_HDA_ELD=y CONFIG_SND_HDA_CODEC_CIRRUS=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CA0110=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_INTEL8X0=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y CONFIG_SND_USB_US122L=m CONFIG_SOUND_PRIME=m CONFIG_SOUND_OSS=m CONFIG_SOUND_TRACEINIT=y CONFIG_SOUND_DMAP=y CONFIG_SOUND_VMIDI=m CONFIG_SOUND_MPU401=m CONFIG_SOUND_PAS=m CONFIG_SOUND_PSS=m CONFIG_PSS_MIXER=y CONFIG_SOUND_SB=m CONFIG_SOUND_YM3812=m CONFIG_SOUND_UART6850=m CONFIG_SOUND_KAHLUA=m CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=m CONFIG_HIDRAW=y CONFIG_USB_HID=m CONFIG_USB_HIDDEV=y CONFIG_HID_A4TECH=m CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m CONFIG_HID_DRAGONRISE=m CONFIG_HID_EZKEY=m CONFIG_HID_KYE=m CONFIG_HID_GYRATION=m CONFIG_HID_TWINHAN=m CONFIG_HID_KENSINGTON=m CONFIG_HID_LOGITECH=m CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m CONFIG_HID_NTRIG=m CONFIG_HID_PANTHERLORD=m CONFIG_HID_PETALYNX=m CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m CONFIG_HID_SUNPLUS=m CONFIG_HID_GREENASIA=m CONFIG_HID_SMARTJOYPLUS=m CONFIG_HID_TOPSEED=m CONFIG_HID_THRUSTMASTER=m CONFIG_HID_WACOM=m CONFIG_HID_ZEROPLUS=m CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=m CONFIG_USB_WUSB=m CONFIG_USB_WUSB_CBAF=m CONFIG_USB_WUSB_CBAF_DEBUG=y CONFIG_USB_C67X00_HCD=m CONFIG_USB_XHCI_HCD=m CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_OHCI_HCD=m CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m CONFIG_USB_WHCI_HCD=m CONFIG_USB_HWA_HCD=m CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DATAFAB=m CONFIG_USB_STORAGE_FREECOM=m CONFIG_USB_STORAGE_ISD200=m CONFIG_USB_STORAGE_USBAT=m CONFIG_USB_STORAGE_SDDR09=m CONFIG_USB_STORAGE_SDDR55=m CONFIG_USB_STORAGE_JUMPSHOT=m CONFIG_USB_STORAGE_ALAUDA=m CONFIG_USB_STORAGE_ONETOUCH=m CONFIG_USB_STORAGE_KARMA=m CONFIG_USB_STORAGE_CYPRESS_ATACB=m CONFIG_USB_SERIAL=m CONFIG_USB_EZUSB=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP210X=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IUU=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_MOTOROLA=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m CONFIG_USB_SERIAL_SPCP8X5=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIEMENS_MPI=m CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_DEBUG=m CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_TEST=m CONFIG_USB_ISIGHTFW=m CONFIG_USB_GADGET=m CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_SELECTED=y CONFIG_USB_GADGET_CI13XXX=y CONFIG_USB_CI13XXX=m CONFIG_USB_GADGET_DUALSPEED=y CONFIG_USB_AUDIO=m CONFIG_USB_GADGETFS=m CONFIG_UWB=m CONFIG_UWB_HWA=m CONFIG_UWB_WHCI=m CONFIG_UWB_WLP=m CONFIG_UWB_I1480U=m CONFIG_UWB_I1480U_WLP=m CONFIG_MMC=m CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m CONFIG_MMC_TEST=m CONFIG_MMC_SDHCI=m CONFIG_MMC_SDHCI_PCI=m CONFIG_MMC_RICOH_MMC=m CONFIG_MMC_SDHCI_PLTFM=m CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m CONFIG_MMC_CB710=m CONFIG_MMC_VIA_SDMMC=m CONFIG_MEMSTICK=m CONFIG_MSPRO_BLOCK=m CONFIG_MEMSTICK_TIFM_MS=m CONFIG_MEMSTICK_JMICRON_38X=m CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m CONFIG_LEDS_PCA9532=m CONFIG_LEDS_CLEVO_MAIL=m CONFIG_LEDS_PCA955X=m CONFIG_LEDS_BD2802=m CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_LEDS_TRIGGER_DEFAULT_ON=m CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y CONFIG_RTC_DRV_TEST=m CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m CONFIG_RTC_DRV_M41T80_WDT=y CONFIG_RTC_DRV_CMOS=m CONFIG_RTC_DRV_DS1286=m CONFIG_RTC_DRV_DS1511=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1742=m CONFIG_UIO=m CONFIG_UIO_PDRV=m CONFIG_UIO_PDRV_GENIRQ=m CONFIG_UIO_PCI_GENERIC=m CONFIG_XEN_BALLOON=y CONFIG_XEN_SCRUB_PAGES=y CONFIG_XEN_DEV_EVTCHN=y CONFIG_XENFS=y CONFIG_XEN_COMPAT_XENFS=y CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_X86_PLATFORM_DEVICES=y CONFIG_ACPI_WMI=m CONFIG_ACPI_TOSHIBA=m CONFIG_EDD=m CONFIG_FIRMWARE_MEMMAP=y CONFIG_EFI_VARS=m CONFIG_DMIID=y CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=m CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=m CONFIG_EXT4_FS_XATTR=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_JBD=m CONFIG_JBD_DEBUG=y CONFIG_JBD2=m CONFIG_JBD2_DEBUG=y CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y CONFIG_BTRFS_FS=m CONFIG_BTRFS_FS_POSIX_ACL=y CONFIG_NILFS2_FS=m CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y CONFIG_PRINT_QUOTA_WARNING=y CONFIG_QUOTA_TREE=m CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_CUSE=m CONFIG_GENERIC_ACL=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y 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=m CONFIG_NTFS_RW=y CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=m CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 CONFIG_UFS_FS=m CONFIG_UFS_FS_WRITE=y CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_V4_1=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m CONFIG_CIFS=m CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_EXPERIMENTAL=y CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m CONFIG_AFS_FS=m CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y CONFIG_SUN_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y CONFIG_STRIP_ASM_SYMS=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400 CONFIG_DEBUG_KMEMLEAK_TEST=m CONFIG_STACKTRACE=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_VIRTUAL=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y CONFIG_RCU_TORTURE_TEST=m CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y CONFIG_LKDTM=m CONFIG_LATENCYTOP=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FTRACE_NMI_ENTER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_RING_BUFFER=y CONFIG_FTRACE_NMI_ENTER=y CONFIG_EVENT_TRACING=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_RING_BUFFER_ALLOW_SWAP=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y CONFIG_SYSPROF_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_BRANCH_PROFILE_NONE=y CONFIG_POWER_TRACER=y CONFIG_KMEMTRACE=y CONFIG_WORKQUEUE_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KPROBE_EVENT=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FTRACE_MCOUNT_RECORD=y CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y CONFIG_KGDB_TESTS_ON_BOOT=y CONFIG_KGDB_TESTS_BOOT_STRING="V1F100" CONFIG_HAVE_ARCH_KMEMCHECK=y CONFIG_STRICT_DEVMEM=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_RODATA=y CONFIG_HAVE_MMIOTRACE_SUPPORT=y 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_DEFAULT_IO_DELAY_TYPE=0 CONFIG_CPA_DEBUG=y CONFIG_KEYS=y CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_DEFAULT_SECURITY="" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y 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_PCOMP=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_CTR=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_FPU=m CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_VMAC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CRC32C_INTEL=m CONFIG_CRYPTO_GHASH=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_RMD128=m CONFIG_CRYPTO_RMD160=m CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=y CONFIG_CRYPTO_LZO=m CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_AMD=m CONFIG_VIRTIO=m CONFIG_VIRTIO_RING=m CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m CONFIG_BINARY_PRINTF=y CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_FIND_LAST_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_LZO_COMPRESS=m CONFIG_LZO_DECOMPRESS=m CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_NLATTR=y ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU 2010-01-11 3:39 ` Sid Boyce (?) @ 2010-01-11 20:04 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:04 UTC (permalink / raw) To: sboyce Cc: Linux Kernel Mailing List, Kernel Testers List, ACPI Devel Maling List On Monday 11 January 2010, Sid Boyce wrote: > On 10/01/10 22:32, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 > > Subject : All kernels after 2.6.32-git10 show only 1 CPU > > Submitter : Sid Boyce <sboyce@blueyonder.co.uk> > > Date : 2009-12-23 16:55 (19 days old) > > References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 > > > > > > > > > > With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its > locking up solid at this part of the boot process as usual. > ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 > HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) > -> IRQ 22. > With acpi=noirq (2 CPU's) > ================ > kvm: Nested Virtualization enabled. > IT8716 Super IO detected > Parport_PC 00:0a: reported by plug and Play ACPI > Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] > parport: irq 7 in use, resorting to polled operation > HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 > > With acpi=ht (1 CPU) > ============= > Hangs at:- > Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for > vector (irq -1) > > With acpi=off (2 CPU's) > ======================== > Hangs at same point as with acpi=noirq. Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* HDA Intel Audio hang on boot @ 2010-01-15 1:24 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-15 1:24 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Rafael J. Wysocki, Kernel Testers List Renaming this bug as the "only 1 CPU" bug has been fixed, but the hang at HDA remains. I shall plug in a SB Audigy and see if it will boot with that. By disabling the on-board HDA Intel audio in the BIOS, the system boots. tindog:~ # uname -r 2.6.33-rc4-smp On 2.6.32-git1 which boots, hwinfo shows:- oss.card_id = 'HDA NVidia' oss.card_id = 'HDA NVidia' oss.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' info.product = 'HDA NVidia ALSA hardware specific Device' alsa.card_id = 'HDA NVidia' info.product = 'HDA NVidia ALSA Control Device' alsa.card_id = 'HDA NVidia' info.product = 'HDA NVidia Sound Card' sound.card_id = 'HDA NVidia' info.linux.driver = 'HDA Intel' 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel HDA Intel: /devices/pci0000:00/0000:00:0e.1 HDA Intel: module = snd_hda_intel irq:0 22 ( 490413) "sata_nv" "HDA Intel" HDA Intel: /devices/pci0000:00/0000:00:0e.1 HDA Intel: module = snd_hda_intel HDA Intel: /devices/pci0000:00/0000:00:0e.1 HDA Intel: module = snd_hda_intel E: DRIVER=HDA Intel <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) -> IRQ 22 <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 Driver: "HDA Intel" Regards Sid. On 11/01/10 03:39, Sid Boyce wrote: > On 10/01/10 22:32, Rafael J. Wysocki wrote: >> This message has been generated automatically as a part of a report >> of recent regressions. >> >> The following bug entry is on the current list of known regressions >> from 2.6.32. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 >> Subject : All kernels after 2.6.32-git10 show only 1 CPU >> Submitter : Sid Boyce <sboyce@blueyonder.co.uk> >> Date : 2009-12-23 16:55 (19 days old) >> References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 >> >> >> >> > > With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its > locking up solid at this part of the boot process as usual. > ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 > HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) > -> IRQ 22. > With acpi=noirq (2 CPU's) > ================ > kvm: Nested Virtualization enabled. > IT8716 Super IO detected > Parport_PC 00:0a: reported by plug and Play ACPI > Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] > parport: irq 7 in use, resorting to polled operation > HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 > > With acpi=ht (1 CPU) > ============= > Hangs at:- > Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for > vector (irq -1) > > With acpi=off (2 CPU's) > ======================== > Hangs at same point as with acpi=noirq. > > Regards > Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* HDA Intel Audio hang on boot @ 2010-01-15 1:24 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-15 1:24 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Rafael J. Wysocki, Kernel Testers List Renaming this bug as the "only 1 CPU" bug has been fixed, but the hang at HDA remains. I shall plug in a SB Audigy and see if it will boot with that. By disabling the on-board HDA Intel audio in the BIOS, the system boots. tindog:~ # uname -r 2.6.33-rc4-smp On 2.6.32-git1 which boots, hwinfo shows:- oss.card_id = 'HDA NVidia' oss.card_id = 'HDA NVidia' oss.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' alsa.card_id = 'HDA NVidia' info.product = 'HDA NVidia ALSA hardware specific Device' alsa.card_id = 'HDA NVidia' info.product = 'HDA NVidia ALSA Control Device' alsa.card_id = 'HDA NVidia' info.product = 'HDA NVidia Sound Card' sound.card_id = 'HDA NVidia' info.linux.driver = 'HDA Intel' 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel HDA Intel: /devices/pci0000:00/0000:00:0e.1 HDA Intel: module = snd_hda_intel irq:0 22 ( 490413) "sata_nv" "HDA Intel" HDA Intel: /devices/pci0000:00/0000:00:0e.1 HDA Intel: module = snd_hda_intel HDA Intel: /devices/pci0000:00/0000:00:0e.1 HDA Intel: module = snd_hda_intel E: DRIVER=HDA Intel <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) -> IRQ 22 <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 Driver: "HDA Intel" Regards Sid. On 11/01/10 03:39, Sid Boyce wrote: > On 10/01/10 22:32, Rafael J. Wysocki wrote: >> This message has been generated automatically as a part of a report >> of recent regressions. >> >> The following bug entry is on the current list of known regressions >> from 2.6.32. Please verify if it still should be listed and let me know >> (either way). >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 >> Subject : All kernels after 2.6.32-git10 show only 1 CPU >> Submitter : Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org> >> Date : 2009-12-23 16:55 (19 days old) >> References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 >> >> >> >> > > With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its > locking up solid at this part of the boot process as usual. > ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 > HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) > -> IRQ 22. > With acpi=noirq (2 CPU's) > ================ > kvm: Nested Virtualization enabled. > IT8716 Super IO detected > Parport_PC 00:0a: reported by plug and Play ACPI > Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] > parport: irq 7 in use, resorting to polled operation > HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 > > With acpi=ht (1 CPU) > ============= > Hangs at:- > Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for > vector (irq -1) > > With acpi=off (2 CPU's) > ======================== > Hangs at same point as with acpi=noirq. > > Regards > Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-15 1:24 ` Sid Boyce (?) @ 2010-01-15 16:01 ` Sid Boyce 2010-01-16 16:44 ` Sid Boyce -1 siblings, 1 reply; 248+ messages in thread From: Sid Boyce @ 2010-01-15 16:01 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List With the PCI Audigy card in, the box wouldn't even enter POST, either the Audigy is bad (unknown - from a box that couldn't see the drives) or there is something faulty on the motherboard. I am currently running 2.6.33-rc4-git2 on the box with a Terratec Aureon 5.1 USB MK II sound card. Regards Sid. On 15/01/10 01:24, Sid Boyce wrote: > Renaming this bug as the "only 1 CPU" bug has been fixed, but the hang > at HDA remains. > I shall plug in a SB Audigy and see if it will boot with that. > By disabling the on-board HDA Intel audio in the BIOS, the system boots. > tindog:~ # uname -r > 2.6.33-rc4-smp > On 2.6.32-git1 which boots, hwinfo shows:- > oss.card_id = 'HDA NVidia' > oss.card_id = 'HDA NVidia' > oss.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia ALSA hardware specific Device' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia ALSA Control Device' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia Sound Card' > sound.card_id = 'HDA NVidia' > info.linux.driver = 'HDA Intel' > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > E: DRIVER=HDA Intel > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > low) -> IRQ 22 > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > Driver: "HDA Intel" > > Regards > Sid. > > On 11/01/10 03:39, Sid Boyce wrote: >> On 10/01/10 22:32, Rafael J. Wysocki wrote: >>> This message has been generated automatically as a part of a report >>> of recent regressions. >>> >>> The following bug entry is on the current list of known regressions >>> from 2.6.32. Please verify if it still should be listed and let me know >>> (either way). >>> >>> >>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 >>> Subject : All kernels after 2.6.32-git10 show only 1 CPU >>> Submitter : Sid Boyce <sboyce@blueyonder.co.uk> >>> Date : 2009-12-23 16:55 (19 days old) >>> References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 >>> >>> >>> >>> >> >> With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its >> locking up solid at this part of the boot process as usual. >> ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 >> HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) >> -> IRQ 22. >> With acpi=noirq (2 CPU's) >> ================ >> kvm: Nested Virtualization enabled. >> IT8716 Super IO detected >> Parport_PC 00:0a: reported by plug and Play ACPI >> Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] >> parport: irq 7 in use, resorting to polled operation >> HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 >> >> With acpi=ht (1 CPU) >> ============= >> Hangs at:- >> Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for >> vector (irq -1) >> >> With acpi=off (2 CPU's) >> ======================== >> Hangs at same point as with acpi=noirq. >> >> Regards >> Sid. > > -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-16 16:44 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-16 16:44 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On 15/01/10 16:01, Sid Boyce wrote: > With the PCI Audigy card in, the box wouldn't even enter POST, either > the Audigy is bad (unknown - from a box that couldn't see the drives) or > there is something faulty on the motherboard. I am currently running > 2.6.33-rc4-git2 on the box with a Terratec Aureon 5.1 USB MK II sound card. > Regards > Sid. > The Audigy card is definitely bad as the original box now works fine without it. Something has definitely changed in the HDA Intel code or handling of it that causes that card to cause a solid lock-up on kernels >2.6.32-git1. Regards Sid. > On 15/01/10 01:24, Sid Boyce wrote: >> Renaming this bug as the "only 1 CPU" bug has been fixed, but the hang >> at HDA remains. >> I shall plug in a SB Audigy and see if it will boot with that. >> By disabling the on-board HDA Intel audio in the BIOS, the system boots. >> tindog:~ # uname -r >> 2.6.33-rc4-smp >> On 2.6.32-git1 which boots, hwinfo shows:- >> oss.card_id = 'HDA NVidia' >> oss.card_id = 'HDA NVidia' >> oss.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> info.product = 'HDA NVidia ALSA hardware specific Device' >> alsa.card_id = 'HDA NVidia' >> info.product = 'HDA NVidia ALSA Control Device' >> alsa.card_id = 'HDA NVidia' >> info.product = 'HDA NVidia Sound Card' >> sound.card_id = 'HDA NVidia' >> info.linux.driver = 'HDA Intel' >> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >> HDA Intel: module = snd_hda_intel >> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >> HDA Intel: module = snd_hda_intel >> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >> HDA Intel: module = snd_hda_intel >> E: DRIVER=HDA Intel >> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >> low) -> IRQ 22 >> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >> Driver: "HDA Intel" >> >> Regards >> Sid. >> >> On 11/01/10 03:39, Sid Boyce wrote: >>> On 10/01/10 22:32, Rafael J. Wysocki wrote: >>>> This message has been generated automatically as a part of a report >>>> of recent regressions. >>>> >>>> The following bug entry is on the current list of known regressions >>>> from 2.6.32. Please verify if it still should be listed and let me know >>>> (either way). >>>> >>>> >>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 >>>> Subject : All kernels after 2.6.32-git10 show only 1 CPU >>>> Submitter : Sid Boyce <sboyce@blueyonder.co.uk> >>>> Date : 2009-12-23 16:55 (19 days old) >>>> References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 >>>> >>>> >>>> >>>> >>> >>> With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its >>> locking up solid at this part of the boot process as usual. >>> ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 >>> HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) >>> -> IRQ 22. >>> With acpi=noirq (2 CPU's) >>> ================ >>> kvm: Nested Virtualization enabled. >>> IT8716 Super IO detected >>> Parport_PC 00:0a: reported by plug and Play ACPI >>> Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] >>> parport: irq 7 in use, resorting to polled operation >>> HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 >>> >>> With acpi=ht (1 CPU) >>> ============= >>> Hangs at:- >>> Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for >>> vector (irq -1) >>> >>> With acpi=off (2 CPU's) >>> ======================== >>> Hangs at same point as with acpi=noirq. >>> >>> Regards >>> Sid. >> >> > > -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-16 16:44 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-16 16:44 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On 15/01/10 16:01, Sid Boyce wrote: > With the PCI Audigy card in, the box wouldn't even enter POST, either > the Audigy is bad (unknown - from a box that couldn't see the drives) or > there is something faulty on the motherboard. I am currently running > 2.6.33-rc4-git2 on the box with a Terratec Aureon 5.1 USB MK II sound card. > Regards > Sid. > The Audigy card is definitely bad as the original box now works fine without it. Something has definitely changed in the HDA Intel code or handling of it that causes that card to cause a solid lock-up on kernels >2.6.32-git1. Regards Sid. > On 15/01/10 01:24, Sid Boyce wrote: >> Renaming this bug as the "only 1 CPU" bug has been fixed, but the hang >> at HDA remains. >> I shall plug in a SB Audigy and see if it will boot with that. >> By disabling the on-board HDA Intel audio in the BIOS, the system boots. >> tindog:~ # uname -r >> 2.6.33-rc4-smp >> On 2.6.32-git1 which boots, hwinfo shows:- >> oss.card_id = 'HDA NVidia' >> oss.card_id = 'HDA NVidia' >> oss.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> alsa.card_id = 'HDA NVidia' >> info.product = 'HDA NVidia ALSA hardware specific Device' >> alsa.card_id = 'HDA NVidia' >> info.product = 'HDA NVidia ALSA Control Device' >> alsa.card_id = 'HDA NVidia' >> info.product = 'HDA NVidia Sound Card' >> sound.card_id = 'HDA NVidia' >> info.linux.driver = 'HDA Intel' >> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >> HDA Intel: module = snd_hda_intel >> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >> HDA Intel: module = snd_hda_intel >> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >> HDA Intel: module = snd_hda_intel >> E: DRIVER=HDA Intel >> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >> low) -> IRQ 22 >> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >> Driver: "HDA Intel" >> >> Regards >> Sid. >> >> On 11/01/10 03:39, Sid Boyce wrote: >>> On 10/01/10 22:32, Rafael J. Wysocki wrote: >>>> This message has been generated automatically as a part of a report >>>> of recent regressions. >>>> >>>> The following bug entry is on the current list of known regressions >>>> from 2.6.32. Please verify if it still should be listed and let me know >>>> (either way). >>>> >>>> >>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 >>>> Subject : All kernels after 2.6.32-git10 show only 1 CPU >>>> Submitter : Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org> >>>> Date : 2009-12-23 16:55 (19 days old) >>>> References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 >>>> >>>> >>>> >>>> >>> >>> With 2.6.33-rc3-git3 I now see 2 CPU's every on a normal boot, but its >>> locking up solid at this part of the boot process as usual. >>> ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 22 >>> HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, low) >>> -> IRQ 22. >>> With acpi=noirq (2 CPU's) >>> ================ >>> kvm: Nested Virtualization enabled. >>> IT8716 Super IO detected >>> Parport_PC 00:0a: reported by plug and Play ACPI >>> Parport 0: PC-Style at 0x378, irq 7 [PCSPP, TRISTATE,EPP] >>> parport: irq 7 in use, resorting to polled operation >>> HDA Intel 0000:00:0e.1: PCI -> APIC IRQ transform: INT B -> IRQ 11 >>> >>> With acpi=ht (1 CPU) >>> ============= >>> Hangs at:- >>> Loading drivees, configuring devices do_IRQ: 0.65 No irq handler for >>> vector (irq -1) >>> >>> With acpi=off (2 CPU's) >>> ======================== >>> Hangs at same point as with acpi=noirq. >>> >>> Regards >>> Sid. >> >> > > -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-25 1:48 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-25 1:48 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On 15/01/10 01:24, Sid Boyce wrote: This is the only outstanding bug. No problems up 2.6.32-git1, but I get a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio is not disabled in the BIOS. Regards Sid. > tindog:~ # uname -r > 2.6.33-rc4-smp > On 2.6.32-git1 which boots, hwinfo shows:- > oss.card_id = 'HDA NVidia' > oss.card_id = 'HDA NVidia' > oss.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia ALSA hardware specific Device' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia ALSA Control Device' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia Sound Card' > sound.card_id = 'HDA NVidia' > info.linux.driver = 'HDA Intel' > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > E: DRIVER=HDA Intel > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > low) -> IRQ 22 > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > Driver: "HDA Intel" > > Regards > Sid. > -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-25 1:48 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-25 1:48 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On 15/01/10 01:24, Sid Boyce wrote: This is the only outstanding bug. No problems up 2.6.32-git1, but I get a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio is not disabled in the BIOS. Regards Sid. > tindog:~ # uname -r > 2.6.33-rc4-smp > On 2.6.32-git1 which boots, hwinfo shows:- > oss.card_id = 'HDA NVidia' > oss.card_id = 'HDA NVidia' > oss.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia ALSA hardware specific Device' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia ALSA Control Device' > alsa.card_id = 'HDA NVidia' > info.product = 'HDA NVidia Sound Card' > sound.card_id = 'HDA NVidia' > info.linux.driver = 'HDA Intel' > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > HDA Intel: module = snd_hda_intel > E: DRIVER=HDA Intel > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > low) -> IRQ 22 > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > Driver: "HDA Intel" > > Regards > Sid. > -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-25 21:39 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-25 21:39 UTC (permalink / raw) To: sboyce, Takashi Iwai; +Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 25 January 2010, Sid Boyce wrote: > On 15/01/10 01:24, Sid Boyce wrote: > This is the only outstanding bug. No problems up 2.6.32-git1, but I get > a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > is not disabled in the BIOS. I guess we should let Takashi know. > > tindog:~ # uname -r > > 2.6.33-rc4-smp > > On 2.6.32-git1 which boots, hwinfo shows:- > > oss.card_id = 'HDA NVidia' > > oss.card_id = 'HDA NVidia' > > oss.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > info.product = 'HDA NVidia ALSA hardware specific Device' > > alsa.card_id = 'HDA NVidia' > > info.product = 'HDA NVidia ALSA Control Device' > > alsa.card_id = 'HDA NVidia' > > info.product = 'HDA NVidia Sound Card' > > sound.card_id = 'HDA NVidia' > > info.linux.driver = 'HDA Intel' > > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > HDA Intel: module = snd_hda_intel > > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > HDA Intel: module = snd_hda_intel > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > HDA Intel: module = snd_hda_intel > > E: DRIVER=HDA Intel > > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > low) -> IRQ 22 > > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > Driver: "HDA Intel" Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-25 21:39 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-25 21:39 UTC (permalink / raw) To: sboyce-QgLWrMLu8clzjhtm8Ag3mw, Takashi Iwai Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 25 January 2010, Sid Boyce wrote: > On 15/01/10 01:24, Sid Boyce wrote: > This is the only outstanding bug. No problems up 2.6.32-git1, but I get > a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > is not disabled in the BIOS. I guess we should let Takashi know. > > tindog:~ # uname -r > > 2.6.33-rc4-smp > > On 2.6.32-git1 which boots, hwinfo shows:- > > oss.card_id = 'HDA NVidia' > > oss.card_id = 'HDA NVidia' > > oss.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > alsa.card_id = 'HDA NVidia' > > info.product = 'HDA NVidia ALSA hardware specific Device' > > alsa.card_id = 'HDA NVidia' > > info.product = 'HDA NVidia ALSA Control Device' > > alsa.card_id = 'HDA NVidia' > > info.product = 'HDA NVidia Sound Card' > > sound.card_id = 'HDA NVidia' > > info.linux.driver = 'HDA Intel' > > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > HDA Intel: module = snd_hda_intel > > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > HDA Intel: module = snd_hda_intel > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > HDA Intel: module = snd_hda_intel > > E: DRIVER=HDA Intel > > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > low) -> IRQ 22 > > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > Driver: "HDA Intel" Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-25 21:54 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-25 21:54 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: sboyce, Linux Kernel Mailing List, Kernel Testers List At Mon, 25 Jan 2010 22:39:02 +0100, Rafael J. Wysocki wrote: > > On Monday 25 January 2010, Sid Boyce wrote: > > On 15/01/10 01:24, Sid Boyce wrote: > > This is the only outstanding bug. No problems up 2.6.32-git1, but I get > > a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > > is not disabled in the BIOS. > > I guess we should let Takashi know. Thanks. > > > tindog:~ # uname -r > > > 2.6.33-rc4-smp > > > On 2.6.32-git1 which boots, hwinfo shows:- > > > oss.card_id = 'HDA NVidia' > > > oss.card_id = 'HDA NVidia' > > > oss.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > info.product = 'HDA NVidia ALSA hardware specific Device' > > > alsa.card_id = 'HDA NVidia' > > > info.product = 'HDA NVidia ALSA Control Device' > > > alsa.card_id = 'HDA NVidia' > > > info.product = 'HDA NVidia Sound Card' > > > sound.card_id = 'HDA NVidia' > > > info.linux.driver = 'HDA Intel' > > > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > HDA Intel: module = snd_hda_intel > > > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > HDA Intel: module = snd_hda_intel > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > HDA Intel: module = snd_hda_intel > > > E: DRIVER=HDA Intel > > > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > > low) -> IRQ 22 > > > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > > Driver: "HDA Intel" What I'd try first is to pass enable_msi=0 option. The MSI is enabled as default on 2.6.33 kernel, and this might be problematic on non-Intel mobo. Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-25 21:54 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-25 21:54 UTC (permalink / raw) To: Rafael J. Wysocki Cc: sboyce-QgLWrMLu8clzjhtm8Ag3mw, Linux Kernel Mailing List, Kernel Testers List At Mon, 25 Jan 2010 22:39:02 +0100, Rafael J. Wysocki wrote: > > On Monday 25 January 2010, Sid Boyce wrote: > > On 15/01/10 01:24, Sid Boyce wrote: > > This is the only outstanding bug. No problems up 2.6.32-git1, but I get > > a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > > is not disabled in the BIOS. > > I guess we should let Takashi know. Thanks. > > > tindog:~ # uname -r > > > 2.6.33-rc4-smp > > > On 2.6.32-git1 which boots, hwinfo shows:- > > > oss.card_id = 'HDA NVidia' > > > oss.card_id = 'HDA NVidia' > > > oss.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > alsa.card_id = 'HDA NVidia' > > > info.product = 'HDA NVidia ALSA hardware specific Device' > > > alsa.card_id = 'HDA NVidia' > > > info.product = 'HDA NVidia ALSA Control Device' > > > alsa.card_id = 'HDA NVidia' > > > info.product = 'HDA NVidia Sound Card' > > > sound.card_id = 'HDA NVidia' > > > info.linux.driver = 'HDA Intel' > > > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > HDA Intel: module = snd_hda_intel > > > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > HDA Intel: module = snd_hda_intel > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > HDA Intel: module = snd_hda_intel > > > E: DRIVER=HDA Intel > > > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > > low) -> IRQ 22 > > > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > > Driver: "HDA Intel" What I'd try first is to pass enable_msi=0 option. The MSI is enabled as default on 2.6.33 kernel, and this might be problematic on non-Intel mobo. Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-25 21:54 ` Takashi Iwai (?) @ 2010-01-25 21:55 ` Takashi Iwai 2010-01-26 0:59 ` Sid Boyce -1 siblings, 1 reply; 248+ messages in thread From: Takashi Iwai @ 2010-01-25 21:55 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: sboyce, Linux Kernel Mailing List, Kernel Testers List At Mon, 25 Jan 2010 22:54:23 +0100, I wrote: > > At Mon, 25 Jan 2010 22:39:02 +0100, > Rafael J. Wysocki wrote: > > > > On Monday 25 January 2010, Sid Boyce wrote: > > > On 15/01/10 01:24, Sid Boyce wrote: > > > This is the only outstanding bug. No problems up 2.6.32-git1, but I get > > > a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > > > is not disabled in the BIOS. > > > > I guess we should let Takashi know. > > Thanks. > > > > > tindog:~ # uname -r > > > > 2.6.33-rc4-smp > > > > On 2.6.32-git1 which boots, hwinfo shows:- > > > > oss.card_id = 'HDA NVidia' > > > > oss.card_id = 'HDA NVidia' > > > > oss.card_id = 'HDA NVidia' > > > > alsa.card_id = 'HDA NVidia' > > > > alsa.card_id = 'HDA NVidia' > > > > alsa.card_id = 'HDA NVidia' > > > > alsa.card_id = 'HDA NVidia' > > > > info.product = 'HDA NVidia ALSA hardware specific Device' > > > > alsa.card_id = 'HDA NVidia' > > > > info.product = 'HDA NVidia ALSA Control Device' > > > > alsa.card_id = 'HDA NVidia' > > > > info.product = 'HDA NVidia Sound Card' > > > > sound.card_id = 'HDA NVidia' > > > > info.linux.driver = 'HDA Intel' > > > > 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > > HDA Intel: module = snd_hda_intel > > > > irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > > HDA Intel: module = snd_hda_intel > > > > HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > > > HDA Intel: module = snd_hda_intel > > > > E: DRIVER=HDA Intel > > > > <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > > > low) -> IRQ 22 > > > > <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > > > Driver: "HDA Intel" > > What I'd try first is to pass enable_msi=0 option. Just to be sure -- it's an option for snd-hda-intel module. Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 0:59 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 0:59 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 25/01/10 21:55, Takashi Iwai wrote: > At Mon, 25 Jan 2010 22:54:23 +0100, > I wrote: >> >> At Mon, 25 Jan 2010 22:39:02 +0100, >> Rafael J. Wysocki wrote: >>> >>> On Monday 25 January 2010, Sid Boyce wrote: >>>> On 15/01/10 01:24, Sid Boyce wrote: >>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>> is not disabled in the BIOS. >>> >>> I guess we should let Takashi know. >> >> Thanks. >> >>>>> tindog:~ # uname -r >>>>> 2.6.33-rc4-smp >>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>> oss.card_id = 'HDA NVidia' >>>>> oss.card_id = 'HDA NVidia' >>>>> oss.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>> alsa.card_id = 'HDA NVidia' >>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>> alsa.card_id = 'HDA NVidia' >>>>> info.product = 'HDA NVidia Sound Card' >>>>> sound.card_id = 'HDA NVidia' >>>>> info.linux.driver = 'HDA Intel' >>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>> HDA Intel: module = snd_hda_intel >>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>> HDA Intel: module = snd_hda_intel >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>> HDA Intel: module = snd_hda_intel >>>>> E: DRIVER=HDA Intel >>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>> low) -> IRQ 22 >>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>> Driver: "HDA Intel" >> >> What I'd try first is to pass enable_msi=0 option. > > Just to be sure -- it's an option for snd-hda-intel module. > > > Takashi > I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command line, still locks up as before. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 0:59 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 0:59 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 25/01/10 21:55, Takashi Iwai wrote: > At Mon, 25 Jan 2010 22:54:23 +0100, > I wrote: >> >> At Mon, 25 Jan 2010 22:39:02 +0100, >> Rafael J. Wysocki wrote: >>> >>> On Monday 25 January 2010, Sid Boyce wrote: >>>> On 15/01/10 01:24, Sid Boyce wrote: >>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>> is not disabled in the BIOS. >>> >>> I guess we should let Takashi know. >> >> Thanks. >> >>>>> tindog:~ # uname -r >>>>> 2.6.33-rc4-smp >>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>> oss.card_id = 'HDA NVidia' >>>>> oss.card_id = 'HDA NVidia' >>>>> oss.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> alsa.card_id = 'HDA NVidia' >>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>> alsa.card_id = 'HDA NVidia' >>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>> alsa.card_id = 'HDA NVidia' >>>>> info.product = 'HDA NVidia Sound Card' >>>>> sound.card_id = 'HDA NVidia' >>>>> info.linux.driver = 'HDA Intel' >>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>> HDA Intel: module = snd_hda_intel >>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>> HDA Intel: module = snd_hda_intel >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>> HDA Intel: module = snd_hda_intel >>>>> E: DRIVER=HDA Intel >>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>> low) -> IRQ 22 >>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>> Driver: "HDA Intel" >> >> What I'd try first is to pass enable_msi=0 option. > > Just to be sure -- it's an option for snd-hda-intel module. > > > Takashi > I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command line, still locks up as before. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-26 0:59 ` Sid Boyce (?) @ 2010-01-26 6:40 ` Takashi Iwai 2010-01-26 6:58 ` Takashi Iwai -1 siblings, 1 reply; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 6:40 UTC (permalink / raw) To: sboyce; +Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 00:59:15 +0000, Sid Boyce wrote: > > On 25/01/10 21:55, Takashi Iwai wrote: > > At Mon, 25 Jan 2010 22:54:23 +0100, > > I wrote: > >> > >> At Mon, 25 Jan 2010 22:39:02 +0100, > >> Rafael J. Wysocki wrote: > >>> > >>> On Monday 25 January 2010, Sid Boyce wrote: > >>>> On 15/01/10 01:24, Sid Boyce wrote: > >>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > >>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > >>>> is not disabled in the BIOS. > >>> > >>> I guess we should let Takashi know. > >> > >> Thanks. > >> > >>>>> tindog:~ # uname -r > >>>>> 2.6.33-rc4-smp > >>>>> On 2.6.32-git1 which boots, hwinfo shows:- > >>>>> oss.card_id = 'HDA NVidia' > >>>>> oss.card_id = 'HDA NVidia' > >>>>> oss.card_id = 'HDA NVidia' > >>>>> alsa.card_id = 'HDA NVidia' > >>>>> alsa.card_id = 'HDA NVidia' > >>>>> alsa.card_id = 'HDA NVidia' > >>>>> alsa.card_id = 'HDA NVidia' > >>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > >>>>> alsa.card_id = 'HDA NVidia' > >>>>> info.product = 'HDA NVidia ALSA Control Device' > >>>>> alsa.card_id = 'HDA NVidia' > >>>>> info.product = 'HDA NVidia Sound Card' > >>>>> sound.card_id = 'HDA NVidia' > >>>>> info.linux.driver = 'HDA Intel' > >>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>> HDA Intel: module = snd_hda_intel > >>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>> HDA Intel: module = snd_hda_intel > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>> HDA Intel: module = snd_hda_intel > >>>>> E: DRIVER=HDA Intel > >>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > >>>>> low) -> IRQ 22 > >>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > >>>>> Driver: "HDA Intel" > >> > >> What I'd try first is to pass enable_msi=0 option. > > > > Just to be sure -- it's an option for snd-hda-intel module. > > > > > > Takashi > > > > I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > line, still locks up as before. OK, are you sure that the lock-up happens at snd-hda-intel module? How about blacklist it once? Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 6:58 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 6:58 UTC (permalink / raw) To: sboyce; +Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 07:40:03 +0100, I wrote: > > At Tue, 26 Jan 2010 00:59:15 +0000, > Sid Boyce wrote: > > > > On 25/01/10 21:55, Takashi Iwai wrote: > > > At Mon, 25 Jan 2010 22:54:23 +0100, > > > I wrote: > > >> > > >> At Mon, 25 Jan 2010 22:39:02 +0100, > > >> Rafael J. Wysocki wrote: > > >>> > > >>> On Monday 25 January 2010, Sid Boyce wrote: > > >>>> On 15/01/10 01:24, Sid Boyce wrote: > > >>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > > >>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > > >>>> is not disabled in the BIOS. > > >>> > > >>> I guess we should let Takashi know. > > >> > > >> Thanks. > > >> > > >>>>> tindog:~ # uname -r > > >>>>> 2.6.33-rc4-smp > > >>>>> On 2.6.32-git1 which boots, hwinfo shows:- > > >>>>> oss.card_id = 'HDA NVidia' > > >>>>> oss.card_id = 'HDA NVidia' > > >>>>> oss.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> info.product = 'HDA NVidia ALSA Control Device' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> info.product = 'HDA NVidia Sound Card' > > >>>>> sound.card_id = 'HDA NVidia' > > >>>>> info.linux.driver = 'HDA Intel' > > >>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>> HDA Intel: module = snd_hda_intel > > >>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>> HDA Intel: module = snd_hda_intel > > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>> HDA Intel: module = snd_hda_intel > > >>>>> E: DRIVER=HDA Intel > > >>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > >>>>> low) -> IRQ 22 > > >>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > >>>>> Driver: "HDA Intel" > > >> > > >> What I'd try first is to pass enable_msi=0 option. > > > > > > Just to be sure -- it's an option for snd-hda-intel module. > > > > > > > > > Takashi > > > > > > > I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > > line, Oh, I overlooked this text. Of course, this can't work :) "modprobe..." isn't for the kernel command line but for modprobe configs, usually specified in /etc/modprobe.d/* file. And... is this report for 2.6.32 or for 2.6.33? If it's with 2.6.32, enable_msi=1 may help instead. Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 6:58 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 6:58 UTC (permalink / raw) To: sboyce-QgLWrMLu8clzjhtm8Ag3mw Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 07:40:03 +0100, I wrote: > > At Tue, 26 Jan 2010 00:59:15 +0000, > Sid Boyce wrote: > > > > On 25/01/10 21:55, Takashi Iwai wrote: > > > At Mon, 25 Jan 2010 22:54:23 +0100, > > > I wrote: > > >> > > >> At Mon, 25 Jan 2010 22:39:02 +0100, > > >> Rafael J. Wysocki wrote: > > >>> > > >>> On Monday 25 January 2010, Sid Boyce wrote: > > >>>> On 15/01/10 01:24, Sid Boyce wrote: > > >>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > > >>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > > >>>> is not disabled in the BIOS. > > >>> > > >>> I guess we should let Takashi know. > > >> > > >> Thanks. > > >> > > >>>>> tindog:~ # uname -r > > >>>>> 2.6.33-rc4-smp > > >>>>> On 2.6.32-git1 which boots, hwinfo shows:- > > >>>>> oss.card_id = 'HDA NVidia' > > >>>>> oss.card_id = 'HDA NVidia' > > >>>>> oss.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> info.product = 'HDA NVidia ALSA Control Device' > > >>>>> alsa.card_id = 'HDA NVidia' > > >>>>> info.product = 'HDA NVidia Sound Card' > > >>>>> sound.card_id = 'HDA NVidia' > > >>>>> info.linux.driver = 'HDA Intel' > > >>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>> HDA Intel: module = snd_hda_intel > > >>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>> HDA Intel: module = snd_hda_intel > > >>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>> HDA Intel: module = snd_hda_intel > > >>>>> E: DRIVER=HDA Intel > > >>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > >>>>> low) -> IRQ 22 > > >>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > >>>>> Driver: "HDA Intel" > > >> > > >> What I'd try first is to pass enable_msi=0 option. > > > > > > Just to be sure -- it's an option for snd-hda-intel module. > > > > > > > > > Takashi > > > > > > > I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > > line, Oh, I overlooked this text. Of course, this can't work :) "modprobe..." isn't for the kernel command line but for modprobe configs, usually specified in /etc/modprobe.d/* file. And... is this report for 2.6.32 or for 2.6.33? If it's with 2.6.32, enable_msi=1 may help instead. Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 12:02 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 12:02 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 26/01/10 06:58, Takashi Iwai wrote: > At Tue, 26 Jan 2010 07:40:03 +0100, > I wrote: >> >> At Tue, 26 Jan 2010 00:59:15 +0000, >> Sid Boyce wrote: >>> >>> On 25/01/10 21:55, Takashi Iwai wrote: >>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>> I wrote: >>>>> >>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>> Rafael J. Wysocki wrote: >>>>>> >>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>> is not disabled in the BIOS. >>>>>> >>>>>> I guess we should let Takashi know. >>>>> >>>>> Thanks. >>>>> >>>>>>>> tindog:~ # uname -r >>>>>>>> 2.6.33-rc4-smp >>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>> E: DRIVER=HDA Intel >>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>> low) -> IRQ 22 >>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>> Driver: "HDA Intel" >>>>> >>>>> What I'd try first is to pass enable_msi=0 option. >>>> >>>> Just to be sure -- it's an option for snd-hda-intel module. >>>> >>>> >>>> Takashi >>>> >>> >>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>> line, > > Oh, I overlooked this text. Of course, this can't work :) > > "modprobe..." isn't for the kernel command line but for modprobe > configs, usually specified in /etc/modprobe.d/* file. > I had already tried that... it locks up at the same point also with "enable_msi=1". tindog:/etc/modprobe.d # less 50-sound.conf options snd slots=snd-hda-intel,enable_msi=0 # mDsH.vLXC8EvZgR7:MCP55 High Definition Audio alias snd-card-0 snd-hda-intel > And... is this report for 2.6.32 or for 2.6.33? > If it's with 2.6.32, enable_msi=1 may help instead. > > The motherboard giving the problem is the Asus M2N32-SLI deluxe. 00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) No such problem with the Asus CROSSHAIR II FORMULA motherboard which also has the 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1) For any kernel >2.6.32-git1 it hangs, i.e 2.6.32-git2 to 2.6.33-rc5. Disabling the sound chip in the BIOS, they all boot. tindog:/etc/modprobe.d # uname -r 2.6.32-git1-smp tindog:/etc/modprobe.d # l /dev/dsp* crw-rw-rw- 1 root audio 14, 3 Jan 26 11:46 /dev/dsp crw-rw-rw- 1 root audio 14, 35 Jan 26 11:46 /dev/dsp2 > Takashi > Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 12:02 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 12:02 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 26/01/10 06:58, Takashi Iwai wrote: > At Tue, 26 Jan 2010 07:40:03 +0100, > I wrote: >> >> At Tue, 26 Jan 2010 00:59:15 +0000, >> Sid Boyce wrote: >>> >>> On 25/01/10 21:55, Takashi Iwai wrote: >>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>> I wrote: >>>>> >>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>> Rafael J. Wysocki wrote: >>>>>> >>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>> is not disabled in the BIOS. >>>>>> >>>>>> I guess we should let Takashi know. >>>>> >>>>> Thanks. >>>>> >>>>>>>> tindog:~ # uname -r >>>>>>>> 2.6.33-rc4-smp >>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>> E: DRIVER=HDA Intel >>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>> low) -> IRQ 22 >>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>> Driver: "HDA Intel" >>>>> >>>>> What I'd try first is to pass enable_msi=0 option. >>>> >>>> Just to be sure -- it's an option for snd-hda-intel module. >>>> >>>> >>>> Takashi >>>> >>> >>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>> line, > > Oh, I overlooked this text. Of course, this can't work :) > > "modprobe..." isn't for the kernel command line but for modprobe > configs, usually specified in /etc/modprobe.d/* file. > I had already tried that... it locks up at the same point also with "enable_msi=1". tindog:/etc/modprobe.d # less 50-sound.conf options snd slots=snd-hda-intel,enable_msi=0 # mDsH.vLXC8EvZgR7:MCP55 High Definition Audio alias snd-card-0 snd-hda-intel > And... is this report for 2.6.32 or for 2.6.33? > If it's with 2.6.32, enable_msi=1 may help instead. > > The motherboard giving the problem is the Asus M2N32-SLI deluxe. 00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) No such problem with the Asus CROSSHAIR II FORMULA motherboard which also has the 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1) For any kernel >2.6.32-git1 it hangs, i.e 2.6.32-git2 to 2.6.33-rc5. Disabling the sound chip in the BIOS, they all boot. tindog:/etc/modprobe.d # uname -r 2.6.32-git1-smp tindog:/etc/modprobe.d # l /dev/dsp* crw-rw-rw- 1 root audio 14, 3 Jan 26 11:46 /dev/dsp crw-rw-rw- 1 root audio 14, 35 Jan 26 11:46 /dev/dsp2 > Takashi > Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-26 12:02 ` Sid Boyce (?) @ 2010-01-26 12:51 ` Rafael J. Wysocki 2010-01-26 13:18 ` Sid Boyce -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-26 12:51 UTC (permalink / raw) To: sboyce; +Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List On Tuesday 26 January 2010, Sid Boyce wrote: > On 26/01/10 06:58, Takashi Iwai wrote: ... > > And... is this report for 2.6.32 or for 2.6.33? > > If it's with 2.6.32, enable_msi=1 may help instead. > > > > > The motherboard giving the problem is the Asus M2N32-SLI deluxe. > 00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio > (rev a2) > > No such problem with the Asus CROSSHAIR II FORMULA motherboard which > also has the > 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S > High Definition Audio (rev a1) > > For any kernel >2.6.32-git1 it hangs, i.e 2.6.32-git2 to 2.6.33-rc5. > Disabling the sound chip in the BIOS, they all boot. > tindog:/etc/modprobe.d # uname -r > 2.6.32-git1-smp > tindog:/etc/modprobe.d # l /dev/dsp* > crw-rw-rw- 1 root audio 14, 3 Jan 26 11:46 /dev/dsp > crw-rw-rw- 1 root audio 14, 35 Jan 26 11:46 /dev/dsp2 Is your adapter build as a module or is it compiled directly into the kernel? Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-26 12:51 ` Rafael J. Wysocki @ 2010-01-26 13:18 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 13:18 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List On 26/01/10 12:51, Rafael J. Wysocki wrote: > On Tuesday 26 January 2010, Sid Boyce wrote: >> On 26/01/10 06:58, Takashi Iwai wrote: > ... >>> And... is this report for 2.6.32 or for 2.6.33? >>> If it's with 2.6.32, enable_msi=1 may help instead. >>> >>> >> The motherboard giving the problem is the Asus M2N32-SLI deluxe. >> 00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio >> (rev a2) >> >> No such problem with the Asus CROSSHAIR II FORMULA motherboard which >> also has the >> 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S >> High Definition Audio (rev a1) >> >> For any kernel >2.6.32-git1 it hangs, i.e 2.6.32-git2 to 2.6.33-rc5. >> Disabling the sound chip in the BIOS, they all boot. >> tindog:/etc/modprobe.d # uname -r >> 2.6.32-git1-smp >> tindog:/etc/modprobe.d # l /dev/dsp* >> crw-rw-rw- 1 root audio 14, 3 Jan 26 11:46 /dev/dsp >> crw-rw-rw- 1 root audio 14, 35 Jan 26 11:46 /dev/dsp2 > > Is your adapter build as a module or is it compiled directly into the kernel? > > Rafael > As a module in 2.6.33-git1 and always for all kernels. # lsmod|grep snd snd_pcm_oss 40102 0 snd_mixer_oss 14822 1 snd_pcm_oss snd_seq 52843 0 snd_hda_codec_analog 73538 1 snd_hda_intel 23660 0 snd_hda_codec 75402 2 snd_hda_codec_analog,snd_hda_intel snd_usb_audio 85288 0 snd_usb_lib 16705 1 snd_usb_audio snd_rawmidi 21568 1 snd_usb_lib snd_pcm 81892 4 snd_pcm_oss,snd_hda_intel,snd_hda_codec,snd_usb_audio snd_seq_device 6514 2 snd_seq,snd_rawmidi snd_hwdep 6346 2 snd_hda_codec,snd_usb_audio snd_timer 20760 2 snd_seq,snd_pcm snd 66395 13 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_usb_lib,snd_rawmidi,snd_pcm,snd_seq_device,snd_hwdep,snd_timer snd_page_alloc 7873 2 snd_hda_intel,snd_pcm soundcore 7147 1 snd usbcore 146206 6 rtl8187,snd_usb_audio,snd_usb_lib,usbhid,ohci_hcd,ehci_hcd Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 12:55 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 12:55 UTC (permalink / raw) To: sboyce; +Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 12:02:44 +0000, Sid Boyce wrote: > > On 26/01/10 06:58, Takashi Iwai wrote: > > At Tue, 26 Jan 2010 07:40:03 +0100, > > I wrote: > >> > >> At Tue, 26 Jan 2010 00:59:15 +0000, > >> Sid Boyce wrote: > >>> > >>> On 25/01/10 21:55, Takashi Iwai wrote: > >>>> At Mon, 25 Jan 2010 22:54:23 +0100, > >>>> I wrote: > >>>>> > >>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > >>>>> Rafael J. Wysocki wrote: > >>>>>> > >>>>>> On Monday 25 January 2010, Sid Boyce wrote: > >>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > >>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > >>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > >>>>>>> is not disabled in the BIOS. > >>>>>> > >>>>>> I guess we should let Takashi know. > >>>>> > >>>>> Thanks. > >>>>> > >>>>>>>> tindog:~ # uname -r > >>>>>>>> 2.6.33-rc4-smp > >>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > >>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> info.product = 'HDA NVidia Sound Card' > >>>>>>>> sound.card_id = 'HDA NVidia' > >>>>>>>> info.linux.driver = 'HDA Intel' > >>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>> E: DRIVER=HDA Intel > >>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > >>>>>>>> low) -> IRQ 22 > >>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > >>>>>>>> Driver: "HDA Intel" > >>>>> > >>>>> What I'd try first is to pass enable_msi=0 option. > >>>> > >>>> Just to be sure -- it's an option for snd-hda-intel module. > >>>> > >>>> > >>>> Takashi > >>>> > >>> > >>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > >>> line, > > > > Oh, I overlooked this text. Of course, this can't work :) > > > > "modprobe..." isn't for the kernel command line but for modprobe > > configs, usually specified in /etc/modprobe.d/* file. > > > I had already tried that... it locks up at the same point also with > "enable_msi=1". > tindog:/etc/modprobe.d # less 50-sound.conf > > options snd slots=snd-hda-intel,enable_msi=0 This is the option for module snd, not snd-hda-intel. Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 12:55 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 12:55 UTC (permalink / raw) To: sboyce-QgLWrMLu8clzjhtm8Ag3mw Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 12:02:44 +0000, Sid Boyce wrote: > > On 26/01/10 06:58, Takashi Iwai wrote: > > At Tue, 26 Jan 2010 07:40:03 +0100, > > I wrote: > >> > >> At Tue, 26 Jan 2010 00:59:15 +0000, > >> Sid Boyce wrote: > >>> > >>> On 25/01/10 21:55, Takashi Iwai wrote: > >>>> At Mon, 25 Jan 2010 22:54:23 +0100, > >>>> I wrote: > >>>>> > >>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > >>>>> Rafael J. Wysocki wrote: > >>>>>> > >>>>>> On Monday 25 January 2010, Sid Boyce wrote: > >>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > >>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > >>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > >>>>>>> is not disabled in the BIOS. > >>>>>> > >>>>>> I guess we should let Takashi know. > >>>>> > >>>>> Thanks. > >>>>> > >>>>>>>> tindog:~ # uname -r > >>>>>>>> 2.6.33-rc4-smp > >>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > >>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > >>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>> info.product = 'HDA NVidia Sound Card' > >>>>>>>> sound.card_id = 'HDA NVidia' > >>>>>>>> info.linux.driver = 'HDA Intel' > >>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>> E: DRIVER=HDA Intel > >>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > >>>>>>>> low) -> IRQ 22 > >>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > >>>>>>>> Driver: "HDA Intel" > >>>>> > >>>>> What I'd try first is to pass enable_msi=0 option. > >>>> > >>>> Just to be sure -- it's an option for snd-hda-intel module. > >>>> > >>>> > >>>> Takashi > >>>> > >>> > >>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > >>> line, > > > > Oh, I overlooked this text. Of course, this can't work :) > > > > "modprobe..." isn't for the kernel command line but for modprobe > > configs, usually specified in /etc/modprobe.d/* file. > > > I had already tried that... it locks up at the same point also with > "enable_msi=1". > tindog:/etc/modprobe.d # less 50-sound.conf > > options snd slots=snd-hda-intel,enable_msi=0 This is the option for module snd, not snd-hda-intel. Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 13:44 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 13:44 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 26/01/10 12:55, Takashi Iwai wrote: > At Tue, 26 Jan 2010 12:02:44 +0000, > Sid Boyce wrote: >> >> On 26/01/10 06:58, Takashi Iwai wrote: >>> At Tue, 26 Jan 2010 07:40:03 +0100, >>> I wrote: >>>> >>>> At Tue, 26 Jan 2010 00:59:15 +0000, >>>> Sid Boyce wrote: >>>>> >>>>> On 25/01/10 21:55, Takashi Iwai wrote: >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>>>> I wrote: >>>>>>> >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>>>> Rafael J. Wysocki wrote: >>>>>>>> >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>>>> is not disabled in the BIOS. >>>>>>>> >>>>>>>> I guess we should let Takashi know. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>>>>> tindog:~ # uname -r >>>>>>>>>> 2.6.33-rc4-smp >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>> E: DRIVER=HDA Intel >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>>>> low) -> IRQ 22 >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>>>> Driver: "HDA Intel" >>>>>>> >>>>>>> What I'd try first is to pass enable_msi=0 option. >>>>>> >>>>>> Just to be sure -- it's an option for snd-hda-intel module. >>>>>> >>>>>> >>>>>> Takashi >>>>>> >>>>> >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>>>> line, >>> >>> Oh, I overlooked this text. Of course, this can't work :) >>> >>> "modprobe..." isn't for the kernel command line but for modprobe >>> configs, usually specified in /etc/modprobe.d/* file. >>> >> I had already tried that... it locks up at the same point also with >> "enable_msi=1". >> tindog:/etc/modprobe.d # less 50-sound.conf >> >> options snd slots=snd-hda-intel,enable_msi=0 > > This is the option for module snd, not snd-hda-intel. > > > Takashi > options snd,enable_msi=0 slots=snd-hda-intel # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio alias snd-card-0 snd-hda-intel enable_msi=0 or 1, it still hangs. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 13:44 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 13:44 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 26/01/10 12:55, Takashi Iwai wrote: > At Tue, 26 Jan 2010 12:02:44 +0000, > Sid Boyce wrote: >> >> On 26/01/10 06:58, Takashi Iwai wrote: >>> At Tue, 26 Jan 2010 07:40:03 +0100, >>> I wrote: >>>> >>>> At Tue, 26 Jan 2010 00:59:15 +0000, >>>> Sid Boyce wrote: >>>>> >>>>> On 25/01/10 21:55, Takashi Iwai wrote: >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>>>> I wrote: >>>>>>> >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>>>> Rafael J. Wysocki wrote: >>>>>>>> >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>>>> is not disabled in the BIOS. >>>>>>>> >>>>>>>> I guess we should let Takashi know. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>>>>> tindog:~ # uname -r >>>>>>>>>> 2.6.33-rc4-smp >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>> E: DRIVER=HDA Intel >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>>>> low) -> IRQ 22 >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>>>> Driver: "HDA Intel" >>>>>>> >>>>>>> What I'd try first is to pass enable_msi=0 option. >>>>>> >>>>>> Just to be sure -- it's an option for snd-hda-intel module. >>>>>> >>>>>> >>>>>> Takashi >>>>>> >>>>> >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>>>> line, >>> >>> Oh, I overlooked this text. Of course, this can't work :) >>> >>> "modprobe..." isn't for the kernel command line but for modprobe >>> configs, usually specified in /etc/modprobe.d/* file. >>> >> I had already tried that... it locks up at the same point also with >> "enable_msi=1". >> tindog:/etc/modprobe.d # less 50-sound.conf >> >> options snd slots=snd-hda-intel,enable_msi=0 > > This is the option for module snd, not snd-hda-intel. > > > Takashi > options snd,enable_msi=0 slots=snd-hda-intel # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio alias snd-card-0 snd-hda-intel enable_msi=0 or 1, it still hangs. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 13:48 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 13:48 UTC (permalink / raw) To: sboyce; +Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 13:44:23 +0000, Sid Boyce wrote: > > On 26/01/10 12:55, Takashi Iwai wrote: > > At Tue, 26 Jan 2010 12:02:44 +0000, > > Sid Boyce wrote: > >> > >> On 26/01/10 06:58, Takashi Iwai wrote: > >>> At Tue, 26 Jan 2010 07:40:03 +0100, > >>> I wrote: > >>>> > >>>> At Tue, 26 Jan 2010 00:59:15 +0000, > >>>> Sid Boyce wrote: > >>>>> > >>>>> On 25/01/10 21:55, Takashi Iwai wrote: > >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, > >>>>>> I wrote: > >>>>>>> > >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > >>>>>>> Rafael J. Wysocki wrote: > >>>>>>>> > >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: > >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > >>>>>>>>> is not disabled in the BIOS. > >>>>>>>> > >>>>>>>> I guess we should let Takashi know. > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>>>>> tindog:~ # uname -r > >>>>>>>>>> 2.6.33-rc4-smp > >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia Sound Card' > >>>>>>>>>> sound.card_id = 'HDA NVidia' > >>>>>>>>>> info.linux.driver = 'HDA Intel' > >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> E: DRIVER=HDA Intel > >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > >>>>>>>>>> low) -> IRQ 22 > >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > >>>>>>>>>> Driver: "HDA Intel" > >>>>>>> > >>>>>>> What I'd try first is to pass enable_msi=0 option. > >>>>>> > >>>>>> Just to be sure -- it's an option for snd-hda-intel module. > >>>>>> > >>>>>> > >>>>>> Takashi > >>>>>> > >>>>> > >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > >>>>> line, > >>> > >>> Oh, I overlooked this text. Of course, this can't work :) > >>> > >>> "modprobe..." isn't for the kernel command line but for modprobe > >>> configs, usually specified in /etc/modprobe.d/* file. > >>> > >> I had already tried that... it locks up at the same point also with > >> "enable_msi=1". > >> tindog:/etc/modprobe.d # less 50-sound.conf > >> > >> options snd slots=snd-hda-intel,enable_msi=0 > > > > This is the option for module snd, not snd-hda-intel. > > > > > > Takashi > > > options snd,enable_msi=0 slots=snd-hda-intel It's a line for module "snd,enable_msi=0", which is likely invalid :) Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 13:48 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 13:48 UTC (permalink / raw) To: sboyce-QgLWrMLu8clzjhtm8Ag3mw Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 13:44:23 +0000, Sid Boyce wrote: > > On 26/01/10 12:55, Takashi Iwai wrote: > > At Tue, 26 Jan 2010 12:02:44 +0000, > > Sid Boyce wrote: > >> > >> On 26/01/10 06:58, Takashi Iwai wrote: > >>> At Tue, 26 Jan 2010 07:40:03 +0100, > >>> I wrote: > >>>> > >>>> At Tue, 26 Jan 2010 00:59:15 +0000, > >>>> Sid Boyce wrote: > >>>>> > >>>>> On 25/01/10 21:55, Takashi Iwai wrote: > >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, > >>>>>> I wrote: > >>>>>>> > >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > >>>>>>> Rafael J. Wysocki wrote: > >>>>>>>> > >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: > >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > >>>>>>>>> is not disabled in the BIOS. > >>>>>>>> > >>>>>>>> I guess we should let Takashi know. > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>>>>> tindog:~ # uname -r > >>>>>>>>>> 2.6.33-rc4-smp > >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia Sound Card' > >>>>>>>>>> sound.card_id = 'HDA NVidia' > >>>>>>>>>> info.linux.driver = 'HDA Intel' > >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> E: DRIVER=HDA Intel > >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > >>>>>>>>>> low) -> IRQ 22 > >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > >>>>>>>>>> Driver: "HDA Intel" > >>>>>>> > >>>>>>> What I'd try first is to pass enable_msi=0 option. > >>>>>> > >>>>>> Just to be sure -- it's an option for snd-hda-intel module. > >>>>>> > >>>>>> > >>>>>> Takashi > >>>>>> > >>>>> > >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > >>>>> line, > >>> > >>> Oh, I overlooked this text. Of course, this can't work :) > >>> > >>> "modprobe..." isn't for the kernel command line but for modprobe > >>> configs, usually specified in /etc/modprobe.d/* file. > >>> > >> I had already tried that... it locks up at the same point also with > >> "enable_msi=1". > >> tindog:/etc/modprobe.d # less 50-sound.conf > >> > >> options snd slots=snd-hda-intel,enable_msi=0 > > > > This is the option for module snd, not snd-hda-intel. > > > > > > Takashi > > > options snd,enable_msi=0 slots=snd-hda-intel It's a line for module "snd,enable_msi=0", which is likely invalid :) Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 18:22 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-26 18:22 UTC (permalink / raw) To: sboyce; +Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List On Tuesday 26 January 2010, Sid Boyce wrote: > On 26/01/10 12:55, Takashi Iwai wrote: > > At Tue, 26 Jan 2010 12:02:44 +0000, > > Sid Boyce wrote: > >> > >> On 26/01/10 06:58, Takashi Iwai wrote: > >>> At Tue, 26 Jan 2010 07:40:03 +0100, > >>> I wrote: > >>>> > >>>> At Tue, 26 Jan 2010 00:59:15 +0000, > >>>> Sid Boyce wrote: > >>>>> > >>>>> On 25/01/10 21:55, Takashi Iwai wrote: > >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, > >>>>>> I wrote: > >>>>>>> > >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > >>>>>>> Rafael J. Wysocki wrote: > >>>>>>>> > >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: > >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > >>>>>>>>> is not disabled in the BIOS. > >>>>>>>> > >>>>>>>> I guess we should let Takashi know. > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>>>>> tindog:~ # uname -r > >>>>>>>>>> 2.6.33-rc4-smp > >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia Sound Card' > >>>>>>>>>> sound.card_id = 'HDA NVidia' > >>>>>>>>>> info.linux.driver = 'HDA Intel' > >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> E: DRIVER=HDA Intel > >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > >>>>>>>>>> low) -> IRQ 22 > >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > >>>>>>>>>> Driver: "HDA Intel" > >>>>>>> > >>>>>>> What I'd try first is to pass enable_msi=0 option. > >>>>>> > >>>>>> Just to be sure -- it's an option for snd-hda-intel module. > >>>>>> > >>>>>> > >>>>>> Takashi > >>>>>> > >>>>> > >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > >>>>> line, > >>> > >>> Oh, I overlooked this text. Of course, this can't work :) > >>> > >>> "modprobe..." isn't for the kernel command line but for modprobe > >>> configs, usually specified in /etc/modprobe.d/* file. > >>> > >> I had already tried that... it locks up at the same point also with > >> "enable_msi=1". > >> tindog:/etc/modprobe.d # less 50-sound.conf > >> > >> options snd slots=snd-hda-intel,enable_msi=0 > > > > This is the option for module snd, not snd-hda-intel. > > > > > > Takashi > > > options snd,enable_msi=0 slots=snd-hda-intel options snd enable_msi=0 slots=snd-hda-intel (ie. the comma shouldn't be present in there). > # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio > alias snd-card-0 snd-hda-intel Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 18:22 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-26 18:22 UTC (permalink / raw) To: sboyce-QgLWrMLu8clzjhtm8Ag3mw Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List On Tuesday 26 January 2010, Sid Boyce wrote: > On 26/01/10 12:55, Takashi Iwai wrote: > > At Tue, 26 Jan 2010 12:02:44 +0000, > > Sid Boyce wrote: > >> > >> On 26/01/10 06:58, Takashi Iwai wrote: > >>> At Tue, 26 Jan 2010 07:40:03 +0100, > >>> I wrote: > >>>> > >>>> At Tue, 26 Jan 2010 00:59:15 +0000, > >>>> Sid Boyce wrote: > >>>>> > >>>>> On 25/01/10 21:55, Takashi Iwai wrote: > >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, > >>>>>> I wrote: > >>>>>>> > >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > >>>>>>> Rafael J. Wysocki wrote: > >>>>>>>> > >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: > >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > >>>>>>>>> is not disabled in the BIOS. > >>>>>>>> > >>>>>>>> I guess we should let Takashi know. > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>>>>> tindog:~ # uname -r > >>>>>>>>>> 2.6.33-rc4-smp > >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> oss.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > >>>>>>>>>> info.product = 'HDA NVidia Sound Card' > >>>>>>>>>> sound.card_id = 'HDA NVidia' > >>>>>>>>>> info.linux.driver = 'HDA Intel' > >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > >>>>>>>>>> HDA Intel: module = snd_hda_intel > >>>>>>>>>> E: DRIVER=HDA Intel > >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > >>>>>>>>>> low) -> IRQ 22 > >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > >>>>>>>>>> Driver: "HDA Intel" > >>>>>>> > >>>>>>> What I'd try first is to pass enable_msi=0 option. > >>>>>> > >>>>>> Just to be sure -- it's an option for snd-hda-intel module. > >>>>>> > >>>>>> > >>>>>> Takashi > >>>>>> > >>>>> > >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > >>>>> line, > >>> > >>> Oh, I overlooked this text. Of course, this can't work :) > >>> > >>> "modprobe..." isn't for the kernel command line but for modprobe > >>> configs, usually specified in /etc/modprobe.d/* file. > >>> > >> I had already tried that... it locks up at the same point also with > >> "enable_msi=1". > >> tindog:/etc/modprobe.d # less 50-sound.conf > >> > >> options snd slots=snd-hda-intel,enable_msi=0 > > > > This is the option for module snd, not snd-hda-intel. > > > > > > Takashi > > > options snd,enable_msi=0 slots=snd-hda-intel options snd enable_msi=0 slots=snd-hda-intel (ie. the comma shouldn't be present in there). > # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio > alias snd-card-0 snd-hda-intel Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 20:25 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 20:25 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: sboyce, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 19:22:35 +0100, Rafael J. Wysocki wrote: > > On Tuesday 26 January 2010, Sid Boyce wrote: > > On 26/01/10 12:55, Takashi Iwai wrote: > > > At Tue, 26 Jan 2010 12:02:44 +0000, > > > Sid Boyce wrote: > > >> > > >> On 26/01/10 06:58, Takashi Iwai wrote: > > >>> At Tue, 26 Jan 2010 07:40:03 +0100, > > >>> I wrote: > > >>>> > > >>>> At Tue, 26 Jan 2010 00:59:15 +0000, > > >>>> Sid Boyce wrote: > > >>>>> > > >>>>> On 25/01/10 21:55, Takashi Iwai wrote: > > >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, > > >>>>>> I wrote: > > >>>>>>> > > >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > > >>>>>>> Rafael J. Wysocki wrote: > > >>>>>>>> > > >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: > > >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > > >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > > >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > > >>>>>>>>> is not disabled in the BIOS. > > >>>>>>>> > > >>>>>>>> I guess we should let Takashi know. > > >>>>>>> > > >>>>>>> Thanks. > > >>>>>>> > > >>>>>>>>>> tindog:~ # uname -r > > >>>>>>>>>> 2.6.33-rc4-smp > > >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > > >>>>>>>>>> oss.card_id = 'HDA NVidia' > > >>>>>>>>>> oss.card_id = 'HDA NVidia' > > >>>>>>>>>> oss.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> info.product = 'HDA NVidia Sound Card' > > >>>>>>>>>> sound.card_id = 'HDA NVidia' > > >>>>>>>>>> info.linux.driver = 'HDA Intel' > > >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>>>>>>> HDA Intel: module = snd_hda_intel > > >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>>>>>>> HDA Intel: module = snd_hda_intel > > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>>>>>>> HDA Intel: module = snd_hda_intel > > >>>>>>>>>> E: DRIVER=HDA Intel > > >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > >>>>>>>>>> low) -> IRQ 22 > > >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > >>>>>>>>>> Driver: "HDA Intel" > > >>>>>>> > > >>>>>>> What I'd try first is to pass enable_msi=0 option. > > >>>>>> > > >>>>>> Just to be sure -- it's an option for snd-hda-intel module. > > >>>>>> > > >>>>>> > > >>>>>> Takashi > > >>>>>> > > >>>>> > > >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > > >>>>> line, > > >>> > > >>> Oh, I overlooked this text. Of course, this can't work :) > > >>> > > >>> "modprobe..." isn't for the kernel command line but for modprobe > > >>> configs, usually specified in /etc/modprobe.d/* file. > > >>> > > >> I had already tried that... it locks up at the same point also with > > >> "enable_msi=1". > > >> tindog:/etc/modprobe.d # less 50-sound.conf > > >> > > >> options snd slots=snd-hda-intel,enable_msi=0 > > > > > > This is the option for module snd, not snd-hda-intel. > > > > > > > > > Takashi > > > > > options snd,enable_msi=0 slots=snd-hda-intel > > options snd enable_msi=0 slots=snd-hda-intel > > (ie. the comma shouldn't be present in there). Heh, not quite right :) You need just a new line containing: options snd-hda-intel enable_msi=0 Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 20:25 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-26 20:25 UTC (permalink / raw) To: Rafael J. Wysocki Cc: sboyce-QgLWrMLu8clzjhtm8Ag3mw, Linux Kernel Mailing List, Kernel Testers List At Tue, 26 Jan 2010 19:22:35 +0100, Rafael J. Wysocki wrote: > > On Tuesday 26 January 2010, Sid Boyce wrote: > > On 26/01/10 12:55, Takashi Iwai wrote: > > > At Tue, 26 Jan 2010 12:02:44 +0000, > > > Sid Boyce wrote: > > >> > > >> On 26/01/10 06:58, Takashi Iwai wrote: > > >>> At Tue, 26 Jan 2010 07:40:03 +0100, > > >>> I wrote: > > >>>> > > >>>> At Tue, 26 Jan 2010 00:59:15 +0000, > > >>>> Sid Boyce wrote: > > >>>>> > > >>>>> On 25/01/10 21:55, Takashi Iwai wrote: > > >>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, > > >>>>>> I wrote: > > >>>>>>> > > >>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, > > >>>>>>> Rafael J. Wysocki wrote: > > >>>>>>>> > > >>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: > > >>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: > > >>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get > > >>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio > > >>>>>>>>> is not disabled in the BIOS. > > >>>>>>>> > > >>>>>>>> I guess we should let Takashi know. > > >>>>>>> > > >>>>>>> Thanks. > > >>>>>>> > > >>>>>>>>>> tindog:~ # uname -r > > >>>>>>>>>> 2.6.33-rc4-smp > > >>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- > > >>>>>>>>>> oss.card_id = 'HDA NVidia' > > >>>>>>>>>> oss.card_id = 'HDA NVidia' > > >>>>>>>>>> oss.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' > > >>>>>>>>>> alsa.card_id = 'HDA NVidia' > > >>>>>>>>>> info.product = 'HDA NVidia Sound Card' > > >>>>>>>>>> sound.card_id = 'HDA NVidia' > > >>>>>>>>>> info.linux.driver = 'HDA Intel' > > >>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel > > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>>>>>>> HDA Intel: module = snd_hda_intel > > >>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" > > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>>>>>>> HDA Intel: module = snd_hda_intel > > >>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 > > >>>>>>>>>> HDA Intel: module = snd_hda_intel > > >>>>>>>>>> E: DRIVER=HDA Intel > > >>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, > > >>>>>>>>>> low) -> IRQ 22 > > >>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 > > >>>>>>>>>> Driver: "HDA Intel" > > >>>>>>> > > >>>>>>> What I'd try first is to pass enable_msi=0 option. > > >>>>>> > > >>>>>> Just to be sure -- it's an option for snd-hda-intel module. > > >>>>>> > > >>>>>> > > >>>>>> Takashi > > >>>>>> > > >>>>> > > >>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command > > >>>>> line, > > >>> > > >>> Oh, I overlooked this text. Of course, this can't work :) > > >>> > > >>> "modprobe..." isn't for the kernel command line but for modprobe > > >>> configs, usually specified in /etc/modprobe.d/* file. > > >>> > > >> I had already tried that... it locks up at the same point also with > > >> "enable_msi=1". > > >> tindog:/etc/modprobe.d # less 50-sound.conf > > >> > > >> options snd slots=snd-hda-intel,enable_msi=0 > > > > > > This is the option for module snd, not snd-hda-intel. > > > > > > > > > Takashi > > > > > options snd,enable_msi=0 slots=snd-hda-intel > > options snd enable_msi=0 slots=snd-hda-intel > > (ie. the comma shouldn't be present in there). Heh, not quite right :) You need just a new line containing: options snd-hda-intel enable_msi=0 Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 20:56 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 20:56 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 26/01/10 20:25, Takashi Iwai wrote: > At Tue, 26 Jan 2010 19:22:35 +0100, > Rafael J. Wysocki wrote: >> >> On Tuesday 26 January 2010, Sid Boyce wrote: >>> On 26/01/10 12:55, Takashi Iwai wrote: >>>> At Tue, 26 Jan 2010 12:02:44 +0000, >>>> Sid Boyce wrote: >>>>> >>>>> On 26/01/10 06:58, Takashi Iwai wrote: >>>>>> At Tue, 26 Jan 2010 07:40:03 +0100, >>>>>> I wrote: >>>>>>> >>>>>>> At Tue, 26 Jan 2010 00:59:15 +0000, >>>>>>> Sid Boyce wrote: >>>>>>>> >>>>>>>> On 25/01/10 21:55, Takashi Iwai wrote: >>>>>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>>>>>>> I wrote: >>>>>>>>>> >>>>>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>>>>>>> Rafael J. Wysocki wrote: >>>>>>>>>>> >>>>>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>>>>>>> is not disabled in the BIOS. >>>>>>>>>>> >>>>>>>>>>> I guess we should let Takashi know. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>>>>> tindog:~ # uname -r >>>>>>>>>>>>> 2.6.33-rc4-smp >>>>>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>>> E: DRIVER=HDA Intel >>>>>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>>>>>>> low) -> IRQ 22 >>>>>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>>>>>>> Driver: "HDA Intel" >>>>>>>>>> >>>>>>>>>> What I'd try first is to pass enable_msi=0 option. >>>>>>>>> >>>>>>>>> Just to be sure -- it's an option for snd-hda-intel module. >>>>>>>>> >>>>>>>>> >>>>>>>>> Takashi >>>>>>>>> >>>>>>>> >>>>>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>>>>>>> line, >>>>>> >>>>>> Oh, I overlooked this text. Of course, this can't work :) >>>>>> >>>>>> "modprobe..." isn't for the kernel command line but for modprobe >>>>>> configs, usually specified in /etc/modprobe.d/* file. >>>>>> >>>>> I had already tried that... it locks up at the same point also with >>>>> "enable_msi=1". >>>>> tindog:/etc/modprobe.d # less 50-sound.conf >>>>> >>>>> options snd slots=snd-hda-intel,enable_msi=0 >>>> >>>> This is the option for module snd, not snd-hda-intel. >>>> >>>> >>>> Takashi >>>> >>> options snd,enable_msi=0 slots=snd-hda-intel >> >> options snd enable_msi=0 slots=snd-hda-intel >> >> (ie. the comma shouldn't be present in there). > > Heh, not quite right :) > You need just a new line containing: > > options snd-hda-intel enable_msi=0 > > > Takashi > Apologies, with the following it boots successfully. options slots=snd-hda-intel # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio alias snd-card-0 snd-hda-intel options snd-hda-intel enable_msi=0 Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 20:56 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 20:56 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 26/01/10 20:25, Takashi Iwai wrote: > At Tue, 26 Jan 2010 19:22:35 +0100, > Rafael J. Wysocki wrote: >> >> On Tuesday 26 January 2010, Sid Boyce wrote: >>> On 26/01/10 12:55, Takashi Iwai wrote: >>>> At Tue, 26 Jan 2010 12:02:44 +0000, >>>> Sid Boyce wrote: >>>>> >>>>> On 26/01/10 06:58, Takashi Iwai wrote: >>>>>> At Tue, 26 Jan 2010 07:40:03 +0100, >>>>>> I wrote: >>>>>>> >>>>>>> At Tue, 26 Jan 2010 00:59:15 +0000, >>>>>>> Sid Boyce wrote: >>>>>>>> >>>>>>>> On 25/01/10 21:55, Takashi Iwai wrote: >>>>>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>>>>>>> I wrote: >>>>>>>>>> >>>>>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>>>>>>> Rafael J. Wysocki wrote: >>>>>>>>>>> >>>>>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>>>>>>> is not disabled in the BIOS. >>>>>>>>>>> >>>>>>>>>>> I guess we should let Takashi know. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>>>>> tindog:~ # uname -r >>>>>>>>>>>>> 2.6.33-rc4-smp >>>>>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>>> E: DRIVER=HDA Intel >>>>>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>>>>>>> low) -> IRQ 22 >>>>>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>>>>>>> Driver: "HDA Intel" >>>>>>>>>> >>>>>>>>>> What I'd try first is to pass enable_msi=0 option. >>>>>>>>> >>>>>>>>> Just to be sure -- it's an option for snd-hda-intel module. >>>>>>>>> >>>>>>>>> >>>>>>>>> Takashi >>>>>>>>> >>>>>>>> >>>>>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>>>>>>> line, >>>>>> >>>>>> Oh, I overlooked this text. Of course, this can't work :) >>>>>> >>>>>> "modprobe..." isn't for the kernel command line but for modprobe >>>>>> configs, usually specified in /etc/modprobe.d/* file. >>>>>> >>>>> I had already tried that... it locks up at the same point also with >>>>> "enable_msi=1". >>>>> tindog:/etc/modprobe.d # less 50-sound.conf >>>>> >>>>> options snd slots=snd-hda-intel,enable_msi=0 >>>> >>>> This is the option for module snd, not snd-hda-intel. >>>> >>>> >>>> Takashi >>>> >>> options snd,enable_msi=0 slots=snd-hda-intel >> >> options snd enable_msi=0 slots=snd-hda-intel >> >> (ie. the comma shouldn't be present in there). > > Heh, not quite right :) > You need just a new line containing: > > options snd-hda-intel enable_msi=0 > > > Takashi > Apologies, with the following it boots successfully. options slots=snd-hda-intel # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio alias snd-card-0 snd-hda-intel options snd-hda-intel enable_msi=0 Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 20:58 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 20:58 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List I forgot to mention 2.6.33-rc5 now boots successfully. Regards Sid. On 26/01/10 18:22, Rafael J. Wysocki wrote: > On Tuesday 26 January 2010, Sid Boyce wrote: >> On 26/01/10 12:55, Takashi Iwai wrote: >>> At Tue, 26 Jan 2010 12:02:44 +0000, >>> Sid Boyce wrote: >>>> >>>> On 26/01/10 06:58, Takashi Iwai wrote: >>>>> At Tue, 26 Jan 2010 07:40:03 +0100, >>>>> I wrote: >>>>>> >>>>>> At Tue, 26 Jan 2010 00:59:15 +0000, >>>>>> Sid Boyce wrote: >>>>>>> >>>>>>> On 25/01/10 21:55, Takashi Iwai wrote: >>>>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>>>>>> I wrote: >>>>>>>>> >>>>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>>>>>> Rafael J. Wysocki wrote: >>>>>>>>>> >>>>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>>>>>> is not disabled in the BIOS. >>>>>>>>>> >>>>>>>>>> I guess we should let Takashi know. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>>>>> tindog:~ # uname -r >>>>>>>>>>>> 2.6.33-rc4-smp >>>>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>> E: DRIVER=HDA Intel >>>>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>>>>>> low) -> IRQ 22 >>>>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>>>>>> Driver: "HDA Intel" >>>>>>>>> >>>>>>>>> What I'd try first is to pass enable_msi=0 option. >>>>>>>> >>>>>>>> Just to be sure -- it's an option for snd-hda-intel module. >>>>>>>> >>>>>>>> >>>>>>>> Takashi >>>>>>>> >>>>>>> >>>>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>>>>>> line, >>>>> >>>>> Oh, I overlooked this text. Of course, this can't work :) >>>>> >>>>> "modprobe..." isn't for the kernel command line but for modprobe >>>>> configs, usually specified in /etc/modprobe.d/* file. >>>>> >>>> I had already tried that... it locks up at the same point also with >>>> "enable_msi=1". >>>> tindog:/etc/modprobe.d # less 50-sound.conf >>>> >>>> options snd slots=snd-hda-intel,enable_msi=0 >>> >>> This is the option for module snd, not snd-hda-intel. >>> >>> >>> Takashi >>> >> options snd,enable_msi=0 slots=snd-hda-intel > > options snd enable_msi=0 slots=snd-hda-intel > > (ie. the comma shouldn't be present in there). > >> # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio >> alias snd-card-0 snd-hda-intel > > Rafael > -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-26 20:58 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-26 20:58 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List I forgot to mention 2.6.33-rc5 now boots successfully. Regards Sid. On 26/01/10 18:22, Rafael J. Wysocki wrote: > On Tuesday 26 January 2010, Sid Boyce wrote: >> On 26/01/10 12:55, Takashi Iwai wrote: >>> At Tue, 26 Jan 2010 12:02:44 +0000, >>> Sid Boyce wrote: >>>> >>>> On 26/01/10 06:58, Takashi Iwai wrote: >>>>> At Tue, 26 Jan 2010 07:40:03 +0100, >>>>> I wrote: >>>>>> >>>>>> At Tue, 26 Jan 2010 00:59:15 +0000, >>>>>> Sid Boyce wrote: >>>>>>> >>>>>>> On 25/01/10 21:55, Takashi Iwai wrote: >>>>>>>> At Mon, 25 Jan 2010 22:54:23 +0100, >>>>>>>> I wrote: >>>>>>>>> >>>>>>>>> At Mon, 25 Jan 2010 22:39:02 +0100, >>>>>>>>> Rafael J. Wysocki wrote: >>>>>>>>>> >>>>>>>>>> On Monday 25 January 2010, Sid Boyce wrote: >>>>>>>>>>> On 15/01/10 01:24, Sid Boyce wrote: >>>>>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get >>>>>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio >>>>>>>>>>> is not disabled in the BIOS. >>>>>>>>>> >>>>>>>>>> I guess we should let Takashi know. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>>>>> tindog:~ # uname -r >>>>>>>>>>>> 2.6.33-rc4-smp >>>>>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:- >>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>> oss.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> info.product = 'HDA NVidia ALSA Control Device' >>>>>>>>>>>> alsa.card_id = 'HDA NVidia' >>>>>>>>>>>> info.product = 'HDA NVidia Sound Card' >>>>>>>>>>>> sound.card_id = 'HDA NVidia' >>>>>>>>>>>> info.linux.driver = 'HDA Intel' >>>>>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel >>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel" >>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1 >>>>>>>>>>>> HDA Intel: module = snd_hda_intel >>>>>>>>>>>> E: DRIVER=HDA Intel >>>>>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level, >>>>>>>>>>>> low) -> IRQ 22 >>>>>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64 >>>>>>>>>>>> Driver: "HDA Intel" >>>>>>>>> >>>>>>>>> What I'd try first is to pass enable_msi=0 option. >>>>>>>> >>>>>>>> Just to be sure -- it's an option for snd-hda-intel module. >>>>>>>> >>>>>>>> >>>>>>>> Takashi >>>>>>>> >>>>>>> >>>>>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command >>>>>>> line, >>>>> >>>>> Oh, I overlooked this text. Of course, this can't work :) >>>>> >>>>> "modprobe..." isn't for the kernel command line but for modprobe >>>>> configs, usually specified in /etc/modprobe.d/* file. >>>>> >>>> I had already tried that... it locks up at the same point also with >>>> "enable_msi=1". >>>> tindog:/etc/modprobe.d # less 50-sound.conf >>>> >>>> options snd slots=snd-hda-intel,enable_msi=0 >>> >>> This is the option for module snd, not snd-hda-intel. >>> >>> >>> Takashi >>> >> options snd,enable_msi=0 slots=snd-hda-intel > > options snd enable_msi=0 slots=snd-hda-intel > > (ie. the comma shouldn't be present in there). > >> # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio >> alias snd-card-0 snd-hda-intel > > Rafael > -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-26 20:58 ` Sid Boyce (?) @ 2010-01-27 0:56 ` Rafael J. Wysocki 2010-01-27 2:40 ` Sid Boyce -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-27 0:56 UTC (permalink / raw) To: sboyce; +Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List On Tuesday 26 January 2010, Sid Boyce wrote: > I forgot to mention 2.6.33-rc5 now boots successfully. Does that mean the problem is fixed in 2.6.33-rc5 or you still need the enable_msi=0 workaround? Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-27 2:40 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-27 2:40 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List On 27/01/10 00:56, Rafael J. Wysocki wrote: > On Tuesday 26 January 2010, Sid Boyce wrote: >> I forgot to mention 2.6.33-rc5 now boots successfully. > > Does that mean the problem is fixed in 2.6.33-rc5 or you still need the > enable_msi=0 workaround? > > Rafael > It boots only with the enable_msi=0 workaround. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-27 2:40 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-27 2:40 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Takashi Iwai, Linux Kernel Mailing List, Kernel Testers List On 27/01/10 00:56, Rafael J. Wysocki wrote: > On Tuesday 26 January 2010, Sid Boyce wrote: >> I forgot to mention 2.6.33-rc5 now boots successfully. > > Does that mean the problem is fixed in 2.6.33-rc5 or you still need the > enable_msi=0 workaround? > > Rafael > It boots only with the enable_msi=0 workaround. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-27 2:40 ` Sid Boyce (?) @ 2010-01-27 6:42 ` Takashi Iwai 2010-01-27 17:17 ` Sid Boyce -1 siblings, 1 reply; 248+ messages in thread From: Takashi Iwai @ 2010-01-27 6:42 UTC (permalink / raw) To: sboyce, Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List At Wed, 27 Jan 2010 02:40:05 +0000, Sid Boyce wrote: > > On 27/01/10 00:56, Rafael J. Wysocki wrote: > > On Tuesday 26 January 2010, Sid Boyce wrote: > >> I forgot to mention 2.6.33-rc5 now boots successfully. > > > > Does that mean the problem is fixed in 2.6.33-rc5 or you still need the > > enable_msi=0 workaround? > > > > Rafael > > > It boots only with the enable_msi=0 workaround. OK, then could you run alsa-info.sh (with --no-upload option), and attach the generated file? I'll add your device to the blacklist for disabling MSI in hda_intel.c. thanks, Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-27 6:42 ` Takashi Iwai @ 2010-01-27 17:17 ` Sid Boyce 2010-01-27 19:29 ` Takashi Iwai 0 siblings, 1 reply; 248+ messages in thread From: Sid Boyce @ 2010-01-27 17:17 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 891 bytes --] On 27/01/10 06:42, Takashi Iwai wrote: > At Wed, 27 Jan 2010 02:40:05 +0000, > Sid Boyce wrote: >> >> On 27/01/10 00:56, Rafael J. Wysocki wrote: >>> On Tuesday 26 January 2010, Sid Boyce wrote: >>>> I forgot to mention 2.6.33-rc5 now boots successfully. >>> >>> Does that mean the problem is fixed in 2.6.33-rc5 or you still need the >>> enable_msi=0 workaround? >>> >>> Rafael >>> >> It boots only with the enable_msi=0 workaround. > > OK, then could you run alsa-info.sh (with --no-upload option), and > attach the generated file? I'll add your device to the blacklist for > disabling MSI in hda_intel.c. > > > thanks, > > Takashi > > Thanks. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks [-- Attachment #2: alsa-info.txt --] [-- Type: text/plain, Size: 194765 bytes --] upload=true&script=true&cardinfo= !!################################ !!ALSA Information Script v 0.4.58 !!################################ !!Script ran on: Wed Jan 27 17:10:57 UTC 2010 !!Linux Distribution !!------------------ Welcome to openSUSE 11.3 "Teal" Milestone 0 - Kernel \r (\l). openSUSE 11.3 Milestone 0 (x86_64) LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64" !!DMI Information !!--------------- Manufacturer: System manufacturer Product Name: System Product Name !!Kernel Information !!------------------ Kernel release: 2.6.33-rc5-git2-smp Operating System: GNU/Linux Architecture: x86_64 Processor: x86_64 SMP Enabled: Yes !!ALSA Version !!------------ Driver version: 1.0.21 Library version: 1.0.22 Utilities version: 1.0.22 !!Loaded ALSA modules !!------------------- snd_hda_intel snd_emu10k1 snd_usb_audio !!Sound Servers on this system !!---------------------------- Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes ESound Daemon: Installed - Yes (/usr/bin/esd) Running - No Jack: Installed - Yes (/usr/local/bin/jackd) Running - No !!Soundcards recognised by ALSA !!----------------------------- 0 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfe020000 irq 30 1 [EMU0404 ]: Audigy2 - E-mu 0404b PCI [MAEM8852] E-mu 0404b PCI [MAEM8852] (rev.0, serial:0x40021102) at 0xec00, irq 16 2 [USB ]: USB-Audio - E-MU 0404 | USB E-MU Systems, Inc. E-MU 0404 | USB at usb-0000:00:04.1-1.3, high speed !!PCI Soundcards installed in the system !!-------------------------------------- 00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1) 01:08.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value 01:09.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 01:09.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) !!Advanced information - PCI Vendor/Device/Susbsystem ID's !!-------------------------------------------------------- 00:07.0 0403: 10de:0774 (rev a1) Subsystem: 1043:829c -- 01:08.0 0401: 1102:0008 Subsystem: 1102:4002 !!Loaded sound module options !!-------------------------- !!Module: snd_hda_intel bdl_pos_adj : 32,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 power_save : 0 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N single_cmd : N !!Module: snd_emu10k1 enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_ir : N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N,N extin : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 extout : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 max_buffer_size : 128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128 max_synth_voices : 64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64 seq_ports : 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4 subsystem : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 !!Module: snd_usb_audio async_unlink : Y device_setup : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) ignore_ctl_error : N index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 nrpacks : 8 pid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 vid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 !!HDA-Intel Codec information !!--------------------------- --startcollapse-- Codec: Analog Devices AD1988B Address: 0 Function Id: 0x1 Vendor Id: 0x11d4198b Subsystem Id: 0x1043829c Revision Id: 0x100400 No Modem Function Group found Default PCM: rates [0x7ff]: 8000 11025 16000 22050 32000 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Default Amp-Out caps: ofs=0x27, nsteps=0x27, stepsize=0x05, mute=0 GPIO: io=2, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=1, unsol=0 Node 0x02 [Audio Output] wcaps 0x30311: Stereo Digital Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="IEC958 Default PCM Playback Switch", index=0, device=0 Device: name="AD198x Digital", type="SPDIF", device=1 Converter: stream=5, channel=0 Digital: Enabled Digital category: 0x0 PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Delay: 3 samples Connection: 1 0x1d Node 0x03 [Audio Output] wcaps 0x405: Stereo Amp-Out Amp-Out caps: ofs=0x27, nsteps=0x27, stepsize=0x05, mute=0 Amp-Out vals: [0x27 0x27] Converter: stream=0, channel=0 Power states: D0 D3 Power: setting=D0, actual=D0 Node 0x04 [Audio Output] wcaps 0x405: Stereo Amp-Out Control: name="Front Playback Volume", index=0, device=0 Device: name="AD198x Analog", type="Audio", device=0 Amp-Out caps: ofs=0x27, nsteps=0x27, stepsize=0x05, mute=0 Amp-Out vals: [0x26 0x26] Converter: stream=5, channel=0 Power states: D0 D3 Power: setting=D0, actual=D0 Node 0x05 [Audio Output] wcaps 0x405: Stereo Amp-Out Control: name="Center Playback Volume", index=0, device=0 Control: name="LFE Playback Volume", index=0, device=0 Amp-Out caps: ofs=0x27, nsteps=0x27, stepsize=0x05, mute=0 Amp-Out vals: [0x26 0x26] Converter: stream=5, channel=0 Power states: D0 D3 Power: setting=D0, actual=D0 Node 0x06 [Audio Output] wcaps 0x405: Stereo Amp-Out Control: name="Surround Playback Volume", index=0, device=0 Amp-Out caps: ofs=0x27, nsteps=0x27, stepsize=0x05, mute=0 Amp-Out vals: [0x26 0x26] Converter: stream=5, channel=0 Power states: D0 D3 Power: setting=D0, actual=D0 Node 0x07 [Audio Input] wcaps 0x130391: Stereo Digital Converter: stream=0, channel=0 SDI-Select: 0 Digital: Digital category: 0x0 PCM: rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Unsolicited: tag=00, enabled=0 Delay: 3 samples Connection: 1 0x1c Node 0x08 [Audio Input] wcaps 0x100501: Stereo Device: name="AD198x Analog", type="Audio", device=0 Converter: stream=1, channel=0 SDI-Select: 0 Power states: D0 D3 Power: setting=D0, actual=D0 Connection: 1 0x0c Node 0x09 [Audio Input] wcaps 0x100501: Stereo Converter: stream=0, channel=0 SDI-Select: 0 Power states: D0 D3 Power: setting=D0, actual=D0 Connection: 1 0x0d Node 0x0a [Audio Output] wcaps 0x405: Stereo Amp-Out Control: name="Side Playback Volume", index=0, device=0 Amp-Out caps: ofs=0x27, nsteps=0x27, stepsize=0x05, mute=0 Amp-Out vals: [0x26 0x26] Converter: stream=5, channel=0 Power states: D0 D3 Power: setting=D0, actual=D0 Node 0x0b [Audio Selector] wcaps 0x300301: Stereo Digital Connection: 3 0x08* 0x09 0x0f Node 0x0c [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Control: name="Capture Volume", index=0, device=0 Control: name="Capture Switch", index=0, device=0 Amp-Out caps: ofs=0x27, nsteps=0x36, stepsize=0x05, mute=1 Amp-Out vals: [0x36 0x36] Connection: 10 0x38 0x39* 0x3a 0x3b 0x3c 0x18 0x24 0x25 0x3d 0x20 Node 0x0d [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Control: name="Capture Volume", index=1, device=0 Control: name="Capture Switch", index=1, device=0 Amp-Out caps: ofs=0x27, nsteps=0x36, stepsize=0x05, mute=1 Amp-Out vals: [0xa7 0xa7] Connection: 10 0x38 0x39* 0x3a 0x3b 0x3c 0x18 0x24 0x25 0x3d 0x20 Node 0x0e [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Control: name="Capture Volume", index=2, device=0 Control: name="Capture Switch", index=2, device=0 Amp-Out caps: ofs=0x27, nsteps=0x36, stepsize=0x05, mute=1 Amp-Out vals: [0xa7 0xa7] Connection: 10 0x38 0x39* 0x3a 0x3b 0x3c 0x18 0x24 0x25 0x3d 0x20 Node 0x0f [Audio Input] wcaps 0x100501: Stereo Converter: stream=0, channel=0 SDI-Select: 0 Power states: D0 D3 Power: setting=D0, actual=D0 Connection: 1 0x0e Node 0x10 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out Control: name="Beep Playback Volume", index=0, device=0 Control: name="Beep Playback Switch", index=0, device=0 Amp-Out caps: ofs=0x0f, nsteps=0x0f, stepsize=0x0b, mute=1 Amp-Out vals: [0x00] Node 0x11 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000373f: IN OUT HP Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 100 Pin Default 0x02214030: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 1 0x22 Node 0x12 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000373f: IN OUT HP Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 100 Pin Default 0x01014010: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 1 0x29 Node 0x13 [Pin Complex] wcaps 0x40010c: Mono Amp-Out Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x00] Pincap 0x00000010: OUT Pin Default 0x511711f0: [N/A] Speaker at Int Rear Conn = Analog, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x2d Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000373f: IN OUT HP Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 100 Pin Default 0x02a1902e: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink DefAssociation = 0x2, Sequence = 0xe Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 1 0x2b Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00003737: IN OUT Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 100 Pin Default 0x01813021: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue DefAssociation = 0x2, Sequence = 0x1 Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 1 0x2c Node 0x16 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00003737: IN OUT Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 100 Pin Default 0x01011012: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0x2 Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 1 0x2a Node 0x17 [Pin Complex] wcaps 0x40098d: Stereo Amp-Out R/L Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00003737: IN OUT Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 100 Pin Default 0x01a19020: [Jack] Mic at Ext Rear Conn = 1/8, Color = Pink DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 1 0x26 Node 0x18 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x00000020: IN Pin Default 0x99331122: [Fixed] CD at Int ATAPI Conn = ATAPI, Color = Black DefAssociation = 0x2, Sequence = 0x2 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x19 [Power Widget] wcaps 0x500500: Mono Power states: D0 D3 Power: setting=D0, actual=D0 Connection: 2 0x20 0x21 Node 0x1a [Pin Complex] wcaps 0x400000: Mono Pincap 0x00000020: IN Pin Default 0x91f711f0: [Fixed] Other at Int Rear Conn = Analog, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x1b [Pin Complex] wcaps 0x40030d: Stereo Digital Amp-Out Control: name="IEC958 Playback Volume", index=0, device=0 Amp-Out caps: ofs=0x27, nsteps=0x27, stepsize=0x05, mute=1 Amp-Out vals: [0x26 0x26] Pincap 0x00000010: OUT Pin Default 0x0145f1f0: [Jack] SPDIF Out at Ext Rear Conn = Optical, Color = Other DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x1c [Pin Complex] wcaps 0x40020b: Stereo Digital Amp-In Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x97 0x97] Pincap 0x00000020: IN Pin Default 0x41c5f1f0: [N/A] SPDIF In at Ext Rear Conn = Optical, Color = Other DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x1d [Audio Mixer] wcaps 0x200303: Stereo Digital Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] Connection: 2 0x01 0x0b Node 0x1e [Audio Mixer] wcaps 0x200103: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] Connection: 2 0x36 0x21 Node 0x1f [Volume Knob Widget] wcaps 0x600080: Mono Volume-Knob: delta=1, steps=63, direct=0, val=0 Unsolicited: tag=00, enabled=0 Connection: 0 Node 0x20 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Mic Playback Volume", index=0, device=0 Control: name="Mic Playback Switch", index=0, device=0 Control: name="Front Mic Playback Volume", index=0, device=0 Control: name="Front Mic Playback Switch", index=0, device=0 Control: name="Line Playback Volume", index=0, device=0 Control: name="Line Playback Switch", index=0, device=0 Control: name="Front Line Playback Volume", index=0, device=0 Control: name="Front Line Playback Switch", index=0, device=0 Control: name="CD Playback Volume", index=0, device=0 Control: name="CD Playback Switch", index=0, device=0 Control: name="Aux Playback Volume", index=0, device=0 Control: name="Aux Playback Switch", index=0, device=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x1f 0x1f] [0x0b 0x0b] [0x1f 0x1f] [0x80 0x80] [0x0c 0x0c] [0x80 0x80] [0x1f 0x1f] [0x80 0x80] Connection: 8 0x39 0x33 0x38 0x3d 0x34 0x3b 0x18 0x1a Node 0x21 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Control: name="Analog Mix Playback Volume", index=0, device=0 Control: name="Analog Mix Playback Switch", index=0, device=0 Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x1f 0x1f] Connection: 1 0x20 Node 0x22 [Audio Mixer] wcaps 0x200103: Stereo Amp-In Control: name="Headphone Playback Switch", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x37 0x21 Node 0x23 [Vendor Defined Widget] wcaps 0xf00100: Mono Connection: 18 0x11* 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x24 0x25 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x20 0x21 Node 0x24 [Pin Complex] wcaps 0x40098d: Stereo Amp-Out R/L Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00000037: IN OUT Detect Trigger ImpSense Pin Default 0x01016011: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Orange DefAssociation = 0x1, Sequence = 0x1 Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x27 Node 0x25 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00000037: IN OUT Detect Trigger ImpSense Pin Default 0x01012014: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Grey DefAssociation = 0x1, Sequence = 0x4 Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x28 Node 0x26 [Audio Mixer] wcaps 0x200103: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] Connection: 2 0x32 0x21 Node 0x27 [Audio Mixer] wcaps 0x200103: Stereo Amp-In Control: name="Center Playback Switch", index=0, device=0 Control: name="LFE Playback Switch", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x05 0x21 Node 0x28 [Audio Mixer] wcaps 0x200103: Stereo Amp-In Control: name="Side Playback Switch", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x0a 0x21 Node 0x29 [Audio Mixer] wcaps 0x200103: Stereo Amp-In Control: name="Front Playback Switch", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x04 0x21 Node 0x2a [Audio Mixer] wcaps 0x200103: Stereo Amp-In Control: name="Surround Playback Switch", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x06 0x21 Node 0x2b [Audio Mixer] wcaps 0x200103: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] Connection: 2 0x30 0x21 Node 0x2c [Audio Mixer] wcaps 0x200103: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] Connection: 2 0x31 0x21 Node 0x2d [Audio Mixer] wcaps 0x200100: Mono Connection: 1 0x1e Node 0x2e [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x2f [Vendor Defined Widget] wcaps 0xf00100: Mono Connection: 6 0x11* 0x12 0x14 0x15 0x16 0x17 Node 0x30 [Audio Selector] wcaps 0x300101: Stereo Connection: 3 0x03* 0x04 0x06 Node 0x31 [Audio Selector] wcaps 0x300101: Stereo Connection: 2 0x04* 0x0a Node 0x32 [Audio Selector] wcaps 0x300101: Stereo Connection: 2 0x05* 0x04 Node 0x33 [Audio Selector] wcaps 0x300101: Stereo Connection: 3 0x3a* 0x25 0x24 Node 0x34 [Audio Selector] wcaps 0x300101: Stereo Connection: 3 0x3c* 0x25 0x24 Node 0x35 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x36 [Audio Selector] wcaps 0x300101: Stereo Connection: 3 0x03 0x04* 0x06 Node 0x37 [Audio Selector] wcaps 0x300101: Stereo Connection: 3 0x03 0x04* 0x06 Node 0x38 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 1 0x11 Node 0x39 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Control: name="Front Mic Boost", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-Out vals: [0x01 0x01] Connection: 1 0x14 Node 0x3a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 1 0x15 Node 0x3b [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 1 0x16 Node 0x3c [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Control: name="Mic Boost", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-Out vals: [0x01 0x01] Connection: 1 0x17 Node 0x3d [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00] Connection: 1 0x12 Codec: Nvidia MCP78 HDMI Address: 3 Function Id: 0x1 Vendor Id: 0x10de0002 Subsystem Id: 0x10de0101 Revision Id: 0x100000 No Modem Function Group found Default PCM: rates [0x0]: bits [0x0]: formats [0x0]: Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x04 [Audio Output] wcaps 0x211: Stereo Digital Control: name="IEC958 Playback Con Mask", index=1, device=0 Control: name="IEC958 Playback Pro Mask", index=1, device=0 Control: name="IEC958 Playback Default", index=1, device=0 Control: name="IEC958 Playback Switch", index=1, device=0 Device: name="NVIDIA HDMI", type="HDMI", device=3 Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0xc0]: 48000 88200 bits [0xf]: 8 16 20 24 formats [0x1]: PCM Node 0x05 [Pin Complex] wcaps 0x400381: Stereo Digital Pincap 0x00000014: OUT Detect Pin Default 0x18560110: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x04 Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0xc0]: 48000 88200 bits [0xf]: 8 16 20 24 formats [0x1]: PCM Node 0x07 [Pin Complex] wcaps 0x400381: Stereo Digital Pincap 0x00000014: OUT Detect Pin Default 0x58560121: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x2, Sequence = 0x1 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x06 Node 0x08 [Audio Output] wcaps 0x211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0xc0]: 48000 88200 bits [0xf]: 8 16 20 24 formats [0x1]: PCM Node 0x09 [Pin Complex] wcaps 0x400381: Stereo Digital Pincap 0x00000014: OUT Detect Pin Default 0x58560122: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x2, Sequence = 0x2 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x08 Node 0x0a [Audio Output] wcaps 0x211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0xc0]: 48000 88200 bits [0xf]: 8 16 20 24 formats [0x1]: PCM Node 0x0b [Pin Complex] wcaps 0x400381: Stereo Digital Pincap 0x00000014: OUT Detect Pin Default 0x58560123: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x2, Sequence = 0x3 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x0a Node 0x0c [Audio Output] wcaps 0x211: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0xc0]: 48000 88200 bits [0xf]: 8 16 20 24 formats [0x1]: PCM Node 0x0d [Pin Complex] wcaps 0x400381: Stereo Digital Pincap 0x00000014: OUT Detect Pin Default 0x58560124: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x2, Sequence = 0x4 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 1 0x0c --endcollapse-- !!ALSA Device nodes !!----------------- crw-rw----+ 1 root audio 116, 24 Jan 27 10:34 /dev/snd/controlC0 crw-rw----+ 1 root audio 116, 17 Jan 27 10:34 /dev/snd/controlC1 crw-rw----+ 1 root audio 116, 7 Jan 27 10:34 /dev/snd/controlC2 crw-rw----+ 1 root audio 116, 23 Jan 27 10:34 /dev/snd/hwC0D0 crw-rw----+ 1 root audio 116, 22 Jan 27 10:34 /dev/snd/hwC0D3 crw-rw----+ 1 root audio 116, 8 Jan 27 10:34 /dev/snd/hwC1D0 crw-rw----+ 1 root audio 116, 26 Jan 27 10:35 /dev/snd/hwC1D2 crw-rw----+ 1 root audio 116, 10 Jan 27 10:34 /dev/snd/midiC1D0 crw-rw----+ 1 root audio 116, 9 Jan 27 10:34 /dev/snd/midiC1D1 crw-rw----+ 1 root audio 116, 27 Jan 27 10:35 /dev/snd/midiC1D2 crw-rw----+ 1 root audio 116, 28 Jan 27 10:35 /dev/snd/midiC1D3 crw-rw----+ 1 root audio 116, 3 Jan 27 10:34 /dev/snd/midiC2D0 crw-rw----+ 1 root audio 116, 21 Jan 27 11:06 /dev/snd/pcmC0D0c crw-rw----+ 1 root audio 116, 20 Jan 27 11:06 /dev/snd/pcmC0D0p crw-rw----+ 1 root audio 116, 19 Jan 27 10:36 /dev/snd/pcmC0D1p crw-rw----+ 1 root audio 116, 18 Jan 27 10:36 /dev/snd/pcmC0D3p crw-rw----+ 1 root audio 116, 16 Jan 27 10:36 /dev/snd/pcmC1D0c crw-rw----+ 1 root audio 116, 15 Jan 27 10:36 /dev/snd/pcmC1D0p crw-rw----+ 1 root audio 116, 14 Jan 27 10:34 /dev/snd/pcmC1D1c crw-rw----+ 1 root audio 116, 13 Jan 27 10:34 /dev/snd/pcmC1D2c crw-rw----+ 1 root audio 116, 12 Jan 27 10:34 /dev/snd/pcmC1D2p crw-rw----+ 1 root audio 116, 11 Jan 27 10:34 /dev/snd/pcmC1D3p crw-rw----+ 1 root audio 116, 6 Jan 27 11:06 /dev/snd/pcmC2D0c crw-rw----+ 1 root audio 116, 5 Jan 27 11:06 /dev/snd/pcmC2D0p crw-rw----+ 1 root audio 116, 4 Jan 27 10:34 /dev/snd/pcmC2D1p crw-rw----+ 1 root audio 116, 25 Jan 27 10:35 /dev/snd/seq crw-rw----+ 1 root audio 116, 2 Jan 27 10:34 /dev/snd/timer /dev/snd/by-id: total 0 drwxr-xr-x 2 root root 60 Jan 27 10:34 . drwxr-xr-x 4 root root 620 Jan 27 10:35 .. lrwxrwxrwx 1 root root 12 Jan 27 10:34 usb-E-MU_Systems__Inc._E-MU_0404___USB_E-MU-63-3F04-07D70A11-07BA0-STATION_2-00 -> ../controlC2 /dev/snd/by-path: total 0 drwxr-xr-x 2 root root 100 Jan 27 10:34 . drwxr-xr-x 4 root root 620 Jan 27 10:35 .. lrwxrwxrwx 1 root root 12 Jan 27 10:34 pci-0000:00:04.1-usb-0:1.3:1.0 -> ../controlC2 lrwxrwxrwx 1 root root 12 Jan 27 10:34 pci-0000:00:07.0 -> ../controlC0 lrwxrwxrwx 1 root root 12 Jan 27 10:34 pci-0000:01:08.0 -> ../controlC1 !!ALSA configuration files !!------------------------ !!User specific config file (~/.asoundrc) defaults.pcm.rate_converter "samplerate" !!System wide config file (/etc/asound.conf) defaults.pcm.rate_converter "samplerate" !!Aplay/Arecord output !!------------ APLAY **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 1: AD198x Digital [AD198x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 0: emu10k1 [ADC Capture/Standard PCM Playback] Subdevices: 32/32 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 Subdevice #8: subdevice #8 Subdevice #9: subdevice #9 Subdevice #10: subdevice #10 Subdevice #11: subdevice #11 Subdevice #12: subdevice #12 Subdevice #13: subdevice #13 Subdevice #14: subdevice #14 Subdevice #15: subdevice #15 Subdevice #16: subdevice #16 Subdevice #17: subdevice #17 Subdevice #18: subdevice #18 Subdevice #19: subdevice #19 Subdevice #20: subdevice #20 Subdevice #21: subdevice #21 Subdevice #22: subdevice #22 Subdevice #23: subdevice #23 Subdevice #24: subdevice #24 Subdevice #25: subdevice #25 Subdevice #26: subdevice #26 Subdevice #27: subdevice #27 Subdevice #28: subdevice #28 Subdevice #29: subdevice #29 Subdevice #30: subdevice #30 Subdevice #31: subdevice #31 card 1: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 2: emu10k1 efx [Multichannel Capture/PT Playback] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 1: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 3: emu10k1 [Multichannel Playback] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: USB [E-MU 0404 | USB], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 card 2: USB [E-MU 0404 | USB], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 ARECORD **** List of CAPTURE Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog] Subdevices: 2/3 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 card 1: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 0: emu10k1 [ADC Capture/Standard PCM Playback] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 1: emu10k1 mic [Mic Capture] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: EMU0404 [E-mu 0404b PCI [MAEM8852]], device 2: emu10k1 efx [Multichannel Capture/PT Playback] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: USB [E-MU 0404 | USB], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 !!Amixer output !!------------- !!-------Mixer controls for card 0 [NVidia] Card hw:0 'NVidia'/'HDA NVidia at 0xfe020000 irq 30' Mixer name : 'Nvidia MCP78 HDMI' Components : 'HDA:11d4198b,1043829c,00100400 HDA:10de0002,10de0101,00100000' Controls : 52 Simple ctrls : 28 Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 39 Mono: Playback 38 [97%] [-1.50dB] [on] Simple mixer control 'Headphone',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [on] Front Right: Playback [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 250 [98%] [-1.00dB] Front Right: Playback 250 [98%] [-1.00dB] Simple mixer control 'Front',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 39 Mono: Front Left: Playback 39 [100%] [0.00dB] [on] Front Right: Playback 39 [100%] [0.00dB] [on] Simple mixer control 'Front Line',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [12.00dB] [on] Front Right: Playback 31 [100%] [12.00dB] [on] Simple mixer control 'Front Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [12.00dB] [on] Front Right: Playback 31 [100%] [12.00dB] [on] Simple mixer control 'Front Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 1 [33%] Front Right: 1 [33%] Simple mixer control 'Surround',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 39 Mono: Front Left: Playback 39 [100%] [0.00dB] [on] Front Right: Playback 39 [100%] [0.00dB] [on] Simple mixer control 'Center',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 39 Mono: Playback 39 [100%] [0.00dB] [on] Simple mixer control 'LFE',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 39 Mono: Playback 39 [100%] [0.00dB] [on] Simple mixer control 'Side',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 39 Mono: Front Left: Playback 39 [100%] [0.00dB] [on] Front Right: Playback 39 [100%] [0.00dB] [on] Simple mixer control 'Line',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 11 [35%] [-18.00dB] [on] Front Right: Playback 11 [35%] [-18.00dB] [on] Simple mixer control 'CD',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [12.00dB] [on] Front Right: Playback 31 [100%] [12.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 12 [39%] [-16.50dB] [on] Front Right: Playback 12 [39%] [-16.50dB] [on] Simple mixer control 'Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 1 [33%] Front Right: 1 [33%] Simple mixer control 'IEC958',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 39 Mono: Front Left: Playback 39 [100%] [0.00dB] [on] Front Right: Playback 39 [100%] [0.00dB] [on] Simple mixer control 'IEC958 Default PCM',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958 Playback Source',0 Capabilities: enum Items: 'PCM' 'ADC1' 'ADC2' 'ADC3' Item0: 'PCM' Simple mixer control 'IEC958',1 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control 'Beep',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 15 Mono: Playback 15 [100%] [0.00dB] [on] Simple mixer control 'Aux',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [12.00dB] [on] Front Right: Playback 31 [100%] [12.00dB] [on] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 54 [100%] [22.50dB] [on] Front Right: Capture 54 [100%] [22.50dB] [on] Simple mixer control 'Capture',1 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off] Simple mixer control 'Capture',2 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 39 [72%] [0.00dB] [off] Front Right: Capture 39 [72%] [0.00dB] [off] Simple mixer control 'Analog Mix',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 31 [100%] [0.00dB] [on] Front Right: Playback 31 [100%] [0.00dB] [on] Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'Front Line' 'CD' 'Aux' 'Mix' Item0: 'Front Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'Front Line' 'CD' 'Aux' 'Mix' Item0: 'Mic' Simple mixer control 'Input Source',2 Capabilities: cenum Items: 'Mic' 'Front Mic' 'Line' 'Front Line' 'CD' 'Aux' 'Mix' Item0: 'Mic' !!-------Mixer controls for card 1 [EMU0404] Card hw:1 'EMU0404'/'E-mu 0404b PCI [MAEM8852] (rev.0, serial:0x40021102) at 0xec00, irq 16' Mixer name : 'SB Audigy' Components : '' Controls : 239 Simple ctrls : 80 Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined penum Playback channels: Mono Limits: Playback 0 - 100 Mono: Playback 99 [99%] [0.40dB] Simple mixer control 'Tone',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [off] Front Right: Playback [off] Simple mixer control 'Bass',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 40 Front Left: 20 [50%] Front Right: 20 [50%] Simple mixer control 'Treble',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 40 Front Left: 20 [50%] Front Right: 20 [50%] Simple mixer control 'PCM',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 100 [100%] [0.00dB] Capture 100 [100%] [0.00dB] Front Right: Playback 100 [100%] [0.00dB] Capture 100 [100%] [0.00dB] Simple mixer control 'PCM Center',0 Capabilities: pvolume pvolume-joined penum Playback channels: Mono Limits: Playback 0 - 100 Mono: Playback 100 [100%] [0.00dB] Simple mixer control 'PCM Front',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 100 Mono: Front Left: Playback 100 [100%] [0.00dB] Front Right: Playback 100 [100%] [0.00dB] Simple mixer control 'PCM LFE',0 Capabilities: pvolume pvolume-joined penum Playback channels: Mono Limits: Playback 0 - 100 Mono: Playback 100 [100%] [0.00dB] Simple mixer control 'PCM Side',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 100 Mono: Front Left: Playback 100 [100%] [0.00dB] Front Right: Playback 100 [100%] [0.00dB] Simple mixer control 'PCM Surround',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 100 Mono: Front Left: Playback 100 [100%] [0.00dB] Front Right: Playback 100 [100%] [0.00dB] Simple mixer control 'Front',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 100 Mono: Front Left: Playback 100 [100%] [0.00dB] Front Right: Playback 100 [100%] [0.00dB] Simple mixer control 'Surround',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 100 Mono: Front Left: Playback 100 [100%] [0.00dB] Front Right: Playback 100 [100%] [0.00dB] Simple mixer control 'Center',0 Capabilities: pvolume pvolume-joined penum Playback channels: Mono Limits: Playback 0 - 100 Mono: Playback 100 [100%] [0.00dB] Simple mixer control 'LFE',0 Capabilities: pvolume pvolume-joined penum Playback channels: Mono Limits: Playback 0 - 100 Mono: Playback 100 [100%] [0.00dB] Simple mixer control 'Side',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 100 Mono: Front Left: Playback 100 [100%] [0.00dB] Front Right: Playback 100 [100%] [0.00dB] Simple mixer control 'Synth',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 80 [80%] [-8.00dB] Capture 100 [100%] [0.00dB] Front Right: Playback 80 [80%] [-8.00dB] Capture 100 [100%] [0.00dB] Simple mixer control 'DSP 0',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: '0202 ADC Left' Simple mixer control 'DSP 1',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: '0202 ADC Right' Simple mixer control 'DSP 10',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 11',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 12',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 13',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 14',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 15',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 2',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 3',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 4',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 5',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 6',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 7',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 8',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP 9',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP A',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP B',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP C',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP D',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP E',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'DSP F',0 Capabilities: cenum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Silence' Simple mixer control 'Line',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 100 [100%] [0.00dB] Capture 100 [100%] [0.00dB] Front Right: Playback 97 [97%] [-1.20dB] Capture 100 [100%] [0.00dB] Simple mixer control 'CD',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 31 [31%] [-27.60dB] Capture 30 [30%] [-28.00dB] Front Right: Playback 31 [31%] [-27.60dB] Capture 30 [30%] [-28.00dB] Simple mixer control 'Mic',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 94 [94%] [-2.40dB] Capture 99 [99%] [0.40dB] Front Right: Playback 94 [94%] [-2.40dB] Capture 100 [100%] [0.00dB] Simple mixer control 'IEC958 Optical',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 0 [0%] [-99999.99dB] Capture 0 [0%] [-99999.99dB] Front Right: Playback 0 [0%] [-99999.99dB] Capture 0 [0%] [-99999.99dB] Simple mixer control 'IEC958 Optical Raw',0 Capabilities: pswitch penum Playback channels: Front Left - Front Right Mono: Front Left: Playback [off] Front Right: Playback [off] Simple mixer control 'Aux',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 0 [0%] [-99999.99dB] Capture 0 [0%] [-99999.99dB] Front Right: Playback 0 [0%] [-99999.99dB] Capture 0 [0%] [-99999.99dB] Simple mixer control '0202 DAC Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Dock ADC1 Left' Simple mixer control '0202 DAC Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'Dock ADC1 Right' Simple mixer control '1010 ADAT 0',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 0' Simple mixer control '1010 ADAT 1',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 1' Simple mixer control '1010 ADAT 2',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 2' Simple mixer control '1010 ADAT 3',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 3' Simple mixer control '1010 ADAT 4',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 4' Simple mixer control '1010 ADAT 5',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 5' Simple mixer control '1010 ADAT 6',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 6' Simple mixer control '1010 ADAT 7',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 7' Simple mixer control '1010 SPDIF Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 0' Simple mixer control '1010 SPDIF Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 1' Simple mixer control 'ADC1 14dB PAD 0202',0 Capabilities: cswitch cswitch-joined penum Capture channels: Mono Mono: Capture [off] Simple mixer control 'ADC1 14dB PAD Audio Dock',0 Capabilities: cswitch cswitch-joined penum Capture channels: Mono Mono: Capture [off] Simple mixer control 'ADC2 14dB PAD Audio Dock',0 Capabilities: cswitch cswitch-joined penum Capture channels: Mono Mono: Capture [off] Simple mixer control 'ADC3 14dB PAD Audio Dock',0 Capabilities: cswitch cswitch-joined penum Capture channels: Mono Mono: Capture [off] Simple mixer control 'Analog Mix',0 Capabilities: pvolume cvolume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 100 Capture 0 - 100 Front Left: Playback 99 [99%] [0.40dB] Capture 96 [96%] [-1.60dB] Front Right: Playback 99 [99%] [0.40dB] Capture 96 [96%] [-1.60dB] Simple mixer control 'Clock Internal Rate',0 Capabilities: enum Items: '44100' '48000' 'SPDIF' 'ADAT' Item0: '48000' Simple mixer control 'DAC1 0202 14dB PAD',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control 'DAC1 Audio Dock 14dB PAD',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'DAC2 Audio Dock 14dB PAD',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'DAC3 Audio Dock 14dB PAD',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'DAC4 Audio Dock 14dB PAD',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'Dock DAC1 Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 0' Simple mixer control 'Dock DAC1 Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 1' Simple mixer control 'Dock DAC2 Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 2' Simple mixer control 'Dock DAC2 Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 3' Simple mixer control 'Dock DAC3 Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 4' Simple mixer control 'Dock DAC3 Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 5' Simple mixer control 'Dock DAC4 Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 6' Simple mixer control 'Dock DAC4 Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 7' Simple mixer control 'Dock Phones Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 0' Simple mixer control 'Dock Phones Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 1' Simple mixer control 'Dock SPDIF Left',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 0' Simple mixer control 'Dock SPDIF Right',0 Capabilities: penum Items: 'Silence' 'Dock Mic A' 'Dock Mic B' 'Dock ADC1 Left' 'Dock ADC1 Right' 'Dock ADC2 Left' 'Dock ADC2 Right' 'Dock ADC3 Left' 'Dock ADC3 Right' '0202 ADC Left' '0202 ADC Right' '0202 SPDIF Left' '0202 SPDIF Right' 'ADAT 0' 'ADAT 1' 'ADAT 2' 'ADAT 3' 'ADAT 4' 'ADAT 5' 'ADAT 6' 'ADAT 7' 'DSP 0' 'DSP 1' 'DSP 2' 'DSP 3' 'DSP 4' 'DSP 5' 'DSP 6' 'DSP 7' 'DSP 8' 'DSP 9' 'DSP 10' 'DSP 11' 'DSP 12' 'DSP 13' 'DSP 14' 'DSP 15' 'DSP 16' 'DSP 17' 'DSP 18' 'DSP 19' 'DSP 20' 'DSP 21' 'DSP 22' 'DSP 23' 'DSP 24' 'DSP 25' 'DSP 26' 'DSP 27' 'DSP 28' 'DSP 29' 'DSP 30' 'DSP 31' Item0: 'DSP 1' Simple mixer control 'EMU',0 Capabilities: cvolume penum Capture channels: Front Left - Front Right Limits: Capture 0 - 100 Front Left: Capture 92 [92%] [-3.20dB] Front Right: Capture 92 [92%] [-3.20dB] !!-------Mixer controls for card 2 [USB] Card hw:2 'USB'/'E-MU Systems, Inc. E-MU 0404 | USB at usb-0000:00:04.1-1.3, high speed' Mixer name : 'USB Mixer' Components : 'USB041e:3f04' Controls : 6 Simple ctrls : 5 Simple mixer control 'PCM',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right - Rear Left - Rear Right Limits: Playback 0 - 200 Mono: Front Left: Playback 200 [100%] [0.00dB] [on] Front Right: Playback 200 [100%] [0.00dB] [on] Rear Left: Playback 0 [0%] [0.00dB] [on] Rear Right: Playback 0 [0%] [0.00dB] [on] Simple mixer control 'Extension Unit',0 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [off] Simple mixer control 'Extension Unit',1 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'Extension Unit',2 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] Simple mixer control 'Extension Unit',3 Capabilities: pswitch pswitch-joined penum Playback channels: Mono Mono: Playback [on] !!Alsactl output !!------------- --startcollapse-- state.NVidia { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 39' comment.dbmin -5850 comment.dbmax 0 iface MIXER name 'Front Playback Volume' value.0 39 value.1 39 } control.2 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Front Playback Switch' value.0 true value.1 true } control.3 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 39' comment.dbmin -5850 comment.dbmax 0 iface MIXER name 'Surround Playback Volume' value.0 39 value.1 39 } control.4 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Surround Playback Switch' value.0 true value.1 true } control.5 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 39' comment.dbmin -5850 comment.dbmax 0 iface MIXER name 'Center Playback Volume' value 39 } control.6 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 39' comment.dbmin -5850 comment.dbmax 0 iface MIXER name 'LFE Playback Volume' value 39 } control.7 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Center Playback Switch' value true } control.8 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'LFE Playback Switch' value true } control.9 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 39' comment.dbmin -5850 comment.dbmax 0 iface MIXER name 'Side Playback Volume' value.0 39 value.1 39 } control.10 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Side Playback Switch' value.0 true value.1 true } control.11 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true } control.12 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -3450 comment.dbmax 1200 iface MIXER name 'Mic Playback Volume' value.0 12 value.1 12 } control.13 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Mic Playback Switch' value.0 true value.1 true } control.14 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 3' comment.dbmin 0 comment.dbmax 3000 iface MIXER name 'Mic Boost' value.0 1 value.1 1 } control.15 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -3450 comment.dbmax 1200 iface MIXER name 'Front Mic Playback Volume' value.0 31 value.1 31 } control.16 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Front Mic Playback Switch' value.0 true value.1 true } control.17 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 3' comment.dbmin 0 comment.dbmax 3000 iface MIXER name 'Front Mic Boost' value.0 1 value.1 1 } control.18 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -3450 comment.dbmax 1200 iface MIXER name 'Line Playback Volume' value.0 11 value.1 11 } control.19 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Line Playback Switch' value.0 true value.1 true } control.20 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -3450 comment.dbmax 1200 iface MIXER name 'Front Line Playback Volume' value.0 31 value.1 31 } control.21 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Front Line Playback Switch' value.0 true value.1 true } control.22 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -3450 comment.dbmax 1200 iface MIXER name 'CD Playback Volume' value.0 31 value.1 31 } control.23 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'CD Playback Switch' value.0 true value.1 true } control.24 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -3450 comment.dbmax 1200 iface MIXER name 'Aux Playback Volume' value.0 31 value.1 31 } control.25 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Aux Playback Switch' value.0 true value.1 true } control.26 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 31' comment.dbmin -4650 comment.dbmax 0 iface MIXER name 'Analog Mix Playback Volume' value.0 31 value.1 31 } control.27 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Analog Mix Playback Switch' value.0 true value.1 true } control.28 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' value.0 54 value.1 54 } control.29 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' value.0 true value.1 true } control.30 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 1 value.0 39 value.1 39 } control.31 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 1 value.0 false value.1 false } control.32 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 54' comment.dbmin -5850 comment.dbmax 2250 iface MIXER name 'Capture Volume' index 2 value.0 39 value.1 39 } control.33 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Capture Switch' index 2 value.0 false value.1 false } control.34 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Mic comment.item.1 'Front Mic' comment.item.2 Line comment.item.3 'Front Line' comment.item.4 CD comment.item.5 Aux comment.item.6 Mix iface MIXER name 'Input Source' value 'Front Mic' } control.35 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Mic comment.item.1 'Front Mic' comment.item.2 Line comment.item.3 'Front Line' comment.item.4 CD comment.item.5 Aux comment.item.6 Mix iface MIXER name 'Input Source' index 1 value Mic } control.36 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Mic comment.item.1 'Front Mic' comment.item.2 Line comment.item.3 'Front Line' comment.item.4 CD comment.item.5 Aux comment.item.6 Mix iface MIXER name 'Input Source' index 2 value Mic } control.37 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 39' comment.dbmin -5850 comment.dbmax 0 iface MIXER name 'IEC958 Playback Volume' value.0 39 value.1 39 } control.38 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 PCM comment.item.1 ADC1 comment.item.2 ADC2 comment.item.3 ADC3 iface MIXER name 'IEC958 Playback Source' value PCM } control.39 { comment.access read comment.type IEC958 comment.count 1 iface MIXER name 'IEC958 Playback Con Mask' value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.40 { comment.access read comment.type IEC958 comment.count 1 iface MIXER name 'IEC958 Playback Pro Mask' value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.41 { comment.access 'read write' comment.type IEC958 comment.count 1 iface MIXER name 'IEC958 Playback Default' value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.42 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'IEC958 Playback Switch' value true } control.43 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'IEC958 Default PCM Playback Switch' value true } control.44 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 15' comment.dbmin -4500 comment.dbmax 0 iface MIXER name 'Beep Playback Volume' value 15 } control.45 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Beep Playback Switch' value true } control.46 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 39' comment.dbmin -5850 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value 38 } control.47 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Master Playback Switch' value true } control.48 { comment.access read comment.type IEC958 comment.count 1 iface MIXER name 'IEC958 Playback Con Mask' index 1 value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.49 { comment.access read comment.type IEC958 comment.count 1 iface MIXER name 'IEC958 Playback Pro Mask' index 1 value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.50 { comment.access 'read write' comment.type IEC958 comment.count 1 iface MIXER name 'IEC958 Playback Default' index 1 value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.51 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'IEC958 Playback Switch' index 1 value false } control.52 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 250 value.1 250 } } state.EMU0404 { control.1 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'PCM Front Playback Volume' value.0 100 value.1 100 } control.2 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'PCM Surround Playback Volume' value.0 100 value.1 100 } control.3 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'PCM Side Playback Volume' value.0 100 value.1 100 } control.4 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'PCM Center Playback Volume' value 100 } control.5 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'PCM LFE Playback Volume' value 100 } control.6 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 100 value.1 100 } control.7 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Synth Playback Volume' value.0 80 value.1 80 } control.8 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'PCM Capture Volume' value.0 100 value.1 100 } control.9 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Synth Capture Volume' value.0 100 value.1 100 } control.10 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'EMU Capture Volume' value.0 92 value.1 92 } control.11 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Mic Playback Volume' value.0 94 value.1 94 } control.12 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Mic Capture Volume' value.0 99 value.1 100 } control.13 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'CD Playback Volume' value.0 31 value.1 31 } control.14 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'CD Capture Volume' value.0 30 value.1 30 } control.15 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'IEC958 Optical Playback Volume' value.0 0 value.1 0 } control.16 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'IEC958 Optical Capture Volume' value.0 0 value.1 0 } control.17 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Line Playback Volume' value.0 100 value.1 97 } control.18 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Line Capture Volume' value.0 100 value.1 100 } control.19 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Analog Mix Playback Volume' value.0 99 value.1 99 } control.20 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Analog Mix Capture Volume' value.0 96 value.1 96 } control.21 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Aux Playback Volume' value.0 0 value.1 0 } control.22 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Aux Capture Volume' value.0 0 value.1 0 } control.23 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Front Playback Volume' value.0 100 value.1 100 } control.24 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Surround Playback Volume' value.0 100 value.1 100 } control.25 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Center Playback Volume' value 100 } control.26 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'LFE Playback Volume' value 100 } control.27 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Side Playback Volume' value.0 100 value.1 100 } control.28 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 40' iface MIXER name 'Tone Control - Bass' value.0 20 value.1 20 } control.29 { comment.access 'read write' comment.type INTEGER comment.count 2 comment.range '0 - 40' iface MIXER name 'Tone Control - Treble' value.0 20 value.1 20 } control.30 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'Tone Control - Switch' value.0 false value.1 false } control.31 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 100' comment.dbmin -4000 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value 99 } control.32 { comment.access 'read write' comment.type BOOLEAN comment.count 2 iface MIXER name 'IEC958 Optical Raw Playback Switch' value.0 false value.1 false } control.33 { comment.access 'read write' comment.type BOOLEAN comment.count 64 iface PCM device 2 name 'Captured FX8010 Outputs' value.0 false value.1 false value.2 false value.3 false value.4 false value.5 false value.6 false value.7 false value.8 false value.9 false value.10 false value.11 false value.12 false value.13 false value.14 false value.15 false value.16 false value.17 false value.18 false value.19 false value.20 false value.21 false value.22 false value.23 false value.24 false value.25 false value.26 false value.27 false value.28 false value.29 false value.30 false value.31 false value.32 true value.33 true value.34 true value.35 true value.36 true value.37 true value.38 true value.39 true value.40 true value.41 true value.42 true value.43 true value.44 true value.45 true value.46 true value.47 true value.48 true value.49 true value.50 true value.51 true value.52 true value.53 true value.54 true value.55 true value.56 true value.57 true value.58 true value.59 true value.60 true value.61 true value.62 true value.63 true } control.178 { comment.access read comment.type IEC958 comment.count 1 iface PCM name 'IEC958 Playback Mask' value ffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 } control.179 { comment.access read comment.type IEC958 comment.count 1 iface PCM name 'IEC958 Playback Mask' index 1 value ffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 } control.180 { comment.access read comment.type IEC958 comment.count 1 iface PCM name 'IEC958 Playback Mask' index 2 value ffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 } control.181 { comment.access 'read write' comment.type IEC958 comment.count 1 iface PCM name 'IEC958 Playback Default' value '0492100200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.182 { comment.access 'read write' comment.type IEC958 comment.count 1 iface PCM name 'IEC958 Playback Default' index 1 value '0492100200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.183 { comment.access 'read write' comment.type IEC958 comment.count 1 iface PCM name 'IEC958 Playback Default' index 2 value '0492100200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' } control.184 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC1 Left Playback Enum' value 'DSP 0' } control.185 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC1 Right Playback Enum' value 'DSP 1' } control.186 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC2 Left Playback Enum' value 'DSP 2' } control.187 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC2 Right Playback Enum' value 'DSP 3' } control.188 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC3 Left Playback Enum' value 'DSP 4' } control.189 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC3 Right Playback Enum' value 'DSP 5' } control.190 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC4 Left Playback Enum' value 'DSP 6' } control.191 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock DAC4 Right Playback Enum' value 'DSP 7' } control.192 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock Phones Left Playback Enum' value 'DSP 0' } control.193 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock Phones Right Playback Enum' value 'DSP 1' } control.194 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock SPDIF Left Playback Enum' value 'DSP 0' } control.195 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'Dock SPDIF Right Playback Enum' value 'DSP 1' } control.196 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 SPDIF Left Playback Enum' value 'DSP 0' } control.197 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 SPDIF Right Playback Enum' value 'DSP 1' } control.198 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '0202 DAC Left Playback Enum' value 'Dock ADC1 Left' } control.199 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '0202 DAC Right Playback Enum' value 'Dock ADC1 Right' } control.200 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 0 Playback Enum' value 'DSP 0' } control.201 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 1 Playback Enum' value 'DSP 1' } control.202 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 2 Playback Enum' value 'DSP 2' } control.203 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 3 Playback Enum' value 'DSP 3' } control.204 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 4 Playback Enum' value 'DSP 4' } control.205 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 5 Playback Enum' value 'DSP 5' } control.206 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 6 Playback Enum' value 'DSP 6' } control.207 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name '1010 ADAT 7 Playback Enum' value 'DSP 7' } control.208 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 0 Capture Enum' value '0202 ADC Left' } control.209 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 1 Capture Enum' value '0202 ADC Right' } control.210 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 2 Capture Enum' value Silence } control.211 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 3 Capture Enum' value Silence } control.212 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 4 Capture Enum' value Silence } control.213 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 5 Capture Enum' value Silence } control.214 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 6 Capture Enum' value Silence } control.215 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 7 Capture Enum' value Silence } control.216 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 8 Capture Enum' value Silence } control.217 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 9 Capture Enum' value Silence } control.218 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP A Capture Enum' value Silence } control.219 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP B Capture Enum' value Silence } control.220 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP C Capture Enum' value Silence } control.221 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP D Capture Enum' value Silence } control.222 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP E Capture Enum' value Silence } control.223 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP F Capture Enum' value Silence } control.224 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 10 Capture Enum' value Silence } control.225 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 11 Capture Enum' value Silence } control.226 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 12 Capture Enum' value Silence } control.227 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 13 Capture Enum' value Silence } control.228 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 14 Capture Enum' value Silence } control.229 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 Silence comment.item.1 'Dock Mic A' comment.item.2 'Dock Mic B' comment.item.3 'Dock ADC1 Left' comment.item.4 'Dock ADC1 Right' comment.item.5 'Dock ADC2 Left' comment.item.6 'Dock ADC2 Right' comment.item.7 'Dock ADC3 Left' comment.item.8 'Dock ADC3 Right' comment.item.9 '0202 ADC Left' comment.item.10 '0202 ADC Right' comment.item.11 '0202 SPDIF Left' comment.item.12 '0202 SPDIF Right' comment.item.13 'ADAT 0' comment.item.14 'ADAT 1' comment.item.15 'ADAT 2' comment.item.16 'ADAT 3' comment.item.17 'ADAT 4' comment.item.18 'ADAT 5' comment.item.19 'ADAT 6' comment.item.20 'ADAT 7' comment.item.21 'DSP 0' comment.item.22 'DSP 1' comment.item.23 'DSP 2' comment.item.24 'DSP 3' comment.item.25 'DSP 4' comment.item.26 'DSP 5' comment.item.27 'DSP 6' comment.item.28 'DSP 7' comment.item.29 'DSP 8' comment.item.30 'DSP 9' comment.item.31 'DSP 10' comment.item.32 'DSP 11' comment.item.33 'DSP 12' comment.item.34 'DSP 13' comment.item.35 'DSP 14' comment.item.36 'DSP 15' comment.item.37 'DSP 16' comment.item.38 'DSP 17' comment.item.39 'DSP 18' comment.item.40 'DSP 19' comment.item.41 'DSP 20' comment.item.42 'DSP 21' comment.item.43 'DSP 22' comment.item.44 'DSP 23' comment.item.45 'DSP 24' comment.item.46 'DSP 25' comment.item.47 'DSP 26' comment.item.48 'DSP 27' comment.item.49 'DSP 28' comment.item.50 'DSP 29' comment.item.51 'DSP 30' comment.item.52 'DSP 31' iface MIXER name 'DSP 15 Capture Enum' value Silence } control.230 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'ADC1 14dB PAD Audio Dock Capture Switch' value false } control.231 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'ADC2 14dB PAD Audio Dock Capture Switch' value false } control.232 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'ADC3 14dB PAD Audio Dock Capture Switch' value false } control.233 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'ADC1 14dB PAD 0202 Capture Switch' value false } control.234 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'DAC1 Audio Dock 14dB PAD Playback Switch' value true } control.235 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'DAC2 Audio Dock 14dB PAD Playback Switch' value true } control.236 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'DAC3 Audio Dock 14dB PAD Playback Switch' value true } control.237 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'DAC4 Audio Dock 14dB PAD Playback Switch' value true } control.238 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'DAC1 0202 14dB PAD Playback Switch' value false } control.239 { comment.access 'read write' comment.type ENUMERATED comment.count 1 comment.item.0 '44100' comment.item.1 '48000' comment.item.2 SPDIF comment.item.3 ADAT iface MIXER name 'Clock Internal Rate' value '48000' } } state.USB { control.1 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'PCM Playback Switch' value true } control.2 { comment.access 'read write' comment.type INTEGER comment.count 4 comment.range '0 - 200' comment.dbmin 0 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 200 value.1 200 value.2 0 value.3 0 } control.3 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Extension Unit Switch' value false } control.4 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Extension Unit Switch' index 1 value true } control.5 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Extension Unit Switch' index 2 value true } control.6 { comment.access 'read write' comment.type BOOLEAN comment.count 1 iface MIXER name 'Extension Unit Switch' index 3 value true } } --endcollapse-- !!All Loaded Modules !!------------------ Module ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables vboxnetadp vboxnetflt vboxdrv bluetooth af_packet nfsd snd_pcm_oss lockd nfs_acl snd_mixer_oss auth_rpcgss sunrpc snd_emu10k1_synth binfmt_misc snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_midi snd_seq_midi_event snd_seq bridge stp llc fuse loop dm_mod i2c_dev dvb_pll mt352 cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core snd_hda_codec_nvhdmi snd_hda_codec_analog arc4 ecb rt73usb rt2500usb rt2x00usb rt2x00lib cx8800 cx8802 cx88xx led_class snd_emu10k1 gspca_m5602 ir_common snd_ac97_codec i2c_algo_bit snd_hda_intel gspca_main v4l2_common snd_hda_codec ac97_bus mac80211 tveeprom snd_usb_audio videodev joydev nvidia ir_core snd_usb_lib ohci1394 snd_pcm cp210x cfg80211 kvm_amd video v4l1_compat usbhid usblp pl2303 usb_storage videobuf_dma_sg snd_util_mem snd_rawmidi snd_timer sr_mod sky2 k10temp forcedeth v4l2_compat_ioctl32 agpgart serio_raw hid edac_core videobuf_core btcx_risc usb_libusual ieee1394 i2c_nforce2 usbserial snd_hwdep snd_seq_device button rfkill sg cdrom output asus_atk0110 kvm snd snd_page_alloc soundcore ohci_hcd rtc_cmos sd_mod rtc_core crc_t10dif ehci_hcd rtc_lib usbcore edd xfs exportfs w83791d hwmon_vid i2c_core k8temp reiserfs jfs ahci fan processor ide_pci_generic amd74xx ide_core ata_generic pata_amd libata scsi_mod thermal thermal_sys hwmon netconsole configfs !!Sysfs Files !!----------- /sys/class/sound/hwC0D0/init_pin_configs: 0x11 0x02214030 0x12 0x01014010 0x13 0x511711f0 0x14 0x02a1902e 0x15 0x01813021 0x16 0x01011012 0x17 0x01a19020 0x18 0x99331122 0x1a 0x91f711f0 0x1b 0x0145f1f0 0x1c 0x41c5f1f0 0x24 0x01016011 0x25 0x01012014 /sys/class/sound/hwC0D0/driver_pin_configs: /sys/class/sound/hwC0D0/user_pin_configs: /sys/class/sound/hwC0D0/init_verbs: /sys/class/sound/hwC0D3/init_pin_configs: 0x05 0x18560110 0x07 0x58560121 0x09 0x58560122 0x0b 0x58560123 0x0d 0x58560124 /sys/class/sound/hwC0D3/driver_pin_configs: /sys/class/sound/hwC0D3/user_pin_configs: /sys/class/sound/hwC0D3/init_verbs: !!ALSA/HDA dmesg !!------------------ ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 20 HDA Intel 0000:00:07.0: PCI INT A -> Link[AAZA] -> GSI 20 (level, low) -> IRQ 20 HDA Intel 0000:00:07.0: irq 30 for MSI/MSI-X HDA Intel 0000:00:07.0: setting latency timer to 64 gspca: probing 0402:5602 -- EMU10K1_Audigy 0000:01:08.0: PCI INT A -> Link[APC1] -> GSI 16 (level, low) -> IRQ 16 ALSA sound/pci/emu10k1/emu10k1_main.c:811: emu1010: Special config. ALSA sound/pci/emu10k1/emu10k1_main.c:850: emu1010: EMU_HANA_ID = 0x3f ALSA sound/pci/emu10k1/emu10k1_main.c:869: emu1010: filename emu/emu0404.fw testing EMU10K1_Audigy 0000:01:08.0: firmware: requesting emu/emu0404.fw -- usbcore: registered new interface driver rt2500usb ALSA sound/pci/emu10k1/emu10k1_main.c:674: firmware size = 0xd67c phy1: Selected rate control algorithm 'minstrel' -- usbcore: registered new interface driver rt73usb ALSA sound/pci/emu10k1/emu10k1_main.c:886: emu1010: Hana Firmware loaded ALSA sound/pci/emu10k1/emu10k1_main.c:889: emu1010: Hana version: 1.1 ALSA sound/pci/emu10k1/emu10k1_main.c:894: emu1010: Card options = 0x1 ALSA sound/pci/emu10k1/emu10k1_main.c:896: emu1010: Card options = 0x1 ALSA sound/pci/emu10k1/emu10k1_main.c:935: emu1010: Card options3 = 0x1 ALSA sound/pci/emu10k1/emu10k1_main.c:219: Audigy2 value: Special config. ALSA sound/pci/emu10k1/emufx.c:1522: EMU outputs on ALSA sound/pci/emu10k1/emufx.c:1570: EMU2 inputs on cx88[0]: subsystem: 17de:08a6, board: KWorld/VStream XPert DVB-T [card=14,autodetected], frontend(s): 1 cx88[0]: TV tuner type 4, Radio tuner type -1 hda_codec: AD1988B: BIOS auto-probing. ALSA sound/pci/hda/hda_codec.c:4284: autoconfig: line_outs=4 (0x12/0x16/0x24/0x25/0x0) ALSA sound/pci/hda/hda_codec.c:4288: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:4292: hp_outs=1 (0x11/0x0/0x0/0x0/0x0) ALSA sound/pci/hda/hda_codec.c:4293: mono: mono_out=0x0 ALSA sound/pci/hda/hda_codec.c:4296: dig-out=0x1b/0x0 ALSA sound/pci/hda/hda_codec.c:4304: inputs: mic=0x17, fmic=0x14, line=0x15, fline=0x0, cd=0x18, aux=0x0 input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:07.0/input/input8 input: cx88 IR (KWorld/VStream XPert D as /devices/pci0000:00/0000:00:08.0/0000:01:09.2/input/input9 -- ip_tables: (C) 2000-2006 Netfilter Core Team ALSA sound/usb/usbaudio.c:354: frame 1 active: -71 kmemleak: 27 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 12 new suspected memory leaks (see /sys/kernel/debug/kmemleak) ALSA sound/usb/usbaudio.c:354: frame 0 active: -75 ALSA sound/usb/usbaudio.c:354: frame 0 active: -75 ALSA sound/usb/usbaudio.c:354: frame 0 active: -71 kmemleak: 3 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) usb 2-2: USB disconnect, address 3 -- sd 11:0:0:0: [sdd] Attached SCSI removable disk ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:354: frame 0 active: -18 ALSA sound/usb/usbaudio.c:708: cannot submit urb (err = -27) ALSA sound/usb/usbaudio.c:731: cannot submit sync urb (err = -27) kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) ALSA sound/pci/hda/hda_intel.c:694: azx_get_response timeout, switching to polling mode: last cmd=0x001f000a ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-27 19:29 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-27 19:29 UTC (permalink / raw) To: sboyce; +Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Wed, 27 Jan 2010 17:17:04 +0000, Sid Boyce wrote: > > On 27/01/10 06:42, Takashi Iwai wrote: > > At Wed, 27 Jan 2010 02:40:05 +0000, > > Sid Boyce wrote: > >> > >> On 27/01/10 00:56, Rafael J. Wysocki wrote: > >>> On Tuesday 26 January 2010, Sid Boyce wrote: > >>>> I forgot to mention 2.6.33-rc5 now boots successfully. > >>> > >>> Does that mean the problem is fixed in 2.6.33-rc5 or you still need the > >>> enable_msi=0 workaround? > >>> > >>> Rafael > >>> > >> It boots only with the enable_msi=0 workaround. > > > > OK, then could you run alsa-info.sh (with --no-upload option), and > > attach the generated file? I'll add your device to the blacklist for > > disabling MSI in hda_intel.c. > > > > > > thanks, > > > > Takashi > > > > > > Thanks. OK, I added the corresponding quirk entry to sound git tree. The patch will be included in the next pull request so that it'll be fixed in 2.6.33-rc6. thanks, Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot @ 2010-01-27 19:29 ` Takashi Iwai 0 siblings, 0 replies; 248+ messages in thread From: Takashi Iwai @ 2010-01-27 19:29 UTC (permalink / raw) To: sboyce-QgLWrMLu8clzjhtm8Ag3mw Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List At Wed, 27 Jan 2010 17:17:04 +0000, Sid Boyce wrote: > > On 27/01/10 06:42, Takashi Iwai wrote: > > At Wed, 27 Jan 2010 02:40:05 +0000, > > Sid Boyce wrote: > >> > >> On 27/01/10 00:56, Rafael J. Wysocki wrote: > >>> On Tuesday 26 January 2010, Sid Boyce wrote: > >>>> I forgot to mention 2.6.33-rc5 now boots successfully. > >>> > >>> Does that mean the problem is fixed in 2.6.33-rc5 or you still need the > >>> enable_msi=0 workaround? > >>> > >>> Rafael > >>> > >> It boots only with the enable_msi=0 workaround. > > > > OK, then could you run alsa-info.sh (with --no-upload option), and > > attach the generated file? I'll add your device to the blacklist for > > disabling MSI in hda_intel.c. > > > > > > thanks, > > > > Takashi > > > > > > Thanks. OK, I added the corresponding quirk entry to sound git tree. The patch will be included in the next pull request so that it'll be fixed in 2.6.33-rc6. thanks, Takashi ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: HDA Intel Audio hang on boot 2010-01-27 19:29 ` Takashi Iwai (?) @ 2010-01-27 22:14 ` Sid Boyce -1 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-27 22:14 UTC (permalink / raw) To: Takashi Iwai Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List On 27/01/10 19:29, Takashi Iwai wrote: > At Wed, 27 Jan 2010 17:17:04 +0000, > Sid Boyce wrote: >> >> On 27/01/10 06:42, Takashi Iwai wrote: >>> At Wed, 27 Jan 2010 02:40:05 +0000, >>> Sid Boyce wrote: >>>> >>>> On 27/01/10 00:56, Rafael J. Wysocki wrote: >>>>> On Tuesday 26 January 2010, Sid Boyce wrote: >>>>>> I forgot to mention 2.6.33-rc5 now boots successfully. >>>>> >>>>> Does that mean the problem is fixed in 2.6.33-rc5 or you still need the >>>>> enable_msi=0 workaround? >>>>> >>>>> Rafael >>>>> >>>> It boots only with the enable_msi=0 workaround. >>> >>> OK, then could you run alsa-info.sh (with --no-upload option), and >>> attach the generated file? I'll add your device to the blacklist for >>> disabling MSI in hda_intel.c. >>> >>> >>> thanks, >>> >>> Takashi >>> >>> >> >> Thanks. > > OK, I added the corresponding quirk entry to sound git tree. > The patch will be included in the next pull request so that it'll > be fixed in 2.6.33-rc6. > > > thanks, > > Takashi > Thanks, I shall give a try then. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14948] EHCI resume sysfs duplicates 2010-01-10 22:27 ` Rafael J. Wysocki ` (12 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 6:05 ` Borislav Petkov -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Borislav Petkov This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 Subject : EHCI resume sysfs duplicates Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:36 (16 days old) References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates 2010-01-10 22:32 ` [Bug #14948] EHCI resume sysfs duplicates Rafael J. Wysocki @ 2010-01-11 6:05 ` Borislav Petkov 0 siblings, 0 replies; 248+ messages in thread From: Borislav Petkov @ 2010-01-11 6:05 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > Subject : EHCI resume sysfs duplicates > Submitter : Borislav Petkov <petkovbb@googlemail.com> > Date : 2009-12-26 9:36 (16 days old) > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> -- Regards/Gruss, Boris. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates @ 2010-01-11 6:05 ` Borislav Petkov 0 siblings, 0 replies; 248+ messages in thread From: Borislav Petkov @ 2010-01-11 6:05 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > Subject : EHCI resume sysfs duplicates > Submitter : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > Date : 2009-12-26 9:36 (16 days old) > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> -- Regards/Gruss, Boris. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates @ 2010-01-11 20:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:06 UTC (permalink / raw) To: Borislav Petkov; +Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 11 January 2010, Borislav Petkov wrote: > On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > > Subject : EHCI resume sysfs duplicates > > Submitter : Borislav Petkov <petkovbb@googlemail.com> > > Date : 2009-12-26 9:36 (16 days old) > > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 > > Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> Sorry, I don't know how to resolve that. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates @ 2010-01-11 20:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:06 UTC (permalink / raw) To: Borislav Petkov; +Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 11 January 2010, Borislav Petkov wrote: > On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > > Subject : EHCI resume sysfs duplicates > > Submitter : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > Date : 2009-12-26 9:36 (16 days old) > > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 > > Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> Sorry, I don't know how to resolve that. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates @ 2010-01-11 22:41 ` Borislav Petkov 0 siblings, 0 replies; 248+ messages in thread From: Borislav Petkov @ 2010-01-11 22:41 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On Mon, Jan 11, 2010 at 09:06:06PM +0100, Rafael J. Wysocki wrote: > On Monday 11 January 2010, Borislav Petkov wrote: > > On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > > > Subject : EHCI resume sysfs duplicates > > > Submitter : Borislav Petkov <petkovbb@googlemail.com> > > > Date : 2009-12-26 9:36 (16 days old) > > > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 > > > > Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> > > Sorry, I don't know how to resolve that. Sorry about that. One way to resolve it would be: http://marc.info/?i=<LKML-Reference>, i.e. http://marc.info/?i=20100105220829.GA31569@xanatos for example, which should get rewritten to http://marc.info/?l=linux-usb&m=126272933202894 I'm sure there are other ways though. -- Regards/Gruss, Boris. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates @ 2010-01-11 22:41 ` Borislav Petkov 0 siblings, 0 replies; 248+ messages in thread From: Borislav Petkov @ 2010-01-11 22:41 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On Mon, Jan 11, 2010 at 09:06:06PM +0100, Rafael J. Wysocki wrote: > On Monday 11 January 2010, Borislav Petkov wrote: > > On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > > > Subject : EHCI resume sysfs duplicates > > > Submitter : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > > Date : 2009-12-26 9:36 (16 days old) > > > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 > > > > Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> > > Sorry, I don't know how to resolve that. Sorry about that. One way to resolve it would be: http://marc.info/?i=<LKML-Reference>, i.e. http://marc.info/?i=20100105220829.GA31569@xanatos for example, which should get rewritten to http://marc.info/?l=linux-usb&m=126272933202894 I'm sure there are other ways though. -- Regards/Gruss, Boris. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates @ 2010-01-11 23:08 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 23:08 UTC (permalink / raw) To: Borislav Petkov; +Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 11 January 2010, Borislav Petkov wrote: > On Mon, Jan 11, 2010 at 09:06:06PM +0100, Rafael J. Wysocki wrote: > > On Monday 11 January 2010, Borislav Petkov wrote: > > > On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > > > > This message has been generated automatically as a part of a report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > (either way). > > > > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > > > > Subject : EHCI resume sysfs duplicates > > > > Submitter : Borislav Petkov <petkovbb@googlemail.com> > > > > Date : 2009-12-26 9:36 (16 days old) > > > > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 > > > > > > Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> > > > > Sorry, I don't know how to resolve that. > > Sorry about that. One way to resolve it would be: > > http://marc.info/?i=<LKML-Reference>, i.e. > > http://marc.info/?i=20100105220829.GA31569@xanatos > > for example, which should get rewritten to > > http://marc.info/?l=linux-usb&m=126272933202894 Thanks, this works. Bug entry updated. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14948] EHCI resume sysfs duplicates @ 2010-01-11 23:08 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 23:08 UTC (permalink / raw) To: Borislav Petkov; +Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 11 January 2010, Borislav Petkov wrote: > On Mon, Jan 11, 2010 at 09:06:06PM +0100, Rafael J. Wysocki wrote: > > On Monday 11 January 2010, Borislav Petkov wrote: > > > On Sun, Jan 10, 2010 at 11:32:55PM +0100, Rafael J. Wysocki wrote: > > > > This message has been generated automatically as a part of a report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > (either way). > > > > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 > > > > Subject : EHCI resume sysfs duplicates > > > > Submitter : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > > > Date : 2009-12-26 9:36 (16 days old) > > > > References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 > > > > > > Preliminary and tested fix is at LKML-Reference: <20100105220829.GA31569@xanatos> > > > > Sorry, I don't know how to resolve that. > > Sorry about that. One way to resolve it would be: > > http://marc.info/?i=<LKML-Reference>, i.e. > > http://marc.info/?i=20100105220829.GA31569@xanatos > > for example, which should get rewritten to > > http://marc.info/?l=linux-usb&m=126272933202894 Thanks, this works. Bug entry updated. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 2010-01-10 22:27 ` Rafael J. Wysocki ` (13 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 9:40 ` Henrique de Moraes Holschuh -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Henrique de Moraes Holschuh, Pavel Machek This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 Subject : gkrellm no longer shows all the temperatures on thinkpad x60 Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-12-27 21:57 (15 days old) References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Patch : http://patchwork.kernel.org/patch/69809/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 2010-01-10 22:32 ` [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 Rafael J. Wysocki @ 2010-01-11 9:40 ` Henrique de Moraes Holschuh 2010-01-11 20:02 ` Rafael J. Wysocki 2010-02-01 10:48 ` Pavel Machek 0 siblings, 2 replies; 248+ messages in thread From: Henrique de Moraes Holschuh @ 2010-01-11 9:40 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Pavel Machek On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 > Subject : gkrellm no longer shows all the temperatures on thinkpad x60 > Submitter : Pavel Machek <pavel@ucw.cz> > Date : 2009-12-27 21:57 (15 days old) > References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 > Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> > Patch : http://patchwork.kernel.org/patch/69809/ Waiting for Pavel to confirm whether this can be closed or not. There could be more than one bug involved, and I only fixed one. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 @ 2010-01-11 20:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:02 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Linux Kernel Mailing List, Kernel Testers List, Pavel Machek On Monday 11 January 2010, Henrique de Moraes Holschuh wrote: > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 > > Subject : gkrellm no longer shows all the temperatures on thinkpad x60 > > Submitter : Pavel Machek <pavel@ucw.cz> > > Date : 2009-12-27 21:57 (15 days old) > > References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 > > Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> > > Patch : http://patchwork.kernel.org/patch/69809/ > > Waiting for Pavel to confirm whether this can be closed or not. There could > be more than one bug involved, and I only fixed one. OK, thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 @ 2010-01-11 20:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:02 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Linux Kernel Mailing List, Kernel Testers List, Pavel Machek On Monday 11 January 2010, Henrique de Moraes Holschuh wrote: > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 > > Subject : gkrellm no longer shows all the temperatures on thinkpad x60 > > Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> > > Date : 2009-12-27 21:57 (15 days old) > > References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 > > Handled-By : Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> > > Patch : http://patchwork.kernel.org/patch/69809/ > > Waiting for Pavel to confirm whether this can be closed or not. There could > be more than one bug involved, and I only fixed one. OK, thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 @ 2010-02-01 10:48 ` Pavel Machek 0 siblings, 0 replies; 248+ messages in thread From: Pavel Machek @ 2010-02-01 10:48 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 > > Subject : gkrellm no longer shows all the temperatures on thinkpad x60 > > Submitter : Pavel Machek <pavel@ucw.cz> > > Date : 2009-12-27 21:57 (15 days old) > > References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 > > Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> > > Patch : http://patchwork.kernel.org/patch/69809/ > > Waiting for Pavel to confirm whether this can be closed or not. There could > be more than one bug involved, and I only fixed one. Can be closed; it seems that gkrellm removed the graphs after it failed once, or something like that. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 @ 2010-02-01 10:48 ` Pavel Machek 0 siblings, 0 replies; 248+ messages in thread From: Pavel Machek @ 2010-02-01 10:48 UTC (permalink / raw) To: Henrique de Moraes Holschuh Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 > > Subject : gkrellm no longer shows all the temperatures on thinkpad x60 > > Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> > > Date : 2009-12-27 21:57 (15 days old) > > References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 > > Handled-By : Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> > > Patch : http://patchwork.kernel.org/patch/69809/ > > Waiting for Pavel to confirm whether this can be closed or not. There could > be more than one bug involved, and I only fixed one. Can be closed; it seems that gkrellm removed the graphs after it failed once, or something like that. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 @ 2010-02-02 21:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-02-02 21:06 UTC (permalink / raw) To: Pavel Machek Cc: Henrique de Moraes Holschuh, Linux Kernel Mailing List, Kernel Testers List On Monday 01 February 2010, Pavel Machek wrote: > > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 > > > Subject : gkrellm no longer shows all the temperatures on thinkpad x60 > > > Submitter : Pavel Machek <pavel@ucw.cz> > > > Date : 2009-12-27 21:57 (15 days old) > > > References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 > > > Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> > > > Patch : http://patchwork.kernel.org/patch/69809/ > > > > Waiting for Pavel to confirm whether this can be closed or not. There could > > be more than one bug involved, and I only fixed one. > > Can be closed; it seems that gkrellm removed the graphs after it > failed once, or something like that. Thanks, already closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 @ 2010-02-02 21:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-02-02 21:06 UTC (permalink / raw) To: Pavel Machek Cc: Henrique de Moraes Holschuh, Linux Kernel Mailing List, Kernel Testers List On Monday 01 February 2010, Pavel Machek wrote: > > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 > > > Subject : gkrellm no longer shows all the temperatures on thinkpad x60 > > > Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> > > > Date : 2009-12-27 21:57 (15 days old) > > > References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 > > > Handled-By : Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> > > > Patch : http://patchwork.kernel.org/patch/69809/ > > > > Waiting for Pavel to confirm whether this can be closed or not. There could > > be more than one bug involved, and I only fixed one. > > Can be closed; it seems that gkrellm removed the graphs after it > failed once, or something like that. Thanks, already closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14944] 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, fengxiangjun, Tejun Heo This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14944 Subject : 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine Submitter : fengxiangjun <fengxiangjun@neusoft.com> Date : 2009-12-21 11:12 (21 days old) References : http://marc.info/?l=linux-kernel&m=126139442328314&w=4 Handled-By : Tejun Heo <tj@kernel.org> Patch : http://patchwork.kernel.org/patch/69746/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14944] 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, fengxiangjun, Tejun Heo This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14944 Subject : 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine Submitter : fengxiangjun <fengxiangjun-YYSg24PYQUdBDgjK7y7TUQ@public.gmane.org> Date : 2009-12-21 11:12 (21 days old) References : http://marc.info/?l=linux-kernel&m=126139442328314&w=4 Handled-By : Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Patch : http://patchwork.kernel.org/patch/69746/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected 2010-01-10 22:27 ` Rafael J. Wysocki ` (15 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 6:11 ` Borislav Petkov -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Borislav Petkov, DRI This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:45 (16 days old) References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected 2010-01-10 22:32 ` [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected Rafael J. Wysocki @ 2010-01-11 6:11 ` Borislav Petkov 0 siblings, 0 replies; 248+ messages in thread From: Borislav Petkov @ 2010-01-11 6:11 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List, DRI On Sun, Jan 10, 2010 at 11:32:56PM +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 > Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected > Submitter : Borislav Petkov <petkovbb@googlemail.com> > Date : 2009-12-26 9:45 (16 days old) > References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 Fix for that is at LKML-Reference: <m1y6kh30pi.fsf_-_@fess.ebiederm.org> AFAIR, GregK-H will pick that one up. -- Regards/Gruss, Boris. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected @ 2010-01-11 6:11 ` Borislav Petkov 0 siblings, 0 replies; 248+ messages in thread From: Borislav Petkov @ 2010-01-11 6:11 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List, DRI On Sun, Jan 10, 2010 at 11:32:56PM +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 > Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected > Submitter : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > Date : 2009-12-26 9:45 (16 days old) > References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 Fix for that is at LKML-Reference: <m1y6kh30pi.fsf_-_-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org> AFAIR, GregK-H will pick that one up. -- Regards/Gruss, Boris. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected @ 2010-01-11 20:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:06 UTC (permalink / raw) To: Borislav Petkov; +Cc: Linux Kernel Mailing List, Kernel Testers List, DRI On Monday 11 January 2010, Borislav Petkov wrote: > On Sun, Jan 10, 2010 at 11:32:56PM +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 > > Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected > > Submitter : Borislav Petkov <petkovbb@googlemail.com> > > Date : 2009-12-26 9:45 (16 days old) > > References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 > > Fix for that is at LKML-Reference: <m1y6kh30pi.fsf_-_@fess.ebiederm.org> Again, I don't know how to resolve that, sorry. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected @ 2010-01-11 20:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:06 UTC (permalink / raw) To: Borislav Petkov; +Cc: Linux Kernel Mailing List, Kernel Testers List, DRI On Monday 11 January 2010, Borislav Petkov wrote: > On Sun, Jan 10, 2010 at 11:32:56PM +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 > > Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected > > Submitter : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > Date : 2009-12-26 9:45 (16 days old) > > References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 > > Fix for that is at LKML-Reference: <m1y6kh30pi.fsf_-_-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org> Again, I don't know how to resolve that, sorry. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14957] Blank screen with KMS enabled 2010-01-10 22:27 ` Rafael J. Wysocki ` (16 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Philipp Kohlbecher, Zhao Yakui This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14957 Subject : Blank screen with KMS enabled Submitter : Philipp Kohlbecher <xt28@gmx.de> Date : 2009-12-30 00:08 (12 days old) Handled-By : Zhao Yakui <yakui.zhao@intel.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24476 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14954] warning from alloc_pages_nodemask on boot -- caused by commit 78f1699659963fff97975df44db6d5dbe7218e55 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alex Chiang, Len Brown, Stephen Hemminger This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14954 Subject : warning from alloc_pages_nodemask on boot -- caused by commit 78f1699659963fff97975df44db6d5dbe7218e55 Submitter : Stephen Hemminger <shemminger@linux-foundation.org> Date : 2009-12-29 19:57 (13 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78f1699659963fff97975df44db6d5dbe7218e55 Handled-By : Alex Chiang <achiang@hp.com> ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14954] warning from alloc_pages_nodemask on boot -- caused by commit 78f1699659963fff97975df44db6d5dbe7218e55 @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alex Chiang, Len Brown, Stephen Hemminger This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14954 Subject : warning from alloc_pages_nodemask on boot -- caused by commit 78f1699659963fff97975df44db6d5dbe7218e55 Submitter : Stephen Hemminger <shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Date : 2009-12-29 19:57 (13 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78f1699659963fff97975df44db6d5dbe7218e55 Handled-By : Alex Chiang <achiang-VXdhtT5mjnY@public.gmane.org> ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14950] tbench regression with 2.6.33-rc1 2010-01-10 22:27 ` Rafael J. Wysocki ` (18 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Lin Ming, Mike Galbraith This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950 Subject : tbench regression with 2.6.33-rc1 Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2009-12-25 11:11 (17 days old) References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14974] tg3 does not resume from hibernation properly on BCM5787M 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Chow Loong Jin, Matt Carlson This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14974 Subject : tg3 does not resume from hibernation properly on BCM5787M Submitter : Chow Loong Jin <hyperair@ubuntu.com> Date : 2010-01-02 05:30 (9 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=87668d352aa8d135bd695a050f18bbfc7b50b506 Handled-By : Matt Carlson <mcarlson@broadcom.com> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=14974#c12 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14974] tg3 does not resume from hibernation properly on BCM5787M @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Chow Loong Jin, Matt Carlson This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14974 Subject : tg3 does not resume from hibernation properly on BCM5787M Submitter : Chow Loong Jin <hyperair-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> Date : 2010-01-02 05:30 (9 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=87668d352aa8d135bd695a050f18bbfc7b50b506 Handled-By : Matt Carlson <mcarlson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> Patch : http://bugzilla.kernel.org/show_bug.cgi?id=14974#c12 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15031] bug in fs/btrfs/ordered-data.c:672 2010-01-10 22:27 ` Rafael J. Wysocki ` (20 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 0:38 ` Carlos R. Mafra -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Carlos R. Mafra, Yan, Zheng This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15031 Subject : bug in fs/btrfs/ordered-data.c:672 Submitter : Carlos R. Mafra <crmafra2@gmail.com> Date : 2010-01-02 11:32 (9 days old) References : http://lkml.org/lkml/2010/1/2/17 Handled-By : Yan, Zheng <yanzheng@21cn.com> Patch : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03686.html ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15031] bug in fs/btrfs/ordered-data.c:672 2010-01-10 22:32 ` [Bug #15031] bug in fs/btrfs/ordered-data.c:672 Rafael J. Wysocki @ 2010-01-11 0:38 ` Carlos R. Mafra 0 siblings, 0 replies; 248+ messages in thread From: Carlos R. Mafra @ 2010-01-11 0:38 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Yan, Zheng On So 10.Jan'10 at 23:32:57 +0100, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15031 > Subject : bug in fs/btrfs/ordered-data.c:672 > Submitter : Carlos R. Mafra <crmafra2@gmail.com> > Date : 2010-01-02 11:32 (9 days old) > References : http://lkml.org/lkml/2010/1/2/17 > Handled-By : Yan, Zheng <yanzheng@21cn.com> > Patch : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03686.html I am using the patch above since Zheng pointed it out to me and the bug no longer appears. But it is not in mainline yet. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15031] bug in fs/btrfs/ordered-data.c:672 @ 2010-01-11 0:38 ` Carlos R. Mafra 0 siblings, 0 replies; 248+ messages in thread From: Carlos R. Mafra @ 2010-01-11 0:38 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Yan, Zheng On So 10.Jan'10 at 23:32:57 +0100, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15031 > Subject : bug in fs/btrfs/ordered-data.c:672 > Submitter : Carlos R. Mafra <crmafra2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2010-01-02 11:32 (9 days old) > References : http://lkml.org/lkml/2010/1/2/17 > Handled-By : Yan, Zheng <yanzheng-0GSiYjBpcig@public.gmane.org> > Patch : http://www.mail-archive.com/linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg03686.html I am using the patch above since Zheng pointed it out to me and the bug no longer appears. But it is not in mainline yet. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15031] bug in fs/btrfs/ordered-data.c:672 2010-01-11 0:38 ` Carlos R. Mafra @ 2010-01-11 20:11 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:11 UTC (permalink / raw) To: Carlos R. Mafra Cc: Linux Kernel Mailing List, Kernel Testers List, Yan, Zheng, Chris Mason On Monday 11 January 2010, Carlos R. Mafra wrote: > On So 10.Jan'10 at 23:32:57 +0100, Rafael J. Wysocki wrote: > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15031 > > Subject : bug in fs/btrfs/ordered-data.c:672 > > Submitter : Carlos R. Mafra <crmafra2@gmail.com> > > Date : 2010-01-02 11:32 (9 days old) > > References : http://lkml.org/lkml/2010/1/2/17 > > Handled-By : Yan, Zheng <yanzheng@21cn.com> > > Patch : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03686.html > > I am using the patch above since Zheng pointed it out to me and the bug > no longer appears. But it is not in mainline yet. Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15031] bug in fs/btrfs/ordered-data.c:672 @ 2010-01-11 20:11 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:11 UTC (permalink / raw) To: Carlos R. Mafra Cc: Linux Kernel Mailing List, Kernel Testers List, Yan, Zheng, Chris Mason On Monday 11 January 2010, Carlos R. Mafra wrote: > On So 10.Jan'10 at 23:32:57 +0100, Rafael J. Wysocki wrote: > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15031 > > Subject : bug in fs/btrfs/ordered-data.c:672 > > Submitter : Carlos R. Mafra <crmafra2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Date : 2010-01-02 11:32 (9 days old) > > References : http://lkml.org/lkml/2010/1/2/17 > > Handled-By : Yan, Zheng <yanzheng-0GSiYjBpcig@public.gmane.org> > > Patch : http://www.mail-archive.com/linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg03686.html > > I am using the patch above since Zheng pointed it out to me and the bug > no longer appears. But it is not in mainline yet. Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14976] No sound on snd_hda_codec_via in 2.6.33-rc2 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Mark Rosenstand This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14976 Subject : No sound on snd_hda_codec_via in 2.6.33-rc2 Submitter : Mark Rosenstand <rosenstand@gmail.com> Date : 2010-01-02 08:27 (9 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14976] No sound on snd_hda_codec_via in 2.6.33-rc2 @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Mark Rosenstand This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14976 Subject : No sound on snd_hda_codec_via in 2.6.33-rc2 Submitter : Mark Rosenstand <rosenstand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2010-01-02 08:27 (9 days old) ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15032] Oops in uart_resume_port() on resume 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alan Cox, Deepak Saxena, Greg Kroah-Hartman, Zdenek Kabelac This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15032 Subject : Oops in uart_resume_port() on resume Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2010-01-04 15:47 (7 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba15ab0e8de0d4439a91342ad52d55ca9e313f3d References : http://marc.info/?l=linux-kernel&m=126262008815689&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15032] Oops in uart_resume_port() on resume @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Alan Cox, Deepak Saxena, Greg Kroah-Hartman, Zdenek Kabelac This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15032 Subject : Oops in uart_resume_port() on resume Submitter : Zdenek Kabelac <zdenek.kabelac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2010-01-04 15:47 (7 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba15ab0e8de0d4439a91342ad52d55ca9e313f3d References : http://marc.info/?l=linux-kernel&m=126262008815689&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15026] i915: Resume regression on MSI Wind U100 w/o KMS 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rafael J. Wysocki This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15026 Subject : i915: Resume regression on MSI Wind U100 w/o KMS Submitter : Rafael J. Wysocki <rjw@sisk.pl> Date : 2010-01-08 23:45 (3 days old) References : http://marc.info/?l=linux-kernel&m=126299433427673&w=4 Handled-By : Rafael J. Wysocki <rjw@sisk.pl> Patch : http://patchwork.kernel.org/patch/71887/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15026] i915: Resume regression on MSI Wind U100 w/o KMS @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Rafael J. Wysocki This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15026 Subject : i915: Resume regression on MSI Wind U100 w/o KMS Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> Date : 2010-01-08 23:45 (3 days old) References : http://marc.info/?l=linux-kernel&m=126299433427673&w=4 Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> Patch : http://patchwork.kernel.org/patch/71887/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15035] BUG: unable to handle kernel paging request in rs600_gart_set_page() 2010-01-10 22:27 ` Rafael J. Wysocki ` (24 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Xiaotian Feng This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15035 Subject : BUG: unable to handle kernel paging request in rs600_gart_set_page() Submitter : Xiaotian Feng <dfeng@redhat.com> Date : 2010-01-05 19:10 (6 days old) References : http://lkml.org/lkml/2010/1/5/95 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15033] drm: gem_object_free without struct_mutex 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Hugh Dickins, Jesse Barnes This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 Subject : drm: gem_object_free without struct_mutex Submitter : Hugh Dickins <hugh.dickins@tiscali.co.uk> Date : 2009-12-30 19:45 (12 days old) References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org> ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15033] drm: gem_object_free without struct_mutex @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Hugh Dickins, Jesse Barnes This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 Subject : drm: gem_object_free without struct_mutex Submitter : Hugh Dickins <hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org> Date : 2009-12-30 19:45 (12 days old) References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org> ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15033] drm: gem_object_free without struct_mutex 2010-01-10 22:32 ` Rafael J. Wysocki @ 2010-01-11 23:15 ` Hugh Dickins -1 siblings, 0 replies; 248+ messages in thread From: Hugh Dickins @ 2010-01-11 23:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Hugh Dickins, Jesse Barnes, Chris Wilson On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 > Subject : drm: gem_object_free without struct_mutex > Submitter : Hugh Dickins <hugh.dickins@tiscali.co.uk> > Date : 2009-12-30 19:45 (12 days old) > References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 > Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org> Thanks, Rafael: please close it now. I just checked latest -git and it is now fixed (but not fixed in 2.6.33-rc3) - thanks, Chris. Hugh ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15033] drm: gem_object_free without struct_mutex @ 2010-01-11 23:15 ` Hugh Dickins 0 siblings, 0 replies; 248+ messages in thread From: Hugh Dickins @ 2010-01-11 23:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Hugh Dickins, Jesse Barnes, Chris Wilson On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 > Subject : drm: gem_object_free without struct_mutex > Submitter : Hugh Dickins <hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org> > Date : 2009-12-30 19:45 (12 days old) > References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 > Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org> Thanks, Rafael: please close it now. I just checked latest -git and it is now fixed (but not fixed in 2.6.33-rc3) - thanks, Chris. Hugh ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15033] drm: gem_object_free without struct_mutex @ 2010-01-11 23:50 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 23:50 UTC (permalink / raw) To: Hugh Dickins Cc: Linux Kernel Mailing List, Kernel Testers List, Jesse Barnes, Chris Wilson On Tuesday 12 January 2010, Hugh Dickins wrote: > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 > > Subject : drm: gem_object_free without struct_mutex > > Submitter : Hugh Dickins <hugh.dickins@tiscali.co.uk> > > Date : 2009-12-30 19:45 (12 days old) > > References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 > > Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org> > > Thanks, Rafael: please close it now. I just checked latest -git > and it is now fixed (but not fixed in 2.6.33-rc3) - thanks, Chris. Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15033] drm: gem_object_free without struct_mutex @ 2010-01-11 23:50 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 23:50 UTC (permalink / raw) To: Hugh Dickins Cc: Linux Kernel Mailing List, Kernel Testers List, Jesse Barnes, Chris Wilson On Tuesday 12 January 2010, Hugh Dickins wrote: > On Sun, 10 Jan 2010, Rafael J. Wysocki wrote: > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15033 > > Subject : drm: gem_object_free without struct_mutex > > Submitter : Hugh Dickins <hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org> > > Date : 2009-12-30 19:45 (12 days old) > > References : http://marc.info/?l=linux-kernel&m=126220236201529&w=4 > > Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org> > > Thanks, Rafael: please close it now. I just checked latest -git > and it is now fixed (but not fixed in 2.6.33-rc3) - thanks, Chris. Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15034] volano ~30% regression 2010-01-10 22:27 ` Rafael J. Wysocki ` (26 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 6:52 ` Mike Galbraith -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Lin Ming, Mike Galbraith This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15034 Subject : volano ~30% regression Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2010-01-04 8:15 (7 days old) References : http://marc.info/?l=linux-kernel&m=126259391411982&w=4 Handled-By : Mike Galbraith <efault@gmx.de> Patch : http://patchwork.kernel.org/patch/70623/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15034] volano ~30% regression 2010-01-10 22:32 ` [Bug #15034] volano ~30% regression Rafael J. Wysocki @ 2010-01-11 6:52 ` Mike Galbraith 0 siblings, 0 replies; 248+ messages in thread From: Mike Galbraith @ 2010-01-11 6:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Lin Ming On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). A verified fix for this one is in the pipe. > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15034 > Subject : volano ~30% regression > Submitter : Lin Ming <ming.m.lin@intel.com> > Date : 2010-01-04 8:15 (7 days old) > References : http://marc.info/?l=linux-kernel&m=126259391411982&w=4 > Handled-By : Mike Galbraith <efault@gmx.de> > Patch : http://patchwork.kernel.org/patch/70623/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15034] volano ~30% regression @ 2010-01-11 6:52 ` Mike Galbraith 0 siblings, 0 replies; 248+ messages in thread From: Mike Galbraith @ 2010-01-11 6:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Lin Ming On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). A verified fix for this one is in the pipe. > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15034 > Subject : volano ~30% regression > Submitter : Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > Date : 2010-01-04 8:15 (7 days old) > References : http://marc.info/?l=linux-kernel&m=126259391411982&w=4 > Handled-By : Mike Galbraith <efault-Mmb7MZpHnFY@public.gmane.org> > Patch : http://patchwork.kernel.org/patch/70623/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15034] volano ~30% regression 2010-01-11 6:52 ` Mike Galbraith (?) @ 2010-01-11 20:08 ` Rafael J. Wysocki 2010-01-12 2:28 ` Mike Galbraith -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:08 UTC (permalink / raw) To: Mike Galbraith; +Cc: Linux Kernel Mailing List, Kernel Testers List, Lin Ming On Monday 11 January 2010, Mike Galbraith wrote: > On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > A verified fix for this one is in the pipe. OK, thanks for the update. A link to that fix would be appreciated. :-) Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15034] volano ~30% regression @ 2010-01-12 2:28 ` Mike Galbraith 0 siblings, 0 replies; 248+ messages in thread From: Mike Galbraith @ 2010-01-12 2:28 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Lin Ming On Mon, 2010-01-11 at 21:08 +0100, Rafael J. Wysocki wrote: > On Monday 11 January 2010, Mike Galbraith wrote: > > On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > > > A verified fix for this one is in the pipe. > > OK, thanks for the update. > > A link to that fix would be appreciated. :-) One link, coming up. http://patchwork.kernel.org/patch/70623/ -Mike ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15034] volano ~30% regression @ 2010-01-12 2:28 ` Mike Galbraith 0 siblings, 0 replies; 248+ messages in thread From: Mike Galbraith @ 2010-01-12 2:28 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Lin Ming On Mon, 2010-01-11 at 21:08 +0100, Rafael J. Wysocki wrote: > On Monday 11 January 2010, Mike Galbraith wrote: > > On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > > > A verified fix for this one is in the pipe. > > OK, thanks for the update. > > A link to that fix would be appreciated. :-) One link, coming up. http://patchwork.kernel.org/patch/70623/ -Mike ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15034] volano ~30% regression @ 2010-01-12 22:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-12 22:06 UTC (permalink / raw) To: Mike Galbraith; +Cc: Linux Kernel Mailing List, Kernel Testers List, Lin Ming On Tuesday 12 January 2010, Mike Galbraith wrote: > On Mon, 2010-01-11 at 21:08 +0100, Rafael J. Wysocki wrote: > > On Monday 11 January 2010, Mike Galbraith wrote: > > > On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > > > > This message has been generated automatically as a part of a report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > (either way). > > > > > > A verified fix for this one is in the pipe. > > > > OK, thanks for the update. > > > > A link to that fix would be appreciated. :-) > > One link, coming up. > > http://patchwork.kernel.org/patch/70623/ Thanks, I have this one already. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15034] volano ~30% regression @ 2010-01-12 22:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-12 22:06 UTC (permalink / raw) To: Mike Galbraith; +Cc: Linux Kernel Mailing List, Kernel Testers List, Lin Ming On Tuesday 12 January 2010, Mike Galbraith wrote: > On Mon, 2010-01-11 at 21:08 +0100, Rafael J. Wysocki wrote: > > On Monday 11 January 2010, Mike Galbraith wrote: > > > On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > > > > This message has been generated automatically as a part of a report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > (either way). > > > > > > A verified fix for this one is in the pipe. > > > > OK, thanks for the update. > > > > A link to that fix would be appreciated. :-) > > One link, coming up. > > http://patchwork.kernel.org/patch/70623/ Thanks, I have this one already. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15037] BUG during shutdown - bisected to commit e2912009 2010-01-10 22:27 ` Rafael J. Wysocki ` (27 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-11 13:12 ` Marc Dionne -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Marc Dionne, Xiaotian Feng This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15037 Subject : BUG during shutdown - bisected to commit e2912009 Submitter : Marc Dionne <marc.c.dionne@gmail.com> Date : 2010-01-02 0:27 (9 days old) References : http://marc.info/?l=linux-kernel&m=126239207631034&w=4 Handled-By : Xiaotian Feng <dfeng@redhat.com> Patch : http://patchwork.kernel.org/patch/71537/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15037] BUG during shutdown - bisected to commit e2912009 2010-01-10 22:32 ` [Bug #15037] BUG during shutdown - bisected to commit e2912009 Rafael J. Wysocki @ 2010-01-11 13:12 ` Marc Dionne 0 siblings, 0 replies; 248+ messages in thread From: Marc Dionne @ 2010-01-11 13:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Xiaotian Feng On Sun, Jan 10, 2010 at 5:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15037 > Subject : BUG during shutdown - bisected to commit e2912009 > Submitter : Marc Dionne <marc.c.dionne@gmail.com> > Date : 2010-01-02 0:27 (9 days old) > References : http://marc.info/?l=linux-kernel&m=126239207631034&w=4 > Handled-By : Xiaotian Feng <dfeng@redhat.com> > Patch : http://patchwork.kernel.org/patch/71537/ I verified that the BUG still occurs with current git. The referenced patch does fix the issue for me, but it hasn't made its way into mainline yet. Thanks, Marc ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15037] BUG during shutdown - bisected to commit e2912009 @ 2010-01-11 13:12 ` Marc Dionne 0 siblings, 0 replies; 248+ messages in thread From: Marc Dionne @ 2010-01-11 13:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Xiaotian Feng On Sun, Jan 10, 2010 at 5:32 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15037 > Subject : BUG during shutdown - bisected to commit e2912009 > Submitter : Marc Dionne <marc.c.dionne-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Date : 2010-01-02 0:27 (9 days old) > References : http://marc.info/?l=linux-kernel&m=126239207631034&w=4 > Handled-By : Xiaotian Feng <dfeng-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > Patch : http://patchwork.kernel.org/patch/71537/ I verified that the BUG still occurs with current git. The referenced patch does fix the issue for me, but it hasn't made its way into mainline yet. Thanks, Marc ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15037] BUG during shutdown - bisected to commit e2912009 @ 2010-01-11 20:10 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:10 UTC (permalink / raw) To: Marc Dionne Cc: Linux Kernel Mailing List, Kernel Testers List, Xiaotian Feng, Mike Galbraith, Peter Zijlstra, Ingo Molnar On Monday 11 January 2010, Marc Dionne wrote: > On Sun, Jan 10, 2010 at 5:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15037 > > Subject : BUG during shutdown - bisected to commit e2912009 > > Submitter : Marc Dionne <marc.c.dionne@gmail.com> > > Date : 2010-01-02 0:27 (9 days old) > > References : http://marc.info/?l=linux-kernel&m=126239207631034&w=4 > > Handled-By : Xiaotian Feng <dfeng@redhat.com> > > Patch : http://patchwork.kernel.org/patch/71537/ > > I verified that the BUG still occurs with current git. > The referenced patch does fix the issue for me, but it hasn't made its > way into mainline yet. Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15037] BUG during shutdown - bisected to commit e2912009 @ 2010-01-11 20:10 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 20:10 UTC (permalink / raw) To: Marc Dionne Cc: Linux Kernel Mailing List, Kernel Testers List, Xiaotian Feng, Mike Galbraith, Peter Zijlstra, Ingo Molnar On Monday 11 January 2010, Marc Dionne wrote: > On Sun, Jan 10, 2010 at 5:32 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15037 > > Subject : BUG during shutdown - bisected to commit e2912009 > > Submitter : Marc Dionne <marc.c.dionne-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Date : 2010-01-02 0:27 (9 days old) > > References : http://marc.info/?l=linux-kernel&m=126239207631034&w=4 > > Handled-By : Xiaotian Feng <dfeng-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > Patch : http://patchwork.kernel.org/patch/71537/ > > I verified that the BUG still occurs with current git. > The referenced patch does fix the issue for me, but it hasn't made its > way into mainline yet. Thanks for the update. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15036] soft lockup in dmesg after suspend/resume 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, ykzhao, Zou, Nanhai This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036 Subject : soft lockup in dmesg after suspend/resume Submitter : ykzhao <yakui.zhao@intel.com> Date : 2010-01-04 5:36 (7 days old) References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15036] soft lockup in dmesg after suspend/resume @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, ykzhao, Zou, Nanhai This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036 Subject : soft lockup in dmesg after suspend/resume Submitter : ykzhao <yakui.zhao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Date : 2010-01-04 5:36 (7 days old) References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15043] Display goes off with i915.powersave=1 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Soeren Sonnenburg This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 Submitter : Soeren Sonnenburg <sonne@debian.org> Date : 2010-01-10 20:09 (1 days old) References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15043] Display goes off with i915.powersave=1 @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Soeren Sonnenburg This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 Submitter : Soeren Sonnenburg <sonne-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> Date : 2010-01-10 20:09 (1 days old) References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15043] Display goes off with i915.powersave=1 2010-01-10 22:32 ` Rafael J. Wysocki @ 2010-01-12 22:31 ` Soeren Sonnenburg -1 siblings, 0 replies; 248+ messages in thread From: Soeren Sonnenburg @ 2010-01-12 22:31 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 968 bytes --] On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 > Subject : Display goes off with i915.powersave=1 > Submitter : Soeren Sonnenburg <sonne@debian.org> > Date : 2010-01-10 20:09 (1 days old) > References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4 I just recognized that only the *internal* display (i.e., LVDS1) goes dark while the external display VGA1 stays on. In addition there is some random screen flickering often before the display turns off... Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15043] Display goes off with i915.powersave=1 @ 2010-01-12 22:31 ` Soeren Sonnenburg 0 siblings, 0 replies; 248+ messages in thread From: Soeren Sonnenburg @ 2010-01-12 22:31 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List [-- Attachment #1: Type: text/plain, Size: 968 bytes --] On Sun, 2010-01-10 at 23:32 +0100, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 > Subject : Display goes off with i915.powersave=1 > Submitter : Soeren Sonnenburg <sonne@debian.org> > Date : 2010-01-10 20:09 (1 days old) > References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4 I just recognized that only the *internal* display (i.e., LVDS1) goes dark while the external display VGA1 stays on. In addition there is some random screen flickering often before the display turns off... Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15041] Pagemap endless read loop with LTP 2010-01-10 22:27 ` Rafael J. Wysocki ` (30 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki 2010-01-13 3:04 ` Américo Wang -1 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Américo Wang, Andi Kleen This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 Subject : Pagemap endless read loop with LTP Submitter : Andi Kleen <andi@firstfloor.org> Date : 2010-01-10 2:09 (1 days old) References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP 2010-01-10 22:32 ` [Bug #15041] Pagemap endless read loop with LTP Rafael J. Wysocki @ 2010-01-13 3:04 ` Américo Wang 0 siblings, 0 replies; 248+ messages in thread From: Américo Wang @ 2010-01-13 3:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Andi Kleen On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > Subject : Pagemap endless read loop with LTP > Submitter : Andi Kleen <andi@firstfloor.org> > Date : 2010-01-10 2:09 (1 days old) > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > According to Andi's later reply, it shoud not be an endless loop, it just takes a rather long time. Thanks. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP @ 2010-01-13 3:04 ` Américo Wang 0 siblings, 0 replies; 248+ messages in thread From: Américo Wang @ 2010-01-13 3:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Andi Kleen On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > Subject : Pagemap endless read loop with LTP > Submitter : Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> > Date : 2010-01-10 2:09 (1 days old) > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > According to Andi's later reply, it shoud not be an endless loop, it just takes a rather long time. Thanks. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP @ 2010-01-13 21:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-13 21:57 UTC (permalink / raw) To: Américo Wang, Andi Kleen Cc: Linux Kernel Mailing List, Kernel Testers List On Wednesday 13 January 2010, Américo Wang wrote: > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > Subject : Pagemap endless read loop with LTP > > Submitter : Andi Kleen <andi@firstfloor.org> > > Date : 2010-01-10 2:09 (1 days old) > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > According to Andi's later reply, it shoud not be an endless loop, > it just takes a rather long time. Andi? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP @ 2010-01-13 21:57 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-13 21:57 UTC (permalink / raw) To: Américo Wang, Andi Kleen Cc: Linux Kernel Mailing List, Kernel Testers List On Wednesday 13 January 2010, Américo Wang wrote: > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > Subject : Pagemap endless read loop with LTP > > Submitter : Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> > > Date : 2010-01-10 2:09 (1 days old) > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > According to Andi's later reply, it shoud not be an endless loop, > it just takes a rather long time. Andi? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP 2010-01-13 21:57 ` Rafael J. Wysocki @ 2010-01-13 22:24 ` Matt Mackall -1 siblings, 0 replies; 248+ messages in thread From: Matt Mackall @ 2010-01-13 22:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Américo Wang, Andi Kleen, Linux Kernel Mailing List, Kernel Testers List On Wed, 2010-01-13 at 22:57 +0100, Rafael J. Wysocki wrote: > On Wednesday 13 January 2010, Américo Wang wrote: > > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > > Subject : Pagemap endless read loop with LTP > > > Submitter : Andi Kleen <andi@firstfloor.org> > > > Date : 2010-01-10 2:09 (1 days old) > > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > > > > According to Andi's later reply, it shoud not be an endless loop, > > it just takes a rather long time. > > Andi? This is expected. Pagemap contains 64 bits per page of _address space_. Sane users will consult ./maps first and then seek. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP @ 2010-01-13 22:24 ` Matt Mackall 0 siblings, 0 replies; 248+ messages in thread From: Matt Mackall @ 2010-01-13 22:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Américo Wang, Andi Kleen, Linux Kernel Mailing List, Kernel Testers List On Wed, 2010-01-13 at 22:57 +0100, Rafael J. Wysocki wrote: > On Wednesday 13 January 2010, Américo Wang wrote: > > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > > Subject : Pagemap endless read loop with LTP > > > Submitter : Andi Kleen <andi@firstfloor.org> > > > Date : 2010-01-10 2:09 (1 days old) > > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > > > > According to Andi's later reply, it shoud not be an endless loop, > > it just takes a rather long time. > > Andi? This is expected. Pagemap contains 64 bits per page of _address space_. Sane users will consult ./maps first and then seek. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP 2010-01-13 21:57 ` Rafael J. Wysocki (?) (?) @ 2010-01-13 23:50 ` Andi Kleen 2010-01-14 0:15 ` Matt Mackall -1 siblings, 1 reply; 248+ messages in thread From: Andi Kleen @ 2010-01-13 23:50 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Américo Wang, Andi Kleen, Linux Kernel Mailing List, Kernel Testers List On Wed, Jan 13, 2010 at 10:57:34PM +0100, Rafael J. Wysocki wrote: > On Wednesday 13 January 2010, Américo Wang wrote: > > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > This message has been generated automatically as a part of a report > > > of recent regressions. > > > > > > The following bug entry is on the current list of known regressions > > > from 2.6.32. Please verify if it still should be listed and let me know > > > (either way). > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > > Subject : Pagemap endless read loop with LTP > > > Submitter : Andi Kleen <andi@firstfloor.org> > > > Date : 2010-01-10 2:09 (1 days old) > > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > > > > According to Andi's later reply, it shoud not be an endless loop, > > it just takes a rather long time. > > Andi? It'll try to read 47 bits worth of 0s on 64bit x86-64. I haven't tried to wait until that finishes, but I estimate a few months of CPU time at least. The interface is just misdesigned, but I guess we cannot do anything about that for now. LTP will just need to do a workaround. This unfortunately breaks older LTP versions. -Andi -- ak@linux.intel.com -- Speaking for myself only. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP @ 2010-01-14 0:15 ` Matt Mackall 0 siblings, 0 replies; 248+ messages in thread From: Matt Mackall @ 2010-01-14 0:15 UTC (permalink / raw) To: Andi Kleen Cc: Rafael J. Wysocki, Américo Wang, Linux Kernel Mailing List, Kernel Testers List On Thu, 2010-01-14 at 00:50 +0100, Andi Kleen wrote: > On Wed, Jan 13, 2010 at 10:57:34PM +0100, Rafael J. Wysocki wrote: > > On Wednesday 13 January 2010, Américo Wang wrote: > > > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > This message has been generated automatically as a part of a report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > (either way). > > > > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > > > Subject : Pagemap endless read loop with LTP > > > > Submitter : Andi Kleen <andi@firstfloor.org> > > > > Date : 2010-01-10 2:09 (1 days old) > > > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > > > > > > > According to Andi's later reply, it shoud not be an endless loop, > > > it just takes a rather long time. > > > > Andi? > > It'll try to read 47 bits worth of 0s on 64bit x86-64. > > I haven't tried to wait until that finishes, but I estimate a few months of > CPU time at least. > > The interface is just misdesigned, but I guess we cannot do > anything about that for now. It's perfectly sensible. What's not sensible is reading the entirety of everything you find in /proc, something that just about every Linux admin figures out moments after running their first recursive grep. > LTP will just need to do a workaround. Or they could actually, you know, add a test of pagemap. Not much chance of that, though - CVS reports it took them until 2005 to figure out that skipping /proc/kcore was a good idea. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP @ 2010-01-14 0:15 ` Matt Mackall 0 siblings, 0 replies; 248+ messages in thread From: Matt Mackall @ 2010-01-14 0:15 UTC (permalink / raw) To: Andi Kleen Cc: Rafael J. Wysocki, Américo Wang, Linux Kernel Mailing List, Kernel Testers List On Thu, 2010-01-14 at 00:50 +0100, Andi Kleen wrote: > On Wed, Jan 13, 2010 at 10:57:34PM +0100, Rafael J. Wysocki wrote: > > On Wednesday 13 January 2010, Américo Wang wrote: > > > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > > > This message has been generated automatically as a part of a report > > > > of recent regressions. > > > > > > > > The following bug entry is on the current list of known regressions > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > (either way). > > > > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > > > Subject : Pagemap endless read loop with LTP > > > > Submitter : Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> > > > > Date : 2010-01-10 2:09 (1 days old) > > > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > > > > > > > According to Andi's later reply, it shoud not be an endless loop, > > > it just takes a rather long time. > > > > Andi? > > It'll try to read 47 bits worth of 0s on 64bit x86-64. > > I haven't tried to wait until that finishes, but I estimate a few months of > CPU time at least. > > The interface is just misdesigned, but I guess we cannot do > anything about that for now. It's perfectly sensible. What's not sensible is reading the entirety of everything you find in /proc, something that just about every Linux admin figures out moments after running their first recursive grep. > LTP will just need to do a workaround. Or they could actually, you know, add a test of pagemap. Not much chance of that, though - CVS reports it took them until 2005 to figure out that skipping /proc/kcore was a good idea. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP 2010-01-14 0:15 ` Matt Mackall @ 2010-01-14 20:38 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-14 20:38 UTC (permalink / raw) To: Matt Mackall Cc: Andi Kleen, Américo Wang, Linux Kernel Mailing List, Kernel Testers List On Thursday 14 January 2010, Matt Mackall wrote: > On Thu, 2010-01-14 at 00:50 +0100, Andi Kleen wrote: > > On Wed, Jan 13, 2010 at 10:57:34PM +0100, Rafael J. Wysocki wrote: > > > On Wednesday 13 January 2010, Américo Wang wrote: > > > > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > > > > This message has been generated automatically as a part of a report > > > > > of recent regressions. > > > > > > > > > > The following bug entry is on the current list of known regressions > > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > > (either way). > > > > > > > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > > > > Subject : Pagemap endless read loop with LTP > > > > > Submitter : Andi Kleen <andi@firstfloor.org> > > > > > Date : 2010-01-10 2:09 (1 days old) > > > > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > > > > > > > > > > According to Andi's later reply, it shoud not be an endless loop, > > > > it just takes a rather long time. > > > > > > Andi? > > > > It'll try to read 47 bits worth of 0s on 64bit x86-64. > > > > I haven't tried to wait until that finishes, but I estimate a few months of > > CPU time at least. > > > > The interface is just misdesigned, but I guess we cannot do > > anything about that for now. > > It's perfectly sensible. What's not sensible is reading the entirety of > everything you find in /proc, something that just about every Linux > admin figures out moments after running their first recursive grep. > > > LTP will just need to do a workaround. > > Or they could actually, you know, add a test of pagemap. Not much chance > of that, though - CVS reports it took them until 2005 to figure out that > skipping /proc/kcore was a good idea. Closing as "documented". Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #15041] Pagemap endless read loop with LTP @ 2010-01-14 20:38 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-14 20:38 UTC (permalink / raw) To: Matt Mackall Cc: Andi Kleen, Américo Wang, Linux Kernel Mailing List, Kernel Testers List On Thursday 14 January 2010, Matt Mackall wrote: > On Thu, 2010-01-14 at 00:50 +0100, Andi Kleen wrote: > > On Wed, Jan 13, 2010 at 10:57:34PM +0100, Rafael J. Wysocki wrote: > > > On Wednesday 13 January 2010, Américo Wang wrote: > > > > On Mon, Jan 11, 2010 at 6:32 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > > > > > This message has been generated automatically as a part of a report > > > > > of recent regressions. > > > > > > > > > > The following bug entry is on the current list of known regressions > > > > > from 2.6.32. Please verify if it still should be listed and let me know > > > > > (either way). > > > > > > > > > > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15041 > > > > > Subject : Pagemap endless read loop with LTP > > > > > Submitter : Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> > > > > > Date : 2010-01-10 2:09 (1 days old) > > > > > References : http://marc.info/?l=linux-kernel&m=126308941423848&w=4 > > > > > > > > > > > > > According to Andi's later reply, it shoud not be an endless loop, > > > > it just takes a rather long time. > > > > > > Andi? > > > > It'll try to read 47 bits worth of 0s on 64bit x86-64. > > > > I haven't tried to wait until that finishes, but I estimate a few months of > > CPU time at least. > > > > The interface is just misdesigned, but I guess we cannot do > > anything about that for now. > > It's perfectly sensible. What's not sensible is reading the entirety of > everything you find in /proc, something that just about every Linux > admin figures out moments after running their first recursive grep. > > > LTP will just need to do a workaround. > > Or they could actually, you know, add a test of pagemap. Not much chance > of that, though - CVS reports it took them until 2005 to figure out that > skipping /proc/kcore was a good idea. Closing as "documented". Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15039] leds_alix2: can't allocate I/O for GPIO 2010-01-10 22:27 ` Rafael J. Wysocki ` (31 preceding siblings ...) (?) @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Arnd Hannemann, Daniel Mack This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15039 Subject : leds_alix2: can't allocate I/O for GPIO Submitter : Arnd Hannemann <hannemann@nets.rwth-aachen.de> Date : 2010-01-07 10:26 (4 days old) References : http://marc.info/?l=linux-kernel&m=126286001106257&w=4 Handled-By : Daniel Mack <daniel@caiaq.de> Patch : http://patchwork.kernel.org/patch/72006/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15038] drm/ksm: fbdev blanking regression 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-10 22:32 ` Rafael J. Wysocki -1 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Airlie, James Simmons, Johan Hovold This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15038 Subject : drm/ksm: fbdev blanking regression Submitter : Johan Hovold <jhovold@gmail.com> Date : 2010-01-06 17:00 (5 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=731b5a15a3b1474a41c2ca29b4c32b0f21bc852e References : http://marc.info/?l=linux-kernel&m=126279726418748&w=4 Handled-By : James Simmons <jsimmons@infradead.org> ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #15038] drm/ksm: fbdev blanking regression @ 2010-01-10 22:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-10 22:32 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Dave Airlie, James Simmons, Johan Hovold This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15038 Subject : drm/ksm: fbdev blanking regression Submitter : Johan Hovold <jhovold-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Date : 2010-01-06 17:00 (5 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=731b5a15a3b1474a41c2ca29b4c32b0f21bc852e References : http://marc.info/?l=linux-kernel&m=126279726418748&w=4 Handled-By : James Simmons <jsimmons-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: 2.6.33-rc3-git3: Reported regressions from 2.6.32 2010-01-10 22:27 ` Rafael J. Wysocki ` (33 preceding siblings ...) (?) @ 2010-01-11 16:00 ` Luis R. Rodriguez -1 siblings, 0 replies; 248+ messages in thread From: Luis R. Rodriguez @ 2010-01-11 16:00 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Adrian Bunk, DRI, Linux SCSI List, Network Development, Linux Wireless List, Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List On Sun, Jan 10, 2010 at 2:27 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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. > Of these only the one below was wireless, which is actually fixed now. Not bad, rc3 and no wireless regressions yet. > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 > Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 > Submitter : Joshua Covington <joshuacov@googlemail.com> > Date : 2009-12-25 00:49 (17 days old) > Handled-By : Luis R. Rodriguez <mcgrof@gmail.com> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 Luis _______________________________________________ linux-pm mailing list linux-pm@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/linux-pm ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: 2.6.33-rc3-git3: Reported regressions from 2.6.32 2010-01-10 22:27 ` Rafael J. Wysocki @ 2010-01-11 16:00 ` Luis R. Rodriguez -1 siblings, 0 replies; 248+ messages in thread From: Luis R. Rodriguez @ 2010-01-11 16:00 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI On Sun, Jan 10, 2010 at 2:27 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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. > Of these only the one below was wireless, which is actually fixed now. Not bad, rc3 and no wireless regressions yet. > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 > Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 > Submitter : Joshua Covington <joshuacov@googlemail.com> > Date : 2009-12-25 00:49 (17 days old) > Handled-By : Luis R. Rodriguez <mcgrof@gmail.com> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 Luis ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: 2.6.33-rc3-git3: Reported regressions from 2.6.32 @ 2010-01-11 16:00 ` Luis R. Rodriguez 0 siblings, 0 replies; 248+ messages in thread From: Luis R. Rodriguez @ 2010-01-11 16:00 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI On Sun, Jan 10, 2010 at 2:27 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote: > This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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. > Of these only the one below was wireless, which is actually fixed now. Not bad, rc3 and no wireless regressions yet. > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14874 > Subject : Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 > Submitter : Joshua Covington <joshuacov@googlemail.com> > Date : 2009-12-25 00:49 (17 days old) > Handled-By : Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Patch : http://bugzilla.kernel.org/attachment.cgi?id=24335 Luis ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: 2.6.33-rc3-git3: Reported regressions from 2.6.32 2010-01-10 22:27 ` Rafael J. Wysocki ` (35 preceding siblings ...) (?) @ 2010-01-11 21:47 ` Nick Bowler 2010-01-11 22:10 ` Rafael J. Wysocki 2010-01-11 22:10 ` Rafael J. Wysocki -1 siblings, 2 replies; 248+ messages in thread From: Nick Bowler @ 2010-01-11 21:47 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI On 23:27 Sun 10 Jan , Rafael J. Wysocki wrote: > This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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. Here are two that I don't see in the list: * LVDS downclocking breaks on G45/thinkpad T500 LKML: http://lkml.org/lkml/2009/12/26/40 FDO: http://bugs.freedesktop.org/show_bug.cgi?id=25809 * Receive failure in et131x (Alan Cox sent me a patch for this but it's not in mainline yet) LKML: http://lkml.org/lkml/2009/12/29/210 -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: 2.6.33-rc3-git3: Reported regressions from 2.6.32 2010-01-11 21:47 ` Nick Bowler @ 2010-01-11 22:10 ` Rafael J. Wysocki 2010-01-11 22:10 ` Rafael J. Wysocki 1 sibling, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 22:10 UTC (permalink / raw) To: Nick Bowler Cc: Adrian Bunk, DRI, Linux SCSI List, Network Development, Linux Wireless List, Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List On Monday 11 January 2010, Nick Bowler wrote: > On 23:27 Sun 10 Jan , Rafael J. Wysocki wrote: > > This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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. > > Here are two that I don't see in the list: > > * LVDS downclocking breaks on G45/thinkpad T500 > > LKML: http://lkml.org/lkml/2009/12/26/40 > FDO: http://bugs.freedesktop.org/show_bug.cgi?id=25809 Added this one. > * Receive failure in et131x (Alan Cox sent me a patch for this but > it's not in mainline yet) > > LKML: http://lkml.org/lkml/2009/12/29/210 This one is a staging driver, so I'm not going to list it. Thanks, Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: 2.6.33-rc3-git3: Reported regressions from 2.6.32 2010-01-11 21:47 ` Nick Bowler 2010-01-11 22:10 ` Rafael J. Wysocki @ 2010-01-11 22:10 ` Rafael J. Wysocki 1 sibling, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-11 22:10 UTC (permalink / raw) To: Nick Bowler Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI On Monday 11 January 2010, Nick Bowler wrote: > On 23:27 Sun 10 Jan , Rafael J. Wysocki wrote: > > This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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. > > Here are two that I don't see in the list: > > * LVDS downclocking breaks on G45/thinkpad T500 > > LKML: http://lkml.org/lkml/2009/12/26/40 > FDO: http://bugs.freedesktop.org/show_bug.cgi?id=25809 Added this one. > * Receive failure in et131x (Alan Cox sent me a patch for this but > it's not in mainline yet) > > LKML: http://lkml.org/lkml/2009/12/29/210 This one is a staging driver, so I'm not going to list it. Thanks, Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: 2.6.33-rc3-git3: Reported regressions from 2.6.32 2010-01-10 22:27 ` Rafael J. Wysocki ` (36 preceding siblings ...) (?) @ 2010-01-11 21:47 ` Nick Bowler -1 siblings, 0 replies; 248+ messages in thread From: Nick Bowler @ 2010-01-11 21:47 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Adrian Bunk, DRI, Linux SCSI List, Network Development, Linux Wireless List, Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List On 23:27 Sun 10 Jan , Rafael J. Wysocki wrote: > This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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. Here are two that I don't see in the list: * LVDS downclocking breaks on G45/thinkpad T500 LKML: http://lkml.org/lkml/2009/12/26/40 FDO: http://bugs.freedesktop.org/show_bug.cgi?id=25809 * Receive failure in et131x (Alan Cox sent me a patch for this but it's not in mainline yet) LKML: http://lkml.org/lkml/2009/12/29/210 -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ^ permalink raw reply [flat|nested] 248+ messages in thread
* 2.6.33-rc5: Reported regressions from 2.6.32 @ 2010-01-24 21:54 Rafael J. Wysocki 2010-01-24 22:04 ` Rafael J. Wysocki 0 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-24 21:54 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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 ---------------------------------------- 2010-01-24 75 29 23 2010-01-10 55 33 21 2009-12-29 36 34 27 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15139 Subject : e1000: transmit queue 0 timed out Submitter : Alexander Beregalov <a.beregalov@gmail.com> Date : 2010-01-23 15:37 (2 days old) References : http://marc.info/?l=linux-netdev&m=126426149306083&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15138 Subject : evdev regression on macbook Submitter : Guillaume Chazarain <guichaz@gmail.com> Date : 2010-01-23 18:53 (2 days old) References : http://marc.info/?l=linux-kernel&m=126427286219235&w=4 Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15133 Subject : Wake on LAN doesn't work in sky2 Submitter : Tino Keitel <tino.keitel@tikei.de> Date : 2010-01-15 9:10 (10 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=166a0fd4c788ec7f10ca8194ec6d526afa12db75 References : http://marc.info/?l=linux-kernel&m=126354704815848&w=4 Handled-By : Stephen Hemminger <shemminger@vyatta.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15132 Subject : OOPS's with large initramfs Submitter : Nigel Kukard <nkukard@lbsd.net> Date : 2010-01-16 11:12 (9 days old) References : http://marc.info/?l=linux-kernel&m=126364100321603&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15129 Subject : [drm:i915_gem_execbuffer] *ERROR* i915_gem_do_execbuffer returns -512 Submitter : Miles Lane <miles.lane@gmail.com> Date : 2010-01-14 23:18 (11 days old) References : http://lkml.org/lkml/2010/1/14/570 Handled-By : Chris Wilson <chris@chris-wilson.co.uk> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15126 Subject : REGRESSION for RT2561/RT61 in 2.6.33 Submitter : Alan Stern <stern@rowland.harvard.edu> Date : 2010-01-11 14:54 (14 days old) References : http://marc.info/?l=linux-kernel&m=126322167427159&w=4 Handled-By : Johannes Berg <johannes@sipsolutions.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15125 Subject : hung task - jbd2/dm-1-8 (during raid rebuild) Submitter : Michael Breuer <mbreuer@majjas.com> Date : 2010-01-10 21:47 (15 days old) References : http://marc.info/?l=linux-kernel&m=126316012025978&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15124 Subject : PCI host bridge windows ignored (works with pci=use_crs) Submitter : Jeff Garrett <jeff@jgarrett.org> Date : 2010-01-13 5:37 (12 days old) References : http://marc.info/?l=linux-kernel&m=126336296600307&w=4 Handled-By : Yinghai Lu <yinghai@kernel.org> Bjorn Helgaas <bjorn.helgaas@hp.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15076 Subject : System panic under load with clockevents_program_event Submitter : okias <d.okias@gmail.com> Date : 2010-01-17 13:03 (8 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 Submitter : Soeren Sonnenburg <sonne@debian.org> Date : 2010-01-10 20:09 (15 days old) References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15038 Subject : drm/ksm: fbdev blanking regression Submitter : Johan Hovold <jhovold@gmail.com> Date : 2010-01-06 17:00 (19 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=731b5a15a3b1474a41c2ca29b4c32b0f21bc852e References : http://marc.info/?l=linux-kernel&m=126279726418748&w=4 Handled-By : James Simmons <jsimmons@infradead.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036 Subject : soft lockup in dmesg after suspend/resume Submitter : ykzhao <yakui.zhao@intel.com> Date : 2010-01-04 5:36 (21 days old) References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15032 Subject : Oops in uart_resume_port() on resume Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2010-01-04 15:47 (21 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba15ab0e8de0d4439a91342ad52d55ca9e313f3d References : http://marc.info/?l=linux-kernel&m=126262008815689&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15025 Subject : Oops in ext4 driver Submitter : Steinar H. Gunderson <sgunderson@bigfoot.com> Date : 2010-01-10 13:09 (15 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15017 Subject : kexec regression, radeon/kms irq related (bisected) Submitter : Markus Trippelsdorf <markus@trippelsdorf.de> Date : 2010-01-09 18:49 (16 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d8f60cfc93452d0554f6a701aa8e3236cbee4636 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15000 Subject : Thinkpad dock button no longer works Submitter : Paul Martin <pm@debian.org> Date : 2010-01-07 02:11 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14999 Subject : possible circular locking dependency detected in rfkill at suspend Submitter : Christian Casteyde <casteyde.christian@free.fr> Date : 2010-01-06 21:52 (19 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950 Subject : tbench regression with 2.6.33-rc1 Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2009-12-25 11:11 (31 days old) References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce@blueyonder.co.uk> Date : 2009-12-23 16:55 (33 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937 Subject : WARNING: at kernel/lockdep.c:2830 Submitter : Grant Wilson <grant.wilson@zen.co.uk> Date : 2009-12-27 13:35 (29 days old) References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14924 Subject : Weird hard hangs when rendering 'some' web-sites in Firefox Submitter : David <david@unsolicited.net> Date : 2009-12-21 21:53 (35 days old) References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14859 Subject : System timer firing too much without cause Submitter : Shawn Starr <shawn.starr@rogers.com> Date : 2009-12-21 19:16 (35 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792 Subject : Misdetection of the TV output Submitter : Santi <santi@agolina.net> Date : 2009-12-12 13:28 (44 days old) Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15137 Subject : NULL pointer dereference in vlan_skb_recv Submitter : Bruno Prémont <bonbons@linux-vserver.org> Date : 2010-01-23 15:56 (2 days old) References : http://marc.info/?l=linux-kernel&m=126426286507497&w=4 Handled-By : Eric Dumazet <eric.dumazet@gmail.com> Patch : http://patchwork.kernel.org/patch/74999/ http://patchwork.kernel.org/patch/75002/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15131 Subject : [OOPS] radeon kms Submitter : John Kacur <jkacur@redhat.com> Date : 2010-01-15 15:45 (10 days old) References : http://lkml.org/lkml/2010/1/15/129 Handled-By : Jerome Glisse <glisse@freedesktop.org> Patch : http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=patch;h=30d2d9a54d48e4fefede0389ded1b6fc2d44a522 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15128 Subject : Boot regression on AMD Submitter : Gene Heskett <gene.heskett@verizon.net> Date : 2010-01-13 20:21 (12 days old) References : http://marc.info/?l=linux-kernel&m=126341413213017&w=4 Handled-By : Andreas Herrmann <andreas.herrmann3@amd.com> Patch : http://patchwork.kernel.org/patch/74883/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15039 Subject : leds_alix2: can't allocate I/O for GPIO Submitter : Arnd Hannemann <hannemann@nets.rwth-aachen.de> Date : 2010-01-07 10:26 (18 days old) References : http://marc.info/?l=linux-kernel&m=126286001106257&w=4 Handled-By : Daniel Mack <daniel@caiaq.de> Patch : http://patchwork.kernel.org/patch/72006/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:45 (30 days old) References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 Handled-By : Eric W. Biederman <ebiederm@aristanetworks.com> Patch : http://patchwork.kernel.org/patch/70461/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 Subject : Something has been broken in the network stack this week Submitter : Delete This Account <speedyboyinovator@hotmail.com> Date : 2009-12-12 13:06 (44 days old) Handled-By : Ben Hutchings <ben@decadent.org.uk> Patch : http://patchwork.kernel.org/patch/72073/ 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 from 2.6.32, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=14885 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU 2010-01-24 21:54 2.6.33-rc5: " Rafael J. Wysocki @ 2010-01-24 22:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-24 22:04 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Sid Boyce This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce@blueyonder.co.uk> Date : 2009-12-23 16:55 (33 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU @ 2010-01-24 22:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-24 22:04 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Sid Boyce This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org> Date : 2009-12-23 16:55 (33 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU 2010-01-24 22:04 ` Rafael J. Wysocki @ 2010-01-25 1:41 ` Sid Boyce -1 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-25 1:41 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On 24/01/10 22:04, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 > Subject : All kernels after 2.6.32-git10 show only 1 CPU > Submitter : Sid Boyce <sboyce@blueyonder.co.uk> > Date : 2009-12-23 16:55 (33 days old) > References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 > > > Definitely fixed in 2.6.33-rc4, thanks. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU @ 2010-01-25 1:41 ` Sid Boyce 0 siblings, 0 replies; 248+ messages in thread From: Sid Boyce @ 2010-01-25 1:41 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List On 24/01/10 22:04, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.32. Please verify if it still should be listed and let me know > (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 > Subject : All kernels after 2.6.32-git10 show only 1 CPU > Submitter : Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org> > Date : 2009-12-23 16:55 (33 days old) > References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 > > > Definitely fixed in 2.6.33-rc4, thanks. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU @ 2010-01-25 21:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-25 21:04 UTC (permalink / raw) To: sboyce; +Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 25 January 2010, Sid Boyce wrote: > On 24/01/10 22:04, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 > > Subject : All kernels after 2.6.32-git10 show only 1 CPU > > Submitter : Sid Boyce <sboyce@blueyonder.co.uk> > > Date : 2009-12-23 16:55 (33 days old) > > References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 > > > > > > > > Definitely fixed in 2.6.33-rc4, thanks. Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU @ 2010-01-25 21:04 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2010-01-25 21:04 UTC (permalink / raw) To: sboyce-QgLWrMLu8clzjhtm8Ag3mw Cc: Linux Kernel Mailing List, Kernel Testers List On Monday 25 January 2010, Sid Boyce wrote: > On 24/01/10 22:04, Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 > > Subject : All kernels after 2.6.32-git10 show only 1 CPU > > Submitter : Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org> > > Date : 2009-12-23 16:55 (33 days old) > > References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 > > > > > > > > Definitely fixed in 2.6.33-rc4, thanks. Thanks, closed. Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* 2.6.33-rc2: Reported regressions from 2.6.32 @ 2009-12-29 15:05 Rafael J. Wysocki 2009-12-29 15:10 ` [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU Rafael J. Wysocki 0 siblings, 1 reply; 248+ messages in thread From: Rafael J. Wysocki @ 2009-12-29 15:05 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI [NOTES: * There you go, another round of tracking regressions. It's not too bad at the moment, as far as the regressions from 2.6.32 are concerned, but we have quite a few -stable regressions, apparently in the DRI area. * Regressions from 2.6.31 are still being reported.] This message contains a list of some regressions from 2.6.32, 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 from 2.6.32, 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-12-29 36 34 27 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14952 Subject : instant reboot on loading 2.6.33-rc on Celeron 900 Submitter : Meelis Roos <mroos@linux.ee> Date : 2009-12-29 13:57 (1 days old) References : http://marc.info/?l=linux-kernel&m=126209508500393&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950 Subject : tbench regression with 2.6.33-rc1 Submitter : Lin Ming <ming.m.lin@intel.com> Date : 2009-12-25 11:11 (5 days old) References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14949 Subject : drm_vm.c:drm_mmap: possible circular locking dependency detected Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:45 (4 days old) References : http://marc.info/?l=linux-kernel&m=126182073616279&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14948 Subject : EHCI resume sysfs duplicates Submitter : Borislav Petkov <petkovbb@googlemail.com> Date : 2009-12-26 9:36 (4 days old) References : http://marc.info/?l=linux-kernel&m=126182020615709&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14947 Subject : Blank screen for Intel KMS Submitter : Miguel Calleja <mcalleja1@telecable.es> Date : 2009-12-25 13:10 (5 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fc816655236cd9da162356e96e74c7cfb0834d92 References : http://marc.info/?l=linux-kernel&m=126174693019098&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce@blueyonder.co.uk> Date : 2009-12-23 16:55 (7 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14942 Subject : gkrellm no longer shows all the temperatures on thinkpad x60 Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-12-27 21:57 (3 days old) References : http://marc.info/?l=linux-kernel&m=126195107005565&w=4 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14940 Subject : cfq-iosched: tiobench regression Submitter : Shaohua Li <shaohua.li@intel.com> Date : 2009-12-24 0:55 (6 days old) References : http://marc.info/?l=linux-kernel&m=126161612401994&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14938 Subject : Unable to handle kernel paging request in radeon_fence_signaled Submitter : Grant Wilson <grant.wilson@zen.co.uk> Date : 2009-12-27 13:40 (3 days old) References : http://marc.info/?l=linux-kernel&m=126192123104047&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937 Subject : WARNING: at kernel/lockdep.c:2830 Submitter : Grant Wilson <grant.wilson@zen.co.uk> Date : 2009-12-27 13:35 (3 days old) References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14936 Subject : kernel BUG at fs/ext4/inode.c:1063 if attempted to use non-ext4 partition with ext4 Submitter : Gene Heskett <gene.heskett@verizon.net> Date : 2009-12-26 14:13 (4 days old) References : http://marc.info/?l=linux-kernel&m=126183682330809&w=4 http://marc.info/?l=linux-kernel&m=126169372613898&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14934 Subject : kernel crash during boot Submitter : werner <w.landgraf@ru.ru> Date : 2009-12-25 5:37 (5 days old) References : http://marc.info/?l=linux-kernel&m=126171951030608&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14925 Subject : sky2 panic under load Submitter : Berck E. Nash <flyboy@gmail.com> Date : 2009-12-21 23:52 (9 days old) References : http://marc.info/?l=linux-kernel&m=126143955730347&w=4 http://marc.info/?l=linux-kernel&m=126160893126548&w=4 Handled-By : Stephen Hemminger <shemminger@vyatta.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14924 Subject : Weird hard hangs when rendering 'some' web-sites in Firefox Submitter : David <david@unsolicited.net> Date : 2009-12-21 21:53 (9 days old) References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14923 Subject : Regression in 2.6.32.2: segfault on halt Submitter : Holger Hoffstaette <holger.hoffstaette@googlemail.com> Date : 2009-12-19 15:10 (11 days old) References : http://marc.info/?l=linux-kernel&m=126123574505069&w=4 Handled-By : Mike Galbraith <efault@gmx.de> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14910 Subject : Stable version 2.6.32.2 broke my KMS Radeon setup Submitter : Ruud Linders <kernelml@xs4all.nl> Date : 2009-12-20 12:02 (10 days old) References : http://marc.info/?l=linux-kernel&m=126131105608871&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14909 Subject : pata_cmd64x broken in 2.6.33-rc1 Submitter : Meelis Roos <mroos@linux.ee> Date : 2009-12-19 22:23 (11 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d43744390e460dce6626fb8de2c02a24ff650005 References : http://marc.info/?l=linux-kernel&m=126126142501594&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14908 Subject : 256MB CF card no longer recognized in PCMCIA slot Submitter : Pavel Machek <pavel@ucw.cz> Date : 2009-12-19 21:55 (11 days old) References : http://marc.info/?l=linux-kernel&m=126125973632173&w=4 Handled-By : Dominik Brodowski <linux@dominikbrodowski.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14907 Subject : Commit "kbuild: fix bzImage build for x86" breaks build Submitter : Oliver Hartkopp <oliver@hartkopp.net> Date : 2009-12-19 19:21 (11 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a2ff67c88211026afcbdbc190c13f705dae1b59 References : http://marc.info/?l=linux-kernel&m=126125050622195&w=4 http://marc.info/?l=linux-kernel&m=126114565103300&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14904 Subject : slab: possible recursive locking detected Submitter : Heiko Carstens <heiko.carstens@de.ibm.com> Date : 2009-12-18 11:58 (12 days old) References : http://marc.info/?l=linux-kernel&m=126113754023909&w=4 Handled-By : Pekka Enberg <penberg@cs.helsinki.fi> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14901 Subject : bisected crash due to "x86: Move swiotlb initialization before dma32_free_bootmem" Submitter : Roland Dreier <rdreier@cisco.com> Date : 2009-12-15 7:47 (15 days old) References : http://marc.info/?l=linux-kernel&m=126086324302061&w=4 Handled-By : FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Yinghai Lu <yinghai@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14900 Subject : drm_i915 error Submitter : Tarkan Erimer <tarkane@netone.com.tr> Date : 2009-12-14 12:50 (16 days old) References : http://marc.info/?l=linux-kernel&m=126079504930147&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14890 Subject : [WMI?] boot hang Submitter : Maciej Rutecki <maciej.rutecki@gmail.com> Date : 2009-12-25 10:10 (5 days old) First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3e9b988e4edf065d39c1343937f717319b1c1065 References : http://marc.info/?l=linux-kernel&m=126173586309724&w=4 http://marc.info/?l=linux-kernel&m=126170348921630&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14887 Subject : suspend doesn't work on X200s Submitter : Andrew Lutomirski <luto@mit.edu> Date : 2009-12-22 0:45 (8 days old) References : http://marc.info/?l=linux-kernel&m=126144274102396&w=4 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14844 Subject : No more wireless interface eth1 after boot Submitter : Christian Casteyde <casteyde.christian@free.fr> Date : 2009-12-19 16:33 (11 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792 Subject : Misdetection of the TV output Submitter : Santi <santi@agolina.net> Date : 2009-12-12 13:28 (18 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14791 Subject : Something has been broken in the network stack this week Submitter : Delete This Account <speedyboyinovator@hotmail.com> Date : 2009-12-12 13:06 (18 days old) Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14951 Subject : lockdep possible recursive lock in slab parent->list->rlock Submitter : Andi Kleen <andi@firstfloor.org> Date : 2009-12-27 12:06 (3 days old) References : http://marc.info/?l=linux-kernel&m=126191560531463&w=4 Handled-By : Pekka Enberg <penberg@cs.helsinki.fi> Patch : http://patchwork.kernel.org/patch/69829/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14944 Subject : 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine Submitter : fengxiangjun <fengxiangjun@neusoft.com> Date : 2009-12-21 11:12 (9 days old) References : http://marc.info/?l=linux-kernel&m=126139442328314&w=4 Handled-By : Tejun Heo <tj@kernel.org> Patch : http://patchwork.kernel.org/patch/69746/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14941 Subject : agpgart-amd64 not initialized Submitter : Marin Mitov <mitov@issp.bas.bg> Date : 2009-12-27 15:19 (3 days old) References : http://marc.info/?l=linux-kernel&m=126192729110083&w=4 Handled-By : FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Patch : http://patchwork.kernel.org/patch/69956/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14935 Subject : hd-audio0 eats 25% CPU (according to top) Submitter : Sergei Trofimovich <slyich@gmail.com> Date : 2009-12-25 10:21 (5 days old) References : http://marc.info/?l=linux-kernel&m=126173644210280&w=4 Handled-By : Takashi Iwai <tiwai@suse.de> Patch : http://patchwork.kernel.org/patch/69747/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14906 Subject : boot problem bisected to commit 99935a7a59 Submitter : Vincent ETIENNE <ve@vetienne.net> Date : 2009-12-19 16:07 (11 days old) References : http://marc.info/?l=linux-kernel&m=126123946509316&w=4 Handled-By : Yinghai Lu <yinghai@kernel.org> Patch : http://patchwork.kernel.org/patch/68941/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14899 Subject : reiserfs: inconsistent lock state Submitter : Alexander Beregalov <a.beregalov@gmail.com> Date : 2009-12-11 22:06 (19 days old) References : http://marc.info/?l=linux-kernel&m=126056920702515&w=4 Handled-By : Frederic Weisbecker <fweisbec@gmail.com> Patch : http://patchwork.kernel.org/patch/67256/ http://patchwork.kernel.org/patch/67257/ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14846 Subject : acer-wmi kernel OOPS, cannot create duplicit sysfs name Submitter : Oldřich Jedlička <oldium.pro@seznam.cz> Date : 2009-12-19 23:44 (11 days old) Handled-By : Carlos Corbacho <carlos@strangeworlds.co.uk> Patch : http://patchwork.kernel.org/patch/69795/ 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 from 2.6.32, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=14885 Please let me know if there are any Bugzilla entries that should be added to the list in there. Thanks, Rafael ^ permalink raw reply [flat|nested] 248+ messages in thread
* [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU 2009-12-29 15:05 2.6.33-rc2: Reported regressions from 2.6.32 Rafael J. Wysocki @ 2009-12-29 15:10 ` Rafael J. Wysocki 0 siblings, 0 replies; 248+ messages in thread From: Rafael J. Wysocki @ 2009-12-29 15:10 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Sid Boyce This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14946 Subject : All kernels after 2.6.32-git10 show only 1 CPU Submitter : Sid Boyce <sboyce@blueyonder.co.uk> Date : 2009-12-23 16:55 (7 days old) References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4 ^ permalink raw reply [flat|nested] 248+ messages in thread
end of thread, other threads:[~2010-02-02 21:06 UTC | newest]
Thread overview: 248+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-10 22:27 2.6.33-rc3-git3: Reported regressions from 2.6.32 Rafael J. Wysocki
2010-01-10 22:27 ` Rafael J. Wysocki
2010-01-10 22:27 ` [Bug #14791] Something has been broken in the network stack this week Rafael J. Wysocki
2010-01-10 22:27 ` Rafael J. Wysocki
2010-01-10 22:46 ` Ben Hutchings
2010-01-10 22:58 ` Rafael J. Wysocki
2010-01-10 22:58 ` Rafael J. Wysocki
2010-01-28 23:18 ` [PATCH net-2.6] cdc_ether: Partially revert "usbnet: Set link down initially ..." Ben Hutchings
2010-01-29 5:37 ` David Miller
2010-01-10 22:32 ` [Bug #14792] Misdetection of the TV output Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14860] No DP-DVI output when laptop is docked Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-12 16:14 ` Pär Andersson
2010-01-12 16:14 ` Pär Andersson
2010-01-12 22:03 ` Rafael J. Wysocki
2010-01-12 22:03 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14874] Ath5k regression with commit 8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 Rafael J. Wysocki
2010-01-11 15:05 ` Luis R. Rodriguez
2010-01-11 15:05 ` Luis R. Rodriguez
2010-01-11 20:01 ` Rafael J. Wysocki
2010-01-11 20:01 ` Rafael J. Wysocki
2010-01-11 20:05 ` Luis R. Rodriguez
2010-01-11 20:05 ` Luis R. Rodriguez
2010-01-10 22:32 ` [Bug #14899] reiserfs: inconsistent lock state Rafael J. Wysocki
2010-01-10 22:49 ` Frederic Weisbecker
2010-01-10 22:49 ` Frederic Weisbecker
2010-01-10 23:02 ` Rafael J. Wysocki
2010-01-10 23:02 ` Rafael J. Wysocki
2010-01-10 23:16 ` Alexander Beregalov
2010-01-10 23:16 ` Alexander Beregalov
2010-01-10 22:32 ` [Bug #14859] System timer firing too much without cause Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-11 3:22 ` Shawn Starr
[not found] ` <201001102222.19700.shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org>
2010-01-11 19:59 ` Rafael J. Wysocki
2010-01-11 3:28 ` Shawn Starr
2010-01-10 22:32 ` [Bug #14924] Weird hard hangs when rendering 'some' web-sites in Firefox Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14907] Commit "kbuild: fix bzImage build for x86" breaks build Rafael J. Wysocki
2010-01-11 1:36 ` Jonathan Nieder
2010-01-11 1:36 ` Jonathan Nieder
2010-01-11 20:02 ` Rafael J. Wysocki
2010-01-11 20:02 ` Rafael J. Wysocki
2010-01-12 9:01 ` Oliver Hartkopp
2010-01-13 12:33 ` Michal Marek
2010-01-13 12:33 ` Michal Marek
2010-01-14 11:05 ` Michal Marek
2010-01-14 11:05 ` Michal Marek
2010-01-14 20:35 ` Rafael J. Wysocki
2010-01-14 20:35 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14934] kernel crash during boot Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14937] WARNING: at kernel/lockdep.c:2830 Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14925] sky2 panic under load Rafael J. Wysocki
2010-01-11 0:36 ` Berck E. Nash
2010-01-11 13:26 ` Jarek Poplawski
2010-01-11 19:32 ` Rafael J. Wysocki
2010-01-11 20:31 ` Jarek Poplawski
2010-01-11 20:50 ` Rafael J. Wysocki
2010-01-11 21:02 ` Berck E. Nash
2010-01-11 21:47 ` Jarek Poplawski
2010-01-11 14:03 ` Mike McCormack
2010-01-11 16:45 ` Stephen Hemminger
2010-01-11 22:07 ` Jarek Poplawski
2010-01-12 0:14 ` David Miller
2010-01-12 7:50 ` Jarek Poplawski
2010-01-12 8:08 ` David Miller
2010-01-12 8:56 ` Jarek Poplawski
2010-01-12 9:42 ` David Miller
2010-01-12 10:31 ` Jarek Poplawski
2010-01-12 10:56 ` David Miller
2010-01-12 11:04 ` Jarek Poplawski
2010-01-12 15:39 ` Stephen Hemminger
2010-01-12 16:15 ` [PATCH] sky2: safer transmit ring cleaning Stephen Hemminger
2010-01-12 16:32 ` Michael Breuer
2010-01-12 17:02 ` Stephen Hemminger
2010-01-12 18:04 ` Jarek Poplawski
2010-01-12 18:13 ` Stephen Hemminger
2010-01-12 18:24 ` Jarek Poplawski
2010-01-12 18:49 ` [PATCH] sky2: safer transmit ring cleaning (v2) Stephen Hemminger
2010-01-12 19:16 ` Jarek Poplawski
2010-01-12 19:23 ` Stephen Hemminger
2010-01-12 19:50 ` Jarek Poplawski
2010-01-13 1:23 ` Stephen Hemminger
2010-01-12 19:34 ` Michael Breuer
2010-01-12 18:35 ` [PATCH] sky2: safer transmit ring cleaning Michael Breuer
2010-01-12 18:42 ` Michael Breuer
2010-01-12 20:31 ` Michael Breuer
2010-01-13 4:10 ` [PATCH] sky2: safer transmit ring cleaning (v3) Stephen Hemminger
2010-01-13 4:31 ` Michael Breuer
2010-01-13 7:35 ` Jarek Poplawski
2010-01-13 16:04 ` Michael Breuer
2010-01-14 3:41 ` [PATCH] sky2: safer transmit ring cleaning (v4) Stephen Hemminger
2010-01-14 10:14 ` Jarek Poplawski
2010-01-14 11:16 ` Jarek Poplawski
2010-01-14 11:20 ` David Miller
2010-01-14 11:26 ` Jarek Poplawski
2010-01-14 13:19 ` Mike McCormack
2010-01-14 15:43 ` Michael Breuer
2010-01-14 16:46 ` Michael Breuer
2010-01-14 17:51 ` Stephen Hemminger
2010-01-14 17:52 ` Stephen Hemminger
2010-01-14 23:51 ` Michael Breuer
2010-01-16 18:35 ` sky2 DHCPOFFER packet loss under load (Was Re: [PATCH] sky2: safer transmit ring cleaning (v4)) Michael Breuer
2010-01-14 15:46 ` [PATCH] sky2: safer transmit ring cleaning (v4) Michael Breuer
2010-01-11 22:31 ` [Bug #14925] sky2 panic under load Jarek Poplawski
2010-01-10 22:32 ` [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU Rafael J. Wysocki
2010-01-11 3:39 ` Sid Boyce
2010-01-11 3:39 ` Sid Boyce
2010-01-11 20:04 ` Rafael J. Wysocki
2010-01-15 1:24 ` HDA Intel Audio hang on boot Sid Boyce
2010-01-15 1:24 ` Sid Boyce
2010-01-15 16:01 ` Sid Boyce
2010-01-16 16:44 ` Sid Boyce
2010-01-16 16:44 ` Sid Boyce
2010-01-25 1:48 ` Sid Boyce
2010-01-25 1:48 ` Sid Boyce
2010-01-25 21:39 ` Rafael J. Wysocki
2010-01-25 21:39 ` Rafael J. Wysocki
2010-01-25 21:54 ` Takashi Iwai
2010-01-25 21:54 ` Takashi Iwai
2010-01-25 21:55 ` Takashi Iwai
2010-01-26 0:59 ` Sid Boyce
2010-01-26 0:59 ` Sid Boyce
2010-01-26 6:40 ` Takashi Iwai
2010-01-26 6:58 ` Takashi Iwai
2010-01-26 6:58 ` Takashi Iwai
2010-01-26 12:02 ` Sid Boyce
2010-01-26 12:02 ` Sid Boyce
2010-01-26 12:51 ` Rafael J. Wysocki
2010-01-26 13:18 ` Sid Boyce
2010-01-26 12:55 ` Takashi Iwai
2010-01-26 12:55 ` Takashi Iwai
2010-01-26 13:44 ` Sid Boyce
2010-01-26 13:44 ` Sid Boyce
2010-01-26 13:48 ` Takashi Iwai
2010-01-26 13:48 ` Takashi Iwai
2010-01-26 18:22 ` Rafael J. Wysocki
2010-01-26 18:22 ` Rafael J. Wysocki
2010-01-26 20:25 ` Takashi Iwai
2010-01-26 20:25 ` Takashi Iwai
2010-01-26 20:56 ` Sid Boyce
2010-01-26 20:56 ` Sid Boyce
2010-01-26 20:58 ` Sid Boyce
2010-01-26 20:58 ` Sid Boyce
2010-01-27 0:56 ` Rafael J. Wysocki
2010-01-27 2:40 ` Sid Boyce
2010-01-27 2:40 ` Sid Boyce
2010-01-27 6:42 ` Takashi Iwai
2010-01-27 17:17 ` Sid Boyce
2010-01-27 19:29 ` Takashi Iwai
2010-01-27 19:29 ` Takashi Iwai
2010-01-27 22:14 ` Sid Boyce
2010-01-10 22:32 ` [Bug #14948] EHCI resume sysfs duplicates Rafael J. Wysocki
2010-01-11 6:05 ` Borislav Petkov
2010-01-11 6:05 ` Borislav Petkov
2010-01-11 20:06 ` Rafael J. Wysocki
2010-01-11 20:06 ` Rafael J. Wysocki
2010-01-11 22:41 ` Borislav Petkov
2010-01-11 22:41 ` Borislav Petkov
2010-01-11 23:08 ` Rafael J. Wysocki
2010-01-11 23:08 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14942] gkrellm no longer shows all the temperatures on thinkpad x60 Rafael J. Wysocki
2010-01-11 9:40 ` Henrique de Moraes Holschuh
2010-01-11 20:02 ` Rafael J. Wysocki
2010-01-11 20:02 ` Rafael J. Wysocki
2010-02-01 10:48 ` Pavel Machek
2010-02-01 10:48 ` Pavel Machek
2010-02-02 21:06 ` Rafael J. Wysocki
2010-02-02 21:06 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14944] 2.6.32.2 SATA link detect failed, 2.6.32.1 works fine Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected Rafael J. Wysocki
2010-01-11 6:11 ` Borislav Petkov
2010-01-11 6:11 ` Borislav Petkov
2010-01-11 20:06 ` Rafael J. Wysocki
2010-01-11 20:06 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14957] Blank screen with KMS enabled Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14954] warning from alloc_pages_nodemask on boot -- caused by commit 78f1699659963fff97975df44db6d5dbe7218e55 Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14950] tbench regression with 2.6.33-rc1 Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14974] tg3 does not resume from hibernation properly on BCM5787M Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15031] bug in fs/btrfs/ordered-data.c:672 Rafael J. Wysocki
2010-01-11 0:38 ` Carlos R. Mafra
2010-01-11 0:38 ` Carlos R. Mafra
2010-01-11 20:11 ` Rafael J. Wysocki
2010-01-11 20:11 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #14976] No sound on snd_hda_codec_via in 2.6.33-rc2 Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15032] Oops in uart_resume_port() on resume Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15026] i915: Resume regression on MSI Wind U100 w/o KMS Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15035] BUG: unable to handle kernel paging request in rs600_gart_set_page() Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15033] drm: gem_object_free without struct_mutex Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-11 23:15 ` Hugh Dickins
2010-01-11 23:15 ` Hugh Dickins
2010-01-11 23:50 ` Rafael J. Wysocki
2010-01-11 23:50 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15034] volano ~30% regression Rafael J. Wysocki
2010-01-11 6:52 ` Mike Galbraith
2010-01-11 6:52 ` Mike Galbraith
2010-01-11 20:08 ` Rafael J. Wysocki
2010-01-12 2:28 ` Mike Galbraith
2010-01-12 2:28 ` Mike Galbraith
2010-01-12 22:06 ` Rafael J. Wysocki
2010-01-12 22:06 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15037] BUG during shutdown - bisected to commit e2912009 Rafael J. Wysocki
2010-01-11 13:12 ` Marc Dionne
2010-01-11 13:12 ` Marc Dionne
2010-01-11 20:10 ` Rafael J. Wysocki
2010-01-11 20:10 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15036] soft lockup in dmesg after suspend/resume Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15043] Display goes off with i915.powersave=1 Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-12 22:31 ` Soeren Sonnenburg
2010-01-12 22:31 ` Soeren Sonnenburg
2010-01-10 22:32 ` [Bug #15041] Pagemap endless read loop with LTP Rafael J. Wysocki
2010-01-13 3:04 ` Américo Wang
2010-01-13 3:04 ` Américo Wang
2010-01-13 21:57 ` Rafael J. Wysocki
2010-01-13 21:57 ` Rafael J. Wysocki
2010-01-13 22:24 ` Matt Mackall
2010-01-13 22:24 ` Matt Mackall
2010-01-13 23:50 ` Andi Kleen
2010-01-14 0:15 ` Matt Mackall
2010-01-14 0:15 ` Matt Mackall
2010-01-14 20:38 ` Rafael J. Wysocki
2010-01-14 20:38 ` Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15039] leds_alix2: can't allocate I/O for GPIO Rafael J. Wysocki
2010-01-10 22:32 ` [Bug #15038] drm/ksm: fbdev blanking regression Rafael J. Wysocki
2010-01-10 22:32 ` Rafael J. Wysocki
2010-01-11 16:00 ` 2.6.33-rc3-git3: Reported regressions from 2.6.32 Luis R. Rodriguez
2010-01-11 16:00 ` Luis R. Rodriguez
2010-01-11 16:00 ` Luis R. Rodriguez
2010-01-11 21:47 ` Nick Bowler
2010-01-11 22:10 ` Rafael J. Wysocki
2010-01-11 22:10 ` Rafael J. Wysocki
2010-01-11 21:47 ` Nick Bowler
-- strict thread matches above, loose matches on Subject: below --
2010-01-24 21:54 2.6.33-rc5: " Rafael J. Wysocki
2010-01-24 22:04 ` [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU Rafael J. Wysocki
2010-01-24 22:04 ` Rafael J. Wysocki
2010-01-25 1:41 ` Sid Boyce
2010-01-25 1:41 ` Sid Boyce
2010-01-25 21:04 ` Rafael J. Wysocki
2010-01-25 21:04 ` Rafael J. Wysocki
2009-12-29 15:05 2.6.33-rc2: Reported regressions from 2.6.32 Rafael J. Wysocki
2009-12-29 15:10 ` [Bug #14946] All kernels after 2.6.32-git10 show only 1 CPU Rafael J. Wysocki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.