| 09:11 | topi`> | at least my mcbin seems to be running OK - for now |
| 09:11 | topi`> | I did experience some mystical crash two months ago, but it hasn't resurfaced |
| 09:12 | topi`> | topi@macchiatobin:~$ uptime;uname -a 08:11:11 up 58 days, 23:43, 2 users, load average: 3.50, 3.59, 3.84 |
| 09:12 | topi`> | Linux macchiatobin 4.4.8-mcbin-marvell #1 SMP PREEMPT Mon May 15 18:59:41 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux |
| 09:13 | Ke> | running vendor kernel, how embarassing |
| 09:13 | topi`> | that's sad, but I don't have a remote serial interface to be able to take the risk of switching kernels |
| 09:13 | topi`> | there is a Raspberry Pi connected to it, but it is no longer responding to TCP |
| 09:13 | Ke> | https://78.media.tumblr.com/tumblr_mbe6dnF39p1qd58j4o1_250.gif |
| 09:14 | topi`> | Ke: do you have any particular kernel modules loaded? |
| 09:15 | topi`> | probably the bug(s) related to the mainline are close to the Marvell hardware and nothing to do with VFS etc layers |
| 09:15 | Ke> | topi`: http://paste.debian.net/1008457/ |
| 09:16 | topi`> | why do you have rt2800usb loaded? |
| 09:16 | Ke> | it could be a combination of slightly broken/overheating hw and bugs in error handling paths |
| 09:16 | topi`> | that's one of the worst offenders as far as modules go |
| 09:16 | Ke> | because it's a access point for wifi |
| 09:16 | topi`> | we replaced tens of rt28xx cards with Atheros wifi cards for our customers because the rt28xx kernel driver and/or the firmware kept on crashing |
| 09:17 | Ke> | was working quite flawlessly with x86_64 linux-4.9 on debian stretch |
| 09:17 | topi`> | and the only cost-effective solution was deemed to be the upgrade of all hardware |
| 09:17 | topi`> | "quite flawlessly", I think it's just pure luck |
| 09:17 | topi`> | I have nothing but hate towards rt28xx |
| 09:18 | topi`> | hey, what's this aes_* module there? |
| 09:18 | Ke> | luck in the sense that sure you can have a configuration that exposes bugs and a configuration that does not |
| 09:18 | topi`> | indeed. |
| 09:19 | Ke> | but it had so long testing perioid that it's not plausible that the problems here were present in that setup |
| 09:19 | topi`> | we also had a long testing period with rt28xx, but then decided to make a new image for the customer based on Jessie |
| 09:19 | topi`> | and then all hell broke loose |
| 09:20 | Ke> | arm64 has crypto extensions, what do you mean more specifically? |
| 09:20 | topi`> | so aes_ce_ccm is some of those kernel crypto subsystem's modules? |
| 09:21 | topi`> | last time I was paid to work on the kernel was 12 years ago; becoming very rusty here |
| 09:21 | Ke> | I would assume so, is there some particular reason to assume it's dubious spyware? |
| 09:21 | topi`> | no, I was just trying to find something that gets close to Marvell hardware |
| 09:22 | topi`> | since it's probably not a generic aarch64 flaw |
| 09:22 | Ke> | just remember that the particular individual has had problems before, perhaps it's just slightly broken |
| 09:22 | topi`> | oh, broken hardware. OK |
| 09:22 | topi`> | I also have one Hummingboard here which has all USB ports mute except one |
| 09:23 | Ke> | well I would not say it has been proven, but there are slight indications of that |
| 09:23 | topi`> | probably some static discharge has damaged one USB hub |
| 09:24 | Ke> | I also see some errors in the serial output, but that's just quite a common thing |
| 09:25 | suihkulokki> | I think aes_ce_* allows using aarch64 crypto extensions for in-kernel AES usage |
| 10:04 | topi`> | Ke: that's strange. The "serial" is behind an uart-usb bridge, and usually in these setups I see no errors in serial output whatsoever |
| 10:04 | topi`> | maybe your power supply is bad? |
| 11:09 | Ke> | perhaps, it's still high quality corsair power supply |