Created attachment 789798 [details] /var/log/messages after system freezes and reboot Description of problem: When I run command 'ip link set wlp2s1 up' system is freezes. 02:01.0 Network controller: Ralink corp. RT3060 Wireless 802.11n 1T/1R (see attachments) Version-Release number of selected component (if applicable): kernel-3.10.7-200.fc19.x86_64 kernel-3.11.0-0.rc6.git2.2.fc19.R.x86_64 (rebuild from koji) How reproducible: All time Steps to Reproduce: 1. Boot with given wireless adapter 2. run command 'ip link set wlp2s1 up' 3. system freezes Actual results: System freezes Expected results: Network interface up and works as expected Additional info:
Created attachment 789799 [details] dmesg
Created attachment 789800 [details] lspci -knnn
Created attachment 789801 [details] dmidecode
This error occurs on my computer. If it is necessary, I'm ready to re-examine or to provide additional information.
I got the same bug on a laptop with brcmsmac. Downgrade kernel to 3.9.9 helps me.
(In reply to Alexei Panov from comment #5) > I got the same bug on a laptop with brcmsmac. > Downgrade kernel to 3.9.9 helps me. Let me start bisect (if jwb or jforbes or ... not opposed)
Downgrade kernel to 3.9.9 helps me too. Today I rechecked it. With kernel 3.9.9-302.fc19.x86_64 system not freeze when 'ip link set wlp2s1 up' (rt2800pci).
Does this happen with 3.10.9? There were some minstrel_ht related fixes that went into that kernel.
Created attachment 790642 [details] bisect.log (In reply to Josh Boyer from comment #8) > Does this happen with 3.10.9? There were some minstrel_ht related fixes > that went into that kernel. No. Problem w/ rt2800pci is still on 3.10.9, but fixed problem w/ brcmsmac Today we started git bisect. But now we haven't completed bisect. Tomorrow I can say what patch causes this regression.
Is this 3.9 -> 3.10 regression or 3.10.0 -> 3.10.9 regression ? If the later, it is most likely problem described here: http://marc.info/?l=linux-kernel&m=137697458915806&w=2 and we also need to disable HT_CCK rates on rt2800 i.e. --- a/drivers/net/wireless/rt2x00/rt2800lib.c +++ b/drivers/net/wireless/rt2x00/rt2800lib.c @@ -5912,8 +5912,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev) IEEE80211_HW_SUPPORTS_PS | IEEE80211_HW_PS_NULLFUNC_STACK | IEEE80211_HW_AMPDU_AGGREGATION | - IEEE80211_HW_REPORTS_TX_ACK_STATUS | - IEEE80211_HW_SUPPORTS_HT_CCK_RATES; + IEEE80211_HW_REPORTS_TX_ACK_STATUS; /* * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices Igor, could you check that if that helps, if not please continue bisection :-)
(In reply to Stanislaw Gruszka from comment #10) > Is this 3.9 -> 3.10 regression or 3.10.0 -> 3.10.9 regression ? > > If the later, it is most likely problem described here: > > http://marc.info/?l=linux-kernel&m=137697458915806&w=2 > > and we also need to disable HT_CCK rates on rt2800 i.e. > > --- a/drivers/net/wireless/rt2x00/rt2800lib.c > +++ b/drivers/net/wireless/rt2x00/rt2800lib.c > @@ -5912,8 +5912,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev > *rt2x00dev) > IEEE80211_HW_SUPPORTS_PS | > IEEE80211_HW_PS_NULLFUNC_STACK | > IEEE80211_HW_AMPDU_AGGREGATION | > - IEEE80211_HW_REPORTS_TX_ACK_STATUS | > - IEEE80211_HW_SUPPORTS_HT_CCK_RATES; > + IEEE80211_HW_REPORTS_TX_ACK_STATUS; > > /* > * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices > > Igor, could you check that if that helps, if not please continue bisection > :-) Ok. I will prepare kernel rpms w/ this patch for Maxim. If this not helps we will continue bisect.
Maxim, please test koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5859000 Stanislaw, but actually this regression at the begin of May. 1-3 of numbers. Bisecting: 373 revisions left to test after this (roughly 9 steps) After test this kernel we can draw conclusions.
With kernel-3.11.0-0.rc7.git0.1rhbz1000679.fc19 (http://koji.fedoraproject.org/koji/taskinfo?taskID=5859000), x86_64 my system freeze when 'ip link set wlp2s1 up'. Tomorrow I will continue my search commit using bisect
Created attachment 791276 [details] bisect.log Hi Stanislaw again! We continue bisect and I was wrong. Wrong commit above 86feff3f3eb643cc5735d414e46a8201a8c67b8f and 5743756161518f279ad0bd21437713f7bc3f0a81. It's above March and April. Not May. 17-20 of March was many commits with rt2x00 and mac80211 but we can't test it all. On Maxim's PC many kernels from this dates has not boot (have kernel panic). You have idea what commit might be problem more accurately?
Only thing I know which could help is "git bisect skip", but seems you know about it already. Did you also try to limit bisection to drivers i.e. "git bisect start -- net/mac80211/ net/wireless/ drivers/net/wireless/rt2x00/" ? If not you can try that. But perhaps we can try to debug this by traditional way, i.e. get kernel messages which print what is wrong. Maxim, please install kernel-debug, boot to it, switch to virtual console from X window (i.e. Ctrl+Alt+F3) and run this 'ip link set wlp2s1 up' command. It should print some messages before kernel hung, please take a photo of the screen and attach it here.
I assemble kernel and install it without rpm-pakage (to spare time), that's why I don't know how to get kernel-debug. I will ask Igor Gnatenko about this. Concerning check-out - I always check (test) in console (Ctrl+Alt+F2), and there is no message, the system just freeze. Now I see: Bisecting: 28 revisions left to test after this (roughly 5 steps) [345fb3f8efe5a4bf4f0e34e0a988b1482cbe9aa2] Merge tag 'for-linville-20130318' of git://github.com/kvalo/ath6kl :)
(In reply to Stanislaw Gruszka from comment #15) > Only thing I know which could help is "git bisect skip", but seems you know > about it already. Did you also try to limit bisection to drivers i.e. "git > bisect start -- net/mac80211/ net/wireless/ drivers/net/wireless/rt2x00/" ? > If not you can try that. Yeah. We used skip. I didn't notice about limit bisection to drives. Is it works w/ started bisection? don't we lose current results?
(In reply to Maxim Polyakov from comment #16) > I assemble kernel and install it without rpm-pakage (to spare time), that's > why I don't know how to get kernel-debug. yum install kernel-debug and you have to setup grub to boot that kernel
Created attachment 791376 [details] bisect.log We found bad commit. I will soon create rpm package w/ revert this commit. c630ccf1a127578421a928489d51e99c05037054 is the first bad commit commit c630ccf1a127578421a928489d51e99c05037054 Author: Stanislaw Gruszka <stf_xl> Date: Sat Mar 16 19:19:46 2013 +0100 rt2800: rearrange bbp/rfcsr initialization This makes order of initialization of various registers similar like on vendor driver. Based on: NICInitializeAsic() RT5592LoadRFNormalModeSetup() from: DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chip/rt5592.c Signed-off-by: Stanislaw Gruszka <stf_xl> Tested-by: Wanlong Gao <gaowanlong.com> Signed-off-by: John W. Linville <linville> :040000 040000 69266bfa97e9e808257f9cfa7196f00222410ebf 7e18f08faa95bb3dd7159381d6085e5b5287809c M drivers
I can't revert this commit. We have too many commits in this file after. Stanislaw, what we should to do ?
Hmm, bad commit does not looks like it can cause freezes. Since revert is not possible, you can verify that by: # git checkout -b test1 c630ccf1a127578421a928489d51e99c05037054 This one should freeze. # git checkout -b test2 c630ccf1a127578421a928489d51e99c05037054~1 If bisection was correct, this one should work ok. Even if bisection was correct, I'm not really sure where the problem is ... Maxim, did you try install debug kernel ? Does it print any messages before freeze ?
"test1" - system freeze "test2" - Ok "RFRemix, with Linux 3.10.9-200.fc19.x86_64.debug" - system freeze without any messages before freeze http://s018.radikal.ru/i503/1308/1f/b54bb725c1a5.png
Created attachment 792041 [details] journalctl from kernel-debug
Created attachment 793152 [details] revert_c630ccf1a127578421a928489d51e99c05037054.patch Here is patch that reverts non RT5592 specific part of commit c630ccf1a127578421a928489d51e99c05037054 . It applies on top of 3.11. Does it prevent freeze ?
Applied patch to upstream 3.11.0. http://ignatenkobrain.fedorapeople.org/kernel/rhbz1000679/ Maxim, please test this kernel.
With that kernel everything works.
Created attachment 793744 [details] 0001-rt2800-change-initialization-sequence.patch Modified revert - proposed fix. It should be the final patch to test. Maxim, does it still work for you? Kernel build with the patch is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5893626
"RFRemix, with Linux 3.9.9-302.fc19.x86_64" - system freeze without any messages before freeze "RFRemix, with Linux 3.9.9-302.fc19.x86_64.debug" - system freeze without any messages before freeze
Sorry, 3.9.9-302.fc19.x86_64 = kernel-3.10.10-200 I was wrong when he wrote the report
(In reply to Maxim Polyakov from comment #29) > Sorry, > 3.9.9-302.fc19.x86_64 = kernel-3.10.10-200 > I was wrong when he wrote the report I understand that the kernel from comment 27 (kernel-3.10.10-200.bz1000679.fc19) frezes, correct ?
(In reply to Stanislaw Gruszka from comment #30) > (In reply to Maxim Polyakov from comment #29) > > Sorry, > > 3.9.9-302.fc19.x86_64 = kernel-3.10.10-200 > > I was wrong when he wrote the report > I understand that the kernel from comment 27 > (kernel-3.10.10-200.bz1000679.fc19) frezes, correct ? I spoke w/ him at jabber. It's correct. Stanislaw, also I think more better change status to assign.
Igor, thank you! Yes, indeed, all right. System freeze without any messages before freeze - kernel-3.10.10-200 (http://koji.fedoraproject.org/koji/taskinfo?taskID=5893626)
I retest kernel-3.10.10-200 - Ok All works in Fedora (3.10.10-200.bz1000679.fc19.x86_64) 19 (Schrödinger’s Cat) Before checking I removed the kernel: # yum remove kernel*3.10.10* and reinstall 3.10.10-200 I apologize for improperly conducted the test
Comment on attachment 793744 [details] 0001-rt2800-change-initialization-sequence.patch fixes bug.
Patch posted here: http://marc.info/?l=linux-wireless&m=137872301718879&w=2 This is 3.11 version, 3.10 version is attached on comment 27. Josh, please apply patch as fix for this bug.
Applied, thanks!
kernel-3.10.11-200.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.10.11-200.fc19
kernel-3.10.11-100.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.10.11-100.fc18
Package kernel-3.10.11-100.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.10.11-100.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16336/kernel-3.10.11-100.fc18 then log in and leave karma (feedback).
kernel-3.10.11-200.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.11.1-300.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.1-300.fc20
kernel-3.10.11-100.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.11.1-300.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.