<thefloweringash>
and then wikipedia says for some specific models in each generation there's ecc support in i3 cpus
<samueldr>
in my case the xeon cpu was more about upgrading that machine while it was still my main machine in like 2015-2017
<samueldr>
yes, 2009 era hardware at that time!
<samueldr>
in 2017 I upgraded to 2012 era hardware with a used off-lease workstation that haad a xeon + ecc
<thefloweringash>
I don't think AMD has had competitive performance at a time when I've been in the market for buying a computer. Though I hear good things now.
<samueldr>
what you're saying is likely
<samueldr>
I wonder in what year I'll be using this decade's hardware (though this decade is quite fresh still)
<DigitalKiwi>
you'll find a lot of discussions on nas4free and freenas forums etc about the consumer intels that support ecc
<samueldr>
and you can come clean: it's for the thrill of owning xeon hardware a bit, right?
<thefloweringash>
I’m still quite fond of that aging hardware. Slightly smaller mATX case, a bunch of ram, remote management. Though that remote management is probably more of a security vulnerability than anything now.
<samueldr>
just don't tell anyone
<DigitalKiwi>
too late
<thefloweringash>
Is 2020 the year of ~linux~ arm on the desktop?
<samueldr>
hopefully!
<samueldr>
I now have the laptop sorted out, finally
<thefloweringash>
I would have bought ecc ram for my arm if I had found any
<DigitalKiwi>
" All AMD desktop CPUs since the Newcastle Athlon 64, including all Semprons, and all APUs since Trinity have supported ECC as far as I know.
<DigitalKiwi>
"
<DigitalKiwi>
so like...since 2003
<DigitalKiwi>
<3 AMD
<thefloweringash>
Yeah. Intel aren’t nice, but they’re fast. Come on amd, we need you.
<DigitalKiwi>
it's amazing they have any employees
orivej has joined #nixos-aarch64
andi- has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 265 seconds]
andi- has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-aarch64
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-aarch64
lopsided98 has quit [Client Quit]
lopsided98 has joined #nixos-aarch64
zarel_ has joined #nixos-aarch64
zarel has quit [Ping timeout: 268 seconds]
zarel has joined #nixos-aarch64
zarel_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
wavirc22 has joined #nixos-aarch64
wavirc22 has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
wavirc22 has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
wavirc22_ has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
m15k has joined #nixos-aarch64
<m15k>
Hej! Anyone is willing to share his configuration.nix for his/her raspberry pi 3?
ar has joined #nixos-aarch64
<evils>
m15k: far from perfect, it doesn't boot unless hdmi is connected and i don't get a wm xD, but it works headless once booted... https://hastebin.com/kanawetaco.bash
<m15k>
evils: are you currently working on getting it run with a wm?
<evils>
not really, my main goal is replacing raspbian for my server pi, and even that's low priority xD (and the not booting thing has higher priority)
<m15k>
Have you installed NixOS with the sd-image. I just wonder where the hardware-condiguration.nix is coming from.
<m15k>
I just installed the sd image to my sd card. And don't have such a file.
<evils>
i think this started with the sd image
<m15k>
Thanks evils! Good reference for me to get into the topic.
<evils>
well, not sure it's a good reference, but it may be better than none
<m15k>
I guess it helps for for reflecting what I need to do :)
orivej has joined #nixos-aarch64
m15k has quit [Remote host closed the connection]
craige has joined #nixos-aarch64
<tilpner>
,stateVersion evils
<{^_^}>
evils: Setting stateVersion to the latest release doesn't upgrade anything and can only break your setup at best. To actually upgrade NixOS see https://nixos.org/nixos/manual/#sec-upgrading. If you want to update the stateVersion option regardless, Ctrl-F for "stateVersion" in https://nixos.org/nixos/manual/release-notes.html to see things that need to be manually migrated with the new value.
<tilpner>
Setting it like that only brings disadvantages, and you gain nothing
ryantrinkle has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
<evils>
tilpner: i set that before i understood what that did, haven't changed it since, and am still unaware of the harm of setting it to unstable
<evils>
though i would set it to a specific version if i were to deploy this
<samueldr>
at one point in the past the linuxPackages_rpi package only worked for the original raspberry pi
<samueldr>
yeah, those instructions are from all the way back in 2017, I started re-doing this page last week to refresh it all and remove outdated or "weird" info
<clever>
bennofs: that line, lets the system write all cores to /mnt, so i can retreive them later on
zupo has joined #nixos-aarch64
<samueldr>
clever: and that's on your custom firmware, right?
<clever>
samueldr: yeah
<bennofs>
no idea what that is. i guess you have to gdb some more :)
<clever>
samueldr: but i dont see how anything the firmware is doing could impact it
<clever>
[ 0.000000] OF: fdt: Command line is: print-fatal-signals=1 console=ttyAMA0,115200 earlyprintk loglevel=7 printk.devkmsg=on boot.trace boot.shell_on_fail memtest=17
<clever>
i had linux run its own internal memtest, and it found zero problems
<clever>
so all ram linux is touching, is functioning properly
<clever>
and the firmware isnt doing anything to the system at the time of the fault
<clever>
bennofs: gdb currently fails in the initrd itself, copy_bin_and_libs broke it, but i can try for a full closure...
<bennofs>
clever: just the core would be enough I think
<bennofs>
to try and find out where it fails inside greedy_realloc, to see if it is an error in the arguments that get passed to it or if the heap state is corrupt
<clever>
bennofs: oh, and things dont fail if running under strace, not sure why yet
<bennofs>
clever: you could try perf trace if you want a less-invasive syscall trace
ryantrinkle has quit [Remote host closed the connection]
ryantrinkle has joined #nixos-aarch64
<m15k>
Can somebody tell me why sometime dmesg output is leaking into the login mask?
<samueldr>
the login mask?
<m15k>
terminal login prompt
<samueldr>
I think it's simply because the kernel writes to the console whenever it feels it needs to
<samueldr>
it just happens it's also the console you login into
<samueldr>
it would also happen over "your session", if you know what I mean
<m15k>
mh
<samueldr>
adapting loglevel and other boot arguments can help
<{^_^}>
#66960 (by samueldr, 22 weeks ago, open): Tracking issue for Raspberry Pi 3B+ and the latest kernel
<samueldr>
I personally can't verify
<samueldr>
I believe it should though
<m15k>
I guess it's not. At least I'm facing the problem with the latest image.
<samueldr>
which image exactly, and what is the issue?
<samueldr>
I mean, state what you're observing on your device
<samueldr>
oh, and which image was used?
<m15k>
At least there are boots without the problem...
<m15k>
Kernel: Linux rspbpi3b-hydrogen 5.4.13 #1-NixOS SMP Fri Jan 17 18:49:08 UTC 2020 aarch64 GNU/Linux
<samueldr>
it could be another issue; if I remember right that issue was an all or nothing situation, and caused by using an older u-boot that didn't know about the B+/A+ raspberry pi 3, and a newer kernel
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<m15k>
19.09.1936
<samueldr>
I didn't personally face the issue, but a couple users chimed in and there was no tracking issues for it
<samueldr>
okay, so 99% sure if there is an issue it's not *that* one
<samueldr>
first thing to note is that HDMI would never work, at all
<m15k>
Basically it's not very consistent. I had several boots with problem. Now after disconnecting power I hadn't.
<samueldr>
the pi 3 already was stretching its limits power-wise, not sure about the 3B+ if it's worse or better
<samueldr>
but one of the issues with the pi 3 was issues with video output
<m15k>
So you mean it's a hardware bug?
<samueldr>
possibly something that's hard to actually fix, though unverified
<samueldr>
that would make the pi print a lightning bolt if it's underpowered
<m15k>
But if this would be the problem shouldn't I see such a warning?
<samueldr>
we're actively removing the warnings in the config.txt since they step, or stepped, on the toes of the mainline linux graphics driver and caused bad behaviour
<samueldr>
for the 3B (not +) it would wreck the display when it tried to print the warning
<m15k>
Mh but that might explain why it's not happening all the time
orivej has quit [Ping timeout: 268 seconds]
<samueldr>
that's my hunch, but I could be off base