<{^_^}>
#97875 (by deliciouslytyped, 32 seconds ago, open): Mixing versions of openiscsi daemon and clients for the daemon results in the clients hanging (and otherwise broken behaviour)
<pie_>
not really sure what could be done about this
<clever>
2020-09-12 21:06:25 < pie_> version your protocols kids
<samueldr>
I'd like a "2.status: will be stale"
<samueldr>
;)
<pie_>
:ppp
<samueldr>
it's not something we can really do anything about
<clever>
id open it against upstream
<samueldr>
so please nudge upstream yeah
<samueldr>
and link back the discussion
<samueldr>
hopefully an issue tracker and not a dreaded mailing list
<pie_>
doesnt let you do anything retroactively but at least maybe fixes the future
<{^_^}>
open-iscsi/open-iscsi#222 (by deliciouslytyped, 31 seconds ago, open): MIxing versions leads to subtle breakage, please version your protocol
* clever
cheers
<pie_>
now with that yak shave aside lets see if i can actually get somewhere
<pie_>
(which should be bed but no :P)
<pie_>
clever: so what do i do after iscsistart? no matter what i do it seems to complain about the session already existing, but it does seem to log in
<clever>
pie_: does a blockdev magically appear in /dev/? check dmesg?
<pie_>
ive been checking /by-path/ and not there
<pie_>
clever: im guessing the disk creation section is failing?
<pie_>
clever: also with iscsistart, the login is done but --logout doesnt work until i restart the daemon and it recovers something
<pie_>
though that might just be because the daemon isnt informed
<pie_>
oh maybe i should stop the daemon
<clever>
yeah
<clever>
iscsistart is meant to be ran without the daemon
<pie_>
man i dont like this stateful stuff
<pie_>
i need to get the containers figured out
<pie_>
i would really like not having to wait for squashfs :p
<pie_>
assuming the image generation is faster withut it
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 240 seconds]
h0m1 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
mvnetbiz_6 has joined #nixos-aarch64
mvnetbiz_ has quit [Ping timeout: 264 seconds]
mvnetbiz_6 is now known as mvnetbiz_
<samueldr>
neat, just took my old work for u-boot on rpi4 and it seems to work now
<samueldr>
maybe the updated packages since that time
knerten2 has joined #nixos-aarch64
<clever>
after countless hours, i finally have the ability to send a 132 byte packet to the VPU firmware, lol
<clever>
the biggest mistake, was just blindly turning interrupts off, then back on, when you register an interrupt handler
<clever>
that turned them on, when they should have been off
<clever>
and then, i forgot to change the clock source, so it was still running at 19.2mhz, and the code couldnt keep up with the uart
knerten1 has quit [Ping timeout: 240 seconds]
<samueldr>
if my intuition is right, we can start shipping u-boot for pi4 with the mainline image, and whenever mainline works on pi4 the image will just work
<samueldr>
(assuming all kernel options are accounted for)
<pinage404[m]>
betrion: i clone it anywhere (usually, in my `/home`) because i do a symlink `sudo ln -sr nixos_config /etc/nixos` to put it in the right path
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
Darkmatter66 has joined #nixos-aarch64
<betrion[m]>
<pinage404[m] "betrion: i clone it anywhere (u"> ok thank you
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
<pinage404[m]>
i'm trying to add this `boot.kernelPackages = pkgs.linuxPackages_rpi3;` in my Raspberry Pi 3 B config (just because the name seems to suit to the machine) but `nixos-rebuild switch` fail, it says there is no space left, it fills the `/tmp` directory with this big directory `nix-build-cpupower-4.19.75-1.20190925.drv-0` ; what can i do ?
alp has quit [Ping timeout: 246 seconds]
andi- has quit [Ping timeout: 244 seconds]
andi- has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
pbb has quit [Ping timeout: 246 seconds]
kloenk has quit [Ping timeout: 244 seconds]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
<Mic92>
Meh. I should have go for rpi rather than a rock64
<Mic92>
Still no upstream support for hdmi sound
t184256 has left #nixos-aarch64 ["Error from remote client"]
<pinage404[m]>
`nix search 'linuxPackages.*rpi'` take MANY memory and doesn't respond after too much times, what happend ?
<pinage404[m]>
if anyone has the same issues for the no space left for `boot.kernelPackages = pkgs.linuxPackages_rpi3;` i have solved with `TMPDIR=/media/data_hdd/tmp nixos-rebuild switch`
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
juliosueiras has joined #nixos-aarch64
pbb has joined #nixos-aarch64
alp has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
zupo has joined #nixos-aarch64
bennofs__ has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 260 seconds]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 246 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
alp has quit [Ping timeout: 244 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 244 seconds]
<samueldr>
Mic92: not like usptream support for the pi is better really
<samueldr>
you would have had to go for a previous model
<Mic92>
Yeah, my rock64 is as old as the previous model
<samueldr>
the only thing the raspberry pi family of products has that is truly different from other devices, is the size of the community
<samueldr>
but the foundation acts just as badly (if not worse) than other vendors regarding their "BSP"
<Mic92>
I can get a up-to-date kernel for the raspiberry pi that fully supports the hardware.
<samueldr>
with a forked-off kernel with enough differences that it causes issues
<Mic92>
The rock64 will never it stuff upstream
<samueldr>
it uses rockchip hardware, once another board has that supported, generally all other boards improve at the same time
<samueldr>
and I'd say that mainline support is as community-supported for other SoCs and SBCs than raspberry pi is
<samueldr>
not entirely sure, I don't think they have people from the foundation working on mainline
<samueldr>
working here meaning the main focus
<Mic92>
Well, I also get the intention that the graphics driver quality is low.
<samueldr>
I assume here rockchip and raspberry pi at the same time
<Mic92>
I just get kernel oops
Darkmatter66 has joined #nixos-aarch64
<samueldr>
though right that panfrost is a bit newer than the vc4 driver
<Mic92>
Maybe I should just go back to x86.
<samueldr>
basically, what I'm saying is that the raspberry pi is not a panacea when thinking mainline, compared to other SBCs
<samueldr>
it's a bit oversold that they're "open source friendly" and "just linux"
<samueldr>
oversold? overblown? anyway, not as true as it is :(
<Mic92>
At least their devices feel more stable
<samueldr>
I'd wager than only a single-digit percentage of users in their community is using mainline
<samueldr>
(there is a wild amount of raspberry pi users! the mainline users are probably, in absolute numbers, much bigger than I'd think anyway, but comparatively it's probably small)
<Mic92>
Yeah. Even more a reason to not go for the niche boards.
<aminechikhaoui>
Hello, is there a usable rpi4 image from hydra by any chance ?
<samueldr>
Mic92: isn't that only for when if= is a file?
<Mic92>
Yes. In your case it is a pipe
<samueldr>
uh, turns out I never pushed my changes
<samueldr>
oh, seek_bytes and skip_bytes could be useful
<samueldr>
I'll try to remember next time I have to make gnarly dd chains
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Thra11>
samueldr: btw, I've started packaging up the plasma-mobile stuff (the mobile frameworks bits + the apps in https://invent.kde.org/plasma-mobile)
<samueldr>
there was a previous (or was it you?) effort IIRC
<samueldr>
just in case you hadn't seen it
<samueldr>
aminechikhaoui: that specific image worked for me
<Thra11>
samueldr: I've seen an old PR just for the plasma-phone-components package. Was there more than that?
<samueldr>
I don't know for sure
<samueldr>
but you made due diligence in checking I assume then :)
<samueldr>
it's such a bummer when you spend some time doing something, only to find a PR with the same exact changes
<Thra11>
True
<Thra11>
When I want something which isn't packaged yet, I usually start with a nixpkgs PR / issue search.
<Thra11>
Probably my number one way of discovering interesting PRs to review
<samueldr>
good, I still forget sometimes to check, for fixing bugs it's kind of worse since it's more likely someone has done the change already!
orivej has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-aarch64
<aminechikhaoui>
samueldr oh then it might be my sdcard or the adapter having problems
<aminechikhaoui>
thanks for checking !
<samueldr>
I guess there could still be the issue of the eeprom content misbehaving with the firmware partition content
<samueldr>
which is... not something I know how to debug really
cole-h has quit [Quit: Goodbye]
<samueldr>
heh, our "all =m" thing for kernel configuration can produce weird results
<samueldr>
like CONFIG_CMDLINE="m"
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Mic92>
thefloweringash: do you know where rockchip's mpp went?
orivej has quit [Ping timeout: 244 seconds]
<Mic92>
I see mpv now supports rkmpp directly
<aminechikhaoui>
samueldr hm raspios did boot fine though
<samueldr>
aminechikhaoui: you did re-dd the nixos image too, right? how did you get the image? maybe you had an incomplete download through the browser?
<samueldr>
I used nix-store --realise
<aminechikhaoui>
I did curl -O of the url of the hydra build product
<aminechikhaoui>
but I can try nix-store -r as well
<samueldr>
the only difference I can see is that nix-store -r would check the outputs
<samueldr>
one thing I wanted to add to burninate was a verification on-device
<samueldr>
aminechikhaoui: your SD card is big enough, right? I think 4GB+ is required
<samueldr>
2GB won't cut it
<aminechikhaoui>
yeah I have 32Gb
<aminechikhaoui>
samueldr magic ! it's now working
<aminechikhaoui>
so it's all stupid issues preventing me from experimenting with it all this time :p
<aminechikhaoui>
it's a bit odd I get something corrupt from curl
<aminechikhaoui>
I meant wouldn't zstd -d fail as well
<samueldr>
I don't know how it acts on a truncated input
<samueldr>
it *is* a stream compression/decompression scheme after all
<samueldr>
you might want to sha256sum the two different files to compare
<samueldr>
if they're the same, then *something else* changed, maybe that `dd` invocation ended up syncing before you removed the device
<samueldr>
you did sync and/or eject, did you?
<aminechikhaoui>
oh it might be a sync problem, tho since I'm not mounting a filesystem I though dd operations don't need sync
<samueldr>
unless you do direct I/O, which I don't know if it'd do by default without being told to, might not
<samueldr>
oflag=direct,sync is what I usually end up using
<samueldr>
which AFAIUI that sync is now redundant
<samueldr>
but eh, better be safe than sorry
<aminechikhaoui>
this might be why I always have problems with dd for burning images :D
<aminechikhaoui>
I sometimes switch to unetbootin just for that, which I guess makes sure to handle syncing
justanotheruser has quit [Ping timeout: 244 seconds]
quinn has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Smith[m] has joined #nixos-aarch64
<samueldr>
clever: you're quite Raspberry Pi-adjacent, do you have any clues to look into for #97732
<samueldr>
it seems that using the Raspberry Pi Foundation's own 5.4 kernel fails to boot with U-Boot
<samueldr>
that same exact kernel boots fine directly from the firmware, and the foundation's 4.9 kernel boots fine both with U-Boot and the firmware
<samueldr>
"fails to boot" here means that during stage-1 mmc0 (the sd card) never shows up
<clever>
samueldr: pi3 or pi4?
<samueldr>
pi 4
<samueldr>
on the pi 3 the same exact kernel is fine
<samueldr>
(using bcm2711_defconfig, so the pi4's defconfig AFAIK)
<clever>
the 4 has a 3rd SD controller, is uboot saying to use the right one?
<samueldr>
hm?
<clever>
try building an initrd that includes a shell and the dtc binary
<clever>
then run `dtc /proc/device-tree` with and without uboot
<clever>
and see what the difference is
t184256 has left #nixos-aarch64 ["Error from remote client"]
<samueldr>
U-Boot itself does not ship a device tree for the rpi4, so this uses a raspberry pi foundation's FDT, which both the pre-built and the kernel-built fail
<clever>
the firmware also patches the dtb after loading it
<clever>
and uboot may undo that patching
<samueldr>
just stating again that with rpi-4.9 all is fine
<clever>
ah, same firmware in both cases?
<samueldr>
yes, only diff is linux_rpi's version
<samueldr>
and using the same prebuilt raspberrypifw FDT
<samueldr>
so it truly is the only difference
<samueldr>
one thing I haven't tried is shoving the prebuilt FDT on top of the kernel-built FDT
<samueldr>
brb
<thefloweringash>
Mic92: your comment made me go look, and it sure looks like the main rockchip-linux/mpp repo his disappeared.
<clever>
that looks like SDHCI, what was the main controller on VC4
<clever>
it may not be muxed to any pins, causing issues
superherointj has joined #nixos-aarch64
<superherointj>
Hello.
<clever>
oh wait, correction, SDHCI was for wifi
<clever>
[ 3.862219] mmc1: new high speed SDIO card at address 0001
<samueldr>
clever: that deferring probe is present too on the non-u-boot image
<clever>
samueldr: so mmc1 is the old SDHCI
<clever>
and it manages wifi
<samueldr>
quite possibly, emmc2 is the name in the DT for mmc0
<clever>
mmc0 then is the uSD slot, but i dont see that in dmesg
<samueldr>
yeah, that's a "failed" boot :)
bennofs__ has quit [Remote host closed the connection]
bennofs has joined #nixos-aarch64
<clever>
samueldr: if you `find /sys
<clever>
samueldr: if you `find /sys | grep mmc` do you see a second instance, that isnt mmc1
<superherointj>
I think the PR is now acceptable: https://github.com/NixOS/nixpkgs/pull/97764 ... with backports 20.09 / 20.03 ready too. It just has to be reviewed and accepted. But I don't want to bother. But I am a bit anxious in seeing it working. Hope you understand. Humans. :D
<lovesegfault>
> The option definition `hardware.deviceTree.base' in `/home/bemeurer/src/nix-config/hardware/rpi4.nix' no longer has any effect; please remove it.
<{^_^}>
error: syntax error, unexpected $undefined, expecting ')', at (string):323:23
<samueldr>
lovesegfault: possible, there are recent PRs changing behaviour
<lovesegfault>
Trying to figure out how it should be now
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
<samueldr>
clever: the .dts don't really seem to have consequential differences