Kernel oops adding eth0 to bridge on Pi3+ #2437
Comments
|
Bridging is an advanced use case that hasn't been tested here. The code path in question doesn't exist in the 4.14 kernel we will be switching to imminently. Can you run |
|
Still get an Oops with Linux version 4.14.26-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1099 SMP Wed Mar 14 14:59:28 GMT 2018
|
|
I too am experiencing this on a RPi3 B-Plus (the RPi3 B works fine with the identical setup). I actually opened a ticket against systemd (using systemd-networkd to setup the bridge): systemd/systemd#8503 thinking it was to blame. Distro: Arch ARM (armv7h) |
|
This may have the same root cause as #2442, for which we are waiting for a patch to be completed and accepted upstream. |
|
@pelwell - Sounds good, thanks for the link. |
See: raspberrypi/linux#2458 kernel: Revert lan78xx: Simple patch to prevent some crashes kernel: lan78xx: Connect phy early kernel: lan78xx: Don't reset the interface on open See: raspberrypi/linux#2437 See: raspberrypi/linux#2442 See: raspberrypi/linux#2457 firmware: clockman: Don't use OSC for pixel clock See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679&start=150#p1297298
See: raspberrypi/linux#2458 kernel: Revert lan78xx: Simple patch to prevent some crashes kernel: lan78xx: Connect phy early kernel: lan78xx: Don't reset the interface on open See: raspberrypi/linux#2437 See: raspberrypi/linux#2442 See: raspberrypi/linux#2457 firmware: clockman: Don't use OSC for pixel clock See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679&start=150#p1297298
|
Latest rpi-update kernel has a potential fix for this issue. Please test. |
|
@popcornmix - Arch ARM doesn't use that script but I am building:
Will try and report back, thank you! |
|
Doesn't look like eth0 works at all now on the 3b+ even before being added to a bridge. Using a fresh 2018-03-13-raspbian-stretch-lite.img (with "enable_uart=1" added to config.txt) On first boot dhcpcd gets an IP on eth0 and it works OK. Run "sudo rpi-update"
And reboot eth0 no longer gets an IP address Even after assigning an IP/netmask to eth0 on the manually it's unable to ping the gateway/other IP in the subnet. |
...does this correspond to a commit in https://github.com/raspberrypi/firmware/commits/master ? I cannot find it. |
|
@graysky2 rpi-update gets firmware from https://github.com/Hexxeh/rpi-firmware |
|
@popcornmix - Thanks. To keep things simple, I will limit my replies to #2442 rather than mirroring them here. |
|
Looking at the output of ethtool before/after updating the only difference I could see was Trying to set it back to external with "sudo ethtool -s eth0 xcvr external" fails with the error
BUT from a fresh boot if I run "sudo ethtool -s eth0 xcvr internal" (even though it already says internal) I get an IPv6 address via NDP and DHCP obtains an IPv4 address a few seconds later and things work again. |
|
Thanks for the update. I've been investigating and the failure seems to be timing dependent - adding logging makes it go away (there may be a minimal useful set), and adding |
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
|
The code that enabled EEE mode was running at the point the interface was being opened. This forced a second round of negotiation, delaying readiness (sometimes permanently, depending on the timing). Moving the EEE enabling into the PHY initialisation function, immediately after the connection to the PHY is established, which is long before phy_start is called, prevents the renegotiation and avoids the slowdown (and occasional failure). |
|
Yes there was another issue, but my moving some of the initialisation code (c2eb306) I believe that issue has been resolved. |
|
With the rpi-update kernel after adding "dtparam=eee=off" eth0 links and works OK on fresh Raspbian and adding to a bridge also works OK. Recompiling with c2eb306 eth0 links OK (without "dtparam=eee=off") and can also be added to a bridge without Oops. |
|
Cool. I'll close the issue after the next firmware release. |
|
@pelwell Do you have a rough idea, when a fixed kernel and firmware will be released as deb package? |
|
The firmware could be released today (@popcornmix), and the .deb depends on @XECDesign. |
|
Given that there are several stability investigations ongoing, releasing a new .deb now would be premature. |
See: raspberrypi/linux#2437 kernel: config: Add BT_HCIUART_BCM=y and SERIAL_DEV_BUS=m See: raspberrypi/linux#2479 firmware: config: gpio - Allow pn (pull none) as alternative to np (no pull)
See: raspberrypi/linux#2437 kernel: config: Add BT_HCIUART_BCM=y and SERIAL_DEV_BUS=m See: raspberrypi/linux#2479 firmware: config: gpio - Allow pn (pull none) as alternative to np (no pull)
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Christoph reports a page allocator splat triggered by xfstests: generic/176 214s ... [ 1204.507931] run fstests generic/176 at 2024-05-27 12:52:30 XFS (nvme0n1): Mounting V5 Filesystem cd936307-415f-48a3-b99d-a2d52ae1f273 XFS (nvme0n1): Ending clean mount XFS (nvme1n1): Mounting V5 Filesystem ab3ee1a4-af62-4934-9a6a-6c2fde321850 XFS (nvme1n1): Ending clean mount XFS (nvme1n1): Unmounting Filesystem ab3ee1a4-af62-4934-9a6a-6c2fde321850 XFS (nvme1n1): Mounting V5 Filesystem 7099b02d-9c58-4d1d-be1d-2cc472d12cd9 XFS (nvme1n1): Ending clean mount ------------[ cut here ]------------ page type is 3, passed migratetype is 1 (nr=512) WARNING: CPU: 0 PID: 509870 at mm/page_alloc.c:645 expand+0x1c5/0x1f0 Modules linked in: i2c_i801 crc32_pclmul i2c_smbus [last unloaded: scsi_debug] CPU: 0 PID: 509870 Comm: xfs_io Not tainted 6.10.0-rc1+ #2437 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:expand+0x1c5/0x1f0 Code: 05 16 70 bf 02 01 e8 ca fc ff ff 8b 54 24 34 44 89 e1 48 c7 c7 80 a2 28 83 48 89 c6 b8 01 00 3 RSP: 0018:ffffc90003b2b968 EFLAGS: 00010082 RAX: 0000000000000000 RBX: ffffffff83fa9480 RCX: 0000000000000000 RDX: 0000000000000005 RSI: 0000000000000027 RDI: 00000000ffffffff RBP: 00000000001f2600 R08: 00000000fffeffff R09: 0000000000000001 R10: 0000000000000000 R11: ffffffff83676200 R12: 0000000000000009 R13: 0000000000000200 R14: 0000000000000001 R15: ffffea0007c98000 FS: 00007f72ca3d5780(0000) GS:ffff8881f9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f72ca1fff38 CR3: 00000001aa0c6002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x7b/0x120 ? expand+0x1c5/0x1f0 ? report_bug+0x191/0x1c0 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? expand+0x1c5/0x1f0 ? expand+0x1c5/0x1f0 __rmqueue_pcplist+0x3a9/0x730 get_page_from_freelist+0x7a0/0xf00 __alloc_pages_noprof+0x153/0x2e0 __folio_alloc_noprof+0x10/0xa0 __filemap_get_folio+0x16b/0x370 iomap_write_begin+0x496/0x680 While trying to service a movable allocation (page type 1), the page allocator runs into a two-pageblock buddy on the movable freelist whose second block is typed as highatomic (page type 3). This inconsistency is caused by the highatomic reservation system operating on single pageblocks, while MAX_ORDER can be bigger than that - in this configuration, pageblock_order is 9 while MAX_PAGE_ORDER is 10. The test case is observed to make several adjacent order-3 requests with __GFP_DIRECT_RECLAIM cleared, which marks the surrounding block as highatomic. Upon freeing, the blocks merge into an order-10 buddy. When the highatomic pool is drained later on, this order-10 buddy gets moved back to the movable list, but only the first pageblock is marked movable again. A subsequent expand() of this buddy warns about the tail being of a different type. This is a long-standing bug that's surfaced by the recent block type warnings added to the allocator. The consequences seem mostly benign, it just results in odd behavior: the highatomic tail blocks are not properly drained, instead they end up on the movable list first, then go back to the highatomic list after an alloc-free cycle. To fix this, make the highatomic reservation code aware that allocations/buddies can be larger than a pageblock. While it's an old quirk, the recently added type consistency warnings seem to be the most prominent consequence of it. Set the Fixes: tag accordingly to highlight this backporting dependency. Link: https://lkml.kernel.org/r/20240530114203.GA1222079@cmpxchg.org Fixes: e0932b6 ("mm: page_alloc: consolidate free page accounting") Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Christoph Hellwig <hch@infradead.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Tested-by: Christoph Hellwig <hch@lst.de> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
commit 54948a2d072e23217ebd5cb89f7ad3754790ee9d from https://github.com/raspberrypi/linux.git rpi-6.6.y Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 54948a2d072e23217ebd5cb89f7ad3754790ee9d from https://github.com/raspberrypi/linux.git rpi-6.6.y Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 54948a2d072e23217ebd5cb89f7ad3754790ee9d from https://github.com/raspberrypi/linux.git rpi-6.6.y Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: #2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
commit 54948a2d072e23217ebd5cb89f7ad3754790ee9d from https://github.com/raspberrypi/linux.git rpi-6.6.y Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 54948a2d072e23217ebd5cb89f7ad3754790ee9d from https://github.com/raspberrypi/linux.git rpi-6.6.y Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 54948a2d072e23217ebd5cb89f7ad3754790ee9d from https://github.com/raspberrypi/linux.git rpi-6.6.y Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
commit 54948a2d072e23217ebd5cb89f7ad3754790ee9d from https://github.com/raspberrypi/linux.git rpi-6.6.y Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Rajeshkumar Ramasamy <rajeshkumar.ramasamy@windriver.com>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi/linux#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
When adding eth0 to a bridge with a Pi3+ (Raspbian 2018-03-13) I get the following Oops on boot.
(full console output attached as startup.txt)
startup.txt
After the Oops Raspbian continues to boot but after many minutes doesn't get to the login prompt.
When the same SD card is used in a Pi3 (none +) it starts correctly and adds eth0 to br0.
To replicate - I'm using a fresh 2018-03-13-raspbian-stretch-lite.img with the following changes.
Add "enable_uart=1" to the end of /boot/config.txt
Boot & login
sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get -y install bridge-utils
sudo cat << EOF | sudo tee -a /etc/network/interfaces
auto br0
iface br0 inet manual
bridge_ports eth0
bridge_stp off
bridge_waitport 0
bridge_fd 0
EOF
echo "denyinterfaces eth0" | sudo tee -a /etc/dhcpcd.conf
sudo reboot
On boot I get the Oops above.
The text was updated successfully, but these errors were encountered: