This can occur either randomly on install/remove of a drive, or after the drive has simply been plugged in for a few hours/days. Occurs if drive is either plugged directly into SBC, or via a powered Pluggable USB3-Hub7C. I've also noticed that I can reliably trigger the issue if I insert the USB device really slowly (ie: not a 'clean' insert) -- not sure if this is related?
I have two N2s (bought in the CoreElec kit), and the issue occurs on both.
Was connected via SSH & running journalctl -f when this happened and saw:
Mar 11 18:12:25 NewPi kernel: sd 0:0:0:1: [sdb] Attached SCSI removable disk
Mar 11 18:12:29 NewPi kernel: usb 2-1.2.3: usb_reset_and_verify_device Failed to disable LTM
.
Mar 11 18:12:29 NewPi kernel: usb 1-1.2.3: new high-speed USB device number 5 using xhci-hcd
Mar 11 18:12:30 NewPi kernel: usb 2-1.2.3: USB disconnect, device number 17
Mar 11 18:12:30 NewPi kernel: amlogic-new-usb2-v2 ffe09000.usb2phy: ---Recovery port(2) tuning for host cf(hub_event)--
Mar 11 18:12:30 NewPi kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000038
Message from syslogd@NewPi at Mar 11 18:12:31 ...
kernel:[ 6740.706919@0] Internal error: Oops: 96000047 [#1] PREEMPT SMP
Is there any way to better capture debug information?
Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
Buster / 10.8
Kernel version | uname -a
Linux NewPi 4.9.241-arm64 #1 SMP PREEMPT Thu Feb 25 18:56:07 CET 2021 aarch64 GNU/Linux
SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
Odroid N2 (aarch64)
Power supply used
Odroid supplied PSU
SDcard used are Sandisk Ultra in Kingston MobileLite G4 card reader and Samsung T5 Portable SSD. Can be either direct plugged or plugged in via a powered Pluggable USB3-Hub7C.
Additional Information (if applicable)
Steps to reproduce
Power on SBC
Plug in USB drive
Wait for a number of hours / days
Observe hard lockup
or
Power on SBC
Repeatedly plug / unplug USB drive
Wait an hour or two
Goto step 2 until hard lockup observed
Expected behaviour
SBC with DietPi should continue running & being available
Actual behaviour
Hard lockup. Console unresponsive (just blinking cursor), no messages. Stops responding to ping or any other network traffic, drops SSH sessions.
Hi,
Running either DietPi or your 'latest' Ubuntu distro (https://odroid.in/ubuntu_20.04lts/n2/ubuntu-20.04-4.9-minimal-odroid-n2-20210202.img.xz) on Odroid N2 (not N2+), I experience hard lockups (console unresponsive, no response to ping on LAN nor any other network traffic, SSH connections dropped) when using USB drives.
This can occur either randomly on install/remove of a drive, or after the drive has simply been plugged in for a few hours/days. Occurs if drive is either plugged directly into SBC, or via a powered Pluggable USB3-Hub7C. I've also noticed that I can reliably trigger the issue if I insert the USB device really slowly (ie: not a 'clean' insert) -- not sure if this is related?
I have two N2s (bought in the CoreElec kit), and the issue occurs on both.
I have gone back-and-forth with the DietPi guys (https://github.com/MichaIng/DietPi/issues/4188) and they've finally said it's a hardware/kernel issue & that I should ask here.
I'm hoping you can help!!! :)
Was connected via SSH & running
journalctl -f
when this happened and saw:Is there any way to better capture debug information?
DietPi version | cat /boot/dietpi/.version
Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
Buster / 10.8
Kernel version | uname -a
Linux NewPi 4.9.241-arm64 #1 SMP PREEMPT Thu Feb 25 18:56:07 CET 2021 aarch64 GNU/Linux
SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
Odroid N2 (aarch64)
Power supply used Odroid supplied PSU
SDcard used are Sandisk Ultra in Kingston MobileLite G4 card reader and Samsung T5 Portable SSD. Can be either direct plugged or plugged in via a powered Pluggable USB3-Hub7C.
Additional Information (if applicable)
Steps to reproduce
or
Expected behaviour
SBC with DietPi should continue running & being available
Actual behaviour
Hard lockup. Console unresponsive (just blinking cursor), no messages. Stops responding to ping or any other network traffic, drops SSH sessions.