Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Andre Valentin writes: > Am 07.04.20 um 17:49 schrieb Bjørn Mork: >> Just remembered an issue on my todo list: There have been some MTU >> handling changes in the kernel networking API. This affected the >> qmi_wwan QMAP handling. I am not sure about the current status. Will >> have to dig a bit more. But this might be your problem. > > > That made me set MTU of wwan0 to 1600, and the qmimux* to 1500. No more > problems anymore. > This should go into documentation, not that anybody makes the same errors. Yes, this goes into the list of issues I'd like to fix with the QMAP implementation. It's also unnecessary hard to configure. And there is no way to figure out which qmap netdev belongs to which mux_id. > How much overhead does qmux create (for correct calculated MTU > offset)? Looks like 4 bytes: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/qmi_wwan.c#n66 Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Fri, Apr 10, 2020 at 2:29 PM Andre Valentin wrote: > [snip] > > Does these changes makes the job for you? Attached new patch. This hopefully works. > No, it does not work. Again I get this: > root@OpenWrt:/# cat /proc/interrupts >CPU0 CPU1 CPU2 CPU3 > 8: 10317 10061 10366 10342 MIPS GIC Local 1 timer > 9: 10946 0 0 0 MIPS GIC 63 IPI call > 10: 0 1973 0 0 MIPS GIC 64 IPI call > 11: 0 0 24992 0 MIPS GIC 65 IPI call > 12: 0 0 0 2087 MIPS GIC 66 IPI call > 13: 1795 0 0 0 MIPS GIC 67 IPI resched > 14: 0 2072 0 0 MIPS GIC 68 IPI resched > 15: 0 0 1883 0 MIPS GIC 69 IPI resched > 16: 0 0 0 1920 MIPS GIC 70 IPI resched > 17: 0 0 0 0 MIPS GIC 19 > 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2 > 19:149 0 0 0 MIPS GIC 33 ttyS0 > 20: 0 0 0 0 MIPS GIC 29 xhci-hcd:usb1 > 21: 10 0 0 0 MIPS GIC 10 > 1e10.ethernet > 23: 0 0 0 0 MIPS GIC 11 mt7615e > ERR: 1 > > Shouldn't at least be something about pci interrupts here? Depending of the number of pcie buses your hardware is using you see here if it has associated irq. So for you only one bus (bus 0) and one slot (slot 1). This means your link status should be '0x2' and the irq to map for this bus should be the number 24 instead of 23. For me with this patch applied I got (not changes here because I am using the three buses): # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 7: 0 0 0 0 MIPS 7 timer 8: 13231 12986 12973 12982 MIPS GIC Local 1 timer 9: 3261 0 0 0 MIPS GIC 63 IPI call 10: 0 1025 0 0 MIPS GIC 64 IPI call 11: 0 0 2196 0 MIPS GIC 65 IPI call 12: 0 0 0 1498 MIPS GIC 66 IPI call 13:488 0 0 0 MIPS GIC 67 IPI resched 14: 0815 0 0 MIPS GIC 68 IPI resched 15: 0 0 2284 0 MIPS GIC 69 IPI resched 16: 0 0 0 3671 MIPS GIC 70 IPI resched 17: 0 0 0 0 MIPS GIC 19 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2 18:114 0 0 0 MIPS GIC 33 ttyS0 19: 0 0 0 0 MIPS GIC 27 1e13.sdhci 20: 26 0 0 0 MIPS GIC 29 xhci-hcd:usb1 21: 10 0 0 0 MIPS GIC 10 1e10.ethernet 23: 0 0 0 0 MIPS GIC 11 ahci[:01:00.0] 24: 0 0 0 0 MIPS GIC 31 ahci[:02:00.0] 25:279 0 0 0 MIPS GIC 32 ahci[:03:00.0] 26: 0 0 0 0 1e000600.gpio 18 reset ERR: 0 And a trace: [ 16.547082] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1) [ 16.561981] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0) [ 16.676717] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz [ 16.687833] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz [ 16.798874] mt7621-pci 1e14.pcie: PCIE0 enabled [ 16.808591] mt7621-pci 1e14.pcie: PCIE1 enabled [ 16.818313] mt7621-pci 1e14.pcie: PCIE2 enabled [ 16.828039] mt7621-pci 1e14.pcie: PCI coherence region base: 0x6000, mask/settings: 0xf002 [ 16.846783] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 [ 16.859473] pci_bus :00: root bus resource [io 0x1e16-0x1e16] [ 16.873171] pci_bus :00: root bus resource [mem 0x6000-0x6fff] [ 16.886880] pci_bus :00: root bus resource [bus 00-ff] [ 16.897862] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 [ 16.909864] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] [ 16.922358] pci :00:00.0: reg 0x14: [mem 0x-0x] [ 16.934928] pci :00:00.0: supports D1 [ 16.942894] pci :00:00.0: PME# supported from D0 D1 D3hot [ 16.954762] pci :00:01.0: [0e8d:0801] type 01 class 0x060400 [ 16.966779] pci :00:01.0: reg 0x10: [mem 0x-0x7fff] [ 16.979275] pci :00:01.0: reg 0x14: [mem 0x-0x] [ 16.991835] pci :00:01.0: supports D1 [ 16.999826] pci :00:01.0: PME# supported from D0 D1 D3hot [ 17.011649] pci :00:
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Sergio
Am 10.04.20 um 13:36 schrieb Sergio Paracuellos:
>> cat /proc/interrupts new:
>>CPU0 CPU1 CPU2 CPU3
>> 8: 75188 75268 75341 75246 MIPS GIC Local 1 timer
>> 9: 24413 0 0 0 MIPS GIC 63 IPI call
>> 10: 0 4442 0 0 MIPS GIC 64 IPI call
>> 11: 0 0 33324 0 MIPS GIC 65 IPI call
>> 12: 0 0 0 4574 MIPS GIC 66 IPI call
>> 13: 3424 0 0 0 MIPS GIC 67 IPI resched
>> 14: 0 4124 0 0 MIPS GIC 68 IPI resched
>> 15: 0 0 3974 0 MIPS GIC 69 IPI resched
>> 16: 0 0 0 4150 MIPS GIC 70 IPI resched
>> 17: 0 0 0 0 MIPS GIC 19
>> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
>> 19:829 0 0 0 MIPS GIC 33 ttyS0
>> 20: 0 0 0 0 MIPS GIC 29 xhci-hcd:usb1
>> 21:817 0 0 0 MIPS GIC 10
>> 1e10.ethernet
>> 23: 0 0 0 0 MIPS GIC 11 mt7615e
>> ERR: 1
>>
>>
>> cat /proc/interrupts old:
>>
>>CPU0 CPU1 CPU2 CPU3
>> 8: 25513 25556 25674 25681 MIPS GIC Local 1 timer
>> 9: 23603 0 0 0 MIPS GIC 63 IPI call
>> 10: 0 4383 0 0 MIPS GIC 64 IPI call
>> 11: 0 0 32117 0 MIPS GIC 65 IPI call
>> 12: 0 0 0 4189 MIPS GIC 66 IPI call
>> 13: 3428 0 0 0 MIPS GIC 67 IPI resched
>> 14: 0 4144 0 0 MIPS GIC 68 IPI resched
>> 15: 0 0 3812 0 MIPS GIC 69 IPI resched
>> 16: 0 0 0 3769 MIPS GIC 70 IPI resched
>> 17: 0 0 0 0 MIPS GIC 19
>> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
>> 19: 1022 0 0 0 MIPS GIC 33 ttyS0
>> 20: 0 0 0 0 MIPS GIC 29 xhci-hcd:usb1
>> 21:269 0 0 0 MIPS GIC 10
>> 1e10.ethernet
>> 24: 1131 0 0 0 MIPS GIC 31 mt7615e
>> ERR: 0
>> => Interesting, different interrupts.
>
> That's weird. Should be the same, AFAICT.
> Needs some investigation but looks like you are not getting interrupts
> at all according to these traces...
>
> Looking into my gnubee I got also 23, 24 and 25.
>
> # cat /proc/interrupts
>CPU0 CPU1 CPU2 CPU3
> 7: 0 0 0 0 MIPS 7 timer
> 8: 3537 3346 3296 3351 MIPS GIC Local 1 timer
> 9: 3025 0 0 0 MIPS GIC 63 IPI call
> 10: 0 1209 0 0 MIPS GIC 64 IPI call
> 11: 0 0 2805 0 MIPS GIC 65 IPI call
> 12: 0 0 0 1200 MIPS GIC 66 IPI call
> 13: 1428 0 0 0 MIPS GIC 67 IPI resched
> 14: 0 4136 0 0 MIPS GIC 68 IPI resched
> 15: 0 0872 0 MIPS GIC 69 IPI resched
> 16: 0 0 0666 MIPS GIC 70 IPI resched
> 17: 0 0 0 0 MIPS GIC 19
> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
> 18:138 0 0 0 MIPS GIC 33 ttyS0
> 19: 0 0 0 0 MIPS GIC 27 1e13.sdhci
> 20: 26 0 0 0 MIPS GIC 29 xhci-hcd:usb1
> 21: 7 0 0 0 MIPS GIC 10
> 1e10.ethernet
> 23: 0 0 0 0 MIPS GIC 11
> ahci[:01:00.0]
> 24: 0 0 0 0 MIPS GIC 31
> ahci[:02:00.0]
> 25:279 0 0 0 MIPS GIC 32
> ahci[:03:00.0]
> 26: 0 0 0 0 1e000600.gpio 18 reset
> ERR: 0
>
>
>>
>> Diff DTS old to new driver:
>> diff --git b/target/linux/ramips/dts/mt7621.dtsi
>> a/target/linux/ramips/dts/mt7621.dtsi
>> index 0bf1069b5c..63befa1fdc 100644
>> --- b/target/linux/ramips/dts/mt7621.dtsi
>> +++ a/target/linux/ramips/dts/mt7621.dtsi
>> @@ -557,9 +550,10 @@
>>
>> pcie: pcie@1e14 {
>> compatible = "mediatek,mt7621-pci";
>> - reg = <0x1e14 0x100
>> - 0x1e142000 0x100>;
>> -
>> + reg = <0x1e14 0x100 /* host-pci bridg
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
On Fri, Apr 10, 2020 at 1:36 PM Sergio Paracuellos wrote: > > Hi André, > > On Fri, Apr 10, 2020 at 11:36 AM Andre Valentin wrote: > > > > Hi Sergio, > > > > the device has an onboard LTE modem. Tonight I noticed that the originial > > pci driver > > must have changed some additional GPIO pins. > > After more testing, I found the GPIO and the LTE device now operates again. > > Good! > > > > > But after more testing, I found out that the wifi chip does not fully > > initialize. > > new PCI driver: > > [0.641632] PCI: CLS 0 bytes, default 32 > > [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie > > [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for > > 1e14.pcie > > [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed > > [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie > > [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for > > 1e14.pcie > > [2.898180] rt2880-pinmux pinctrl: pcie is already enabled > > [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse > > things back > > [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > > port = 1) > > [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of > > node '/pcie@1e14[0]' - status (0) > > [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > > of node '/pcie@1e14[1]' > > [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property > > of node '/pcie@1e14[1]' > > [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > > [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found > > [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > > port = 0) > > [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > > of node '/pcie@1e14[2]' > > [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property > > of node '/pcie@1e14[2]' > > [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > > [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found > > [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > > [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > > [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & > > CLK) > > [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & > > CLK) > > [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled > > [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: > > 0x6000, mask/settings: 0xf002 > > [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 > > [3.244820] pci_bus :00: root bus resource [io > > 0x1e16-0x1e16] > > [3.258527] pci_bus :00: root bus resource [mem > > 0x6000-0x6fff] > > [3.272233] pci_bus :00: root bus resource [bus 00-ff] > > [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > > [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] > > [3.320294] pci :00:00.0: supports D1 > > [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot > > [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > > [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > > limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 > > GT/s x1 link) > > [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] > > [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] > > [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] > > [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f > > pref] > > [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > > [3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > > [3.472600] pci :00:00.0: BAR 0: failed to assign [mem size > > 0x8000] > > [3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > > [3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f > > pref] > > [3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020] > > [3.527951] pci :00:00.0: BAR 7: assigned [io 0x1e16-0x1e160fff] > > [3.5414
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi André, On Fri, Apr 10, 2020 at 11:36 AM Andre Valentin wrote: > > Hi Sergio, > > the device has an onboard LTE modem. Tonight I noticed that the originial pci > driver > must have changed some additional GPIO pins. > After more testing, I found the GPIO and the LTE device now operates again. Good! > > But after more testing, I found out that the wifi chip does not fully > initialize. > new PCI driver: > [0.641632] PCI: CLS 0 bytes, default 32 > [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie > [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie > [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed > [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie > [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie > [2.898180] rt2880-pinmux pinctrl: pcie is already enabled > [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse > things back > [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > port = 1) > [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of > node '/pcie@1e14[0]' - status (0) > [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > of node '/pcie@1e14[1]' > [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of > node '/pcie@1e14[1]' > [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > port = 0) > [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > of node '/pcie@1e14[2]' > [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of > node '/pcie@1e14[2]' > [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK) > [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK) > [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled > [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: > 0x6000, mask/settings: 0xf002 > [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 > [3.244820] pci_bus :00: root bus resource [io 0x1e16-0x1e16] > [3.258527] pci_bus :00: root bus resource [mem 0x6000-0x6fff] > [3.272233] pci_bus :00: root bus resource [bus 00-ff] > [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] > [3.320294] pci :00:00.0: supports D1 > [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot > [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited > by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 > link) > [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] > [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] > [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] > [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f > pref] > [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > [3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > [3.472600] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] > [3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > [3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f > pref] > [3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020] > [3.527951] pci :00:00.0: BAR 7: assigned [io 0x1e16-0x1e160fff] > [3.541489] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f > 64bit] > [3.556077] pci :00:00.0: PCI bridge to [bus 01] > [3.565975] pci :00:00.0: bridge window [io 0x1e16-0x1e160fff] > [3.579504] pci :00:00.0: bridge window
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Sergio, the device has an onboard LTE modem. Tonight I noticed that the originial pci driver must have changed some additional GPIO pins. After more testing, I found the GPIO and the LTE device now operates again. But after more testing, I found out that the wifi chip does not fully initialize. new PCI driver: [0.641632] PCI: CLS 0 bytes, default 32 [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie [2.898180] rt2880-pinmux pinctrl: pcie is already enabled [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse things back [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1) [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/pcie@1e14[0]' - status (0) [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/pcie@1e14[1]' [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/pcie@1e14[1]' [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0) [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/pcie@1e14[2]' [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/pcie@1e14[2]' [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK) [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK) [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: 0x6000, mask/settings: 0xf002 [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 [3.244820] pci_bus :00: root bus resource [io 0x1e16-0x1e16] [3.258527] pci_bus :00: root bus resource [mem 0x6000-0x6fff] [3.272233] pci_bus :00: root bus resource [bus 00-ff] [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] [3.320294] pci :00:00.0: supports D1 [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 link) [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f pref] [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 [3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000] [3.472600] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] [3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] [3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f pref] [3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020] [3.527951] pci :00:00.0: BAR 7: assigned [io 0x1e16-0x1e160fff] [3.541489] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f 64bit] [3.556077] pci :00:00.0: PCI bridge to [bus 01] [3.565975] pci :00:00.0: bridge window [io 0x1e16-0x1e160fff] [3.579504] pci :00:00.0: bridge window [mem 0x6000-0x600f] [3.593037] pci :00:00.0: bridge window [mem 0x6010-0x601f pref] [ 27.217458] pci :00:00.0: enabling device (0006 -> 0007) [ 27.217158] mt7615e :01:00.0: no of_node; not parsing pinc
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Am 07.04.20 um 17:49 schrieb Bjørn Mork: > Just remembered an issue on my todo list: There have been some MTU > handling changes in the kernel networking API. This affected the > qmi_wwan QMAP handling. I am not sure about the current status. Will > have to dig a bit more. But this might be your problem. That made me set MTU of wwan0 to 1600, and the qmimux* to 1500. No more problems anymore. This should go into documentation, not that anybody makes the same errors. How much overhead does qmux create (for correct calculated MTU offset)? Thanks you! Kind regards, André smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
As a side note, even my Netgear R6220 won't boot;unfortunately no serial port, so can't diagnose the issue. Sorry guys. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Thu, Apr 9, 2020 at 12:19 PM Andre Valentin wrote: > > Am 09.04.20 um 06:48 schrieb Sergio Paracuellos: > > On Thu, Apr 9, 2020 at 6:36 AM Sergio Paracuellos > > wrote: > >> > >> Hi again, > >> > >> On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos > >> wrote: > >>> > >>> Hi Andre, > >>> > >>> On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos > >>> wrote: > > Hi André, > > > On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin > wrote: > > > > Hi Sergio! > > > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > >> Hi Andre, > >> > >> On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > >> wrote: > >>> > >>> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > Hi, > > On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > wrote: > > > > [CC Sergio who worked on upstream PCIE driver] > > > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > > wrote: > >> > >> Hi! > >> > >> Currently I'm having some serious problems with the new 5.4 port. > >> 1) PCIe > >> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a > >> mt7615e connected to second bus on the first phy. > >> If booting the device, kernel hangs with a RST message, telling > >> the device is not detected. It seems the PCIe bus 1 > >> cannot be reseted because nothing is connected to bus 0. > >> An upport of the old PCI driver reenables the function. I can > >> provide more logs on this if needed. > > Logs and dmesg traces are always welcome and would be helpful. Both > working and not working traces. > >>> > >>> Of course, here we go with the old PCIe driver taken from 4.14 > >>> openwrt kernel: > >>> [0.485729] pinctrl core: add 0 pinctrl maps > >>> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > >>> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > >>> [0.806088] * Xtal 40MHz * > >>> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > >>> [0.823025] Port 0 N_FTS = 1b102800 > >>> [0.829933] Port 1 N_FTS = 1b105000 > >>> [0.836849] Port 2 N_FTS = 1b102800 > >>> [1.995991] PCIE0 no card, disable it(RST&CLK) > >>> [2.004682] PCIE2 no card, disable it(RST&CLK) > >>> [2.013495] -> 20107f2 > >>> [2.018328] PCIE1 enabled > >>> [2.023532] PCI host bridge /pcie@1e14 ranges: > >>> [2.033045] MEM 0x6000..0x6fff > >>> [2.043401] IO 0x1e16..0x1e16 > >>> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > >>> 0x6000 > >>> [2.091056] PCI host bridge to bus :00 > >>> [2.099131] pci_bus :00: root bus resource [mem > >>> 0x6000-0x6fff] > >>> [2.112734] pci_bus :00: root bus resource [io 0x] > >>> [2.124486] pci_bus :00: root bus resource [??? 0x > >>> flags 0x0] > >>> [2.137962] pci_bus :00: No busn resource found for root bus, > >>> will use [bus 00-ff] > >>> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > >>> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > >>> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > >>> [2.190585] pci :00:00.0: supports D1 > >>> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > >>> [2.211463] random: fast init done > >>> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > >>> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f > >>> 64bit] > >>> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > >>> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s > >>> with 5 GT/s x1 link) > >>> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated > >>> to 01 > >>> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated > >>> to 01 > >>> [2.298493] pci :00:00.0: BAR 0: no space for [mem size > >>> 0x8000] > >>> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size > >>> 0x8000] > >>> [2.325410] pci :00:00.0: BAR 8: assigned [mem > >>> 0x6000-0x600f] > >>> [2.33] pci :00:00.0: BAR 1: assigned [mem > >>> 0x6010-0x6010] > >>> [2.352376] pci :01:00.0: BAR 0: assigned [mem > >>> 0x6000-0x600f 64bit] > >>> [2.366887] pci :00:00.0: PCI bridge to [bus 01] > >>> [2.376728] pci :00:00.0: bridge window [mem > >>> 0x6000-0x600f] > >>> > >>> > >>> And this is on 5.4 with the new driver with pcie0 status=disabled:
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Am 09.04.20 um 06:48 schrieb Sergio Paracuellos: > On Thu, Apr 9, 2020 at 6:36 AM Sergio Paracuellos > wrote: >> >> Hi again, >> >> On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos >> wrote: >>> >>> Hi Andre, >>> >>> On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos >>> wrote: Hi André, On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin wrote: > > Hi Sergio! > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: >> Hi Andre, >> >> On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin >> wrote: >>> >>> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: Hi, On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > > [CC Sergio who worked on upstream PCIE driver] > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > wrote: >> >> Hi! >> >> Currently I'm having some serious problems with the new 5.4 port. >> 1) PCIe >> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e >> connected to second bus on the first phy. >> If booting the device, kernel hangs with a RST message, telling the >> device is not detected. It seems the PCIe bus 1 >> cannot be reseted because nothing is connected to bus 0. >> An upport of the old PCI driver reenables the function. I can >> provide more logs on this if needed. Logs and dmesg traces are always welcome and would be helpful. Both working and not working traces. >>> >>> Of course, here we go with the old PCIe driver taken from 4.14 openwrt >>> kernel: >>> [0.485729] pinctrl core: add 0 pinctrl maps >>> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 >>> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 >>> [0.806088] * Xtal 40MHz * >>> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 >>> [0.823025] Port 0 N_FTS = 1b102800 >>> [0.829933] Port 1 N_FTS = 1b105000 >>> [0.836849] Port 2 N_FTS = 1b102800 >>> [1.995991] PCIE0 no card, disable it(RST&CLK) >>> [2.004682] PCIE2 no card, disable it(RST&CLK) >>> [2.013495] -> 20107f2 >>> [2.018328] PCIE1 enabled >>> [2.023532] PCI host bridge /pcie@1e14 ranges: >>> [2.033045] MEM 0x6000..0x6fff >>> [2.043401] IO 0x1e16..0x1e16 >>> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: >>> 0x6000 >>> [2.091056] PCI host bridge to bus :00 >>> [2.099131] pci_bus :00: root bus resource [mem >>> 0x6000-0x6fff] >>> [2.112734] pci_bus :00: root bus resource [io 0x] >>> [2.124486] pci_bus :00: root bus resource [??? 0x flags >>> 0x0] >>> [2.137962] pci_bus :00: No busn resource found for root bus, >>> will use [bus 00-ff] >>> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 >>> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] >>> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] >>> [2.190585] pci :00:00.0: supports D1 >>> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot >>> [2.211463] random: fast init done >>> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 >>> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f >>> 64bit] >>> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, >>> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with >>> 5 GT/s x1 link) >>> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to >>> 01 >>> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to >>> 01 >>> [2.298493] pci :00:00.0: BAR 0: no space for [mem size >>> 0x8000] >>> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size >>> 0x8000] >>> [2.325410] pci :00:00.0: BAR 8: assigned [mem >>> 0x6000-0x600f] >>> [2.33] pci :00:00.0: BAR 1: assigned [mem >>> 0x6010-0x6010] >>> [2.352376] pci :01:00.0: BAR 0: assigned [mem >>> 0x6000-0x600f 64bit] >>> [2.366887] pci :00:00.0: PCI bridge to [bus 01] >>> [2.376728] pci :00:00.0: bridge window [mem >>> 0x6000-0x600f] >>> >>> >>> And this is on 5.4 with the new driver with pcie0 status=disabled: >>> [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset >>> [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO >>> lookup >>> [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO >>> lookup >>> [ 30.464484] mt762
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
On Thu, Apr 9, 2020 at 6:36 AM Sergio Paracuellos wrote: > > Hi again, > > On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos > wrote: > > > > Hi Andre, > > > > On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos > > wrote: > > > > > > Hi André, > > > > > > > > > On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin > > > wrote: > > > > > > > > Hi Sergio! > > > > > > > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > > > > Hi Andre, > > > > > > > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > > > > > wrote: > > > > >> > > > > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > > > >>> Hi, > > > > >>> > > > > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > > > > >>> wrote: > > > > > > > > [CC Sergio who worked on upstream PCIE driver] > > > > > > > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > > > > wrote: > > > > > > > > > > Hi! > > > > > > > > > > Currently I'm having some serious problems with the new 5.4 port. > > > > > 1) PCIe > > > > > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a > > > > > mt7615e connected to second bus on the first phy. > > > > > If booting the device, kernel hangs with a RST message, telling > > > > > the device is not detected. It seems the PCIe bus 1 > > > > > cannot be reseted because nothing is connected to bus 0. > > > > > An upport of the old PCI driver reenables the function. I can > > > > > provide more logs on this if needed. > > > > >>> > > > > >>> Logs and dmesg traces are always welcome and would be helpful. Both > > > > >>> working and not working traces. > > > > >> > > > > >> Of course, here we go with the old PCIe driver taken from 4.14 > > > > >> openwrt kernel: > > > > >> [0.485729] pinctrl core: add 0 pinctrl maps > > > > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > > > > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > > > > >> [0.806088] * Xtal 40MHz * > > > > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > > > > >> [0.823025] Port 0 N_FTS = 1b102800 > > > > >> [0.829933] Port 1 N_FTS = 1b105000 > > > > >> [0.836849] Port 2 N_FTS = 1b102800 > > > > >> [1.995991] PCIE0 no card, disable it(RST&CLK) > > > > >> [2.004682] PCIE2 no card, disable it(RST&CLK) > > > > >> [2.013495] -> 20107f2 > > > > >> [2.018328] PCIE1 enabled > > > > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > > > > >> [2.033045] MEM 0x6000..0x6fff > > > > >> [2.043401] IO 0x1e16..0x1e16 > > > > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > > > > >> 0x6000 > > > > >> [2.091056] PCI host bridge to bus :00 > > > > >> [2.099131] pci_bus :00: root bus resource [mem > > > > >> 0x6000-0x6fff] > > > > >> [2.112734] pci_bus :00: root bus resource [io 0x] > > > > >> [2.124486] pci_bus :00: root bus resource [??? 0x > > > > >> flags 0x0] > > > > >> [2.137962] pci_bus :00: No busn resource found for root bus, > > > > >> will use [bus 00-ff] > > > > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > > > >> [2.165651] pci :00:00.0: reg 0x10: [mem > > > > >> 0x-0x7fff] > > > > >> [2.178057] pci :00:00.0: reg 0x14: [mem > > > > >> 0x6010-0x6010] > > > > >> [2.190585] pci :00:00.0: supports D1 > > > > >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > > > > >> [2.211463] random: fast init done > > > > >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > > > >> [2.230071] pci :01:00.0: reg 0x10: [mem > > > > >> 0x-0x000f 64bit] > > > > >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe > > > > >> bandwidth, limited by 2.5 GT/s x1 link at :00:00.0 (capable of > > > > >> 4.000 Gb/s with 5 GT/s x1 link) > > > > >> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated > > > > >> to 01 > > > > >> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated > > > > >> to 01 > > > > >> [2.298493] pci :00:00.0: BAR 0: no space for [mem size > > > > >> 0x8000] > > > > >> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size > > > > >> 0x8000] > > > > >> [2.325410] pci :00:00.0: BAR 8: assigned [mem > > > > >> 0x6000-0x600f] > > > > >> [2.33] pci :00:00.0: BAR 1: assigned [mem > > > > >> 0x6010-0x6010] > > > > >> [2.352376] pci :01:00.0: BAR 0: assigned [mem > > > > >> 0x6000-0x600f 64bit] > > > > >> [2.366887] pci :00:00.0: PCI bridge to [bus 01] > > > > >> [2.376728] pci :00:00.0: bridge window [mem > > > > >> 0x6000-0x600f] > > > > >> > > > > >> > > > > >> And this is on 5.4 with the new driver with pcie0 status=disabled: > > > > >> [ 30.464407] mt7621-pci 1e14000
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi again, On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos wrote: > > Hi Andre, > > On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos > wrote: > > > > Hi André, > > > > > > On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin wrote: > > > > > > Hi Sergio! > > > > > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > > > Hi Andre, > > > > > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > > > > wrote: > > > >> > > > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > > >>> Hi, > > > >>> > > > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > > > >>> wrote: > > > > > > [CC Sergio who worked on upstream PCIE driver] > > > > > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > > > wrote: > > > > > > > > Hi! > > > > > > > > Currently I'm having some serious problems with the new 5.4 port. > > > > 1) PCIe > > > > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > > > connected to second bus on the first phy. > > > > If booting the device, kernel hangs with a RST message, telling the > > > > device is not detected. It seems the PCIe bus 1 > > > > cannot be reseted because nothing is connected to bus 0. > > > > An upport of the old PCI driver reenables the function. I can > > > > provide more logs on this if needed. > > > >>> > > > >>> Logs and dmesg traces are always welcome and would be helpful. Both > > > >>> working and not working traces. > > > >> > > > >> Of course, here we go with the old PCIe driver taken from 4.14 openwrt > > > >> kernel: > > > >> [0.485729] pinctrl core: add 0 pinctrl maps > > > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > > > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > > > >> [0.806088] * Xtal 40MHz * > > > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > > > >> [0.823025] Port 0 N_FTS = 1b102800 > > > >> [0.829933] Port 1 N_FTS = 1b105000 > > > >> [0.836849] Port 2 N_FTS = 1b102800 > > > >> [1.995991] PCIE0 no card, disable it(RST&CLK) > > > >> [2.004682] PCIE2 no card, disable it(RST&CLK) > > > >> [2.013495] -> 20107f2 > > > >> [2.018328] PCIE1 enabled > > > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > > > >> [2.033045] MEM 0x6000..0x6fff > > > >> [2.043401] IO 0x1e16..0x1e16 > > > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > > > >> 0x6000 > > > >> [2.091056] PCI host bridge to bus :00 > > > >> [2.099131] pci_bus :00: root bus resource [mem > > > >> 0x6000-0x6fff] > > > >> [2.112734] pci_bus :00: root bus resource [io 0x] > > > >> [2.124486] pci_bus :00: root bus resource [??? 0x > > > >> flags 0x0] > > > >> [2.137962] pci_bus :00: No busn resource found for root bus, > > > >> will use [bus 00-ff] > > > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > > >> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > > > >> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > > > >> [2.190585] pci :00:00.0: supports D1 > > > >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > > > >> [2.211463] random: fast init done > > > >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > > >> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f > > > >> 64bit] > > > >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > > > >> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s > > > >> with 5 GT/s x1 link) > > > >> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated > > > >> to 01 > > > >> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated > > > >> to 01 > > > >> [2.298493] pci :00:00.0: BAR 0: no space for [mem size > > > >> 0x8000] > > > >> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size > > > >> 0x8000] > > > >> [2.325410] pci :00:00.0: BAR 8: assigned [mem > > > >> 0x6000-0x600f] > > > >> [2.33] pci :00:00.0: BAR 1: assigned [mem > > > >> 0x6010-0x6010] > > > >> [2.352376] pci :01:00.0: BAR 0: assigned [mem > > > >> 0x6000-0x600f 64bit] > > > >> [2.366887] pci :00:00.0: PCI bridge to [bus 01] > > > >> [2.376728] pci :00:00.0: bridge window [mem > > > >> 0x6000-0x600f] > > > >> > > > >> > > > >> And this is on 5.4 with the new driver with pcie0 status=disabled: > > > >> [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > > >> [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO > > > >> lookup > > > >> [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO > > > >> lookup > > > >> [ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos wrote: > > Hi André, > > > On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin wrote: > > > > Hi Sergio! > > > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > > Hi Andre, > > > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > > > wrote: > > >> > > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > >>> Hi, > > >>> > > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > > >>> wrote: > > > > [CC Sergio who worked on upstream PCIE driver] > > > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > > wrote: > > > > > > Hi! > > > > > > Currently I'm having some serious problems with the new 5.4 port. > > > 1) PCIe > > > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > > connected to second bus on the first phy. > > > If booting the device, kernel hangs with a RST message, telling the > > > device is not detected. It seems the PCIe bus 1 > > > cannot be reseted because nothing is connected to bus 0. > > > An upport of the old PCI driver reenables the function. I can provide > > > more logs on this if needed. > > >>> > > >>> Logs and dmesg traces are always welcome and would be helpful. Both > > >>> working and not working traces. > > >> > > >> Of course, here we go with the old PCIe driver taken from 4.14 openwrt > > >> kernel: > > >> [0.485729] pinctrl core: add 0 pinctrl maps > > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > > >> [0.806088] * Xtal 40MHz * > > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > > >> [0.823025] Port 0 N_FTS = 1b102800 > > >> [0.829933] Port 1 N_FTS = 1b105000 > > >> [0.836849] Port 2 N_FTS = 1b102800 > > >> [1.995991] PCIE0 no card, disable it(RST&CLK) > > >> [2.004682] PCIE2 no card, disable it(RST&CLK) > > >> [2.013495] -> 20107f2 > > >> [2.018328] PCIE1 enabled > > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > > >> [2.033045] MEM 0x6000..0x6fff > > >> [2.043401] IO 0x1e16..0x1e16 > > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > > >> 0x6000 > > >> [2.091056] PCI host bridge to bus :00 > > >> [2.099131] pci_bus :00: root bus resource [mem > > >> 0x6000-0x6fff] > > >> [2.112734] pci_bus :00: root bus resource [io 0x] > > >> [2.124486] pci_bus :00: root bus resource [??? 0x flags > > >> 0x0] > > >> [2.137962] pci_bus :00: No busn resource found for root bus, > > >> will use [bus 00-ff] > > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > >> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > > >> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > > >> [2.190585] pci :00:00.0: supports D1 > > >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > > >> [2.211463] random: fast init done > > >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > >> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f > > >> 64bit] > > >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > > >> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with > > >> 5 GT/s x1 link) > > >> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to > > >> 01 > > >> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to > > >> 01 > > >> [2.298493] pci :00:00.0: BAR 0: no space for [mem size > > >> 0x8000] > > >> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size > > >> 0x8000] > > >> [2.325410] pci :00:00.0: BAR 8: assigned [mem > > >> 0x6000-0x600f] > > >> [2.33] pci :00:00.0: BAR 1: assigned [mem > > >> 0x6010-0x6010] > > >> [2.352376] pci :01:00.0: BAR 0: assigned [mem > > >> 0x6000-0x600f 64bit] > > >> [2.366887] pci :00:00.0: PCI bridge to [bus 01] > > >> [2.376728] pci :00:00.0: bridge window [mem > > >> 0x6000-0x600f] > > >> > > >> > > >> And this is on 5.4 with the new driver with pcie0 status=disabled: > > >> [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > >> [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO > > >> lookup > > >> [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO > > >> lookup > > >> [ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found > > >> [ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST > > >> & CLK) > > >> [ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual > > >> bridges. Exiting... > > >> booting goes on. > > >> > > >> And with pcie status=enabled: > > >> [ 32.4158
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi André, On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin wrote: > > Hi Sergio! > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > Hi Andre, > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin wrote: > >> > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > >>> Hi, > >>> > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > > [CC Sergio who worked on upstream PCIE driver] > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > wrote: > > > > Hi! > > > > Currently I'm having some serious problems with the new 5.4 port. > > 1) PCIe > > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > connected to second bus on the first phy. > > If booting the device, kernel hangs with a RST message, telling the > > device is not detected. It seems the PCIe bus 1 > > cannot be reseted because nothing is connected to bus 0. > > An upport of the old PCI driver reenables the function. I can provide > > more logs on this if needed. > >>> > >>> Logs and dmesg traces are always welcome and would be helpful. Both > >>> working and not working traces. > >> > >> Of course, here we go with the old PCIe driver taken from 4.14 openwrt > >> kernel: > >> [0.485729] pinctrl core: add 0 pinctrl maps > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > >> [0.806088] * Xtal 40MHz * > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > >> [0.823025] Port 0 N_FTS = 1b102800 > >> [0.829933] Port 1 N_FTS = 1b105000 > >> [0.836849] Port 2 N_FTS = 1b102800 > >> [1.995991] PCIE0 no card, disable it(RST&CLK) > >> [2.004682] PCIE2 no card, disable it(RST&CLK) > >> [2.013495] -> 20107f2 > >> [2.018328] PCIE1 enabled > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > >> [2.033045] MEM 0x6000..0x6fff > >> [2.043401] IO 0x1e16..0x1e16 > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > >> 0x6000 > >> [2.091056] PCI host bridge to bus :00 > >> [2.099131] pci_bus :00: root bus resource [mem > >> 0x6000-0x6fff] > >> [2.112734] pci_bus :00: root bus resource [io 0x] > >> [2.124486] pci_bus :00: root bus resource [??? 0x flags > >> 0x0] > >> [2.137962] pci_bus :00: No busn resource found for root bus, will > >> use [bus 00-ff] > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > >> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > >> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > >> [2.190585] pci :00:00.0: supports D1 > >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > >> [2.211463] random: fast init done > >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > >> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f > >> 64bit] > >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > >> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 > >> GT/s x1 link) > >> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > >> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01 > >> [2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > >> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size > >> 0x8000] > >> [2.325410] pci :00:00.0: BAR 8: assigned [mem > >> 0x6000-0x600f] > >> [2.33] pci :00:00.0: BAR 1: assigned [mem > >> 0x6010-0x6010] > >> [2.352376] pci :01:00.0: BAR 0: assigned [mem > >> 0x6000-0x600f 64bit] > >> [2.366887] pci :00:00.0: PCI bridge to [bus 01] > >> [2.376728] pci :00:00.0: bridge window [mem > >> 0x6000-0x600f] > >> > >> > >> And this is on 5.4 with the new driver with pcie0 status=disabled: > >> [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > >> [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > >> [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO > >> lookup > >> [ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found > >> [ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & > >> CLK) > >> [ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual > >> bridges. Exiting... > >> booting goes on. > >> > >> And with pcie status=enabled: > >> [ 32.415863] rt2880-pinmux pinctrl: pcie is already enabled > >> [ 32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse > >> things back > >> [ 32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > >> port = 1) > >> [ 32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > >> po
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Sergio! Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > Hi Andre, > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin wrote: >> >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: >>> Hi, >>> >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: [CC Sergio who worked on upstream PCIE driver] On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: > > Hi! > > Currently I'm having some serious problems with the new 5.4 port. > 1) PCIe > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > connected to second bus on the first phy. > If booting the device, kernel hangs with a RST message, telling the > device is not detected. It seems the PCIe bus 1 > cannot be reseted because nothing is connected to bus 0. > An upport of the old PCI driver reenables the function. I can provide > more logs on this if needed. >>> >>> Logs and dmesg traces are always welcome and would be helpful. Both >>> working and not working traces. >> >> Of course, here we go with the old PCIe driver taken from 4.14 openwrt >> kernel: >> [0.485729] pinctrl core: add 0 pinctrl maps >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 >> [0.806088] * Xtal 40MHz * >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 >> [0.823025] Port 0 N_FTS = 1b102800 >> [0.829933] Port 1 N_FTS = 1b105000 >> [0.836849] Port 2 N_FTS = 1b102800 >> [1.995991] PCIE0 no card, disable it(RST&CLK) >> [2.004682] PCIE2 no card, disable it(RST&CLK) >> [2.013495] -> 20107f2 >> [2.018328] PCIE1 enabled >> [2.023532] PCI host bridge /pcie@1e14 ranges: >> [2.033045] MEM 0x6000..0x6fff >> [2.043401] IO 0x1e16..0x1e16 >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: >> 0x6000 >> [2.091056] PCI host bridge to bus :00 >> [2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff] >> [2.112734] pci_bus :00: root bus resource [io 0x] >> [2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0] >> [2.137962] pci_bus :00: No busn resource found for root bus, will >> use [bus 00-ff] >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 >> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] >> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] >> [2.190585] pci :00:00.0: supports D1 >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot >> [2.211463] random: fast init done >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 >> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, >> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 >> GT/s x1 link) >> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 >> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01 >> [2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000] >> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size >> 0x8000] >> [2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] >> [2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010] >> [2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f >> 64bit] >> [2.366887] pci :00:00.0: PCI bridge to [bus 01] >> [2.376728] pci :00:00.0: bridge window [mem 0x6000-0x600f] >> >> >> And this is on 5.4 with the new driver with pcie0 status=disabled: >> [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset >> [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup >> [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup >> [ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found >> [ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & >> CLK) >> [ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual >> bridges. Exiting... >> booting goes on. >> >> And with pcie status=enabled: >> [ 32.415863] rt2880-pinmux pinctrl: pcie is already enabled >> [ 32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse >> things back >> [ 32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual >> port = 1) >> [ 32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual >> port = 0) >> [ 32.571556] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz >> [ 32.582680] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz >> [ 32.693592] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & >> CLK) >> hangs. > > I think the problem here is that upstream driver use two phy's node
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin wrote: > > Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > Hi, > > > > On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > >> > >> [CC Sergio who worked on upstream PCIE driver] > >> > >> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > >> wrote: > >>> > >>> Hi! > >>> > >>> Currently I'm having some serious problems with the new 5.4 port. > >>> 1) PCIe > >>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > >>> connected to second bus on the first phy. > >>> If booting the device, kernel hangs with a RST message, telling the > >>> device is not detected. It seems the PCIe bus 1 > >>> cannot be reseted because nothing is connected to bus 0. > >>> An upport of the old PCI driver reenables the function. I can provide > >>> more logs on this if needed. > > > > Logs and dmesg traces are always welcome and would be helpful. Both > > working and not working traces. > > Of course, here we go with the old PCIe driver taken from 4.14 openwrt kernel: > [0.485729] pinctrl core: add 0 pinctrl maps > [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > [0.806088] * Xtal 40MHz * > [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > [0.823025] Port 0 N_FTS = 1b102800 > [0.829933] Port 1 N_FTS = 1b105000 > [0.836849] Port 2 N_FTS = 1b102800 > [1.995991] PCIE0 no card, disable it(RST&CLK) > [2.004682] PCIE2 no card, disable it(RST&CLK) > [2.013495] -> 20107f2 > [2.018328] PCIE1 enabled > [2.023532] PCI host bridge /pcie@1e14 ranges: > [2.033045] MEM 0x6000..0x6fff > [2.043401] IO 0x1e16..0x1e16 > [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > 0x6000 > [2.091056] PCI host bridge to bus :00 > [2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff] > [2.112734] pci_bus :00: root bus resource [io 0x] > [2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0] > [2.137962] pci_bus :00: No busn resource found for root bus, will use > [bus 00-ff] > [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > [2.190585] pci :00:00.0: supports D1 > [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > [2.211463] random: fast init done > [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited > by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 > link) > [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01 > [2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] > [2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > [2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010] > [2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f > 64bit] > [2.366887] pci :00:00.0: PCI bridge to [bus 01] > [2.376728] pci :00:00.0: bridge window [mem 0x6000-0x600f] > > > And this is on 5.4 with the new driver with pcie0 status=disabled: > [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK) > [ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual > bridges. Exiting... > booting goes on. > > And with pcie status=enabled: > [ 32.415863] rt2880-pinmux pinctrl: pcie is already enabled > [ 32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse > things back > [ 32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > port = 1) > [ 32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > port = 0) > [ 32.571556] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > [ 32.582680] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > [ 32.693592] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK) > hangs. I think the problem here is that upstream driver use two phy's nodes with pcie-phy0 being a dual ported one. Because there is nothing connected in pcie0 the phy is just stopped assuming nothing will be connected also in pcie1.
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Am 07.04.20 um 20:05 schrieb Sergio Paracuellos:
> Hi,
>
> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote:
>>
>> [CC Sergio who worked on upstream PCIE driver]
>>
>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote:
>>>
>>> Hi!
>>>
>>> Currently I'm having some serious problems with the new 5.4 port.
>>> 1) PCIe
>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e
>>> connected to second bus on the first phy.
>>> If booting the device, kernel hangs with a RST message, telling the device
>>> is not detected. It seems the PCIe bus 1
>>> cannot be reseted because nothing is connected to bus 0.
>>> An upport of the old PCI driver reenables the function. I can provide more
>>> logs on this if needed.
>
> Logs and dmesg traces are always welcome and would be helpful. Both
> working and not working traces.
Of course, here we go with the old PCIe driver taken from 4.14 openwrt kernel:
[0.485729] pinctrl core: add 0 pinctrl maps
[0.485865] pull PCIe RST: RALINK_RSTCTRL = 400
[0.796015] release PCIe RST: RALINK_RSTCTRL = 700
[0.806088] * Xtal 40MHz *
[0.812829] release PCIe RST: RALINK_RSTCTRL = 700
[0.823025] Port 0 N_FTS = 1b102800
[0.829933] Port 1 N_FTS = 1b105000
[0.836849] Port 2 N_FTS = 1b102800
[1.995991] PCIE0 no card, disable it(RST&CLK)
[2.004682] PCIE2 no card, disable it(RST&CLK)
[2.013495] -> 20107f2
[2.018328] PCIE1 enabled
[2.023532] PCI host bridge /pcie@1e14 ranges:
[2.033045] MEM 0x6000..0x6fff
[2.043401] IO 0x1e16..0x1e16
[2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: 0x6000
[2.091056] PCI host bridge to bus :00
[2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff]
[2.112734] pci_bus :00: root bus resource [io 0x]
[2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0]
[2.137962] pci_bus :00: No busn resource found for root bus, will use
[bus 00-ff]
[2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400
[2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
[2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010]
[2.190585] pci :00:00.0: supports D1
[2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot
[2.211463] random: fast init done
[2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280
[2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit]
[2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited
by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 link)
[2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01
[2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000]
[2.311581] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000]
[2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f]
[2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010]
[2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f
64bit]
[2.366887] pci :00:00.0: PCI bridge to [bus 01]
[2.376728] pci :00:00.0: bridge window [mem 0x6000-0x600f]
And this is on 5.4 with the new driver with pcie0 status=disabled:
[ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset
[ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup
[ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup
[ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found
[ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK)
[ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual
bridges. Exiting...
booting goes on.
And with pcie status=enabled:
[ 32.415863] rt2880-pinmux pinctrl: pcie is already enabled
[ 32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse things
back
[ 32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port
= 1)
[ 32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port
= 0)
[ 32.571556] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
[ 32.582680] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
[ 32.693592] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK)
hangs.
DTS Config:
mt7621.dtsi
pcie: pcie@1e14 {
compatible = "mediatek,mt7621-pci";
reg = <0x1e14 0x100 /* host-pci bridge registers */
0x1e142000 0x100/* pcie port 0 RC control registers
*/
0x1e143000 0x100/* pcie port 1 RC control registers
*/
0x1e144000 0x100>; /* pcie port 2 RC control registers
*/
#address-cells = <3>;
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Am 07.04.20 um 12:16 schrieb Chuanhong Guo: > [CC Sergio who worked on upstream PCIE driver] > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: >> >> Hi! >> >> Currently I'm having some serious problems with the new 5.4 port. >> 1) PCIe >> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e >> connected to second bus on the first phy. >> If booting the device, kernel hangs with a RST message, telling the device >> is not detected. It seems the PCIe bus 1 >> cannot be reseted because nothing is connected to bus 0. >> An upport of the old PCI driver reenables the function. I can provide more >> logs on this if needed. > > Hi Sergio: > You may want to look into this. > >> 2) DSA >> These are my first experiments with DSA. I've configured 2 bridges: >> lan: lan1 lan2 lan3 lan4 >> dmz: lan1.20 lan2.20 lan3.20 lan4.20 >> >> Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 >> port but does note arrive at the other end. >> >> Should this work with DSA on mediathek? > > It's supposed to work so this may be yet another bug upstream. > >> If not, I can offer that I write a patch for traditional swconfig. > > swconfig is considered deprecated so there's no need to do so. > In fact, this driver under mediatek target also works for mt7621: > target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x > I already took some patches from there. I'll gonna check if a replacement makes a difference. Kind regards, André smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Am 07.04.20 um 17:49 schrieb Bjørn Mork: > Just remembered an issue on my todo list: There have been some MTU > handling changes in the kernel networking API. This affected the > qmi_wwan QMAP handling. I am not sure about the current status. Will > have to dig a bit more. But this might be your problem. Thank you very much for taking a look! André ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi, On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > > [CC Sergio who worked on upstream PCIE driver] > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: > > > > Hi! > > > > Currently I'm having some serious problems with the new 5.4 port. > > 1) PCIe > > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > connected to second bus on the first phy. > > If booting the device, kernel hangs with a RST message, telling the device > > is not detected. It seems the PCIe bus 1 > > cannot be reseted because nothing is connected to bus 0. > > An upport of the old PCI driver reenables the function. I can provide more > > logs on this if needed. Logs and dmesg traces are always welcome and would be helpful. Both working and not working traces. > > Hi Sergio: > You may want to look into this. > > > 2) DSA > > These are my first experiments with DSA. I've configured 2 bridges: > > lan: lan1 lan2 lan3 lan4 > > dmz: lan1.20 lan2.20 lan3.20 lan4.20 > > > > Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 > > port but does note arrive at the other end. > > > > Should this work with DSA on mediathek? > > It's supposed to work so this may be yet another bug upstream. > > > If not, I can offer that I write a patch for traditional swconfig. > > swconfig is considered deprecated so there's no need to do so. > In fact, this driver under mediatek target also works for mt7621: > target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x > > -- > Regards, > Chuanhong Guo Best regards, Sergio Paracuellos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Just remembered an issue on my todo list: There have been some MTU handling changes in the kernel networking API. This affected the qmi_wwan QMAP handling. I am not sure about the current status. Will have to dig a bit more. But this might be your problem. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Andre Valentin writes:
>> Is your modem connected by USB3 or USB2? Any of
>
> The modem is an integrated USB3 LTE modem. As said, without qmap it
> works stable.
ah, missed that important point.
There were a few qmap fixes between v4.14 and v5.4, but I guess we can
rule out those since you have the same issues with the v4.14 driver on
v5.4.
I must admit I am totally blank here. I haven't actually tested the
qmap features much yet. It is completely integrated in qmi_wwan. But
there is also a separate implementation from Qualcomm in
drivers/net/ethernet/qualcomm/rmnet . Which I haven't tried at all...
Are you using the QMAP implementation in qmi_wwan? That's the one with
the /sys/class/net/wwan0/qmi/{add,del}_mux ABI.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Am 07.04.20 um 16:33 schrieb Bjørn Mork: > Andre Valentin writes: > >> 3) Problems with QMI Interfaces >> QMI is used for mobile phones and interact with the qmi_wwan driver in the >> kernel. I had transmit issues, >> switched the driver back to the 4.14 while still on 5.4. But the same >> problem happens again. >> Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches >> somehow are the root cause. >> Here's the kernel message: >> >> >> [ 4199.444191] [ cut here ] >> [ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 >> dev_watchdog+0x2f8/0x300 >> [ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out > > And this is not just an occasional timeout? The driver hangs completely > there? It hangs, no more packets are transmitted over network, > > I don't think there were many qmi_wwan changes between v4.14 and v5.4, > except for device additions and some fixes which mostly have been > backported to v4.14-stable. But maybe this is related to your specific > modem? Do you have a device ID for that? The funny thing is, that if I remove all changes from 5.4 qmi_wwan.c and set it back to the 4.14 driver, the same happens again. Perhaps the problem is in the muxing code? Is that outside of qmi_wwan.c ? Only if I disable qmap and use the wwan0 device with only one PDF, it seems to be stable over days. The device is a: Bus 002 Device 002: ID 2c7c:0306 Quectel Wireless Solutions Co., Ltd. EG06/EP06/EM06 LTE-A modem > Do we know that USB is working on v5.4 BTW? The MT7621 device I am > using doesn't have any USB ports, so I can't check that myself. > > Is your modem connected by USB3 or USB2? Any of The modem is an integrated USB3 LTE modem. As said, without qmap it works stable. > > lsusb -v -- Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 3 bMaxPacketSize0 9 idVendor 0x1d6b Linux Foundation idProduct 0x0003 3.0 root hub bcdDevice5.04 iManufacturer 3 Linux 5.4.28 vhci_hcd iProduct2 USB/IP Virtual Host Controller iSerial 1 vhci_hcd.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 31 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 bMaxBurst 0 Hub Descriptor: bLength 12 bDescriptorType 42 nNbrPorts 8 wHubCharacteristic 0x0001 Per-port power switching Ganged overcurrent protection bPwrOn2PwrGood0 * 2 milli seconds bHubContrCurrent 0 milli Ampere bHubDecLat 0.4 micro seconds wHubDelay 4 nano seconds DeviceRemovable0xff 0xff Hub Port Status: Port 1: .0200 5Gbps power U0 Port 2: .0200 5Gbps power U0 Port 3: .0200 5Gbps power U0 Port 4: .0200 5Gbps power U0 Port 5: .0200 5Gbps power U0 Port 6: .0200 5Gbps power U0 Port 7: .0200 5Gbps power U0 Port 8: .0200 5Gbps power U0 Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 15 bNumDeviceCaps 1 SuperSpeed USB Device Capability: bLength10 bDescriptorType16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x0008 Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 3 Lowest fully-functional device speed is SuperSpeed (5Gbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds Device Status: 0x0001 Self Powered Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Andre Valentin writes: > 3) Problems with QMI Interfaces > QMI is used for mobile phones and interact with the qmi_wwan driver in the > kernel. I had transmit issues, > switched the driver back to the 4.14 while still on 5.4. But the same problem > happens again. > Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches somehow > are the root cause. > Here's the kernel message: > > > [ 4199.444191] [ cut here ] > [ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 > dev_watchdog+0x2f8/0x300 > [ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out And this is not just an occasional timeout? The driver hangs completely there? I don't think there were many qmi_wwan changes between v4.14 and v5.4, except for device additions and some fixes which mostly have been backported to v4.14-stable. But maybe this is related to your specific modem? Do you have a device ID for that? Do we know that USB is working on v5.4 BTW? The MT7621 device I am using doesn't have any USB ports, so I can't check that myself. Is your modem connected by USB3 or USB2? Any of lsusb -v cat /sys/kernel/debug/usb/devices grep . /sys/bus/usb/devices/*/version will tell. You'll have to match up the latter with the device if you have more than one USB device connected. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
[CC Sergio who worked on upstream PCIE driver] On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: > > Hi! > > Currently I'm having some serious problems with the new 5.4 port. > 1) PCIe > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e connected > to second bus on the first phy. > If booting the device, kernel hangs with a RST message, telling the device is > not detected. It seems the PCIe bus 1 > cannot be reseted because nothing is connected to bus 0. > An upport of the old PCI driver reenables the function. I can provide more > logs on this if needed. Hi Sergio: You may want to look into this. > 2) DSA > These are my first experiments with DSA. I've configured 2 bridges: > lan: lan1 lan2 lan3 lan4 > dmz: lan1.20 lan2.20 lan3.20 lan4.20 > > Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 > port but does note arrive at the other end. > > Should this work with DSA on mediathek? It's supposed to work so this may be yet another bug upstream. > If not, I can offer that I write a patch for traditional swconfig. swconfig is considered deprecated so there's no need to do so. In fact, this driver under mediatek target also works for mt7621: target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Currently I'm having some serious problems with the new 5.4 port. 1) PCIe I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e connected to second bus on the first phy. If booting the device, kernel hangs with a RST message, telling the device is not detected. It seems the PCIe bus 1 cannot be reseted because nothing is connected to bus 0. An upport of the old PCI driver reenables the function. I can provide more logs on this if needed. 2) DSA These are my first experiments with DSA. I've configured 2 bridges: lan: lan1 lan2 lan3 lan4 dmz: lan1.20 lan2.20 lan3.20 lan4.20 Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 port but does note arrive at the other end. Should this work with DSA on mediathek? If not, I can offer that I write a patch for traditional swconfig. 3) Problems with QMI Interfaces QMI is used for mobile phones and interact with the qmi_wwan driver in the kernel. I had transmit issues, switched the driver back to the 4.14 while still on 5.4. But the same problem happens again. Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches somehow are the root cause. Here's the kernel message: [ 4199.444191] [ cut here ] [ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 dev_watchdog+0x2f8/0x300 [ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out Mon Apr 6 16:27[ 4199.483839] Modules linked in: qcserial option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppoe pl2303 l2tp_ppp iptable_nat ipt_REJECT huawei_cdc_ncm ftdi_sio cdc_subset cdc_ncm cdc_ether cdc_eem xt_u32 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_socket xt_recent xt_quota xt_policy xt_pkttype xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_cluster xt_bpf xt_addrtype xt_TRACE xt_TPROXY xt_TCPMSS xt_REDIRECT xt_NETMAP xt_MASQUERADE xt_LOG xt_LED xt_HL xt_DSCP xt_CT xt_CLASSIFY xor wireguard vhci_hcd usbserial usbnet usblp usbip_host usbip_core ts_fsm ts_bm pptp pppox ppp_synctty ppp_mppe ppp_async nfnetlink_queue nfnetlink_log nf_tproxy_ipv6 nf_tproxy_ipv4 nf_socket_ipv6 nf_socket_ipv4 nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4 :24 2020 kern.wa[ 4199.484081] nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conncount macvlan iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ECN ipt_CLUSTERIP ipheth ip6table_raw ip_tables hso crc_ccitt cdc_wdm cdc_acm asn1_decoder arptable_filter arpt_mangle arp_tables fuse sch_teql sch_sfq sch_red sch_prio sch_pie sch_multiq sch_gred sch_fq sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp act_simple act_police act_pedit act_ipt act_gact act_csum libcrc32c act_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred evdev lp i2c_dev ledtrig_usbport ppdev parport ledtrig_heartbeat ledtrig_gpio cryptodev xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface rn kernel: [ 419[ 4199.660920] ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_rt ip6t_mh ip6t_ipv6header ip6t_hbh ip6t_frag ip6t_eui64 ip6t_ah nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 pppoatm ppp_generic slhc msdos bonding ip6_gre ip_gre gre ifb dummy nat46 l2tp_ip6 l2tp_ip l2tp_eth ip6_vti ip_vti sit l2tp_netlink l2tp_core ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel ipcomp esp4 ah4 ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel veth tun xfrm_user xfrm_ipcomp af_key xfrm_algo vfat fat udf crc_itu_t ntfs isofs dns_resolver br2684 atm fscache nls_utf8 nls_iso8859_1 nls_cp850 nls_cp437 nls_cp1250 vxlan udp_tunnel ip6_udp_tunnel wp512 twofish_generic twofish_common tgr192 tea serpent_generic khazad cast6_generic cast5_generic cast_common camellia_generic blowfish_generic blowfish_common anubis xts 9.444191] --[ 4199.836284] crypto_user algif_skcipher algif_rng algif_hash algif_aead af_alg sha512_generic sha256_generic libsha256 sha1_generic seqiv jitterentropy_rng drbg pcbc michael_mic md5 md4 hmac ghash_generic gf128mul gcm echainiv ecb des_generic libdes ctr cmac ccm cbc authenc arc4 usb_storage input_polldev leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ledtrig_transient fsl_mph_dr_of ehci_platform ehci_fsl sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jb
