log☇︎
83400+ entries in 0.052s
mircea_popescu: yes, you miss out on downloading sony camera contents in such a manner as the "your media contains pictures!!!" popup can shoot "usefully fast". this is not a permitted usecase anyway.
a111: Logged on 2018-08-01 21:33 asciilifeform: building a kernel without xhci would almost certainly do the job tho
mircea_popescu: http://btcbase.org/log/2018-08-01#1838829 << this is quite conceivably the right solution, and imo a fine candidate for cuntoo list. ☝︎
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.
mircea_popescu: right. and i didn't say anything about this then, either. also not :)
asciilifeform: mircea_popescu: observe that i did not put a ram buffer in FG (aside from the 16bit debias/accumulator ) , it was not happenstance.
mircea_popescu: and that's a complete world-enumeration.
a111: Logged on 2018-08-01 01:52 asciilifeform could not muster the fuck-giving to read the payload, has nfi what the thing wants
mircea_popescu: pick any two.
mircea_popescu: there is no such thing as data that is all three of 1) random ; 2) useful and 3) buffered. ☟︎
a111: Logged on 2018-08-01 16:08 asciilifeform: 2 possible tacks -- 1) kill, with flamethrower, 'new api' 2) FG opened once per machine boot and left running into buffer
mircea_popescu: http://btcbase.org/log/2018-08-01#1838730 << 1. put the old thing back in. ☝︎
asciilifeform: mircea_popescu: eat the l0g...
a111: Logged on 2018-08-01 16:03 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
mircea_popescu: http://btcbase.org/log/2018-08-01#1838724 << on the positive score, kernel patch for cuntoo killing this with fire quite feasible. ☝︎
asciilifeform: for all the usb2/3 suckage, it sadly remains the only means to connect fast external disks to pc.
diana_coman: but now I admit I got angry with ehci after all of today's barfing on the topic
diana_coman: and yes, otherwise I was thinking that a script can't be all that difficult to write for it too
asciilifeform: ( if diana_coman wants to take a crack at this, worx, otherwise asciilifeform will do it later this wk )
diana_coman: ah, built-in ttl serialports sounds good, yes; re problem dun seem to exist, mhm, I'd rather expect it would pop up sooner or later if used intensively in this little&frequent style
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 )
diana_coman: so hm, on rockchip then FG are actually usable only with manual downgrade of usb port ?
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.
diana_coman: well yes, and 10 or whatever they come up with next
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
diana_coman: after reading around on this mess with the usb speeds, the summary + questions would be: 1. the dwc_otg seems actually specific to raspberry pi so I don't see how it's directly useful atm; am I missing something? 2. the manual/runtime pill so far relies on the companion mechanism to force a USB port down from "high speed" to "full speed" so basically from ehci to uhci/ohci; wouldn't it make more sense to blacklist ehci, xhci and whatever ☟︎
deedbot: http://qntra.net/2018/08/reddit-hacked-user-data-taken/ << Qntra - Reddit Hacked, User Data Taken ☟︎
BingoBoingo: asciilifeform: The other fishwrap refused to archived cleanly. Failed with a generic "content not available in your region" error page being archived instead.
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.'
diana_coman: k, test server is for testing; will do
asciilifeform: diana_coman: afaik that's the only reliable way, usb bus numbering isn't iirc stable across boots
diana_coman: makes sense; how do I do that best on gentoo? still line in /boot/cmdline.txt ?
asciilifeform: diana_coman: you'll probably want to make it happen on boot.
diana_coman: this was on the smg test machine
asciilifeform: diana_coman: interestingly, in my (conventional gentoo) userland, worked as posted ( i.e. with the newline )
diana_coman: for future ref: echo first barfed with "invalid argument" ; it turns out it was appending a newline so it had to be "echo -n portnumber > ..."
diana_coman: so basically that's not for "if more than 2" but rather "always do it"
diana_coman: oh hey, asciilifeform that cure seems to work
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: 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: ( i've yet to find ~one~ pc board, of any vintage, with ttl ports )
asciilifeform: pc is the hardcore tard reservation.
asciilifeform: mircea_popescu: fwiw rockchip and similar boards actually include several ttl-level serial ports.
deedbot: http://trilema.com/2018/qntra-sqntr-july-2018-statement/ << Trilema - Qntra (S.QNTR) July 2018 Statement
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
mircea_popescu adds to wishlist for eventual fab.
asciilifeform: mircea_popescu: there's no ttl serial on pc mobo
mircea_popescu: asciilifeform is there some way to connect as a tty bypass the usb altogether ? i really dun wanna include usb if can be helped.
asciilifeform: fwiw asciilifeform's official FG tester rig runs always in this mode.
mircea_popescu: not like we use usb for anything else anyway, so this may well work ad interim.
asciilifeform: ( the above is == to the 'Tip for Linux Users' item in http://nosuchlabs.com/hardware.html , which i listed as workaround for 'more than 3 pl2303' infamous bugola )
asciilifeform: ( forcing 12MB/s usb1 speed has no effect on FG performance, even 10 FG on 1 jack falls considerably below the max usb1 rate )
asciilifeform: dozen runs of diana_coman's test all work
asciilifeform: http://p.bvulpes.com/pastes/xAQ4U/?raw=true << manual example , testable without rebooting kernel
mircea_popescu: still tbh i'm kinda pleased with how this ratchet works. mystery meat in fg-machine interaction had to await s.mg to be found. item's been out what, years, undergone all sorta testing...
asciilifeform: ( not tried yet )
mircea_popescu: this is looking more and more like we're going to have to write a pl replacement does it
mircea_popescu: as in, "i checked, we don't have" or as in "we couldn't possibly have something this fucking stupid o oops there it is how the hell did it sneak in"
asciilifeform: mircea_popescu: we dun have this item to begin with
mircea_popescu: modprobe -r option << does ditching the "option" bs do anything ?
diana_coman: ah, that might explain why I haven't yet noticed it
asciilifeform: diana_coman: the line_request one is sporadic ( erry dozen or so runs )
diana_coman: that one I got even 8 times in a row there
diana_coman: asciilifeform, I get as I recalled this "[63939.499700] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32" but I don't see the others, hmm
diana_coman: mod6, I'd say don't worry about it; as a rule though productive people do stuff, not as if they need to "say" productively things
asciilifeform: 'most people are just going to go with a cheaper & higher performance alternative' dontchaknow.
mod6: shit on the rug in the foyer.
mod6: thought he might wanna talk about his rockchip, so was willing to give him the chance.
mod6: i should have just ignored. typically I do.
asciilifeform: d00d could 'productive' any fucking time he feels like it.
diana_coman: "productive things to say " lol
asciilifeform: mod6: lol, 'productive things'
mod6: it never fails. answering the door just doesn't work out too well for ole mod6
diana_coman: asciilifeform, I certainly say the last line, don't recall the first 2 but I might have missed them
mod6: guy says '<douchebag> can I be upped? I have some productive things to say' in PM, and I think "hmm. alright"
asciilifeform: [8621835.463377] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
asciilifeform: [8621835.122919] pl2303 ttyUSB0: pl2303_set_line_request - failed: -32
asciilifeform: [8621835.122044] pl2303 ttyUSB0: pl2303_get_line_request - failed: -110
asciilifeform: btw, diana_coman , mircea_popescu , there's visible sys log barf from pl2303 when operating diana_coman's test :
a111: Logged on 2018-08-01 13:58 asciilifeform: i suspect an oddity with the linux tty subsystem. the Right Thing solution would be to find it. the alternative, ugly solution, is 1) 512 byte buffered reads 2) with timeout .
mircea_popescu: http://btcbase.org/log/2018-08-01#1838691 << da fuck buffered state machine, defeats the whole purpose of the thing. ☝︎
mircea_popescu: speaking of which, i wonder how that fellow's business/revolutionary/technico-theoretical/etc idea is faring these days.
a111: Logged on 2018-08-01 02:55 mod6: douchebag wants the mic
mircea_popescu: http://btcbase.org/log/2018-08-01#1838608 << incidentally, maybe the correct move re the day's ninjashogun would be to redirect them to whatever castle one feels like ? trilema-mod6 or such. ☝︎
diana_coman: myeah, 1 promises to eat up a lot of time
asciilifeform: i'ma let mircea_popescu say, whether Right Thing is to start with (2) and proceed to (1), or straight to (1) .
asciilifeform: 2 possible tacks -- 1) kill, with flamethrower, 'new api' 2) FG opened once per machine boot and left running into buffer ☟︎
asciilifeform: confirms my earlier suspicion tho.
asciilifeform: the given 'solution' is absolutely prohibited for FG, tho, it ~must~ operate as blocking read
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 ☟︎
diana_coman: asciilifeform, ah,ah, the "modprobe -r " lulz, yes