This message contains a list of some regressions from 2.6.28, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.28, please let me know
either and I'll add them to the list. Also, please let me know if any of the
entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2009-03-14 124 36 32
2009-03-03 108 33 28
2009-02-24 95 32 24
2009-02-14 85 33 27
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12872
Subject : pwc mmap always fails with EAGAIN
Submitter : Markus <[email protected]>
Date : 2009-03-14 16:42 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123704902201378&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12871
Subject : usb bluetooth crashes system
Submitter : Pavel Machek <[email protected]>
Date : 2009-03-10 11:23 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123668450400940&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12870
Subject : 2.6.29-rc "TKIP: replay detected" regression
Submitter : Hugh Dickins <[email protected]>
Date : 2009-03-11 12:07 (4 days old)
References : http://marc.info/?l=linux-kernel&m=123677337219148&w=4
Handled-By : John W. Linville <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12867
Subject : 2.6.29-rc7 broke r8169 MAC on Thecus n2100 ARM board
Submitter : Mikael Pettersson <[email protected]>
Date : 2009-03-09 20:29 (6 days old)
References : http://marc.info/?l=linux-kernel&m=123663065403760&w=4
Handled-By : Francois Romieu <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject : Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter : Emil Karlson <[email protected]>
Date : 2009-03-12 12:06 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12856
Subject : Thinkpad freezes with X.org and acpi=rsdt
Submitter : Maciej Piechotka <[email protected]>
Date : 2009-03-11 16:46 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12846
Subject : Regression issue with kernel 2.6.29-rc6-git1: high power consumption during sleep
Submitter : Raymond Wooninck <[email protected]>
Date : 2009-03-09 08:18 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12842
Subject : CCMP: replay detected
Submitter : Peter Teoh <[email protected]>
Date : 2009-03-08 07:42 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12836
Subject : 2.6.29-rc breaks STD using Intel 945
Submitter : Rolf Eike Beer <[email protected]>
Date : 2009-03-04 19:20 (11 days old)
References : http://marc.info/?l=linux-kernel&m=123619451406192&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12831
Subject : Hot/Fn Keys do not work EEEPC 1000HE (eeepc_laptop)
Submitter : Matthew <[email protected]>
Date : 2009-03-07 10:05 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12809
Subject : iozone regression with 2.6.29-rc6
Submitter : Lin Ming <[email protected]>
Date : 2009-02-27 9:13 (16 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018
References : http://marc.info/?l=linux-kernel&m=123572630504360&w=4
Handled-By : Wu Fengguang <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12808
Subject : Suspend regression with 2.6.29-rc
Submitter : Tino Keitel <[email protected]>
Date : 2009-02-24 19:08 (19 days old)
References : http://marc.info/?l=linux-kernel&m=123550257312112&w=4
Handled-By : Rafael J. Wysocki <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12806
Subject : i915 broken STR
Submitter : Harvey Harrison <[email protected]>
Date : 2009-02-28 4:20 (15 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5669fcacc58bf3a7386057addffd280d75380858
References : http://marc.info/?l=linux-kernel&m=123579487801064&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12805
Subject : QinQ vlan trunking regression
Submitter : Bart Trojanowski <[email protected]>
Date : 2009-02-28 18:05 (15 days old)
References : http://marc.info/?l=linux-kernel&m=123584439115868&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12800
Subject : x86 PAT invalid vm_insert_pfn assumptions
Submitter : Thomas Hellstrom <[email protected]>
Date : 2009-03-02 01:40 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12792
Subject : 2.6.29-rc6-git4 boot failure
Submitter : Sachin P. Sant <[email protected]>
Date : 2009-02-27 23:19 (16 days old)
References : http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068771.html
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12778
Subject : suspend regression from 29rc5 to 29rc6
Submitter : yury <[email protected]>
Date : 2009-02-25 09:25 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12771
Subject : Oops in i915_gem_flush
Submitter : Kalev Lember <[email protected]>
Date : 2009-02-24 08:35 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <[email protected]>
Date : 2009-02-21 15:38 (22 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12763
Subject : Different cpu MHz values for processor0 and processor1
Submitter : Matthew A. Bockol <[email protected]>
Date : 2009-02-21 5:42 (22 days old)
References : http://marc.info/?l=linux-kernel&m=123519687807246&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <[email protected]>
Date : 2009-02-13 9:33 (30 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Len Brown <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <[email protected]>
Date : 2009-02-09 13:01 (34 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12680
Subject : Entropy pool problem
Submitter : Valentin QUEQUET <[email protected]>
Date : 2009-02-09 09:12 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12670
Subject : BUG: unable to handle kernel paging request at pin_to_kill+0x21
Submitter : Alessandro Bono <[email protected]>
Date : 2009-02-08 11:04 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123409113223833&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
Subject : USB flash disk surprise disconnect
Submitter : Vegard Nossum <[email protected]>
Date : 2009-02-08 10:21 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <[email protected]>
Date : 2009-01-29 11:35 (45 days old)
References : http://lkml.org/lkml/2009/2/9/205
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <[email protected]>
Date : 2009-01-13 18:34 (61 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <[email protected]>
Date : 2009-01-12 7:38 (62 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By : Bob Copeland <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
Subject : X hangs following switch from radeonfb console - Bisected
Submitter : Graham Murray <[email protected]>
Date : 2009-01-13 14:03 (61 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419
Subject : possible circular locking dependency on i915 dma
Submitter : Wang Chen <[email protected]>
Date : 2009-01-08 14:11 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=546b0974c39657017407c86fe79811100b60700d
References : http://marc.info/?l=linux-kernel&m=123142399720125&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12418
Subject : Repeated ioctl(4, 0x40046445, ..) loop in glxgears
Submitter : Pallipadi, Venkatesh <[email protected]>
Date : 2009-01-07 22:43 (67 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
References : http://marc.info/?l=linux-kernel&m=123136836213319&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12414
Subject : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
Submitter : Jeff Chua <[email protected]>
Date : 2009-01-05 4:13 (69 days old)
References : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12869
Subject : BUG when disabled ipv6 module is unloaded
Submitter : Thomas Backlund <[email protected]>
Date : 2009-03-10 20:15 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123671614621097&w=4
Handled-By : John Dykstra <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=123672746905127&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12758
Subject : ACPI exception with 2.6.29-rc6
Submitter : Heinz Diehl <[email protected]>
Date : 2009-02-23 16:46 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123540758700861&w=4
Handled-By : Len Brown <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=20368&action=view
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12671
Subject : uvc_status_cleanup(): undefined reference to `input_unregister_device'
Submitter : Ingo Molnar <[email protected]>
Date : 2009-02-08 14:58 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123410529909318&w=4
Handled-By : Randy Dunlap <[email protected]>
Patch : http://lkml.org/lkml/2009/2/15/172
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter : Paul Collins <[email protected]>
Date : 2009-01-21 7:15 (53 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
Handled-By : Benjamin Herrenschmidt <[email protected]>
Patch : http://lkml.org/lkml/2009/2/16/78
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.28,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12414
Subject : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
Submitter : Jeff Chua <[email protected]>
Date : 2009-01-05 4:13 (69 days old)
References : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419
Subject : possible circular locking dependency on i915 dma
Submitter : Wang Chen <[email protected]>
Date : 2009-01-08 14:11 (66 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=546b0974c39657017407c86fe79811100b60700d
References : http://marc.info/?l=linux-kernel&m=123142399720125&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
Subject : X hangs following switch from radeonfb console - Bisected
Submitter : Graham Murray <[email protected]>
Date : 2009-01-13 14:03 (61 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <[email protected]>
Date : 2009-01-13 18:34 (61 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <[email protected]>
Date : 2009-01-12 7:38 (62 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By : Bob Copeland <[email protected]>
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12418
Subject : Repeated ioctl(4, 0x40046445, ..) loop in glxgears
Submitter : Pallipadi, Venkatesh <[email protected]>
Date : 2009-01-07 22:43 (67 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
References : http://marc.info/?l=linux-kernel&m=123136836213319&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12671
Subject : uvc_status_cleanup(): undefined reference to `input_unregister_device'
Submitter : Ingo Molnar <[email protected]>
Date : 2009-02-08 14:58 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123410529909318&w=4
Handled-By : Randy Dunlap <[email protected]>
Patch : http://lkml.org/lkml/2009/2/15/172
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12705
Subject : X200: Brightness broken since 2.6.29-rc4-58-g4c098bc
Submitter : Nico Schottelius <[email protected]>
Date : 2009-02-13 9:33 (30 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e806b4957412bf472d826bd8cc571da041248799
References : http://marc.info/?l=linux-kernel&m=123451768406825&w=4
http://marc.info/?l=linux-kernel&m=123479975503827&w=2
Handled-By : Len Brown <[email protected]>
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12763
Subject : Different cpu MHz values for processor0 and processor1
Submitter : Matthew A. Bockol <[email protected]>
Date : 2009-02-21 5:42 (22 days old)
References : http://marc.info/?l=linux-kernel&m=123519687807246&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12681
Subject : s2ram: fails to wake up on Acer Extensa 4220 (SMP disabled)
Submitter : Orivej Desh <[email protected]>
Date : 2009-02-09 13:01 (34 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cfe62c8010ac56e1bd3827e30386a87cc2f3594
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <[email protected]>
Date : 2009-01-29 11:35 (45 days old)
References : http://lkml.org/lkml/2009/2/9/205
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12670
Subject : BUG: unable to handle kernel paging request at pin_to_kill+0x21
Submitter : Alessandro Bono <[email protected]>
Date : 2009-02-08 11:04 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123409113223833&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter : Paul Collins <[email protected]>
Date : 2009-01-21 7:15 (53 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
Handled-By : Benjamin Herrenschmidt <[email protected]>
Patch : http://lkml.org/lkml/2009/2/16/78
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
Subject : USB flash disk surprise disconnect
Submitter : Vegard Nossum <[email protected]>
Date : 2009-02-08 10:21 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
Subject : i915 VT switch with AIGLX causes X lock up
Submitter : Sitsofe Wheeler <[email protected]>
Date : 2009-02-21 15:38 (22 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12758
Subject : ACPI exception with 2.6.29-rc6
Submitter : Heinz Diehl <[email protected]>
Date : 2009-02-23 16:46 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123540758700861&w=4
Handled-By : Len Brown <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=20368&action=view
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12792
Subject : 2.6.29-rc6-git4 boot failure
Submitter : Sachin P. Sant <[email protected]>
Date : 2009-02-27 23:19 (16 days old)
References : http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068771.html
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12771
Subject : Oops in i915_gem_flush
Submitter : Kalev Lember <[email protected]>
Date : 2009-02-24 08:35 (19 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12680
Subject : Entropy pool problem
Submitter : Valentin QUEQUET <[email protected]>
Date : 2009-02-09 09:12 (34 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12778
Subject : suspend regression from 29rc5 to 29rc6
Submitter : yury <[email protected]>
Date : 2009-02-25 09:25 (18 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12831
Subject : Hot/Fn Keys do not work EEEPC 1000HE (eeepc_laptop)
Submitter : Matthew <[email protected]>
Date : 2009-03-07 10:05 (8 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12808
Subject : Suspend regression with 2.6.29-rc
Submitter : Tino Keitel <[email protected]>
Date : 2009-02-24 19:08 (19 days old)
References : http://marc.info/?l=linux-kernel&m=123550257312112&w=4
Handled-By : Rafael J. Wysocki <[email protected]>
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12806
Subject : i915 broken STR
Submitter : Harvey Harrison <[email protected]>
Date : 2009-02-28 4:20 (15 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5669fcacc58bf3a7386057addffd280d75380858
References : http://marc.info/?l=linux-kernel&m=123579487801064&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12809
Subject : iozone regression with 2.6.29-rc6
Submitter : Lin Ming <[email protected]>
Date : 2009-02-27 9:13 (16 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018
References : http://marc.info/?l=linux-kernel&m=123572630504360&w=4
Handled-By : Wu Fengguang <[email protected]>
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12805
Subject : QinQ vlan trunking regression
Submitter : Bart Trojanowski <[email protected]>
Date : 2009-02-28 18:05 (15 days old)
References : http://marc.info/?l=linux-kernel&m=123584439115868&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12800
Subject : x86 PAT invalid vm_insert_pfn assumptions
Submitter : Thomas Hellstrom <[email protected]>
Date : 2009-03-02 01:40 (13 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12842
Subject : CCMP: replay detected
Submitter : Peter Teoh <[email protected]>
Date : 2009-03-08 07:42 (7 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12856
Subject : Thinkpad freezes with X.org and acpi=rsdt
Submitter : Maciej Piechotka <[email protected]>
Date : 2009-03-11 16:46 (4 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12870
Subject : 2.6.29-rc "TKIP: replay detected" regression
Submitter : Hugh Dickins <[email protected]>
Date : 2009-03-11 12:07 (4 days old)
References : http://marc.info/?l=linux-kernel&m=123677337219148&w=4
Handled-By : John W. Linville <[email protected]>
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12836
Subject : 2.6.29-rc breaks STD using Intel 945
Submitter : Rolf Eike Beer <[email protected]>
Date : 2009-03-04 19:20 (11 days old)
References : http://marc.info/?l=linux-kernel&m=123619451406192&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12861
Subject : Xorg fails to start "Failed to allocate space for kernel memory manager"
Submitter : Emil Karlson <[email protected]>
Date : 2009-03-12 12:06 (3 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12846
Subject : Regression issue with kernel 2.6.29-rc6-git1: high power consumption during sleep
Submitter : Raymond Wooninck <[email protected]>
Date : 2009-03-09 08:18 (6 days old)
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12867
Subject : 2.6.29-rc7 broke r8169 MAC on Thecus n2100 ARM board
Submitter : Mikael Pettersson <[email protected]>
Date : 2009-03-09 20:29 (6 days old)
References : http://marc.info/?l=linux-kernel&m=123663065403760&w=4
Handled-By : Francois Romieu <[email protected]>
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12869
Subject : BUG when disabled ipv6 module is unloaded
Submitter : Thomas Backlund <[email protected]>
Date : 2009-03-10 20:15 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123671614621097&w=4
Handled-By : John Dykstra <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=123672746905127&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12871
Subject : usb bluetooth crashes system
Submitter : Pavel Machek <[email protected]>
Date : 2009-03-10 11:23 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123668450400940&w=4
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.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12872
Subject : pwc mmap always fails with EAGAIN
Submitter : Markus <[email protected]>
Date : 2009-03-14 16:42 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123704902201378&w=4
From: "Rafael J. Wysocki" <[email protected]>
Date: Sat, 14 Mar 2009 20:05:33 +0100 (CET)
> 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.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12805
> Subject : QinQ vlan trunking regression
> Submitter : Bart Trojanowski <[email protected]>
> Date : 2009-02-28 18:05 (15 days old)
> References : http://marc.info/?l=linux-kernel&m=123584439115868&w=4
Fixed by:
commit 9d40bbda599def1e1d155d7f7dca14fe8744bd2b
Author: David S. Miller <[email protected]>
Date: Wed Mar 4 23:46:25 2009 -0800
vlan: Fix vlan-in-vlan crashes.
As analyzed by Patrick McHardy, vlan needs to reset it's
netdev_ops pointer in it's ->init() function but this
leaves the compat method pointers stale.
Add a netdev_resync_ops() and call it from the vlan code.
Any other driver which changes ->netdev_ops after register_netdevice()
will need to call this new function after doing so too.
With help from Patrick McHardy.
Tested-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Rafael J. Wysocki skrev:
> 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.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12869
> Subject : BUG when disabled ipv6 module is unloaded
> Submitter : Thomas Backlund <[email protected]>
> Date : 2009-03-10 20:15 (5 days old)
> References : http://marc.info/?l=linux-kernel&m=123671614621097&w=4
> Handled-By : John Dykstra <[email protected]>
> Patch : http://marc.info/?l=linux-kernel&m=123672746905127&w=4
>
>
Yeah, sorry for the delay testing it...
I confirm the bug is fixed with the above patch...
--
Thomas
From: Thomas Backlund <[email protected]>
Date: Sun, 15 Mar 2009 00:04:42 +0200
> Rafael J. Wysocki skrev:
> > 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.28. Please verify if it still should be listed and let me know
> > (either way).
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12869
> > Subject : BUG when disabled ipv6 module is unloaded
> > Submitter : Thomas Backlund <[email protected]>
> > Date : 2009-03-10 20:15 (5 days old)
> > References : http://marc.info/?l=linux-kernel&m=123671614621097&w=4
> > Handled-By : John Dykstra <[email protected]>
> > Patch : http://marc.info/?l=linux-kernel&m=123672746905127&w=4
> >
>
> Yeah, sorry for the delay testing it...
>
> I confirm the bug is fixed with the above patch...
Yes and that patch will be on it's way to Linus from the
net-2.6 tree shortly.
On Saturday 14 March 2009, David Miller wrote:
> From: "Rafael J. Wysocki" <[email protected]>
> Date: Sat, 14 Mar 2009 20:05:33 +0100 (CET)
>
> > 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.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12805
> > Subject : QinQ vlan trunking regression
> > Submitter : Bart Trojanowski <[email protected]>
> > Date : 2009-02-28 18:05 (15 days old)
> > References : http://marc.info/?l=linux-kernel&m=123584439115868&w=4
>
> Fixed by:
>
> commit 9d40bbda599def1e1d155d7f7dca14fe8744bd2b
> Author: David S. Miller <[email protected]>
> Date: Wed Mar 4 23:46:25 2009 -0800
>
> vlan: Fix vlan-in-vlan crashes.
>
> As analyzed by Patrick McHardy, vlan needs to reset it's
> netdev_ops pointer in it's ->init() function but this
> leaves the compat method pointers stale.
>
> Add a netdev_resync_ops() and call it from the vlan code.
>
> Any other driver which changes ->netdev_ops after register_netdevice()
> will need to call this new function after doing so too.
>
> With help from Patrick McHardy.
>
> Tested-by: Patrick McHardy <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
Thanks, closed.
Rafael
On Sat, 14 Mar 2009, Rafael J. Wysocki wrote:
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12809
> Subject : iozone regression with 2.6.29-rc6
> Submitter : Lin Ming <[email protected]>
> Date : 2009-02-27 9:13 (16 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018
> References : http://marc.info/?l=linux-kernel&m=123572630504360&w=4
> Handled-By : Wu Fengguang <[email protected]>
I suspect that I should just raise the default dirty limits. Wu reported
that it fixed the regression, and while he picked some rather high
percentages, I think we could certainly raise the rather aggressive
default ones.
After all, those default percentages were picked (a) with the old dirty
logic and (b) largely at random and (c) designed to be aggressive. In
particular, that (a) means that having fixed some of the dirty accounting,
maybe the real bug is now that it was always too aggressive, just hidden
by an accounting issue.
If we raised the default ratio from 5/10 to 10/20, what happens to the
iozone regression?
Linus
On Sun, Mar 15, 2009 at 3:01 AM, Rafael J. Wysocki <[email protected]> wrote:
> Bug-Entry ? ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=12414
> Subject ? ? ? ? : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
> Submitter ? ? ? : Jeff Chua <[email protected]>
> Date ? ? ? ? ? ?: 2009-01-05 4:13 (69 days old)
> References ? ? ?: http://marc.info/?l=linux-kernel&m=123112882127823&w=4
Still not working in linux-2.6.29-rc8. Broken after the commit below.
There were many changes to wireless after this commit, and simply
reverting this commit will break compiling.
Jeff.
commit 41bb73eeac5ff5fb217257ba33b654747b3abf11
Author: Johannes Berg <[email protected]>
Date: Wed Oct 29 01:09:37 2008 +0100
mac80211: remove SSID driver code
On Sun, Mar 15, 2009 at 10:58 AM, Jeff Chua <[email protected]> wrote:
> On Sun, Mar 15, 2009 at 3:01 AM, Rafael J. Wysocki <[email protected]> wrote:
>> Bug-Entry ? ? ? : http://bugzilla.kernel.org/show_bug.cgi?id=12414
>> Subject ? ? ? ? : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
>> Submitter ? ? ? : Jeff Chua <[email protected]>
>> Date ? ? ? ? ? ?: 2009-01-05 4:13 (69 days old)
>> References ? ? ?: http://marc.info/?l=linux-kernel&m=123112882127823&w=4
>
> Still not working in linux-2.6.29-rc8. Broken after the commit below.
> There were many changes to wireless after this commit, and simply
> reverting this commit will break compiling.
>
> Jeff.
>
>
>
> commit 41bb73eeac5ff5fb217257ba33b654747b3abf11
> Author: Johannes Berg <[email protected]>
> Date: ? Wed Oct 29 01:09:37 2008 +0100
>
> ? ?mac80211: remove SSID driver code
>
The commit below is causing problem with associating with the hidden AP as well.
Thanks,
Jeff.
71c11fb57b924c160297ccd9e1761db598d00ac2 is first bad commit
commit 71c11fb57b924c160297ccd9e1761db598d00ac2
Author: Johannes Berg <[email protected]>
Date: Tue Oct 28 18:29:48 2008 +0100
b43/legacy: remove SSID code
The SSID programmed into the device is used by the ucode only
to reply to probe requests, a functionality we disable anyway
because it doesn't fit with the mac80211/hostapd programming
model. Therefore, it isn't useful to program the SSID into
device.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
:040000 040000 18109a6ea13da3cd13bfadd625617894c9f91b50
fc2ca13f0efcd9e51403b5b55ed730e2457a29c0 M drivers
On Sat, 2009-03-14 at 20:05 +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.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12806
> Subject : i915 broken STR
> Submitter : Harvey Harrison <[email protected]>
> Date : 2009-02-28 4:20 (15 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5669fcacc58bf3a7386057addffd280d75380858
> References : http://marc.info/?l=linux-kernel&m=123579487801064&w=4
>
>
You can close this, turns out KMS got enabled in my config and userspace
was too old to cope.
Harvey
On Sat, Mar 14, 2009 at 08:05:39PM +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.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12871
> Subject : usb bluetooth crashes system
> Submitter : Pavel Machek <[email protected]>
> Date : 2009-03-10 11:23 (5 days old)
> References : http://marc.info/?l=linux-kernel&m=123668450400940&w=4
I think we need some more information here.
Pavel?
On Sun, Mar 15, 2009 at 08:27:08AM +0800, Linus Torvalds wrote:
>
>
> On Sat, 14 Mar 2009, Rafael J. Wysocki wrote:
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12809
> > Subject : iozone regression with 2.6.29-rc6
> > Submitter : Lin Ming <[email protected]>
> > Date : 2009-02-27 9:13 (16 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018
> > References : http://marc.info/?l=linux-kernel&m=123572630504360&w=4
> > Handled-By : Wu Fengguang <[email protected]>
>
> I suspect that I should just raise the default dirty limits. Wu reported
> that it fixed the regression, and while he picked some rather high
> percentages, I think we could certainly raise the rather aggressive
> default ones.
>
> After all, those default percentages were picked (a) with the old dirty
> logic and (b) largely at random and (c) designed to be aggressive. In
> particular, that (a) means that having fixed some of the dirty accounting,
> maybe the real bug is now that it was always too aggressive, just hidden
> by an accounting issue.
I second that.
1) The _real_ dirty threshold used to be large.
2) It is a _real_ regression. It impacts real user experiences.
So when introducing Nick's correct-dirty-accounting patch, we'd better
increase the dirty thresholds correspondingly.
> If we raised the default ratio from 5/10 to 10/20, what happens to the
> iozone regression?
Maybe tomorrow. Ling Ming?
In general we should not cater the thresholds for one specific workload.
But this is a case of _regression_, and it would be better to raise the
bars above it.
Thanks,
Fengguang
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12792
> Subject : 2.6.29-rc6-git4 boot failure
> Submitter : Sachin P. Sant <[email protected]>
> Date : 2009-02-27 23:19 (16 days old)
> References : http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068771.html
>
I can still recreate this with 2.6.29-rc8-git1. Same trace and same
point of failure.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
I am no longer seeing this problem with 2.6.29-rc8-00090g326d851, but I
have also upgrade various parts of X including the radeon driver to
version 6.12.0.
> 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.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
> Subject : X hangs following switch from radeonfb console - Bisected
> Submitter : Graham Murray <[email protected]>
> Date : 2009-01-13 14:03 (61 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
On Sunday 15 March 2009, Harvey Harrison wrote:
> On Sat, 2009-03-14 at 20:05 +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.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12806
> > Subject : i915 broken STR
> > Submitter : Harvey Harrison <[email protected]>
> > Date : 2009-02-28 4:20 (15 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5669fcacc58bf3a7386057addffd280d75380858
> > References : http://marc.info/?l=linux-kernel&m=123579487801064&w=4
> >
> >
>
> You can close this, turns out KMS got enabled in my config and userspace
> was too old to cope.
Thanks, closed.
Rafael
On Sunday 15 March 2009, Jeff Chua wrote:
> On Sun, Mar 15, 2009 at 10:58 AM, Jeff Chua <[email protected]> wrote:
> > On Sun, Mar 15, 2009 at 3:01 AM, Rafael J. Wysocki <[email protected]> wrote:
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12414
> >> Subject : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
> >> Submitter : Jeff Chua <[email protected]>
> >> Date : 2009-01-05 4:13 (69 days old)
> >> References : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> >
> > Still not working in linux-2.6.29-rc8. Broken after the commit below.
> > There were many changes to wireless after this commit, and simply
> > reverting this commit will break compiling.
> >
> > Jeff.
> >
> >
> >
> > commit 41bb73eeac5ff5fb217257ba33b654747b3abf11
> > Author: Johannes Berg <[email protected]>
> > Date: Wed Oct 29 01:09:37 2008 +0100
> >
> > mac80211: remove SSID driver code
> >
>
> The commit below is causing problem with associating with the hidden AP as well.
>
> Thanks,
> Jeff.
>
>
> 71c11fb57b924c160297ccd9e1761db598d00ac2 is first bad commit
> commit 71c11fb57b924c160297ccd9e1761db598d00ac2
> Author: Johannes Berg <[email protected]>
> Date: Tue Oct 28 18:29:48 2008 +0100
>
> b43/legacy: remove SSID code
>
> The SSID programmed into the device is used by the ucode only
> to reply to probe requests, a functionality we disable anyway
> because it doesn't fit with the mac80211/hostapd programming
> model. Therefore, it isn't useful to program the SSID into
> device.
>
> Signed-off-by: Johannes Berg <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
Thanks for the update.
Rafael
On Sunday 15 March 2009, Graham Murray wrote:
> I am no longer seeing this problem with 2.6.29-rc8-00090g326d851, but I
> have also upgrade various parts of X including the radeon driver to
> version 6.12.0.
This is a code fix anyway, closing. :-)
> > 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.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
> > Subject : X hangs following switch from radeonfb console - Bisected
> > Submitter : Graham Murray <[email protected]>
> > Date : 2009-01-13 14:03 (61 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
Thanks,
Rafael
On Sunday 15 March 2009, Sachin Sant wrote:
> Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12792
> > Subject : 2.6.29-rc6-git4 boot failure
> > Submitter : Sachin P. Sant <[email protected]>
> > Date : 2009-02-27 23:19 (16 days old)
> > References : http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068771.html
> >
> I can still recreate this with 2.6.29-rc8-git1. Same trace and same
> point of failure.
Thanks for the update.
Rafael
Rafael J. Wysocki wrote:
>> I can still recreate this with 2.6.29-rc8-git1. Same trace and same
>> point of failure.
>>
This problem seems to have been introduced somewhere during 2.6.28 git3/git4.
I can boot 2.6.28-git2 successfully on this box. Could not confirm with git3
as it had kernel build failure issues. git4 kernel failed to boot with same
backtrace as reported.
Will try to further narrow down this issue.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
On Sun, 2009-03-15 at 11:06 +0800, Jeff Chua wrote:
> The commit below is causing problem with associating with the hidden AP as well.
> 71c11fb57b924c160297ccd9e1761db598d00ac2 is first bad commit
> commit 71c11fb57b924c160297ccd9e1761db598d00ac2
> Author: Johannes Berg <[email protected]>
> Date: Tue Oct 28 18:29:48 2008 +0100
>
> b43/legacy: remove SSID code
>
> The SSID programmed into the device is used by the ucode only
> to reply to probe requests, a functionality we disable anyway
> because it doesn't fit with the mac80211/hostapd programming
> model. Therefore, it isn't useful to program the SSID into
> device.
That's not believable, sorry. I know exactly what the microcode uses the
SSID here for, and it never uses it when we're in station mode.
johannes
On Sun, 15 Mar 2009, Johannes Berg wrote:
> On Sun, 2009-03-15 at 11:06 +0800, Jeff Chua wrote:
>
> > The commit below is causing problem with associating with the hidden AP as well.
>
> > 71c11fb57b924c160297ccd9e1761db598d00ac2 is first bad commit
> > commit 71c11fb57b924c160297ccd9e1761db598d00ac2
> > Author: Johannes Berg <[email protected]>
> > Date: Tue Oct 28 18:29:48 2008 +0100
> >
> > b43/legacy: remove SSID code
> >
> > The SSID programmed into the device is used by the ucode only
> > to reply to probe requests, a functionality we disable anyway
> > because it doesn't fit with the mac80211/hostapd programming
> > model. Therefore, it isn't useful to program the SSID into
> > device.
>
> That's not believable, sorry. I know exactly what the microcode uses the
> SSID here for, and it never uses it when we're in station mode.
Jeff - can you test the kernels before-and-after this commit (with _no_
other changes) and descibe the differences?
Johannes - "not believable" is simply not an argument. If Jeff can show a
difference, then your disbelief is totally irrelevant, and clearly shows
that you are basing your beliefs on incorrect assumptions (like some
specific version of firmware that isn't the whole story).
Linus
On Sun, 2009-03-15 at 11:44 -0700, Linus Torvalds wrote:
> Johannes - "not believable" is simply not an argument. If Jeff can show a
> difference, then your disbelief is totally irrelevant, and clearly shows
> that you are basing your beliefs on incorrect assumptions (like some
> specific version of firmware that isn't the whole story).
Linus, Jeff is totally unbelievable here -- I just realised that the
commit he quotes doesn't even change the driver he's working with.
johannes
* Johannes Berg <[email protected]> wrote:
> On Sun, 2009-03-15 at 11:44 -0700, Linus Torvalds wrote:
>
> > Johannes - "not believable" is simply not an argument. If
> > Jeff can show a difference, then your disbelief is totally
> > irrelevant, and clearly shows that you are basing your
> > beliefs on incorrect assumptions (like some specific version
> > of firmware that isn't the whole story).
>
> Linus, Jeff is totally unbelievable here -- I just realised
> that the commit he quotes doesn't even change the driver he's
> working with.
Even if so (bisection is very hard and error-prone) why do you
shape your reaction to it as a personal attack? Why do you say
"Jeff is totally unbelievable" - why dont you say something more
amicable like:
" Hm, that's weird - that commit does not even seem to affect
the driver you are working with. Could you please re-check
the final bits of the bisection to make sure you got the
right commit ID? "
Instead of this irritated-sounding attack tone you are using.
It's not helpful. Testers are there to help you, not to annoy
you. If they annoy you then you are in the wrong business.
Ingo
On Sat, Mar 14, 2009 at 08:05:29PM +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.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
> Subject : possible circular locking dependency detected
> Submitter : Michael S. Tsirkin <[email protected]>
> Date : 2009-01-29 11:35 (45 days old)
> References : http://lkml.org/lkml/2009/2/9/205
>
It's still there in rc8.
On Sun, 2009-03-15 at 03:01 +0800, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 2.6.28, for which there
> are no fixes in the mainline I know of. If any of them have been fixed already,
> please let me know.
>
> If you know of any other unresolved regressions from 2.6.28, please let me know
> either and I'll add them to the list. Also, please let me know if any of the
> entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2009-03-14 124 36 32
> 2009-03-03 108 33 28
> 2009-02-24 95 32 24
> 2009-02-14 85 33 27
> 2009-02-08 82 45 36
> 2009-02-04 66 51 39
> 2009-01-20 38 35 27
> 2009-01-11 13 13 10
>
>
> Unresolved regressions
> ----------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12831
> Subject : Hot/Fn Keys do not work EEEPC 1000HE (eeepc_laptop)
> Submitter : Matthew <[email protected]>
> Date : 2009-03-07 10:05 (8 days old)
patch is available at
http://bugzilla.kernel.org/show_bug.cgi?id=12831#c11
thanks,
rui
On Sun, 2009-03-15 at 08:27 +0800, Linus Torvalds wrote:
>
> On Sat, 14 Mar 2009, Rafael J. Wysocki wrote:
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12809
> > Subject : iozone regression with 2.6.29-rc6
> > Submitter : Lin Ming <[email protected]>
> > Date : 2009-02-27 9:13 (16 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018
> > References : http://marc.info/?l=linux-kernel&m=123572630504360&w=4
> > Handled-By : Wu Fengguang <[email protected]>
>
> I suspect that I should just raise the default dirty limits. Wu reported
> that it fixed the regression, and while he picked some rather high
> percentages, I think we could certainly raise the rather aggressive
> default ones.
>
> After all, those default percentages were picked (a) with the old dirty
> logic and (b) largely at random and (c) designed to be aggressive. In
> particular, that (a) means that having fixed some of the dirty accounting,
> maybe the real bug is now that it was always too aggressive, just hidden
> by an accounting issue.
>
> If we raised the default ratio from 5/10 to 10/20, what happens to the
> iozone regression?
echo 10 > /proc/sys/vm/dirty_background_ratio
echo 20 > /proc/sys/vm/dirty_ratio
It fixed the regression of iozone (filesize 1200M) on 4P dual-core HT
machine(8G mem).
Lin Ming
On Mon, Mar 16, 2009 at 01:03:42PM +0800, Lin, Ming wrote:
> On Sun, 2009-03-15 at 08:27 +0800, Linus Torvalds wrote:
> >
> > On Sat, 14 Mar 2009, Rafael J. Wysocki wrote:
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me know
> > > (either way).
> > >
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12809
> > > Subject : iozone regression with 2.6.29-rc6
> > > Submitter : Lin Ming <[email protected]>
> > > Date : 2009-02-27 9:13 (16 days old)
> > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1cf6e7d83bf334cc5916137862c920a97aabc018
> > > References : http://marc.info/?l=linux-kernel&m=123572630504360&w=4
> > > Handled-By : Wu Fengguang <[email protected]>
> >
> > I suspect that I should just raise the default dirty limits. Wu reported
> > that it fixed the regression, and while he picked some rather high
> > percentages, I think we could certainly raise the rather aggressive
> > default ones.
> >
> > After all, those default percentages were picked (a) with the old dirty
> > logic and (b) largely at random and (c) designed to be aggressive. In
> > particular, that (a) means that having fixed some of the dirty accounting,
> > maybe the real bug is now that it was always too aggressive, just hidden
> > by an accounting issue.
> >
> > If we raised the default ratio from 5/10 to 10/20, what happens to the
> > iozone regression?
>
> echo 10 > /proc/sys/vm/dirty_background_ratio
> echo 20 > /proc/sys/vm/dirty_ratio
>
> It fixed the regression of iozone (filesize 1200M) on 4P dual-core HT
> machine(8G mem).
A quick&coarse calculation: 8G * 15% = 1200M.
This means an iozone process dirtying 1200M data won't be write-blocked.
So the thresholds of 10/20 are just about enough for fixing this regression.
Thanks,
Fengguang
On Mon, Mar 16, 2009 at 4:26 AM, Ingo Molnar <[email protected]> wrote:
> * Johannes Berg <[email protected]> wrote:
>> that the commit he quotes doesn't even change the driver he's
>> working with.
Here's what I did, and it's repeatable.
Take the attached bisect log and replay it, and the last offending
commit is this ...
# git log
commit 71c11fb57b924c160297ccd9e1761db598d00ac2
Author: Johannes Berg <[email protected]>
Date: Tue Oct 28 18:29:48 2008 +0100
b43/legacy: remove SSID code
Yes, this is not the real problem, but it's the last commit that cause
the problem, and I couldn't bisect further, typing the next "git
bisect bad" and the commit is
# git bisect bad
71c11fb57b924c160297ccd9e1761db598d00ac2 is first bad commit
commit 71c11fb57b924c160297ccd9e1761db598d00ac2
Author: Johannes Berg <[email protected]>
Date: Tue Oct 28 18:29:48 2008 +0100
b43/legacy: remove SSID code
Johannes, Ok, this is not the commit causing the problem, but anything
after this commit doesn't associate with my hidden APs. I may not have
run over every single commits since, but 2.6.29-rc8 is definitely not
associating at all automatically -- only manually by specifying the
AP.
This bug is quite hard to trigger, and it doesn't shows easily in
2.6.28-rc3. May be once every 10 times you tried.
# git reset --hard 71c11fb57b924c160297ccd9e1761db598d00ac2
I've tried on two different Linksys's AP. Association with WAG354G is
better than with WAG200G ... meaning it's harder to get association
failure on 2.6.28-rc3. 1/10 fail on WAG354G, and 9/10 fails on
WAG200G.
Here's how I associate with the AP.
# modprobe -r iwlagn
# modprobe iwlagn
# iwconfig wlan0 mode Managed
# ifconfig wlan0 up
# iwconfig wlan0 essid "myessid"
# iwconfig wlan0 key restricted "hex key"
# iwconfig wlan0 ap auto channel auto
# ... wait for association
# ping -c 3 <IP of the AP>
# shutdown the interface
# ifconfig wlan0 down
# modprobe -r iwlagn
Repeat these and it'll fail to associate. On WAG200G, can't associate
after 2nd attempt.
Next revert these two commits
commit 4607816f608b42a5379aca97ceed08378804c99f
Author: Johannes Berg <[email protected]>
Date: Tue Oct 28 18:25:43 2008 +0100
iwlwifi: remove unused essid variable
commit a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
Author: Johannes Berg <[email protected]>
Date: Tue Oct 28 18:21:05 2008 +0100
iwlwifi: remove implicit direct scan
With these patches reverted, associating with the APs are always
successful 10 out of 10 times with the same steps as above.
I've even used the bad modules and when it failed, I can associate
again with the patched module. Same 2.6.28-rc3 kernel.
Here's part of the dmesg
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: US
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
cfg80211: Calling CRDA for country: US
iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
iwlagn: Copyright(c) 2003-2008 Intel Corporation
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: setting latency timer to 64
iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
iwlagn: Tunable channels: 11 802.11bg, 13 802.11a channels
iwlagn 0000:03:00.0: PCI INT A disabled
wmaster0 (iwlagn): not using net_device_ops yet
phy0: Selected rate control algorithm 'iwl-agn-rs'
wlan0 (iwlagn): not using net_device_ops yet
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: restoring config space at offset 0x1 (was
0x100102, writing 0
x100106)
iwlagn 0000:03:00.0: irq 28 for MSI/MSI-X
iwlagn 0000:03:00.0: firmware: requesting iwlwifi-4965-2.ucode
iwlagn loaded firmware version 228.57.2.23
Registered led device: iwl-phy0:radio
Registered led device: iwl-phy0:assoc
Registered led device: iwl-phy0:RX
Registered led device: iwl-phy0:TX
iwlagn: TX Power requested while scanning!
Anything I can help to debug further, just let me know.
Thanks,
Jeff.
On Sat, Mar 14, 2009 at 08:05:32PM +0100, Rafael J. Wysocki wrote:
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
> Subject : i915 VT switch with AIGLX causes X lock up
> Submitter : Sitsofe Wheeler <[email protected]>
> Date : 2009-02-21 15:38 (22 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
Still here in 2.6.29-rc8.
--
Sitsofe | http://sucs.org/~sits/
On Mon, 16 Mar 2009, Jeff Chua wrote:
>
> Take the attached bisect log and replay it
Taking a bisect log is repeatable, but pointless.
If you made any mistakes in bisecting (marking a kernel that was good as
being bad, or the other way around), the log will always replay to the
same thing, but it will still be wrong.
In other words, "git bisect" is only as reliable as the data you feed it,
and if the behavior isn't 100% repeatable and unambiguous (or if you
simply made a mistake), you need to double-check things.
So after bisecting a commit, if there is any question what-so-ever whether
the commit makes sense as a result, you need to double-check it. The best
way to double-check it is to go back to a known-bad state (preferably the
tip of the branch) and revert the presumed-bad commit, and verify that it
really fixes the behavior.
But if that is impossible (for example, because the commit no longer
reverts cleanly), at least make 100% sure that the state at the commit is
bad, and then go to (all) parents of that commit and make 100% sure that
the state at those points is _good_.
IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
being bad, then you should go back and double-check that its parent
(in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
Because if it's parent is also bad, then that just means that you made
some mistake in "git bisect".
The thing about bisecting is that it is _extremely_ efficient. It takes
essentially the minimal number of answers to get to the end result. But
that very efficiency also means that getting even just _one_ of those
answers wrong will take you _way_ off base. There's no room for error,
because bisect will take each bit and use it to maximally split the error
space.
In this case, it really sounds like maybe you marked the parent good, even
though you should have marked it bad.
Linus
On Sat, 14 Mar 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12870
> Subject : 2.6.29-rc "TKIP: replay detected" regression
> Submitter : Hugh Dickins <[email protected]>
> Date : 2009-03-11 12:07 (4 days old)
> References : http://marc.info/?l=linux-kernel&m=123677337219148&w=4
> Handled-By : John W. Linville <[email protected]>
Yes, it should still be listed, but could go into the "with patches"
section: there's a good patch from John in linux-next, which I expect
he'll get Linus to pull in due course.
Hugh
On Monday 16 March 2009, Hugh Dickins wrote:
> On Sat, 14 Mar 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12870
> > Subject : 2.6.29-rc "TKIP: replay detected" regression
> > Submitter : Hugh Dickins <[email protected]>
> > Date : 2009-03-11 12:07 (4 days old)
> > References : http://marc.info/?l=linux-kernel&m=123677337219148&w=4
> > Handled-By : John W. Linville <[email protected]>
>
> Yes, it should still be listed, but could go into the "with patches"
> section: there's a good patch from John in linux-next, which I expect
> he'll get Linus to pull in due course.
Well, I need a pointer to the patch please. John?
Rafael
On Tue, Mar 17, 2009 at 3:57 AM, Linus Torvalds
<[email protected]> wrote:
> IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
> being bad, then you should go back and double-check that its parent
> (in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
> Because if it's parent is also bad, then that just means that you made
> some mistake in "git bisect".
> In this case, it really sounds like maybe you marked the parent good, even
> though you should have marked it bad.
I should have been more careful, just got thrown off during the last
few steps of the bisect. But with the bad association to the AP after
a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9 (iwlwifi: remove implicit
direct scan), can someone suggest where to go from here?
Meanwhile, I'll try bisecting again.
Thanks,
Jeff.
On Mon, Mar 16, 2009 at 10:57:06PM +0100, Rafael J. Wysocki wrote:
> On Monday 16 March 2009, Hugh Dickins wrote:
> > On Sat, 14 Mar 2009, Rafael J. Wysocki wrote:
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12870
> > > Subject : 2.6.29-rc "TKIP: replay detected" regression
> > > Submitter : Hugh Dickins <[email protected]>
> > > Date : 2009-03-11 12:07 (4 days old)
> > > References : http://marc.info/?l=linux-kernel&m=123677337219148&w=4
> > > Handled-By : John W. Linville <[email protected]>
> >
> > Yes, it should still be listed, but could go into the "with patches"
> > section: there's a good patch from John in linux-next, which I expect
> > he'll get Linus to pull in due course.
>
> Well, I need a pointer to the patch please. John?
http://marc.info/?l=linux-wireless&m=123678463704691&w=2
Just sent a pull request through Dave...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, 2009-03-17 at 07:55 +0800, Jeff Chua wrote:
> > IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
> > being bad, then you should go back and double-check that its parent
> > (in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
> > Because if it's parent is also bad, then that just means that you made
> > some mistake in "git bisect".
> > In this case, it really sounds like maybe you marked the parent good, even
> > though you should have marked it bad.
>
> I should have been more careful, just got thrown off during the last
> few steps of the bisect. But with the bad association to the AP after
> a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9 (iwlwifi: remove implicit
> direct scan), can someone suggest where to go from here?
That actually makes some sense, though I'm convinced the code I removed
there is actually wrong that doesn't mean it couldn't have had positive
side effects too. I'll take a look at it, in the meantime your time
would be better spent trying to capture what's going on on the air
instead of bisecting again.
If you don't have a second device to monitor, you can also create a
monitor interface as such:
iw dev wlan0 interface add moni0 type monitor flags none
and run tcpdump on the resulting 'moni0' interface while you try to
associate etc. Write the packets to files and send them to me.
Due to this implicit scan modification in the driver that I removed,
however, I won't see scans in that file, so it won't be all that useful,
a capture made on a second device would be much better.
johannes
On Tue, Mar 17, 2009 at 07:55:49AM +0800, Jeff Chua wrote:
> On Tue, Mar 17, 2009 at 3:57 AM, Linus Torvalds
> <[email protected]> wrote:
>
> > IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
> > being bad, then you should go back and double-check that its parent
> > (in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
> > Because if it's parent is also bad, then that just means that you made
> > some mistake in "git bisect".
> > In this case, it really sounds like maybe you marked the parent good, even
> > though you should have marked it bad.
>
> I should have been more careful, just got thrown off during the last
> few steps of the bisect. But with the bad association to the AP after
> a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9 (iwlwifi: remove implicit
> direct scan), can someone suggest where to go from here?
The obvious question for me is did you try this?
git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
Does that restore operation for you?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, Mar 17, 2009 at 10:48:02AM -0400, John W. Linville wrote:
> On Tue, Mar 17, 2009 at 07:55:49AM +0800, Jeff Chua wrote:
> > On Tue, Mar 17, 2009 at 3:57 AM, Linus Torvalds
> > <[email protected]> wrote:
> >
> > > IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
> > > being bad, then you should go back and double-check that its parent
> > > (in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
> > > Because if it's parent is also bad, then that just means that you made
> > > some mistake in "git bisect".
> > > In this case, it really sounds like maybe you marked the parent good, even
> > > though you should have marked it bad.
> >
> > I should have been more careful, just got thrown off during the last
> > few steps of the bisect. But with the bad association to the AP after
> > a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9 (iwlwifi: remove implicit
> > direct scan), can someone suggest where to go from here?
>
> The obvious question for me is did you try this?
>
> git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
Hmmm...more like this:
git revert 41bb73eeac5ff5fb217257ba33b654747b3abf11
git revert b23f99bcfa12c7b452f7ad201ea5921534d4e9ff
git revert 71c11fb57b924c160297ccd9e1761db598d00ac2
git revert 4607816f608b42a5379aca97ceed08378804c99f
git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
This first one has a conflict -- just take the hunk.
> Does that restore operation for you?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
* John W. Linville <[email protected]> wrote:
> On Tue, Mar 17, 2009 at 10:48:02AM -0400, John W. Linville wrote:
> > On Tue, Mar 17, 2009 at 07:55:49AM +0800, Jeff Chua wrote:
> > > On Tue, Mar 17, 2009 at 3:57 AM, Linus Torvalds
> > > <[email protected]> wrote:
> > >
> > > > IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
> > > > being bad, then you should go back and double-check that its parent
> > > > (in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
> > > > Because if it's parent is also bad, then that just means that you made
> > > > some mistake in "git bisect".
> > > > In this case, it really sounds like maybe you marked the parent good, even
> > > > though you should have marked it bad.
> > >
> > > I should have been more careful, just got thrown off during the last
> > > few steps of the bisect. But with the bad association to the AP after
> > > a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9 (iwlwifi: remove implicit
> > > direct scan), can someone suggest where to go from here?
> >
> > The obvious question for me is did you try this?
> >
> > git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
>
> Hmmm...more like this:
>
> git revert 41bb73eeac5ff5fb217257ba33b654747b3abf11
> git revert b23f99bcfa12c7b452f7ad201ea5921534d4e9ff
> git revert 71c11fb57b924c160297ccd9e1761db598d00ac2
> git revert 4607816f608b42a5379aca97ceed08378804c99f
> git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
>
> This first one has a conflict -- just take the hunk.
Since you apparently have done this sequence and have
resolved the conflict (which is hard to do for testers
even in trivial cases) - would you mind to post the
resulting combo patch for Jeff to test?
Ingo
On Tue, Mar 17, 2009 at 04:39:24PM +0100, Ingo Molnar wrote:
>
> * John W. Linville <[email protected]> wrote:
>
> > On Tue, Mar 17, 2009 at 10:48:02AM -0400, John W. Linville wrote:
> > > On Tue, Mar 17, 2009 at 07:55:49AM +0800, Jeff Chua wrote:
> > > > On Tue, Mar 17, 2009 at 3:57 AM, Linus Torvalds
> > > > <[email protected]> wrote:
> > > >
> > > > > IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
> > > > > being bad, then you should go back and double-check that its parent
> > > > > (in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
> > > > > Because if it's parent is also bad, then that just means that you made
> > > > > some mistake in "git bisect".
> > > > > In this case, it really sounds like maybe you marked the parent good, even
> > > > > though you should have marked it bad.
> > > >
> > > > I should have been more careful, just got thrown off during the last
> > > > few steps of the bisect. But with the bad association to the AP after
> > > > a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9 (iwlwifi: remove implicit
> > > > direct scan), can someone suggest where to go from here?
> > >
> > > The obvious question for me is did you try this?
> > >
> > > git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
> >
> > Hmmm...more like this:
> >
> > git revert 41bb73eeac5ff5fb217257ba33b654747b3abf11
> > git revert b23f99bcfa12c7b452f7ad201ea5921534d4e9ff
> > git revert 71c11fb57b924c160297ccd9e1761db598d00ac2
> > git revert 4607816f608b42a5379aca97ceed08378804c99f
> > git revert a57a59f247b651e8ed6d3eeb7e2f9d83b83134c9
> >
> > This first one has a conflict -- just take the hunk.
>
> Since you apparently have done this sequence and have
> resolved the conflict (which is hard to do for testers
> even in trivial cases) - would you mind to post the
> resulting combo patch for Jeff to test?
Since Jeff has been using git for bisect, I presumed he could handle
the reverts. But if you think it is helpful:
http://bugzilla.kernel.org/attachment.cgi?id=20567&action=view
Hth!
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, Mar 18, 2009 at 12:05 AM, John W. Linville <[email protected]>
> the reverts. ?But if you think it is helpful:
> ? ? ? ?http://bugzilla.kernel.org/attachment.cgi?id=20567&action=view
I tried applying the above patch against the latest linux git
(18439c39e826191c0ef08c3a3271ce7ece46a860), but got a lot of rejects.
Is this supposed to be?
patch -p1 </tar/v2.6/revert-remove-ssid-knowledge-from-driver-series.patch
1 out of 1 hunk FAILED -- saving rejects to file
drivers/net/wireless/adm8211.h.rej
1 out of 2 hunks FAILED -- saving rejects to file
drivers/net/wireless/b43/main.c.rej
1 out of 2 hunks FAILED -- saving rejects to file
drivers/net/wireless/b43legacy/main.c.rej
1 out of 1 hunk FAILED -- saving rejects to file
drivers/net/wireless/iwlwifi/iwl-3945.h.rej
3 out of 4 hunks FAILED -- saving rejects to file
drivers/net/wireless/iwlwifi/iwl-agn.c.rej
1 out of 1 hunk FAILED -- saving rejects to file
drivers/net/wireless/iwlwifi/iwl-dev.h.rej
3 out of 5 hunks FAILED -- saving rejects to file
drivers/net/wireless/iwlwifi/iwl3945-base.c.rej
1 out of 3 hunks FAILED -- saving rejects to file include/net/mac80211.h.rej
Thanks,
Jeff.
On Wed, Mar 18, 2009 at 12:24:33AM +0800, Jeff Chua wrote:
> On Wed, Mar 18, 2009 at 12:05 AM, John W. Linville <[email protected]>
> > the reverts. ?But if you think it is helpful:
> > ? ? ? ?http://bugzilla.kernel.org/attachment.cgi?id=20567&action=view
>
> I tried applying the above patch against the latest linux git
> (18439c39e826191c0ef08c3a3271ce7ece46a860), but got a lot of rejects.
> Is this supposed to be?
>
>
> patch -p1 </tar/v2.6/revert-remove-ssid-knowledge-from-driver-series.patch
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/net/wireless/adm8211.h.rej
> 1 out of 2 hunks FAILED -- saving rejects to file
> drivers/net/wireless/b43/main.c.rej
> 1 out of 2 hunks FAILED -- saving rejects to file
> drivers/net/wireless/b43legacy/main.c.rej
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/net/wireless/iwlwifi/iwl-3945.h.rej
> 3 out of 4 hunks FAILED -- saving rejects to file
> drivers/net/wireless/iwlwifi/iwl-agn.c.rej
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/net/wireless/iwlwifi/iwl-dev.h.rej
> 3 out of 5 hunks FAILED -- saving rejects to file
> drivers/net/wireless/iwlwifi/iwl3945-base.c.rej
> 1 out of 3 hunks FAILED -- saving rejects to file include/net/mac80211.h.rej
Works for me...I even re-downloaded the patch from bugzilla.
/home/linville/git/linux-2.6
[linville-t400.local]:> git show
commit 18439c39e826191c0ef08c3a3271ce7ece46a860
Merge: 9e8912e... b35f8ca...
Author: Linus Torvalds <[email protected]>
Date: Tue Mar 17 08:59:33 2009 -0700
Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm
* git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm:
dm crypt: wait for endio to complete before destruction
dm crypt: fix kcryptd_async_done parameter
dm io: respect BIO_MAX_PAGES limit
dm table: rework reference counting fix
dm ioctl: validate name length when renaming
/home/linville/git/linux-2.6
[linville-t400.local]:> patch -p1 < revert-remove-ssid-knowledge-from-driver-series.patch
patching file drivers/net/wireless/adm8211.c
patching file drivers/net/wireless/adm8211.h
patching file drivers/net/wireless/b43/main.c
patching file drivers/net/wireless/b43legacy/main.c
patching file drivers/net/wireless/iwlwifi/iwl-3945.h
patching file drivers/net/wireless/iwlwifi/iwl-agn.c
patching file drivers/net/wireless/iwlwifi/iwl-dev.h
patching file drivers/net/wireless/iwlwifi/iwl-scan.c
patching file drivers/net/wireless/iwlwifi/iwl3945-base.c
patching file include/net/mac80211.h
patching file net/mac80211/ieee80211_i.h
patching file net/mac80211/main.c
patching file net/mac80211/mlme.c
patching file net/mac80211/wext.c
Perhaps you have a dirty tree?
git checkout -f
Does that help?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, Mar 17, 2009 at 3:50 PM, Johannes Berg
<[email protected]> wrote:
> If you don't have a second device to monitor, you can also create a
> monitor interface as such:
> ? ? ? ?iw dev wlan0 interface add moni0 type monitor flags none
>
> and run tcpdump on the resulting 'moni0' interface while you try to
> associate etc. Write the packets to files and send them to me.
>
> Due to this implicit scan modification in the driver that I removed,
> however, I won't see scans in that file, so it won't be all that useful,
> a capture made on a second device would be much better.
Ok, I'll try this out later. Got good news to share. I've applied
John's patches and just need to modified net/mac80211/wext.c slightly
since len and ssid are not defined, and function arguments are
different. I'm checking my tree again ... my seems different from his.
Thanks,
Jeff.
On Wed, Mar 18, 2009 at 1:10 AM, John W. Linville
> Works for me...I even re-downloaded the patch from bugzilla.
> commit 18439c39e826191c0ef08c3a3271ce7ece46a860
> Merge: 9e8912e... b35f8ca...
> Author: Linus Torvalds <[email protected]>
> Date: ? Tue Mar 17 08:59:33 2009 -0700
Same.
> [linville-t400.local]:> patch -p1 < revert-remove-ssid-knowledge-from-driver-series.patch
> patching file drivers/net/wireless/adm8211.c
> patching file drivers/net/wireless/adm8211.h
> patching file drivers/net/wireless/b43/main.c
> patching file drivers/net/wireless/b43legacy/main.c
> patching file drivers/net/wireless/iwlwifi/iwl-3945.h
> patching file drivers/net/wireless/iwlwifi/iwl-agn.c
> patching file drivers/net/wireless/iwlwifi/iwl-dev.h
> patching file drivers/net/wireless/iwlwifi/iwl-scan.c
> patching file drivers/net/wireless/iwlwifi/iwl3945-base.c
> patching file include/net/mac80211.h
> patching file net/mac80211/ieee80211_i.h
> patching file net/mac80211/main.c
> patching file net/mac80211/mlme.c
> patching file net/mac80211/wext.c
>
> Perhaps you have a dirty tree?
> git checkout -f
May be. Checking now.
> Does that help?
Definitely. Even with the failing chunks, and I copied back the old
wext.c from 2.6.28-rc3, and now my wireless is associating to the
hidden AP on 2.6.29-rc8. I tried just a few times, and it's ok so far.
I'll have to pit against the WAG200G that seems to have a worse
behavior tomorrow. ... anyway, this is all good. With the patch, it's
_impossible_ to "auto" associate to the AP. Definitely on the right
track!
Thanks,
Jeff.
On Wed, Mar 18, 2009 at 1:27 AM, Jeff Chua
>> Perhaps you have a dirty tree?
>> ? ? ? ?git checkout -f
>
> May be. Checking now.
Oh, now I know why. I was "mucking" the SSID stuffs trying to revert
some of the wireless codes on 2.6.29-rc8, and just applied your
patches on top.
My downloaded tree is clean. I'm trying your patches now.
Jeff.
On Wed, Mar 18, 2009 at 1:31 AM, Jeff Chua <[email protected]> wrote:
> My downloaded tree is clean. I'm trying your patches now.
John,
Your patches applied cleanly this time. And associating to the hidden
AP on 2.6.29-rc8. I'll run it against the WAG200G tomorrow. But from
what I can see, it's working well with the WAG354G.
I'll try out this as well "iw dev wlan0 interface add moni0 type
monitor flags none"
Your guys are great!
Thank you.
Jeff.
On Mon, 2009-03-16 at 21:24 +0800, Jeff Chua wrote:
> Here's what I did, and it's repeatable.
>
> Take the attached bisect log and replay it, and the last offending
> commit is this ...
> # git log
> commit 71c11fb57b924c160297ccd9e1761db598d00ac2
> Author: Johannes Berg <[email protected]>
> Date: Tue Oct 28 18:29:48 2008 +0100
>
> b43/legacy: remove SSID code
>
> Yes, this is not the real problem, but it's the last commit that cause
> the problem, and I couldn't bisect further, typing the next "git
> bisect bad" and the commit is
I'm on 0191b62 now and cannot reproduce the problem with iwlwifi
hardware and a linksys (broadcom-based) AP with hidden SSID.
> Anything I can help to debug further, just let me know.
Compile iwlwifi with debugging please, and instead of plain modprobe
iwlagn, do this:
modprobe iwlagn debug=0x800 debug50=0x800
Then send me the relevant dmesg output from a working and a failed
attempt. You should see something like this
[ 318.420537] ieee80211 phy4: U iwl_bg_request_scan Start direct scan for 'myssid'
in the log. I can't see any reason why it would be missing. For me, the
association is instantaneous after saying "ap any". This is expected
too, because
iwconfig wlan0 essid "myessid"
will have triggered a directed scan for the AP.
There are two possible failure scenarios that I can imagine:
1) You see no line like the one above in your log, but rather
[ 736.047879] ieee80211 phy5: U iwl_bg_request_scan Start indirect scan.
This would indicate a bug in the driver.
2) You do see the line with the SSID, but you don't get any reply. In
this case, please try doing it manually:
iwlist wlan0 scan essid 'myssid'
Wait about 15 seconds between each attempt of doing so, and report
whether your AP is listed in the results or not. If it isn't most of the
time, then your AP is broken.
johannes
On Wed, Mar 18, 2009 at 3:22 AM, Johannes Berg
<[email protected]> wrote:
> I'm on 0191b62 now and cannot reproduce the problem with
> iwlwifi hardware and a linksys (broadcom-based) AP wit
> hidden SSID.
I think I know why it works on your but not mind.
I've tracked down to the sequence of iwconfig that causes it to fail.
I can now get vanilla 2.6.28-rc8 to work (7/10 times) by changing the
sequence of iwconfig.
This loop does not work at all without John's patch , but will work
100% when patched.
iwconfig wlan0 mode Managed essid xxx key restricted xxx
for((i = 0; i < 5; i++))
do
iwconfig wlan0 ap auto channel auto # auto inside loop
iwconfig wlan0 | grep -q "Access Point: Not-Associated"
[ $? -ne 0 ] && break
echo ".\c"
sleep 1
done
This loop only works 8 of 10 times with/without the patch.
iwconfig wlan0 mode Managed essid xxx key restricted xxx
iwconfig wlan0 ap auto channel auto # auto outside loop
for((i = 0; i < 5; i++))
do
iwconfig wlan0 | grep -q "Access Point: Not-Associated"
[ $? -ne 0 ] && break
echo ".\c"
sleep 1
done
The only difference is having "iwconfig wlan0 ap auto channel auto"
inside the loop.
> Then send me the relevant dmesg output from a working and a
> failed attempt. You should see something like this
> [ ?318.420537] ieee80211 phy4: U iwl_bg_request_scan Start
> direct scan for 'myssid'
Yes, I see it.
> 2) You do see the line with the SSID, but you don't get any reply. In
> this case, please try doing it manually:
> ? ? ? ?iwlist wlan0 scan essid 'myssid'
> Wait about 15 seconds between each attempt of doing so, and
> report whether your AP is listed in the results or not. If it isn't
> most of the time, then your AP is broken.
Can be broken if it works with the patch? Also, it works with WinXP,
Nokia phone, and everything else.
Attached are 4 logs (all runs with the "auto" outside loop).
nopatch.fail
nopatch.pass
patched.fail
patched.pass
Thanks,
Jeff.
On Thu, Mar 19, 2009 at 10:58 AM, Jeff Chua <[email protected]> wrote:
> I've tracked down to the sequence of iwconfig that causes it to fail.
> This loop only works 8 of 10 times with/without the patch.
> ? ? ? ?iwconfig wlan0 mode Managed essid xxx key restricted xxx
> ? ? ? ?iwconfig wlan0 ap auto channel auto ?# auto outside loop
> ? ? ? ?for((i = 0; i < 5; i++))
> ? ? ? ?do
> ? ? ? ? ? ? ? ?iwconfig wlan0 | grep -q "Not-Associated"
> ? ? ? ? ? ? ? ?[ $? -ne 0 ] && break
> ? ? ? ? ? ? ? ?echo ".\c"
> ? ? ? ? ? ? ? ?sleep 1
> ? ? ? ?done
I've modified it a little, and now it works 100% without patch, by
using "iwlist scan" instead of "sleep 1" ...
iwconfig wlan0 mode Managed essid xxx key restricted xxx
iwconfig wlan0 ap auto channel auto # auto outside loop
for((i = 0; i < 5; i++))
do
iwlist wlan0 scan >/dev/null #use scan instead of sleep
iwconfig $DEV | grep -q "Access Point: Not-Associated"
[ $? -ne 0 ] && break
echo ".\c"
done
So, this will work for older kernel and well as 2.6.29-rc8.
Rafael, can we close the case? It's the iwconfig sequence that used to
work on 2.6.28-rc3 but now needs to be updated for 2.6.29-rc8.
Thanks,
Jeff.
On Thu, Mar 19, 2009 at 11:25 AM, Jeff Chua <[email protected]> wrote:
> Rafael, can we close the case?
Not yet. I reran a few more times, and without patch, it'll fail sometimes.
Here's the 3 files. With patch, pass every time (so far).
nopatch.fail
nopatch.pass
passed.pass
> 1) You see no line like the one above in your log, but rather
> [ 736.047879] ieee80211 phy5: U iwl_bg_request_scan
> Start indirect scan.
> This would indicate a bug in the driver.
*** this is in nopatch.fail ***
2009-03-19T12:07:22.437578+08:00 boston kernel: ieee80211 phy0: U
iwl_bg_request_scan Start direct scan for 'sdg2088a88'
2009-03-19T12:07:24.337644+08:00 boston kernel: ieee80211 phy0: U
iwl_bg_request_scan Start indirect scan.
For the passing run, it's always "direct scan".
Thanks,
Jeff.
On Thu, Mar 19, 2009 at 10:58 AM, Jeff Chua <[email protected]> wrote:
> I've tracked down to the sequence of iwconfig that causes it to fail.
> This loop does not work at all without John's patch , but will work
> 100% when patched.
> This loop only works 8 of 10 times with/without the patch.
Ignore the above loop thing. The cause seems to be this one instead.
# this needs patch to work ...
iwconfig wlan0 mode Managed
ifconfig wlan0 up
iwconfig wlan0 essid xxx
iwconfig wlan0 key restricted xxx
iwconfig wlan0 ap auto channel auto
# this works with patch ...
iwconfig wlan0 mode Managed essid xxx key restricted xxx
ifconfig wlan0 up
iwconfig wlan0 ap auto channel auto
It looks the placement of "ifconfig" matters. But works on 2.6.28-rc3.
Thanks,
Jeff.
On Thu, 2009-03-19 at 12:49 +0800, Jeff Chua wrote:
> Ignore the above loop thing. The cause seems to be this one instead.
>
>
> # this needs patch to work ...
> iwconfig wlan0 mode Managed
> ifconfig wlan0 up
> iwconfig wlan0 essid xxx
> iwconfig wlan0 key restricted xxx
> iwconfig wlan0 ap auto channel auto
If you swap the key and essid lines, it will probably always work. But
I've yet to analyse your data to see why it doesn't in the other case.
johannes
On Monday 16 March 2009, Sitsofe Wheeler wrote:
> On Sat, Mar 14, 2009 at 08:05:32PM +0100, Rafael J. Wysocki wrote:
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12765
> > Subject : i915 VT switch with AIGLX causes X lock up
> > Submitter : Sitsofe Wheeler <[email protected]>
> > Date : 2009-02-21 15:38 (22 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=14d200c5e5bd19219d930bbb9a5a22758c8f5bec
> > References : http://marc.info/?l=linux-kernel&m=123523074304955&w=4
>
> Still here in 2.6.29-rc8.
Thanks for the update.
Rafael
On Monday 16 March 2009, Michael S. Tsirkin wrote:
> On Sat, Mar 14, 2009 at 08:05:29PM +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.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
> > Subject : possible circular locking dependency detected
> > Submitter : Michael S. Tsirkin <[email protected]>
> > Date : 2009-01-29 11:35 (45 days old)
> > References : http://lkml.org/lkml/2009/2/9/205
> >
>
> It's still there in rc8.
Thanks for the update.
Rafael
On Thu, Mar 19, 2009 at 10:38:54AM +0100, Johannes Berg wrote:
> On Thu, 2009-03-19 at 12:49 +0800, Jeff Chua wrote:
>
> > Ignore the above loop thing. The cause seems to be this one instead.
> >
> >
> > # this needs patch to work ...
> > iwconfig wlan0 mode Managed
> > ifconfig wlan0 up
> > iwconfig wlan0 essid xxx
> > iwconfig wlan0 key restricted xxx
> > iwconfig wlan0 ap auto channel auto
>
> If you swap the key and essid lines, it will probably always work. But
> I've yet to analyse your data to see why it doesn't in the other case.
That is what I was going to suggest. I go so far as to say that you
should set everything else before doing the "iwconfig wlan0 essid
xxx" bit.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
John W. Linville wrote:
> On Thu, Mar 19, 2009 at 10:38:54AM +0100, Johannes Berg wrote:
>> On Thu, 2009-03-19 at 12:49 +0800, Jeff Chua wrote:
>> > # this needs patch to work ...
>> > iwconfig wlan0 mode Managed
>> > ifconfig wlan0 up
>> > iwconfig wlan0 essid xxx
>> > iwconfig wlan0 key restricted xxx
>> > iwconfig wlan0 ap auto channel auto
>>
>> If you swap the key and essid lines, it will probably always work. But
>> I've yet to analyse your data to see why it doesn't in the other case.
>
> That is what I was going to suggest. I go so far as to say that you
> should set everything else before doing the "iwconfig wlan0 essid
> xxx" bit.
Mostly just curious, but is that actually required by some wireless
standard? If not, is it really reasonable to ask userland to do things in
that particular order?
Reason I ask is that for example when writing wireless support for e.g. a
distro installation system, it seems most logical to *first* ask the user
what network (ESSID) he wants to connect to. Next to check if we can
connect to that network without additional authentication and only then,
if needed, ask for keys etc.
If it's not possible to set that info in that logical order that seems
rather restrictive to me and would probably mean that you'd have to reset
AP, ESSID and possibly other settings before each incremental attempt.
Cheers,
FJP
On Thu, Mar 19, 2009 at 04:02:56PM +0100, Frans Pop wrote:
> John W. Linville wrote:
> > On Thu, Mar 19, 2009 at 10:38:54AM +0100, Johannes Berg wrote:
> >> On Thu, 2009-03-19 at 12:49 +0800, Jeff Chua wrote:
> >> > # this needs patch to work ...
> >> > iwconfig wlan0 mode Managed
> >> > ifconfig wlan0 up
> >> > iwconfig wlan0 essid xxx
> >> > iwconfig wlan0 key restricted xxx
> >> > iwconfig wlan0 ap auto channel auto
> >>
> >> If you swap the key and essid lines, it will probably always work. But
> >> I've yet to analyse your data to see why it doesn't in the other case.
> >
> > That is what I was going to suggest. I go so far as to say that you
> > should set everything else before doing the "iwconfig wlan0 essid
> > xxx" bit.
>
> Mostly just curious, but is that actually required by some wireless
> standard? If not, is it really reasonable to ask userland to do things in
> that particular order?
>
> Reason I ask is that for example when writing wireless support for e.g. a
> distro installation system, it seems most logical to *first* ask the user
> what network (ESSID) he wants to connect to. Next to check if we can
> connect to that network without additional authentication and only then,
> if needed, ask for keys etc.
> If it's not possible to set that info in that logical order that seems
> rather restrictive to me and would probably mean that you'd have to reset
> AP, ESSID and possibly other settings before each incremental attempt.
You can ask the user for the data in whatever order you like, but
when you are done collecting it you should issue the "iwconfig wlan0
essid xxx" command (or execute the SIOCSIWESSID ioctl) last. IMHO,
it is silly to even bother setting the SSID before you have set any
required key or (if you so choose) selecting an AP or channel.
This is a limitation of the wireless extensions API -- nothing in
the API really defines when an association should be triggered.
The mac80211 component uses the setting of the SSID as the trigger
for association. AFAIK, this ordering should work with all other
drivers as well.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Thu, Mar 19, 2009 at 11:24 PM, John W. Linville
<[email protected]> wrote:
> On Thu, Mar 19, 2009 at 04:02:56PM +0100, Frans Pop wrote:
>> John W. Linville wrote:
>> > On Thu, Mar 19, 2009 at 10:38:54AM +0100, Johannes Berg wrote:
>> >> On Thu, 2009-03-19 at 12:49 +0800, Jeff Chua wrote:
>> >> > # this needs patch to work ...
>> >> > iwconfig wlan0 mode Managed
>> >> > ifconfig wlan0 up
>> >> > iwconfig wlan0 essid xxx
>> >> > iwconfig wlan0 key restricted xxx
>> >> > iwconfig wlan0 ap auto channel auto
>> >>
>> >> If you swap the key and essid lines, it will probably always work.
I just discovered that "iwconfig wlan0 ap auto channel auto" is the
one causing the problem on 2.6.29-rc8. Remove the line and it'll
associate to the AP. Just tried on two different APs a few times, and
it seems to behave that way. If I execute the "auto" command, it'll
fail to associate, but works fine with the patch.
Jeff.
On Thu, 2009-03-19 at 16:02 +0100, Frans Pop wrote:
> Mostly just curious, but is that actually required by some wireless
> standard? If not, is it really reasonable to ask userland to do things in
> that particular order?
Wext is a mess, and we've known that for a long time... But no, the
sequence should _not_ be required, it's just _easier_ for the kernel,
and as such has a better probability of succeeding if there are
problems, it should still work though.
However, one thing that will _not_ work is this:
iwconfig wlan0 essid xyz
iwconfig wlan0 key s:xyz
you still need
iwconfig wlan0 ap any
or anything similar after setting the key to trigger the kernel to do
something.
> Reason I ask is that for example when writing wireless support for e.g. a
> distro installation system, it seems most logical to *first* ask the user
> what network (ESSID) he wants to connect to. Next to check if we can
> connect to that network without additional authentication and only then,
> if needed, ask for keys etc.
> If it's not possible to set that info in that logical order that seems
> rather restrictive to me and would probably mean that you'd have to reset
> AP, ESSID and possibly other settings before each incremental attempt.
That's a pretty wrong argument, nothing says your software cannot
collect all the information and then give it to the kernel at once
later, I think... In fact, this is required anyway when you use RSN or
WPA (wpa_supplicant needs all information at once), for example.
johannes
On Thu, 2009-03-19 at 12:23 +0800, Jeff Chua wrote:
> *** this is in nopatch.fail ***
>
> 2009-03-19T12:07:22.437578+08:00 boston kernel: ieee80211 phy0: U
> iwl_bg_request_scan Start direct scan for 'sdg2088a88'
>
> 2009-03-19T12:07:24.337644+08:00 boston kernel: ieee80211 phy0: U
> iwl_bg_request_scan Start indirect scan.
>
>
> For the passing run, it's always "direct scan".
That's because of your 'iwlist wlan0 scan' command, it triggers an
indirect scan, if you did 'iwlist wlan0 scan essid sdg2088a88' you would
get a direct scan there. It's always 'direct' for when it passes because
then you don't get to the point where you scan again, I think.
All in all, I don't see much in the logs, it seems to be behaving
properly and asking for a direct scan when you set the essid. The kernel
will not try to connect to an encrypted network before you give it a
key, but "iwconfig wlan0 ap any" should trigger the association
process...
Can you do something else for me?
Get iw (some distros ship it, or see wireless.kernel.org) and enter this
command:
iw dev wlan0 interface add moni0 type monitor flags none
Then,
ip link set moni0 up
Start a capture:
iwevent > /tmp/event.txt
Now do, in a separate shell:
iwconfig wlan0 essid ...
iwconfig wlan0 key ...
_Now_ start tcpdump:
tcpdump -i moni0 -s 10000 -w /tmp/dump.pkt
and in a separate shell do:
iwlist wlan0 scan last > /tmp/scan.txt ; iwconfig wlan0 ap any
(this is important in one command so it's timed closed together)
Send me the contents of all the files from a failed run please.
johannes
On Thursday 19 March 2009, Johannes Berg wrote:
> Wext is a mess, and we've known that for a long time... But no, the
> sequence should _not_ be required, it's just _easier_ for the kernel,
> and as such has a better probability of succeeding if there are
> problems, it should still work though.
>
> However, one thing that will _not_ work is this:
> iwconfig wlan0 essid xyz
> iwconfig wlan0 key s:xyz
>
> you still need:
> iwconfig wlan0 ap any
>
> or anything similar after setting the key to trigger the kernel to do
> something.
OK. Thanks for the info.
> > Reason I ask is that for example when writing wireless support for
> > e.g. a distro installation system, it seems most logical to *first*
> > ask the user what network (ESSID) he wants to connect to. Next to
> > check if we can connect to that network without additional
> > authentication and only then, if needed, ask for keys etc.
> > If it's not possible to set that info in that logical order that
> > seems rather restrictive to me and would probably mean that you'd
> > have to reset AP, ESSID and possibly other settings before each
> > incremental attempt.
>
> That's a pretty wrong argument, nothing says your software cannot
> collect all the information and then give it to the kernel at once
> later, I think... In fact, this is required anyway when you use RSN or
> WPA (wpa_supplicant needs all information at once), for example.
Well, the thing is that we'll already have tried just setting essid to
check if it's an open network. However, I can see the point of needing to
set the essid _again_ after asking the key info and setting that.
I can also see how you might have to unset some settings in some cases,
for example if the NIC has already associated with the wrong network
(e.g. because there's a totally open network in range).
Our current logic (in Debian Installer) definitely needs improving and
these pointers will help. Thanks.
On Thu, 2009-03-19 at 20:24 +0100, Frans Pop wrote:
> > > Reason I ask is that for example when writing wireless support for
> > > e.g. a distro installation system, it seems most logical to *first*
> > > ask the user what network (ESSID) he wants to connect to. Next to
> > > check if we can connect to that network without additional
> > > authentication and only then, if needed, ask for keys etc.
> > > If it's not possible to set that info in that logical order that
> > > seems rather restrictive to me and would probably mean that you'd
> > > have to reset AP, ESSID and possibly other settings before each
> > > incremental attempt.
> >
> > That's a pretty wrong argument, nothing says your software cannot
> > collect all the information and then give it to the kernel at once
> > later, I think... In fact, this is required anyway when you use RSN or
> > WPA (wpa_supplicant needs all information at once), for example.
>
> Well, the thing is that we'll already have tried just setting essid to
> check if it's an open network. However, I can see the point of needing to
> set the essid _again_ after asking the key info and setting that.
Ah.
> I can also see how you might have to unset some settings in some cases,
> for example if the NIC has already associated with the wrong network
> (e.g. because there's a totally open network in range).
No, there should be no need for that really, an
iwconfig wlan0 ap any
should always make it associate with the current settings.
Now, this thread is about why it doesn't for Jeff :)
johannes
On Thu, Mar 19, 2009 at 5:38 PM, Johannes Berg
<[email protected]> wrote:
> On Thu, 2009-03-19 at 12:49 +0800, Jeff Chua wrote:
>
>> Ignore the above loop thing. The cause seems to be this one instead.
>>
>>
>> # this needs patch to work ...
>> iwconfig wlan0 mode Managed
>> ifconfig wlan0 up
>> iwconfig wlan0 essid xxx
>> iwconfig wlan0 key restricted xxx
>> iwconfig wlan0 ap auto channel auto
>
> If you swap the key and essid lines, it will probably always work. But
> I've yet to analyse your data to see why it doesn't in the other case.
Doesn't. Taking away "hiwconfig wlan0 ap auto channel auto" makes it works.
Thanks,
Jeff.
On Fri, Mar 20, 2009 at 12:55 PM, Jeff Chua <[email protected]> wrote:
> On Thu, Mar 19, 2009 at 5:38 PM, Johannes Berg
> <[email protected]> wrote:
>> On Thu, 2009-03-19 at 12:49 +0800, Jeff Chua wrote:
>>
>>> Ignore the above loop thing. The cause seems to be this one instead.
>>>
>>>
>>> # this needs patch to work ...
>>> iwconfig wlan0 mode Managed
>>> ifconfig wlan0 up
>>> iwconfig wlan0 essid xxx
>>> iwconfig wlan0 key restricted xxx
>>> iwconfig wlan0 ap auto channel auto
>>
>> If you swap the key and essid lines, it will probably always work. But
>> I've yet to analyse your data to see why it doesn't in the other case.
>
> Doesn't. Taking away "hiwconfig wlan0 ap auto channel auto" makes it works.
More discoveries...
It seems position of "ifconfig wlan0 up" matters
1) It can't be before iwconfig which will result in "SET failed on
device wlan0 ; Device or resource busy".
2) _Before_ "essid" and "key" settings. "ap auto channel auto" MUST NOT BE SET.
3) _After_ "essid" and "key". Ensure all iwconfig settings comes
before "ifconfig".
So, it seems "ifconfig" must be done as the last stage.
Thanks,
Jeff.
On Fri, 2009-03-20 at 12:55 +0800, Jeff Chua wrote:
> >> # this needs patch to work ...
> >> iwconfig wlan0 mode Managed
> >> ifconfig wlan0 up
> >> iwconfig wlan0 essid xxx
> >> iwconfig wlan0 key restricted xxx
> >> iwconfig wlan0 ap auto channel auto
> >
> > If you swap the key and essid lines, it will probably always work. But
> > I've yet to analyse your data to see why it doesn't in the other case.
>
> Doesn't. Taking away "hiwconfig wlan0 ap auto channel auto" makes it works.
That's a little weird, but not entirely, you probably manage to cut it
short in the middle of the assoc process when issuing the auto command.
> It seems position of "ifconfig wlan0 up" matters
>
> 1) It can't be before iwconfig which will result in "SET failed on
> device wlan0 ; Device or resource busy".
>
> 2) _Before_ "essid" and "key" settings. "ap auto channel auto" MUST
> NOT BE SET.
>
> 3) _After_ "essid" and "key". Ensure all iwconfig settings comes
> before "ifconfig".
>
>
> So, it seems "ifconfig" must be done as the last stage.
This, however, is completely strange. You should always set the
interface up before doing anything with it. wext allows you to do it the
other way around, but that's not quite natural since without it being up
you cannot even scan.
However, -EBUSY isn't returned anywhere in mac80211, and I don't see the
driver passing it out either. So your point 1) confuses me. Can you
explain that a little more?
As for 2), that is very very strange since ap auto channel auto is the
default, so saying that before you do anything else should do anything
at all.
I suspect something is going on in the driver because the ifconfig order
matters and for mac80211, it shouldn't make a difference when the state
machine is really started. I'll probably need to try to reproduce this,
but to be honest between the varying failure modes, undefined wireless
extensions semantics, etc. I'm not very confident I can.
johannes
On Fri, Mar 20, 2009 at 4:32 PM, Johannes Berg
<[email protected]> wrote:
> 1) It can't be before iwconfig which will result in "SET failed on
> device wlan0 ; Device or resource busy".
> So your point 1) confuses me. Can you
> explain that a little more?
This is what happened ...
# modprobe -r iwlagn
# modprobe iwlagn
# ifconfig wlan0 up
# iwconfig wlan0 mode Managed
Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Device or resource busy.
> As for 2), that is very very strange since ap auto channel auto is the
> default, so saying that before you do anything else should do anything
> at all.
>
> I suspect something is going on in the driver because the ifconfig order
> matters and for mac80211, it shouldn't make a difference when the state
> machine is really started. I'll probably need to try to reproduce this,
> but to be honest between the varying failure modes, undefined wireless
> extensions semantics, etc. I'm not very confident I can.
I'll try all the different combination again for 2.6.28, and see if
it's the same, and on the other AP that seems harder to associate (but
works well in 2.6.28, and other OSs include Nokia phones ... so I
don't think it's the AP problem ... because it's been around a while
and gone thru many 2.6.xx).
It worked so well before that I didn't even bother to think twice, and
I may have made silly mistakes along the way, so pardon me if I
confused you.
Thanks for your help.
Jeff.
On Fri, 2009-03-20 at 18:04 +0800, Jeff Chua wrote:
> On Fri, Mar 20, 2009 at 4:32 PM, Johannes Berg
> <[email protected]> wrote:
> > 1) It can't be before iwconfig which will result in "SET failed on
> > device wlan0 ; Device or resource busy".
> > So your point 1) confuses me. Can you
> > explain that a little more?
>
> This is what happened ...
>
> # modprobe -r iwlagn
> # modprobe iwlagn
> # ifconfig wlan0 up
> # iwconfig wlan0 mode Managed
> Error for wireless request "Set Mode" (8B06) :
> SET failed on device wlan0 ; Device or resource busy.
Oh, ok, yes, you cannot change the mode while the interface is up.
Though I guess setting it to the same mode should be accepted. Not that
it matters, the default mode is "managed" anyway.
> > As for 2), that is very very strange since ap auto channel auto is the
> > default, so saying that before you do anything else should do anything
> > at all.
> >
> > I suspect something is going on in the driver because the ifconfig order
> > matters and for mac80211, it shouldn't make a difference when the state
> > machine is really started. I'll probably need to try to reproduce this,
> > but to be honest between the varying failure modes, undefined wireless
> > extensions semantics, etc. I'm not very confident I can.
>
> I'll try all the different combination again for 2.6.28, and see if
> it's the same, and on the other AP that seems harder to associate (but
> works well in 2.6.28, and other OSs include Nokia phones ... so I
> don't think it's the AP problem ... because it's been around a while
> and gone thru many 2.6.xx).
Yeah, I have to admit that an AP problem doesn't make much sense -- but
the entire failure mode doesn't make much sense to me so far.
> It worked so well before that I didn't even bother to think twice, and
> I may have made silly mistakes along the way, so pardon me if I
> confused you.
No worries. It really should still work well. Can I convince you to try
getting the packet dump I asked for in another mail?
johannes
On Fri, Mar 20, 2009 at 6:13 PM, Johannes Berg
<[email protected]> wrote:
> Can I convince you to try getting the packet dump I asked for in
> another mail?
Was digging around for the "iw" package and got distracted. I'll test it soon.
I went back to 2.6.28 and found out that I could associate as follows
(but this would not work in 2.6.29-rc8 ... should work with the
patch).
modprobe -r iwlagn
modprobe iwlagn
iwconfig wlan0 mode Managed
ifconfig wlan0 up
iwconfig wlan0 essid "xxx"
iwconfig wlan0 key restricted xxx
iwconfig wlan0 ap auto channel auto
iwlist wlan0 scan >/dev/null
Thanks,
Jeff.
On Fri, Mar 20, 2009 at 12:59 AM, Johannes Berg
<[email protected]> wrote:
> Send me the contents of all the files from a failed run please.
Attached. 2 runs.
Thanks,
Jeff.
On Sat, 2009-03-21 at 00:14 +0800, Jeff Chua wrote:
> I went back to 2.6.28 and found out that I could associate as follows
> (but this would not work in 2.6.29-rc8 ... should work with the
> patch).
>
> modprobe -r iwlagn
> modprobe iwlagn
> iwconfig wlan0 mode Managed
> ifconfig wlan0 up
> iwconfig wlan0 essid "xxx"
> iwconfig wlan0 key restricted xxx
> iwconfig wlan0 ap auto channel auto
> iwlist wlan0 scan >/dev/null
Thing is that this works perfectly fine for me, on very similar
hardware.
OTOH, maybe it got _fixed_ again. Would you check wireless-testing
(http://wireless.kernel.org/en/developers/Documentation#wireless-testing.git) for me? Or compat-wireless (http://wireless.kernel.org/en/users/Download)
johannes
On Sat, Mar 21, 2009 at 8:09 PM, Johannes Berg
<[email protected]> wrote:
> Thing is that this works perfectly fine for me, on very similar
> hardware.
I've set hidden SSID + mac address filtering (only allow my notebook
MAC address) as well as 128 WEP. And no problem to associate with
non-hidden AP.
> OTOH, maybe it got _fixed_ again. Would you check wireless-testing
> (http://wireless.kernel.org/en/developers/Documentation#wireless-testing.git) for me? Or compat-wireless (http://wireless.kernel.org/en/users/Download)
I'll try that tomorrow. Seems a lot to pull from git.
Thanks,
Jeff.
On Sat, 2009-03-21 at 23:08 +0800, Jeff Chua wrote:
> On Sat, Mar 21, 2009 at 8:09 PM, Johannes Berg
> <[email protected]> wrote:
> > Thing is that this works perfectly fine for me, on very similar
> > hardware.
>
> I've set hidden SSID + mac address filtering (only allow my notebook
> MAC address) as well as 128 WEP. And no problem to associate with
> non-hidden AP.
Ok, I haven't tried WEP or MAC address filtering, but I don't see how
those would make a significant difference. I can try again, but not
before mid next week since I'm away from my test machine.
> > OTOH, maybe it got _fixed_ again. Would you check wireless-testing
> >
> (http://wireless.kernel.org/en/developers/Documentation#wireless-testing.git) for me? Or compat-wireless (http://wireless.kernel.org/en/users/Download)
>
> I'll try that tomorrow. Seems a lot to pull from git.
Thanks, I appreciate it. You should be able to cut it down by using
--reference /path/to/local/linux-git-tree or just compat (though I would
recommend using the git tree). I've also tried to go back to the
versions you were testing before and had no problem.
johannes