Re: 4.10.9 nok with realtek wlan, atom
On Sun, Apr 16, 2017 at 6:02 PM, Larry Finger <larry.fin...@lwfinger.net> wrote:
> On 04/16/2017 05:23 AM, rupert THURNER wrote:
>>
>> On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger
>> <larry.fin...@lwfinger.net> wrote:
>>>
>>> On 04/14/2017 03:26 PM, rupert THURNER wrote:
>>>>
>>>>
>>>> On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <larry.fin...@lwfinger.net>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> [+cc rtl8192ce folks in case they've seen this]
>>>>>>
>>>>>> On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> hi,
>>>>>>>
>>>>>>> not technical expert enough, i just wanted to give a short user
>>>>>>> feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
>>>>>>> kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
>>>>>>> well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
>>>>>>> hotspot is possible then drops, or connecting to wlan fails
>>>>>>> alltogether.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks very much for your report, and sorry for the inconvenience.
>>>>>>
>>>>>> v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.
>>>>>>
>>>>>> But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
>>>>>> need to figure out why and make sure we fix the v4.9 stable series.
>>>>>>
>>>>>> I can't tell yet whether this is PCI-related or not. If it is,
>>>>>> 4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
>>>>>> appeared in v4.9.6, and there is a known issue with that. The issue
>>>>>> should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
>>>>>> as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
>>>>>> the first thing to do would be to test v4.9.9.
>>>>>>
>>>>>> If it's not fixed in v4.9.9, can you share the complete dmesg log
>>>>>> (output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
>>>>>> known working version) and v4.9.6 (first known broken version)? On
>>>>>> v4.9.6, collect the dmesg output after the failure occurs.
>>>>>>
>>>>>>> 24: PCI 300.0: 0282 WLAN controller
>>>>>>> [Created at pci.366]
>>>>>>> Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
>>>>>>> Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
>>>>>>> Revision: 0x01
>>>>>>> Driver: "rtl8192ce"
>>>>>>> Driver Modules: "rtl8192ce"
>>>>>>> Device File: wlp3s0
>>>>>>> Features: WLAN
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> It would be helpful if someone were to bisect this issue. The only
>>>>> issue
>>>>> that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi:
>>>>> rtl8192ce:
>>>>> Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
>>>>> backported to 4.9.
>>>>>
>>>>> The above issue is one that could not be reproduced on my hardware,
>>>>> thus
>>>>> it
>>>>> took Jurij Smakov to find the fix. Without his bisection of the
>>>>> problem,
>>>>> who
>>>>> knows how long it would have taken to find my edit mistake.
>>>>
>>>>
>>>>
>>>> larry, using the newest kernel 4.10.8 the network connection dropps
>>>> again irregular.
>>>>
>>>> # dmesg
>>>> [0.00] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
>>>> version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
>>>> 2017
>>>> [ 11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
>>>> [ 11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
>>>> [ 11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
>>>> [ 11.978945] rtlwifi: rtlwifi: wireless switch is on
>>>>
>>>> # lspci -vv
>>>> Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi
>>>> Adapter
>>>> Kernel driver in use: rtl8192ce
>>>
>>>
>>>
>>> Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?
>>
>>
>> 4.10.x used to work. 4.10.6 or 4.10.7 it started failing? i am not too
>> sure about it.
>>
>> # ls -l /usr/lib/firmware/rtlwifi/rtl8192cfw.bin
>> -rw-r--r-- 1 root root 16192 Mar 10 12:15
>> /usr/lib/firmware/rtlwifi/rtl8192cfw.bin
>
>
> That does not answer my question.
4.10, 4.10.2, 4.10.3, 4.10.5 worked. as far as i can tell
rtl8192cfw.bin did not change and was used. with kernels 4.9 there was
a phase where rtl8192cfwU.bin was loaded which did not work. or i do
not understand your question correctly?
Re: 4.10.9 nok with realtek wlan, atom
On Sat, Apr 15, 2017 at 10:40 PM, Larry Finger
<larry.fin...@lwfinger.net> wrote:
> On 04/14/2017 03:26 PM, rupert THURNER wrote:
>>
>> On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <larry.fin...@lwfinger.net>
>> wrote:
>>>
>>> On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:
>>>>
>>>>
>>>> [+cc rtl8192ce folks in case they've seen this]
>>>>
>>>> On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:
>>>>>
>>>>>
>>>>> hi,
>>>>>
>>>>> not technical expert enough, i just wanted to give a short user
>>>>> feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
>>>>> kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
>>>>> well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
>>>>> hotspot is possible then drops, or connecting to wlan fails
>>>>> alltogether.
>>>>
>>>>
>>>>
>>>> Thanks very much for your report, and sorry for the inconvenience.
>>>>
>>>> v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.
>>>>
>>>> But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
>>>> need to figure out why and make sure we fix the v4.9 stable series.
>>>>
>>>> I can't tell yet whether this is PCI-related or not. If it is,
>>>> 4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
>>>> appeared in v4.9.6, and there is a known issue with that. The issue
>>>> should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
>>>> as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
>>>> the first thing to do would be to test v4.9.9.
>>>>
>>>> If it's not fixed in v4.9.9, can you share the complete dmesg log
>>>> (output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
>>>> known working version) and v4.9.6 (first known broken version)? On
>>>> v4.9.6, collect the dmesg output after the failure occurs.
>>>>
>>>>> 24: PCI 300.0: 0282 WLAN controller
>>>>> [Created at pci.366]
>>>>> Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
>>>>> Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
>>>>> Revision: 0x01
>>>>> Driver: "rtl8192ce"
>>>>> Driver Modules: "rtl8192ce"
>>>>> Device File: wlp3s0
>>>>> Features: WLAN
>>>
>>>
>>>
>>> It would be helpful if someone were to bisect this issue. The only issue
>>> that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
>>> Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
>>> backported to 4.9.
>>>
>>> The above issue is one that could not be reproduced on my hardware, thus
>>> it
>>> took Jurij Smakov to find the fix. Without his bisection of the problem,
>>> who
>>> knows how long it would have taken to find my edit mistake.
>>
>>
>> larry, using the newest kernel 4.10.8 the network connection dropps
>> again irregular.
>>
>> # dmesg
>> [0.00] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
>> version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
>> 2017
>> [ 11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
>> [ 11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
>> [ 11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
>> [ 11.978945] rtlwifi: rtlwifi: wireless switch is on
>>
>> # lspci -vv
>> Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi
>> Adapter
>> Kernel driver in use: rtl8192ce
>
>
> Is firmware rtlwifi/rtl8192cfw.bin also used on kernels that work?
4.10.x used to work. 4.10.6 or 4.10.7 it started failing? i am not too
sure about it.
# ls -l /usr/lib/firmware/rtlwifi/rtl8192cfw.bin
-rw-r--r-- 1 root root 16192 Mar 10 12:15
/usr/lib/firmware/rtlwifi/rtl8192cfw.bin
rupert
4.10.9 nok with realtek wlan, atom
On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <larry.fin...@lwfinger.net> wrote:
> On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:
>>
>> [+cc rtl8192ce folks in case they've seen this]
>>
>> On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:
>>>
>>> hi,
>>>
>>> not technical expert enough, i just wanted to give a short user
>>> feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
>>> kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
>>> well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
>>> hotspot is possible then drops, or connecting to wlan fails
>>> alltogether.
>>
>>
>> Thanks very much for your report, and sorry for the inconvenience.
>>
>> v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.
>>
>> But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
>> need to figure out why and make sure we fix the v4.9 stable series.
>>
>> I can't tell yet whether this is PCI-related or not. If it is,
>> 4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
>> appeared in v4.9.6, and there is a known issue with that. The issue
>> should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
>> as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
>> the first thing to do would be to test v4.9.9.
>>
>> If it's not fixed in v4.9.9, can you share the complete dmesg log
>> (output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
>> known working version) and v4.9.6 (first known broken version)? On
>> v4.9.6, collect the dmesg output after the failure occurs.
>>
>>> 24: PCI 300.0: 0282 WLAN controller
>>> [Created at pci.366]
>>> Model: "Realtek RTL8188CE 802.11b/g/n WiFi Adapter"
>>> Device: pci 0x8176 "RTL8188CE 802.11b/g/n WiFi Adapter"
>>> Revision: 0x01
>>> Driver: "rtl8192ce"
>>> Driver Modules: "rtl8192ce"
>>> Device File: wlp3s0
>>> Features: WLAN
>
>
> It would be helpful if someone were to bisect this issue. The only issue
> that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
> Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
> backported to 4.9.
>
> The above issue is one that could not be reproduced on my hardware, thus it
> took Jurij Smakov to find the fix. Without his bisection of the problem, who
> knows how long it would have taken to find my edit mistake.
larry, using the newest kernel 4.10.8 the network connection dropps
again irregular.
# dmesg
[0.00] Linux version 4.10.9-1-ARCH (builduser@tobias) (gcc
version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Apr 8 12:39:59 CEST
2017
[ 11.933373] rtl8192ce: rtl8192ce: Power Save off (module option)
[ 11.933396] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
[ 11.978307] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 11.978945] rtlwifi: rtlwifi: wireless switch is on
# lspci -vv
Subsystem: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter
Kernel driver in use: rtl8192ce
best,
rupert
Re: linux <=4.9.5, 4.10-rc7 ok, 4.9.6 - 4.9.8 nok with realtek wlan, atom
On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger <larry.fin...@lwfinger.net> wrote:
> On 02/09/2017 01:43 PM, Bjorn Helgaas wrote:
>>
>> [+cc rtl8192ce folks in case they've seen this]
>>
>> On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote:
>>>
>>> hi,
>>>
>>> not technical expert enough, i just wanted to give a short user
>>> feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and
>>> kernel 4.10.0-rc7-g926af6273fc6 (arch linux-git version numbering) as
>>> well. kernels 4.9.6, 4.9.7, and 4.9.8 fail, i.e. connection to a WLAN
>>> hotspot is possible then drops, or connecting to wlan fails
>>> alltogether.
>>
>>
>> Thanks very much for your report, and sorry for the inconvenience.
>>
>> v4.10-rc7 works, so I guess we don't need to worry about fixing v4.10.
>>
>> But the stable kernels v4.9.6, v4.9.7, and v4.9.8 are broken, so we
>> need to figure out why and make sure we fix the v4.9 stable series.
>>
>> I can't tell yet whether this is PCI-related or not. If it is,
>> 4922a6a5cfa7 ("PCI: Enumerate switches below PCI-to-PCIe bridges")
>> appeared in v4.9.6, and there is a known issue with that. The issue
>> should be fixed by 610c2b7ff8f6 ("PCI/ASPM: Handle PCI-to-PCIe bridges
>> as roots of PCIe hierarchies"), which appeared in v4.9.9, so I guess
>> the first thing to do would be to test v4.9.9.
>>
>> If it's not fixed in v4.9.9, can you share the complete dmesg log
>> (output of "dmesg" command) and "lspci -vv" output for v4.9.5 (last
>> known working version) and v4.9.6 (first known broken version)? On
>> v4.9.6, collect the dmesg output after the failure occurs.
>
> It would be helpful if someone were to bisect this issue. The only issue
> that comes to mind was fixed in commit 52f5631a4c05 ("rtlwifi: rtl8192ce:
> Fix loading of incorrect firmware") which is in 4.10-rc7 and will be
> backported to 4.9.
thanks for the quick and very helpful hints! larry, it matches what
you write - 4.9.9 dropped the connection after a couple of hours.
lspci -vv is the same for 4.9.5 and 4.9.6. dmesg for both below. in
this case with 4.9.6 it did never get a network connection after boot.
$ sudo lspci -vv
00:00.0 Host bridge: Intel Corporation Atom Processor
D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
Subsystem: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-
Kernel modules: intel_agp
00:1b.0 Audio device: Intel Corporation NM10/ICH7 Family High
Definition Audio Controller (rev 02)
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 2005
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
SERR- TAbort-
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
L0s <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #32, PowerLimit 10.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0f00c Data: 41a1
Capabilities: [90] Subsystem: Holco Enterprise Co, Ltd/Shuttle
Computer Device 2005
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64-
