<damo22>gnu_srs1: it is a global variable, yes, it is set via trivfs_S_fsys_startup iirc <damo22>the stub in libtrivfs/startup.c is a weak alias so is not used when the real one is implemented <youpi>damo22: really sorry about yesterday evening, I was getting requested over several channels by different people, at some point I'm just mixing everything :/ <damo22>no worries, i ask a lot of simple questions, maybe you can tell me a good time to bother you <youpi>normally my daily work stops around 19:00 Paris time <youpi>that said, on thursday evenings (like now) I'm usually late to manage to prepare my course for friday afternoon <damo22>ok so after 5am my time there may be a small window for me to ask you <youpi>yeah you have your work as well :) <damo22>yeah, fortunately, i switch contexts by rotating my body 90 degrees to my other laptop <damo22>i now have a thinkpad just for hurd :D <damo22>the networking does not work on it with netdde yet, its a x230 and quite modern so probably needs rumpnet <gnu_srs1>damo22: Thanks for your reply :) Nevertheless, the code you pasted yesterday is very different from what youpi committed to savannah 3days ago? <damo22>yeah i will have a patch coming soon when i figure out how to make the stat work <youpi>I guess you can already send the fsys_init call fix, it makes sense alone anyway <damo22>yes, but unfortunately im technically at work now <youpi>I won't have time until friday 18:00 Paris time anyway <damo22>my work just obtained 4x Tesla NV gpus <youpi>for what kind of computation? <youpi>there are a lot of data transfers in genomics? <damo22>yes, we align whole human genomes <damo22>there is some cuda software that is closed source that will do it <damo22>one patient = 30GB bam file (compressed) <youpi>ok that doesn't even fit one GPU indeed :) <damo22>but the process is very repetitive <damo22>its like a jigsaw puzzle to put the pieces in the reference align <damo22>i hope one day to implement it in free software on gpus <damo22>the reference genome can fit in the GPU RAM <youpi>how many patients would typically be processed? <damo22>and then stream out of the card a series of results that solves the alignment <youpi>are you using PowerPC-based systems, or x86? <youpi>so the transfers from main memory are quite slow unfortunately <youpi>I guess the proprietary software wasn't available for PowerPC? <damo22>probably we do thousands per year <youpi>PowerPCNV's ability to avoid the PCI bottleneck is really useful <damo22>i will ask you more on this another day <youpi>that can be during the work-time, since in that case it's actually my work :) <damo22>we have purchased a specialised ASIC that does alignment and variant calling via FPGA <damo22>its fast, but we dont want to be locked to that vendor forever <youpi>is it more energy-efficient than GPUs? <youpi>being single-pcie is not the only criteria :) <damo22>it would be nice to have a free software alternative to the whole system though <youpi>that'd have to be OpenCL for instance <damo22>because we can run it on any gpu with opencl support, and fall back to cpu <youpi>yes, having the same code on the cpu is a big plus <youpi>getting good performance with the same code on cpu *and* on gpu is another question :) <damo22>well yeah, isnt that because the cpu usually has 1/100 of the processors? <youpi>it's also because execution units etc. are really very different <youpi>the basics of vectorization are similar <youpi>but the constraints are very differents <youpi>so the vectorization lengths at least, have to be completely different <damo22>i am interested in APU, when there is memory sharing between gpu and cpu, you dont need to copy the data <damo22>but NV is a pain with their binary drivers <damo22>nouveau are doing a great job, but one day they will too be stuck with signed firmware <damo22>being unable to change the default clock speed of the cards ***Server sets mode: +nt
***Server sets mode: +nt
*youpi finished preparing his course, crashing to bed <swivel>damo22: hey are you damo from zamaudio? <damo22>i hope to do audio recording with hurd one day <swivel>oh, that answers where I chatted with you about the mbox1, I just emailed you :) <swivel>it's popping and clicking randomly while I use it for audio playback <swivel>curious if you had any ideas for what might be causing that <damo22>sudo lsusb -vv -d 0dba:1000 |grep bcdDevice |awk '{print $2}' <swivel># lsusb -vv -d 0dba:1000 |grep bcdDevice |awk '{print $2}' <swivel>before updating i had the white noise problem you mentioned in your blog post ;) <damo22>great so you have the latest firmware, thats good <swivel>5.12.0-rc3 compiled from source, linus' tree, no patches <damo22>hmm i havent tried that kernel yet, but it should work. Do you have an oldish machine? <swivel>thinkpad x220 sandybridge i7 2.8ghz <damo22>i think x220 has some freezing issue with coreboot <damo22>you need to disable some cstates <damo22>ok then forget that line of thinking <damo22>maybe your irq scheduling is causing issues <swivel>i don't see these pops/clicks with the intel hda, it almost seems like a buffer alignment problem or brief underrun <damo22>do you use other usb devices on the same bus a lot? <damo22>i would try with no other usb devices plugged in at all <damo22>another thing you can try is enabling the IOMMU <damo22>it routes interrupts differentlt <damo22>i think its something in the kernel cmdline intel_iommu=on <swivel>lemme dig out another thinkpad to try it on since i need the usb wifi on this one to be online <damo22>i have a collection of mbox1 lying around as spares <swivel>you're the reason i picked one up :) <swivel>and it does sound much better than the intel hda integratd headphone stuff on my x220 <swivel>haven't even tried the microphone recording yet <damo22>capture is dead silent they didnt skimp on bypass caps <damo22>but if you want more channels, i recommend the Soundcraft Signature 12 multitrack <damo22>its an analog mixing desk with 14 ins and 12 outs <damo22>all individual channels go to usb2 <damo22>works out of the box with linux driver <swivel>i mostly just needed a clean usb audio output for coax spdif into my preamp, the fancy microphone inputs was a bonus <damo22>btw, i enabled the spdif sync source in alsamixer <damo22>so you can use external clock source from some other spdif <swivel>i saw that in the git history, nice work <damo22>bit perfect transfer of samples from a DAT for example <damo22>hmm in theory you could run two mbox1 with one synced via spdif to the other, but i havent tried it <swivel>ok have my x230 up... gotta get some music on it an dtest this <swivel>ive been meaning to pivot into my x230 but the fan buzzes a little and i have an x61 keyboard mod on the x220 i need to repro on the 230 <damo22>the w520 has 4 dimms slots, you can run 32GB ram <damo22>x230 has zero bugs in coreboot that i know of <damo22>and you can partially remove the management engine garbage <swivel>what are the major advantages of using coreboot over the factory bios, beyond just the philosophical difference? <damo22>doesnt have malware that we know of <swivel>don't you throw away some functionality from the factory bios? <swivel>yeah but that's not strictly true <damo22>in practice, *nobody* knows what is in the factory bios <damo22>that is a good reason to not use it imho <swivel>but it has a bunch of useful features too, it's not all useless/bad, i'm just curious what if any of those you're dispensing with by going coreboot <swivel>like you already mentioned coreboot having lockups <damo22>well yea, that is a bug and needs to be fixed <damo22>you can put grub in flash if you want <damo22>i think even e2fsprogs can be built into flash in grub <damo22>so you can fsck a disk without booting a rescue env <swivel>nod, that was something i have on my todo list to explore, actually i was curious about just putting the kernel+initrd in flash on my x230 for a small solar mining rig at one point, with no storage <damo22>i wouldnt bother trying to fit a kernel in there <swivel>-rw-r----- 1 root root 8.2M Mar 15 14:55 vmlinuz-5.12.0-rc3-nohz-idle-rtl8192cu-pti-xhci-x32-memcg-usbeth-uinput-usbsnd <swivel>the idea at the time was just a cost minimization choice <swivel>and kind of a useless-if-stolen kind of thing, since it'd have a generally unusable bios and only know how to boot to its mining purpose <swivel>but that's not really a project i'm pursuing anymore <swivel>it's updating everything because i had to install a modern mpg123 from the repo <damo22>i havent heard of anyone having issues since i suggested upgrading the firmware <swivel>and it wants a newer libc, hadn't booted it in forever <swivel>i'll know as soon as it finishes upgrading world :) <swivel>i should have just built mpg123 from source <swivel>has hurd been your primary focus now? <damo22>i was working on improving the netbsd audio buffer pointers <damo22>i used to do recordings for money but it turned out to not pay the bills <swivel>nod, seems difficult to make work if you're not known <swivel>do you happen to know what the mbox1 firmware update changed? <damo22>i think it fixed a bug in the changing of sample rate <swivel>i had to find a local with a mac to help update it today <damo22>i cant justify reverse engineering the firmware upgrade sequence <damo22>and extracting the actual binary <swivel>right, i poked a bit at the executable in the .dmg but lost interest, i don't have good tooling or experience for mach-o binaries <swivel>it looked like something written with some NXP toolkit <swivel>made me wonder if the mbox1 uses an NXP SoC or something <damo22>its pretty close to being class 1 audio compliant <swivel>i haven't opened it to poke around <swivel>some people have been modding them to make standalone microphone preamps <swivel>looked like just one bodge wire and disconnecting a pin <damo22>i play keys for my own enjoyment <damo22>do you have a budget to buy a keyboard? <swivel>probably, im kind of short on space+time atm, but likely this fall/winter i'll be able to do some music edu <damo22>the smaller keyboards (less than 88 keys) are usually less realistic in terms of weighting of the keys, if you had the space, id recommend to buy an old acoustic piano <swivel>not going to hvae space for that <swivel>was thinking an acoustic guitar would be good <damo22>piano or guitar are both a good idea <swivel>the woman who helped me update the firmware today has an earthdome full of instruments <damo22>teach yourself to tune an old guitar and a few chords later you'll be jamming <swivel>whenever i visit there it reminds me i need to learn to play something as it would open a world of social interactions in that group <damo22>guitar is definitely more portable <swivel>it would be easier to fit in my place <swivel>so do you think the wifi usb is contending for the bus causing an underrun? <swivel>i wonder if there's a prioritization scheme i can configure <damo22>i suggest getting a minipcie wifi dongle <damo22>most thinkpads come with them built in <swivel>i deliberately removed the one my x220 had because it runs binary blob firmware on the pci bus <damo22>you can get a free software friendly one <swivel>that struck me as a higher priority to elimminate than the bios <damo22>i think they are atheros chipset <swivel>i got an edimax rtl8192cu usb dongle that needs no blobs and usb doesn't poke in system ram <damo22>you could try swapping the ports around <damo22>maybe the EHCI and XHCI are on separate irqs <swivel>yeah, i'll have to play with it, fortunately the plan is to hook the mbox1 to a dedicated rpi4 for media use <swivel>but for now it's just the laptop i use for internet <damo22>good luck i need to do some actual work now <swivel>yeah, no prob, thanks for the help <swivel>it's useful just to know that you don't experience this problem <swivel>im waiting for the x230 to finish updating, m yinternet here isn't very fast. <damo22>yeah rtirq is the priority scheme for irqs you can tinker with that <damo22>but using ports on separate physical interrupt lines would be ideal <swivel>welp it appears i rebooted the arch box and there's no vmlinuz files now, weee <swivel>using the tab completion in grub to try fixup the `linux /path/to/vmlinuz` line is only showing me initramfs-linux.img and initramfs-linux-fallback.img lost+found/ and grub/ <damo22>check the other partition for kernel <swivel>but im confused why it has deleted the old kernel completely and not put the new kernel where the old kernel was <damo22>maybe you compiled your own kernel and didnt install a kernel package <damo22>sometimes the kernel goes on / instead of /boot <swivel>yeah i suspect it just put the kernel in / and iddin't think to check it before rebooting <damo22>does your grub rescue have crypto <swivel>on top of it i think my initrd contains the crypto key, i don't remember what it is hahah <swivel>but maybe i can at least coax grub into mounting the initrd to print the key if i can get it to do dmcrypt too <swivel>this is not at all what i signed up for tonight <damo22>if your key is embedded in the initrd i dont think you can boot the initrd without starting a kernel <swivel>this laptop originally had normal dmcrypt fde with a luks passphrase prompt @ boot, then at one point I needed to make it boot hands-free to serve as a security camera while i was on vacation, so the passphrase was shoved in the initrd using cryptkey= <damo22>this is why i dont use encyption on my disk <damo22>you can pull out the hdd and mount it with a usb caddy and copy a kernel into /boot <swivel>i consider it non-negotiable, fde is the only sane protection against theft compromising your shit <damo22>i consider physical access to my machine pwned <swivel>my ceo's laptop was stolen out of his back seat in my last startup while he was in a bodega in SF <swivel>nothing but stress afterards since he didn't have fde setup <swivel>just piles of IP on his machine, term sheets, lots of financial data <damo22>whats the point of FDE if there is no passphrase or the key is stored on another partition unencrypted on the same disk?? <swivel>did you not read how i didn't set that up that way originally? it was a temp hack to make the machine useful for security camera while i was on vacation and i didn't have time for a reinstall <swivel>it was just a last minute "hey i should turn that old x230 on and aim it at the front door of the cabin while im gone for summer" <damo22>FDE is full disk encryption, every byte on the disk should be encrypted so it looks random <swivel>don't let perfect be the enemy of good enough or be overly pedantic <damo22>putting the key on the same disk is not FDE <swivel>the key isn't supposed to be on the disk <swivel>it's supposed to ask for a passphrase <swivel>i haven't booted this laptop since it was used as a security camera <damo22>there should not be a partition table on the disk <swivel>at which point i removed all the data from it and just made it boot hands-free temporarily in the half hour i spent before walking out the door for summer <damo22>im just trying to explain that what youve got is not FDE <swivel>but this is bullshit, arch throwing out my kernel <swivel>it has an unencrypted boot partition <swivel>the rest is dmcrypt with lvm and lvs <damo22>but the full disk has a partition table and unencrypted /boot <swivel>i don't care if a thief gets my kernel+initrd <swivel>for al lintents and purposes it's FDE, i'm not defending against evil maids <damo22>if a thief gets your disk as is, they can boot up your os <swivel>yes, because i have the key in the initrd, becaues it's currently a security camera <swivel>and the encryption was just left in place to avoid rebuilding the machine <damo22>youre confusing the key with the passphrase <damo22>but the passphrase is now in the initrd <swivel>the key is in the dmcrypt header of the dmcrypt partition <swivel>the passphrase is in the initrd in /boot <swivel>are we on the same page that the encryption has been temporarily castrated to make the laptop a camera? <swivel>and at this moment is just a major inconvenience <swivel>before the camera repurposing it asked for the passphrase and the key is in dmcrypt like practically every dmcrypt+lvm linux install <swivel>there's nothing particularly interesting going on here other than the hack to make it boot hands-free in a hurry <damo22>i just would not bother with disk encryption unless i had a removable usb stick with the dmcrypt headers and the passphrase in my head <swivel>suit yourself, i'm perfectly satisfied with on-disk key in the dmcrypt header an passphrase in my head <swivel>my threat vector is "random asshole steals my laptop and can't easily mount the disk" <damo22>with the dmcrypt headers (key) and encrypted disk, they can offline attack the disk itself <swivel>"they" are not going to bother unless I'm specifically targeted by someone seriously determined to access my data <swivel>the amount of effort they will expend is very little <swivel>it'll be: I can't boot this thing because it wants a password, friend help me install an OS so I can sell it on ebay/cl <swivel>i just don't want whoever yanks the ssd to be able to throw it in a caddy and trivially browse the fs with zero friction whatever <damo22>yeah but i argue that the effort required to do it properly so they cannot do that at all is not worth my time <swivel>and right now i'm annoyed about the choice to use an m.sata in the x230 because i don't have anything else to plug it into, maybe the x220 has an m.sata socket? <damo22>some distros kernel will probably work <damo22>you could just boot off a stick and copy its kernel over to /bot <swivel>i could stick the x220 ssd in the x230's bay and boot that to get a kernel in the mSATA's /boot <damo22>i always keep a usb installer thumbdrive ready <damo22>just plug that in and use its kernel <swivel>can grub access files from usb storage when the grub wasn't loaded from usb storage in the bios usb hd emulation stuff? <damo22>ls should show you what devices are available <damo22>linux (usb0)/boot/vmlinuz-blah root=/dev/sda2 or something <swivel>nod, it only showed hd0, i was hoping the random thumbdrive i have here for files would show up on hotplug but that seemed a long shot considering.. usb <swivel>i just gotta dig up something suitable for making a usb bootable thing <damo22>download fedora 33 or something and dd it to a stick <swivel>the vmlinuz appears to be at /lib/modules/$(uname -r)/vmlinuz now <swivel>not sure what's the right thing to do in the interests of preventing a future pacman -Syu from throwing out my kernel in /boot, but things work again, back to seeing if the mbox doesn't click on the x230 <damo22>you can also play with rtirq, i think there is a pro audio package that tweaks it optimally for audio <swivel>damo22: have you used the spdif output on the mbox1? <swivel>i don't have the fancy preamp+power amplifier setup here yet so i can't try it out <damo22>i think its just an added on piece of hw that runs in parallel to the normal output <damo22>if my amp had it i would probably use it <damo22>but im using a mixer with usb currently as a sound card ***c0le_ is now known as c0le
<gnu_srs1>youpi: When are rumpdisk and lwip going to be the default for Hurd? <gnu_srs1>A proposal when they are: Consider to have a goal of making Hurd GPLv3+ WDYT? <damo22>i sent in two patches that get it closer but it still hangs <damo22>and the proc/6/stat does not get set with the argv <youpi>and I'm not to decide the licence of the software, it's the maintainers who do (no, I'm not officially a maintainer) <gnu_srs1>How to start using lwip instead of the linux pfinet code? <youpi>by trying, checking that it works with various software etc. <youpi>then writing the proper hurd package bits that properly set it up by default, and ideally also migrate existing systems <youpi>also better check the obtained performance <gnu_srs1>So even if lwip is built there is no easy way to include it and exclude pfinet? <damo22>netdde does not detect my x230 nic <damo22>or is netdde the driver and pfinet is the network stack? <damo22>are you going to use netdde with lwip? <damo22>maybe i need to write a rumpnet driver <gnu_srs1>damo22: Yes: netdde is the network driver and lwip is the network stack. <damo22>i hate to break it to you, but rump has a network stack too <damo22>i need to figure out if the rump network stack is separate from the driver <damo22>we need to work with netbsd people, at one point they were planning to either drop rump support or integrate it fully into their build system <damo22>if we help them, maybe they will integrate it fully and we can have a synced tree with master netbsd kernel <youpi>gnu_srs1: about including lwip instead of pfinet: no idea, I haven't had a look, somebody has to <youpi>damo22: I'd rather see the tcp/ip stack in a separate process from the networker drivers, but that also could be rump-based, yes <youpi>making sure that the rump project still continues in a usable state for us is important indeed <damo22>what is the state of play of gnumach + smp <damo22>i noticed there are a bunch of tagged commits in gnumach sv <damo22>im pretty sure we need smp + apic irqs + lapic timers to be completed as one block <damo22>or can the multiprocessing work with PIC? <damo22>in that case we need to decide to put some basic ACPI parsing in gnumach to deduce the real PCI IRQs <youpi>and iirc we need that kind of support upgrade for 64bit support <damo22>i recall writing some of that already in my branch it almost booted but i ran out of patience <damo22>on x86 sometimes the timer interrupt is on the pic but the apic is used for everything else? <damo22>i skipped the part that actually detects the pci irqs <damo22>they are in the MADT table as overrides to the defaults <damo22>i dont know which branch to start working from for smp <damo22>there are pages and pages of commits on 0.0.10_2 ***foggy68 is now known as foggy67
<damo22>i got feedback from someone i know in netbsd, there has been no changes in the last few months regarding rump, so i expressed my interest in allocating a portion of my free time to help make rump into a first class target for their main build system <damo22>i think someone has to make the effort or it wont get done <gnu_srs1>damo22: Very good initiative, I salute you :) <damo22>gnu_srs1: maybe you can help if it is a lot of work <damo22>i dont know what it involved yet <damo22>i have a little experience with them fixing broken tests <damo22>if that is all that is needed, it should be pretty straightforward <damo22>Pellescours: when i find out what is involved, i can write a doc on how to get set up with a vm to get started <damo22>it will likely involve installing netbsd itself and iterating on trying to build rump with tests and fixing the bugs with the broken ones, that is my guess <damo22>then when all the bugs are gone, we can try building it in a hurd vm <damo22>i think there is a buildrump.sh script, and it needs to be merged with main build.sh instead