OpenWrt/LEDE Project

Welcome to the OpenWrt/LEDE Project bug reporting and issue tracking system

Problems to be reported here are for the OpenWrt/LEDE Project targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt/LEDE Project website. Problems related to LuCI or OpenWrt packages need to be reported in their repositories:

Notifications of all submissions and task changes are sent to lede-bugs@infradead.org.

OpenedIDCategoryTask TypePrioritySeveritySummaryReported InStatus
18.05.20203109Base systemBug ReportVery LowCriticalUBIFS failure/crash on BT HomeHub 2B: __nand_correct_da...openwrt-19.07Unconfirmed Task Description

Device: BT HomeHub Version 2B (Lantiq XWAY)

Software: 19.07.3 downloaded from:

https://downloads.openwrt.org/releases/19.07.3/targets/lantiq/xway/openwrt-19.07.3-lantiq-xway-bt_homehub-v2b-squashfs-sysupgrade.bin

After an hour or so of usage, the router reboots itself with a corrupted filesystem. I’ve attached the log to this bug report. The log contains:

__nand_correct_data: uncorrectable ECC error

so I think there might be a link with the similar problem that the BT HomeHub Version 5A had a long time ago, as per:

https://bugs.openwrt.org/index.php?do=details&task_id=245 (”Lede won’t boot on HHB5”)

and

http://openwrt.ebilan.co.uk/viewtopic.php?f=7&t=133#p1022 (post by Mathias Kresin / mkresin who fixed the problem with the Home Hub 5A)

This bug may also be related to:

https://bugs.openwrt.org/index.php?do=details&task_id=1842

(I think that this bug may affect every release since 18.06.0)

10.03.20202893Base systemBug ReportVery LowHighEthernet port not receiving data on Ubiquiti LiteAP ac ...TrunkUnconfirmed Task Description

Hi,

The Ubiquiti LiteAP ac (LAP-120) does not receive incoming packets via eth0 with the latest snapshot (OpenWrt SNAPSHOT, r12498-2a18840cc7):

root@OpenWrt:/# ifconfig 
br-lan    Link encap:Ethernet  HWaddr B4:FB:E4:FA:FA:FA
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fdaa:a708:e003::1/60 Scope:Global
          inet6 addr: fe80::b6fb:e4ff:fefa:fafa/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:4420 (4.3 KiB)

eth0      Link encap:Ethernet  HWaddr B4:FB:E4:FA:FA:FA  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:6622 (6.4 KiB)
          Interrupt:4

It works correctly with latest stable, 19.07.2.

Using tcpdump on the connected computer I see outgoing traffic from the device, but incoming traffic does not reach the device.

The device correctly detects link changes, but different link speeds make no difference:

[ 1536.519019] eth0: link down
[ 1536.522824] br-lan: port 1(eth0) entered disabled state
[ 1537.561807] eth0: link up (1000Mbps/Full duplex)
[ 1537.566554] br-lan: port 1(eth0) entered blocking state
[ 1537.571932] br-lan: port 1(eth0) entered forwarding state
[ 1541.719009] eth0: link down
[ 1541.722824] br-lan: port 1(eth0) entered disabled state
[ 1542.761703] eth0: link up (100Mbps/Half duplex)
[ 1542.766359] br-lan: port 1(eth0) entered blocking state
[ 1542.771738] br-lan: port 1(eth0) entered forwarding state
[ 1545.879008] eth0: link down
[ 1545.882820] br-lan: port 1(eth0) entered disabled state
[ 1546.921800] eth0: link up (10Mbps/Half duplex)
[ 1546.926365] br-lan: port 1(eth0) entered blocking state
[ 1546.931744] br-lan: port 1(eth0) entered forwarding state

Please find attached dmesg outputs for both snapshot (snap) and 19.07.2 (19072).

12.11.20181946PackagesBug ReportVery LowLowuqmi --set-data-format does nothingTrunkUnconfirmed Task Description

Investigating commands.c file I’ve found that cmd_ctl_set_data_format_prepare (executed on –set-data-format option) sends zeroed ‘struct qmi_ctl_set_data_format_request sreq’ (command.c lines 149 to 163) to the modem so that operation does not affect modem’s behavior any way.

24.06.20181610Base systemBug ReportVery LowLowsysupgrade Image metadata not foundTrunkUnconfirmed Task Description

root@OpenWrt:~# sysupgrade openwrt-x86-64-combined-squashfs.img.gz
Image metadata not found
Reading partition table from bootdisk...
Reading partition table from image...
Saving config files...
Commencing upgrade. All shell sessions will be closed now.

 

And my .config file is ..

14.06.2017845KernelBug ReportVery LowMediumMT7628 : wrong data reading the I2C busAllUnconfirmed Task Description

Hi,

I’ve already talked to blogic about this issue. He asked me to perform some tests on the platform even back to openwrt CC.

The bug in question occurs with the MT7628 chip and the I2C bus (WRTNode 2p board).
Configuring the pinmux and enabling the driver, the kernel correctly sees the i2c bus. But then going to use the “i2cdetect” command from i2c-tools package has a surprising result: devices are actually sees devices that are not connected.

Curious about the problem I connected my DSO and I did the probe of the SDA and SCL pins. Data and clock seem to be transferred correctly. So the problem seems to be in the “reading”.

According to the i2c specification if SDA is pull-low and you do an i2cdetect the system should identify in the bus an ACK for each slave address, this does does not happen and the same list appear again.

Turning back to different versions this still happens, unfortunately I have not been able to test every single commit.
The test I’ve made:

  • Openwrt CC the device was not supported.
  • Openwrt first commit of the device support: the i2c bus was not recognized by the driver.
  • Openwrt trunk, the i2c bus is not registered
  • LEDE 12.01 the problem as described above.
  • LEDE HEAD: the problem as described above.
  • LEDE HEAD 4.9 (kernel): The problem as described above.

i2cdetect result (same result with SDA pulled low) .config wrtnode2p.dts

Regards,
hitech95

Showing tasks 1 - 5 of 5 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing