asciilifeform: ( not even sure it'd fit on an ice40 )
asciilifeform: mircea_popescu: the only board holes in current boxen are pcie, and that's megatonne of stateful logic
asciilifeform: ( there's no reasonable way to connect it to pc , currently )
asciilifeform: incidentally , lack of a sane usb2 chipset is what's holding up the lyso crystal super-FG item
asciilifeform: imho at the very least usb jacks oughta default to 1, and if really needs the uglyhax of 2/3 should have to manually trigger. rather than the current sad.
asciilifeform: ( bad enuff that i only even have usb2, not 3, on dulap, and it takes 3hrs )
asciilifeform: i ain't waiting 3 wks to reimage a motherfuckign 64GB stick.
asciilifeform: if somebody absolutely positively MUST buffer his FG, because, idk, he's generating a icbm launch key and wants to xorlemma 8 weeks of entropy into 4096b, oughta do it ~in his proggy~ imho.
asciilifeform: there's likewise a reason i did not publish a 'demon' to go with FG. ideally random bitz oughta live the shortest possible life, and walk shortest possible path from point of birth to use.
asciilifeform: ( erry heathen rng i know of , includes... )
asciilifeform: mircea_popescu: observe that i did not put a ram buffer in FG (aside from the 16bit debias/accumulator ) , it was not happenstance.
asciilifeform: ( if diana_coman wants to take a crack at this, worx, otherwise asciilifeform will do it later this wk )
asciilifeform: diana_coman: re usb1 forcing, i was thinking the proper pill might be to write a shell thing that parses output of lsusb -t and does the correct magics ; rather than modded kernel
asciilifeform: diana_coman: problem dun seem to exist on my desk rockchip. ( and in the end we'll move the rk FGs over to the convenient built-in TTL serialports )
asciilifeform: one type of existing machine where we can't afford to lose usb3 is the rockchip, it would be quite unusable without it ( main disk is solely usb3 )
asciilifeform: diana_coman: 'nexts' wouldn't affect the existing iron tho.
asciilifeform: ( i can't afford it on dulap, because it also doubles as reimaging station for rockchippen , but s.mg prolly can safely say goodbye to usb3 )☟︎
asciilifeform: diana_coman: on server ? can't think of any, aside from 'backups to/from external drives'
asciilifeform: building a kernel without xhci would almost certainly do the job tho☟︎
asciilifeform: diana_coman: seems that you're right re the flag, it is specific to a nonstandard kernel
asciilifeform: BingoBoingo: from other fishwraps, re qntra, 'The grandson said they’re not selling guns, but reported that two men recently knocked on the door asking if they had gun parts or body armor. Hanabarger reportedly said “no” and showed them inside a storage container. But now they’re wondering if there’s a connection between those men and Tuesday’s raid.'
asciilifeform: diana_coman: afaik that's the only reliable way, usb bus numbering isn't iirc stable across boots
asciilifeform: diana_coman: you'll probably want to make it happen on boot.
asciilifeform: diana_coman: interestingly, in my (conventional gentoo) userland, worked as posted ( i.e. with the newline )
asciilifeform: incidentally, there is also a potential iron cure, currently FG at pizarro are attached to miniature usb2 hubs. ( asciilifeform was not able to source pure usb1 hubs, but potentially these exist somewhere. )
asciilifeform: diana_coman, mircea_popescu lemme know if the given cure, is curative. ( no change to diana_coman's coad is needed )
asciilifeform: diana_coman: usb1 switchover also confirmed to cure log barfola.
asciilifeform: thing eats 8ma, could easily run off, e.g., solar cell in a well-lit room.
asciilifeform: FG is transmit-only. there is literally nothing the attached pc can do ~to~ it, other than cycle the +5 supply ( and even this, strictly if the +5 supply is tied to the pc's )
asciilifeform: usb is evil in 9000 ways. not only the ridiculous complexity, which makes it impractical to use with ~simple~ microcontrollers, msdos boxen, etc. but also the fact that it is impossible to make a ~transmit only~ (or , for that matter, receive-only) usb device, they are mandatorily stateful. which is the fundamental reason why asciilifeform refused to put a usb chip on FG proper.
asciilifeform: mircea_popescu: fwiw rockchip and similar boards actually include several ttl-level serial ports.
asciilifeform: mircea_popescu: there is sometimes 1 or even 2 rs232 ports , but they go at -12v/+12v , and needs level shifter, which in turn oscillates, and potentially pollutes rng
asciilifeform: mircea_popescu: there's no ttl serial on pc mobo
asciilifeform: fwiw asciilifeform's official FG tester rig runs always in this mode.
asciilifeform: 'After much researching it seems this is NOT a driver bug but a CHANGE in the kernel Serial API semantics. What has happened is that the API now blocks when a Serial device is not indicating it is ready. This included 'open' on a serial device which now can block. Since lots of RS232 serial devices do not bother with any control signals such as DCD (data carrier detect) they never indicate they are ready and open blocks. This is the☟︎
asciilifeform: diana_coman: lulzily, turns out that our horror show is not unknown, https://archive.fo/kRfZy ( spoiler: none of the proposed pills, have any effect
asciilifeform: diana_coman: i'ma have to do a detailed dig in re the linux tty thing. but this could take a while, and no guarantee of finding culprit in the 100s of MB of open sores liquishit. so you will need the buffer+timeout thing, i suspect.
asciilifeform: ( observe, if tty ~does~ successfully open, can read 4evah, i had one dd going for 6 months without problem )
asciilifeform: possibly asciilifeform is doomed to write the FG-reading daemon after all.
asciilifeform: no other device does the random ~rate~ thing.
asciilifeform: note that FG outputs not only random bytes, but at random ~rate~ . currently i wonder if we've unearthed an 'impedence mismatch' in linux tty.
