Pi hangs during boot on some powered USB hubs. #175
Comments
|
The USB power cable into the Pi has no data lines, so there is no identification info. I don't think the change in kernel version is significant. I think you have probably been underpowering the Pi and getting away with it. Possibly the kernel change has changed the timing of bootup, and you are getting a power surge (and hence a voltage drop) at a more critical time than before. |
|
I've checked the voltages, and they appear to be fine (average 4.97 volts) |
|
Are you powering the Pi through the micro usb power socket (S1)? |
|
Through the micro socket. Just checked the console again, it looks like one of the two chips in the hub may be bad, the Pi is trying to talk to devices that don't exist. |
|
Double checked without the hub; it won't boot at all, but I think that that is because the SSD that the root filesystem is on is not getting enough power. |
|
I've double checked the hub on another system, and have determined that the problem that I was having was in the hub itself, apparently the 4-port hub IC's the device uses aren't very well designed, and long term continuous use can cause them to overheat. |
popcornmix
pushed a commit
that referenced
this issue
Oct 8, 2014
Corrects the following checkpatch gripes:
WARNING: quoted string split across lines
#95: FILE: drivers/mfd/ab3100-core.c:95:
+ "write error (write register) "
+ "%d bytes transferred (expected 2)\n",
WARNING: quoted string split across lines
#139: FILE: drivers/mfd/ab3100-core.c:139:
+ "write error (write test register) "
+ "%d bytes transferred (expected 2)\n",
WARNING: quoted string split across lines
#175: FILE: drivers/mfd/ab3100-core.c:175:
+ "write error (send register address) "
+ "%d bytes transferred (expected 1)\n",
WARNING: quoted string split across lines
#193: FILE: drivers/mfd/ab3100-core.c:193:
+ "write error (read register) "
+ "%d bytes transferred (expected 1)\n",
WARNING: quoted string split across lines
#241: FILE: drivers/mfd/ab3100-core.c:241:
+ "write error (send first register address) "
+ "%d bytes transferred (expected 1)\n",
WARNING: quoted string split across lines
#256: FILE: drivers/mfd/ab3100-core.c:256:
+ "write error (read register page) "
+ "%d bytes transferred (expected %d)\n",
WARNING: quoted string split across lines
#299: FILE: drivers/mfd/ab3100-core.c:299:
+ "write error (maskset send address) "
+ "%d bytes transferred (expected 1)\n",
WARNING: quoted string split across lines
#314: FILE: drivers/mfd/ab3100-core.c:314:
+ "write error (maskset read register) "
+ "%d bytes transferred (expected 1)\n",
WARNING: quoted string split across lines
#334: FILE: drivers/mfd/ab3100-core.c:334:
+ "write error (write register) "
+ "%d bytes transferred (expected 2)\n",
WARNING: please, no spaces at the start of a line
#374: FILE: drivers/mfd/ab3100-core.c:374:
+ return blocking_notifier_chain_unregister(&ab3100->event_subscribers,$
WARNING: Prefer seq_puts to seq_printf
#458: FILE: drivers/mfd/ab3100-core.c:458:
+ seq_printf(s, "AB3100 registers:\n");
WARNING: quoted string split across lines
#564: FILE: drivers/mfd/ab3100-core.c:564:
+ "debug write reg[0x%02x] with 0x%02x, "
+ "after readback: 0x%02x\n",
WARNING: quoted string split across lines
#723: FILE: drivers/mfd/ab3100-core.c:723:
+ "AB3100 P1E variant detected, "
+ "forcing chip to 32KHz\n");
WARNING: quoted string split across lines
#882: FILE: drivers/mfd/ab3100-core.c:882:
+ "could not communicate with the AB3100 analog "
+ "baseband chip\n");
WARNING: quoted string split across lines
#906: FILE: drivers/mfd/ab3100-core.c:906:
+ dev_err(&client->dev, "accepting it anyway. Please update "
+ "the driver.\n");
total: 0 errors, 15 warnings, 999 lines checked
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Dec 10, 2018
When the armada thermal module is inserted, removed and then reinserted, the system panics as per the messages below. The reason is that "edit" a live resource in the resource tree twice, and end up with it pointing to some other hardware. Editing live resources (resources that are part of the registered resource tree) is not permissible - the resource tree is an ordered set of resources, sorted by start address, and when a new resource is inserted, it is validated that it (a) fits within its parent resource and (b) does not overlap a neighbouring resource. Get rid of this resource editing. We can instead adjust the return value from ioremap() as ioremap() deals with the creation of page- based mappings - provided the adjustment does not cross a page boundary. SError Interrupt on CPU1, code 0xbf000000 -- SError CPU: 1 PID: 2749 Comm: modprobe Not tainted 4.19.0+ #175 Hardware name: Marvell 8040 MACCHIATOBin Double shot (DT) pstate: 20400085 (nzCv daIf +PAN -UAO) pc : regmap_mmio_read+0x3c/0x60 lr : regmap_mmio_read+0x3c/0x60 sp : ffffff800d453900 x29: ffffff800d453900 x28: ffffff800096a1d0 x27: 0000000000000100 x26: ffffff80009696d8 x25: ffffff8000969000 x24: ffffffc13a588918 x23: ffffffc13a9a28a8 x22: ffffff800d4539dc x21: 0000000000000084 x20: ffffff800d4539dc x19: ffffffc13a5d5480 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000030 x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : 0000000000000000 x8 : ffffffc13a5d5a80 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffff800851be70 x2 : ffffff800851bd60 x1 : ffffff800d492ff8 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 1 PID: 2749 Comm: modprobe Not tainted 4.19.0+ #175 Hardware name: Marvell 8040 MACCHIATOBin Double shot (DT) Call trace: dump_backtrace+0x0/0x158 show_stack+0x14/0x1c dump_stack+0x90/0xb0 panic+0x128/0x298 print_tainted+0x0/0xa8 arm64_serror_panic+0x74/0x80 do_serror+0x5c/0xb8 el1_error+0xb4/0x144 regmap_mmio_read+0x3c/0x60 _regmap_bus_reg_read+0x18/0x20 _regmap_read+0x64/0x180 regmap_read+0x44/0x6c armada_ap806_init+0x24/0x5c [armada_thermal] armada_thermal_probe+0x2c8/0x37c [armada_thermal] platform_drv_probe+0x4c/0xb0 really_probe+0x21c/0x2b4 driver_probe_device+0x58/0xfc __driver_attach+0xd4/0xd8 bus_for_each_dev+0x50/0xa0 driver_attach+0x20/0x28 bus_add_driver+0x1c4/0x228 driver_register+0x6c/0x124 __platform_driver_register+0x4c/0x54 armada_thermal_driver_init+0x20/0x1000 [armada_thermal] do_one_initcall+0x30/0x204 do_init_module+0x5c/0x1d4 load_module+0x1a88/0x212c __se_sys_finit_module+0xa0/0xac __arm64_sys_finit_module+0x1c/0x24 el0_svc_common+0x94/0xf0 el0_svc_handler+0x24/0x80 el0_svc+0x8/0x3c0 SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,21806000 Memory Limit: none Signed-off-by: Russell King <[email protected]> Tested-by: Miquel Raynal <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
Feb 6, 2023
If a relocatable kernel is loaded at a non-zero address and told not to relocate to zero (kdump or RELOCATABLE_TEST), the mapping of the interrupt code at zero is left with RWX permissions. That is a security weakness, and leads to a warning at boot if CONFIG_DEBUG_WX is enabled: powerpc/mm: Found insecure W+X mapping at address 00000000056435bc/0xc000000000000000 WARNING: CPU: 1 PID: 1 at arch/powerpc/mm/ptdump/ptdump.c:193 note_page+0x484/0x4c0 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc1-00001-g8ae8e98aea82-dirty #175 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,git-dd0dca hv:linux,kvm pSeries NIP: c0000000004a1c34 LR: c0000000004a1c30 CTR: 0000000000000000 REGS: c000000003503770 TRAP: 0700 Not tainted (6.2.0-rc1-00001-g8ae8e98aea82-dirty) MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 24000220 XER: 00000000 CFAR: c000000000545a58 IRQMASK: 0 ... NIP note_page+0x484/0x4c0 LR note_page+0x480/0x4c0 Call Trace: note_page+0x480/0x4c0 (unreliable) ptdump_pmd_entry+0xc8/0x100 walk_pgd_range+0x618/0xab0 walk_page_range_novma+0x74/0xc0 ptdump_walk_pgd+0x98/0x170 ptdump_check_wx+0x94/0x100 mark_rodata_ro+0x30/0x70 kernel_init+0x78/0x1a0 ret_from_kernel_thread+0x5c/0x64 The fix has two parts. Firstly the pages from zero up to the end of interrupts need to be marked read-only, so that they are left with R-X permissions. Secondly the mapping logic needs to be taught to ensure there is a page boundary at the end of the interrupt region, so that the permission change only applies to the interrupt text, and not the region following it. Fixes: c55d7b5 ("powerpc: Remove STRICT_KERNEL_RWX incompatibility with RELOCATABLE") Reported-by: Sachin Sant <[email protected]> Tested-by: Sachin Sant <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
popcornmix
pushed a commit
that referenced
this issue
Mar 2, 2023
[ Upstream commit 111bcb3 ] If a relocatable kernel is loaded at a non-zero address and told not to relocate to zero (kdump or RELOCATABLE_TEST), the mapping of the interrupt code at zero is left with RWX permissions. That is a security weakness, and leads to a warning at boot if CONFIG_DEBUG_WX is enabled: powerpc/mm: Found insecure W+X mapping at address 00000000056435bc/0xc000000000000000 WARNING: CPU: 1 PID: 1 at arch/powerpc/mm/ptdump/ptdump.c:193 note_page+0x484/0x4c0 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.2.0-rc1-00001-g8ae8e98aea82-dirty #175 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,git-dd0dca hv:linux,kvm pSeries NIP: c0000000004a1c34 LR: c0000000004a1c30 CTR: 0000000000000000 REGS: c000000003503770 TRAP: 0700 Not tainted (6.2.0-rc1-00001-g8ae8e98aea82-dirty) MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 24000220 XER: 00000000 CFAR: c000000000545a58 IRQMASK: 0 ... NIP note_page+0x484/0x4c0 LR note_page+0x480/0x4c0 Call Trace: note_page+0x480/0x4c0 (unreliable) ptdump_pmd_entry+0xc8/0x100 walk_pgd_range+0x618/0xab0 walk_page_range_novma+0x74/0xc0 ptdump_walk_pgd+0x98/0x170 ptdump_check_wx+0x94/0x100 mark_rodata_ro+0x30/0x70 kernel_init+0x78/0x1a0 ret_from_kernel_thread+0x5c/0x64 The fix has two parts. Firstly the pages from zero up to the end of interrupts need to be marked read-only, so that they are left with R-X permissions. Secondly the mapping logic needs to be taught to ensure there is a page boundary at the end of the interrupt region, so that the permission change only applies to the interrupt text, and not the region following it. Fixes: c55d7b5 ("powerpc: Remove STRICT_KERNEL_RWX incompatibility with RELOCATABLE") Reported-by: Sachin Sant <[email protected]> Tested-by: Sachin Sant <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
popcornmix
pushed a commit
that referenced
this issue
May 6, 2025
Commit <5518f239aff1> ("iommu/vt-d: Move scalable mode ATS enablement to
probe path") changed the PCI ATS enablement logic to run earlier,
specifically before the default domain attachment.
On some client platforms, this change resulted in boot failures, causing
the kernel to panic with the following message and call trace:
Kernel panic - not syncing: DMAR hardware is malfunctioning
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc3+ #175
Call Trace:
<TASK>
dump_stack_lvl+0x6f/0xb0
dump_stack+0x10/0x16
panic+0x10a/0x2b7
iommu_enable_translation.cold+0xc/0xc
intel_iommu_init+0xe39/0xec0
? trace_hardirqs_on+0x1e/0xd0
? __pfx_pci_iommu_init+0x10/0x10
pci_iommu_init+0xd/0x40
do_one_initcall+0x5b/0x390
kernel_init_freeable+0x26d/0x2b0
? __pfx_kernel_init+0x10/0x10
kernel_init+0x15/0x120
ret_from_fork+0x35/0x60
? __pfx_kernel_init+0x10/0x10
ret_from_fork_asm+0x1a/0x30
RIP: 1f0f:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 0000:0000000000000000 EFLAGS: 841f0f2e66 ORIG_RAX:
1f0f2e6600000000
RAX: 0000000000000000 RBX: 1f0f2e6600000000 RCX:
2e66000000000084
RDX: 0000000000841f0f RSI: 000000841f0f2e66 RDI:
00841f0f2e660000
RBP: 00841f0f2e660000 R08: 00841f0f2e660000 R09:
000000841f0f2e66
R10: 0000000000841f0f R11: 2e66000000000084 R12:
000000841f0f2e66
R13: 0000000000841f0f R14: 2e66000000000084 R15:
1f0f2e6600000000
</TASK>
---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
Fix this by reverting the timing change for ATS enablement introduced by
the offending commit and restoring the previous behavior.
Fixes: 5518f23 ("iommu/vt-d: Move scalable mode ATS enablement to probe path")
Reported-by: Jarkko Nikula <[email protected]>
Closes: https://lore.kernel.org/linux-iommu/[email protected]/
Signed-off-by: Lu Baolu <[email protected]>
Tested-by: Jarkko Nikula <[email protected]>
Reviewed-by: Kevin Tian <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When powering the Raspberry Pi from a known good powered USB hub, Linux gets stuck in an infinite loop trying to get identification info from it the Pi's power cable.
Kernel is locally built from the 3.6.y branch; if needed, i can post the full config.
The hub is a D-Link DUB-H7.
This worked previously, prior to 523029f.
Works fine if not powering the Pi from the hub.
The text was updated successfully, but these errors were encountered: