channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=5&d=24

Thursday, 24 May 2018

00:00:00 --- log: started osdev/18.05.24
00:00:12 <geist> then i think i used a K10 or something until switching to the intel train around 2001
00:00:33 <_mjg_> nic
00:00:34 <_mjg_> e
00:00:53 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
00:00:54 <_mjg_> i think i had an amd-produced 486
00:00:56 <geist> that sandy bridge 2600k in 2001 held me until last year when i upgraded to a 6700k
00:01:32 <geist> yeah amd 486s were the shit
00:01:45 <geist> the first linux box i ran in college was a home built am486-133
00:02:02 <geist> that was the first real headless box i ever owned. the idea was pretty novel at the time (to me)
00:02:19 --- quit: Halofreak1990 (Ping timeout: 260 seconds)
00:02:40 <geist> and i remember that was propbably late 95 or 96, and an am486-133 was about p90 speed but a lot cheaper, if you weren't playing games that were tweaked for pentium
00:03:28 <geist> er sandy bridge 2600k in 2011 that is
00:04:28 <_mjg_> haha
00:04:45 <_mjg_> i had 486 50, a friend had 66
00:04:57 <geist> oooh was it one of the non dx2 ones?
00:04:59 <geist> those were rare
00:05:01 <_mjg_> it was *way* faster, now i suspect he had cache
00:05:11 <_mjg_> still dx2
00:05:14 <geist> ah yeah
00:05:25 <_mjg_> then i had no idea what's going on
00:05:35 --- quit: Halofreak1990_ (Ping timeout: 260 seconds)
00:05:44 <_mjg_> same games which would be unplayable on my box were runing smooth as shit
00:05:46 <_mjg_> on his
00:05:56 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
00:05:59 --- quit: bcos (Ping timeout: 248 seconds)
00:06:16 --- join: bcos (~bcos@101.172.87.13) joined #osdev
00:06:28 <geist> could be your video card setup too
00:06:44 <geist> vlbus based stuff was finiky, and he would have been running the bus at 33 instead of 25
00:07:29 <geist> that reminds me, i remember there being a standard cache memory slot for 486 and penium motherboards
00:07:41 <geist> i wonder what the pinout is. probably just raw sram
00:08:15 <geist> https://en.wikipedia.org/wiki/Cache_on_a_stick apparently
00:08:15 <bslsk05> ​en.wikipedia.org: Cache on a stick - Wikipedia
00:08:50 <_mjg_> hm
00:09:07 <_mjg_> could 486 have pci?
00:09:19 <_mjg_> i definitely had an isa video card
00:09:24 <_mjg_> i don't know what he had
00:09:46 <geist> yep. some of the later 486s had pci, yep
00:09:57 <geist> yeah he probably had a vlbus or pci card then
00:10:15 <geist> vlbus is basically 486 only, but is essentially the raw 486 bus on a card
00:10:22 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
00:10:29 <geist> and thus you could only really have one and it was finicky signalling wise
00:11:13 <geist> since by then isa would have had to go through a few wait states to step down the 25 or 33mhz processor bus to 8mhz
00:11:15 <_mjg_> that said, my next box was p75 and it was smoking fast comparatively
00:17:10 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
00:17:25 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
00:17:30 --- quit: gareppa (Remote host closed the connection)
00:17:31 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
00:17:47 --- nick: Halofreak1990 -> Halofreak
00:17:48 --- quit: Nokurn (Ping timeout: 276 seconds)
00:19:41 --- quit: Affliction (Quit: Read error: Connection reset by beer)
00:21:13 --- join: Affliction (~Afflictio@2402:1f00:8101:135::) joined #osdev
00:21:20 <geist> oooph anandtech got a hold of a thunderx2
00:21:27 <geist> https://www.anandtech.com/show/12694/assessing-cavium-thunderx2-arm-server-reality
00:21:28 <bslsk05> ​www.anandtech.com: Assessing Cavium's ThunderX2: The Arm Server Dream Realized At Last
00:22:23 --- join: m3nt4L (~asvos@2a02:587:a001:6900:3285:a9ff:fe8f:665d) joined #osdev
00:23:34 --- join: Nokurn (~Nokurn@71-95-52-160.dhcp.rvsd.ca.charter.com) joined #osdev
00:28:17 --- join: `Guest00000 (~user@37.113.160.44) joined #osdev
00:38:43 --- quit: Salek (Ping timeout: 260 seconds)
00:44:28 --- join: KidBeta (~textual@61.68.91.220) joined #osdev
00:50:29 --- quit: dengke (Quit: Leaving)
00:50:32 --- join: bauen1 (~bauen1@ANancy-655-1-4-115.w86-223.abo.wanadoo.fr) joined #osdev
00:53:07 --- quit: janemba (Ping timeout: 245 seconds)
00:56:27 --- quit: ZipCPU (Ping timeout: 256 seconds)
01:01:25 --- join: ZipCPU (~ZipCPU@pool-72-73-36-192.clppva.east.verizon.net) joined #osdev
01:08:32 --- quit: mrush (Ping timeout: 245 seconds)
01:10:40 --- join: mrush (~user@64.72.212.39) joined #osdev
01:11:03 --- nick: mrush -> Guest23707
01:13:45 --- join: BartAdv (uid90451@gateway/web/irccloud.com/x-gkdpajltvulkmwjh) joined #osdev
01:14:23 <sahibatko> Crap, XD bit plays tricks on me... when I load sections to memory and do not set XD anywhere, it works. When I only allow .text (only section having the MEM_EXECUTE flag in PE) to be executed and set XD to the others, it won't do a 'call _func', yet the entry point code written in assembly works...
01:18:09 --- quit: sympt_ (Remote host closed the connection)
01:18:33 --- quit: Halofreak (Ping timeout: 256 seconds)
01:22:06 --- quit: Goplat (Remote host closed the connection)
01:25:55 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
01:29:18 --- quit: bauen1 (Remote host closed the connection)
01:37:16 --- quit: CheckDavid (Quit: Connection closed for inactivity)
01:38:34 --- quit: KidBeta (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
01:40:05 --- join: Sonicbit (~Sonicbit@185.53.85.1) joined #osdev
01:43:40 --- join: zeus1 (~zeus@197.239.1.33) joined #osdev
01:43:52 --- join: elderK (~k@122-61-64-89-adsl.bb.spark.co.nz) joined #osdev
01:43:52 --- quit: elderK (Changing host)
01:43:52 --- join: elderK (~k@pdpc/supporter/active/elderk) joined #osdev
01:44:48 --- join: stav (~stavvvv@athedsl-13130.home.otenet.gr) joined #osdev
01:52:52 --- join: vaibhav (~vnagare@125.16.97.121) joined #osdev
01:55:01 --- quit: hmmmm (Remote host closed the connection)
01:58:06 --- join: sympt (~sympt@209.58.137.94) joined #osdev
01:59:04 --- join: oaken-so1rce (~oaken-sou@141.89.226.146) joined #osdev
02:00:37 --- quit: oaken-source (Ping timeout: 245 seconds)
02:05:28 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
02:05:52 --- quit: oaken-so1rce (Ping timeout: 252 seconds)
02:05:59 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
02:06:23 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
02:06:24 --- nick: Halofreak1990_ -> Halofreak1990
02:07:37 --- quit: mowi (Ping timeout: 268 seconds)
02:08:22 --- quit: jakogut (Quit: jakogut)
02:08:43 --- quit: lecx (Ping timeout: 240 seconds)
02:08:44 --- quit: pisculichi (Ping timeout: 256 seconds)
02:08:44 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
02:08:52 --- quit: Sjors (Ping timeout: 256 seconds)
02:08:53 --- quit: valerius (Ping timeout: 245 seconds)
02:08:57 --- quit: zedsdeadbaby (Ping timeout: 276 seconds)
02:09:11 --- quit: Mikaku (Ping timeout: 256 seconds)
02:09:17 --- quit: z0ttel (Ping timeout: 256 seconds)
02:09:40 --- join: ljc (~ljc@unaffiliated/ljc) joined #osdev
02:09:41 --- quit: goncalo (Ping timeout: 276 seconds)
02:13:49 --- join: Kimundi_ (~Kimundi@i577A9F5D.versanet.de) joined #osdev
02:14:16 --- quit: elevated (Quit: bye)
02:14:23 --- quit: grumble (Ping timeout: 608 seconds)
02:14:45 --- quit: radens` (*.net *.split)
02:14:45 --- quit: nzoueidi_ (*.net *.split)
02:15:59 --- join: Mikaku (~Mikaku@pdpc/supporter/active/mikaku) joined #osdev
02:16:03 --- join: lecx (lex@yuuh.pw) joined #osdev
02:16:25 --- join: goncalo (~goncalog@blacksand.promisc.org) joined #osdev
02:17:41 --- join: Sjors (~quassel@bulbasaur.sjorsgielen.nl) joined #osdev
02:18:08 --- quit: jakogut (Quit: jakogut)
02:18:29 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
02:21:00 --- join: pisculichi (pisculichi@shell.bshellz.net) joined #osdev
02:31:24 --- join: valerius (~valerius@2a01:4f8:d16:2052::2) joined #osdev
02:31:24 --- quit: valerius (Excess Flood)
02:31:36 --- quit: sympt (Ping timeout: 260 seconds)
02:34:54 --- join: valerius (~valerius@2a01:4f8:d16:2052::2) joined #osdev
02:34:54 --- quit: valerius (Excess Flood)
02:36:24 --- join: valerius (~valerius@2a01:4f8:d16:2052::2) joined #osdev
02:36:24 --- quit: valerius (Excess Flood)
02:37:25 --- join: valerius (~valerius@2a01:4f8:d16:2052::2) joined #osdev
02:41:26 --- join: grumble (~grumble@freenode/staff/grumble) joined #osdev
02:45:52 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
02:53:00 --- quit: Lucretia (Remote host closed the connection)
02:53:19 --- join: Lucretia (~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5) joined #osdev
02:53:19 --- quit: Lucretia (Changing host)
02:53:19 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
02:59:02 --- quit: `Guest00000 (Ping timeout: 252 seconds)
03:03:28 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
03:03:30 --- join: Halofreak1990_ (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
03:03:47 --- nick: Halofreak1990_ -> Halofreak1990
03:05:06 --- join: grumblr (~grumble@freenode/staff/grumble) joined #osdev
03:06:00 --- join: `Guest00000 (~user@37.113.160.44) joined #osdev
03:14:43 --- quit: grumble (Ping timeout: 606 seconds)
03:14:45 --- nick: grumblr -> grumble
03:17:06 --- join: baschdel_ (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
03:20:09 --- quit: baschdel_ (Client Quit)
03:20:39 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
03:25:10 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
03:27:07 --- quit: nj0rd (Ping timeout: 264 seconds)
03:35:03 --- quit: oaken-source (Ping timeout: 248 seconds)
03:39:47 --- join: sympt (~sympt@209.58.135.120) joined #osdev
03:42:51 --- join: nj0rd (~nj0rd@mue-88-130-48-024.dsl.tropolys.de) joined #osdev
03:53:43 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
03:58:51 --- quit: sympt (Remote host closed the connection)
04:03:06 --- quit: jordyd (Quit: Bye!)
04:03:39 --- join: jordyd (~jordyd@pampanic/co-maintainer/jordyd) joined #osdev
04:10:01 --- join: quc (~quc@87.116.229.183) joined #osdev
04:15:52 --- join: millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) joined #osdev
04:16:44 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:17:41 --- quit: tsurai (Quit: ZNC 1.6.6 - http://znc.in)
04:18:10 --- join: tsurai (~tsurai@2001:19f0:6c01:5d0:5400:1ff:fe49:f728) joined #osdev
04:18:51 --- quit: ljc (Quit: ayy)
04:20:19 --- join: GautamS (~sgautam@unaffiliated/gautams) joined #osdev
04:27:40 --- join: regreg (~regreg@85.121.54.224) joined #osdev
04:29:03 --- quit: GautamS (Quit: Leaving.)
04:29:55 --- join: GautamS (~sgautam@unaffiliated/gautams) joined #osdev
04:30:56 --- quit: cirno_ (Remote host closed the connection)
04:31:37 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:36:56 --- quit: Halofreak1990 (Ping timeout: 252 seconds)
04:38:48 --- quit: GautamS (Quit: brb getting a better IRC client)
04:39:44 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
04:42:59 --- join: S_Gautam (~GautamS@unaffiliated/gautams) joined #osdev
04:48:15 --- join: light2yellow (~l2y@217.30.64.102) joined #osdev
04:51:38 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
04:59:07 --- quit: immibis (Ping timeout: 260 seconds)
05:00:55 --- quit: cirno_ (Remote host closed the connection)
05:01:37 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
05:01:38 --- join: CRoemheld (584610f2@gateway/web/freenode/ip.88.70.16.242) joined #osdev
05:02:05 <CRoemheld> Hi there!
05:02:51 <CRoemheld> As it seems, I have quite a confusing situation right here, and it is not even OS related
05:03:20 <CRoemheld> If you define a macro in C with the #define directive, the variables usually are substituted, right?
05:03:57 <_mjg_> ?
05:04:00 <CRoemheld> So I had an idea for calling custom assembly functions via its label and the asm(...) macro
05:04:07 <CRoemheld> For example:
05:04:08 <_mjg_> show the example
05:04:18 <CRoemheld> #define _callr(function, result) asm(function: "=a" (result));
05:04:52 <CRoemheld> But to my irritation, the following error is being produced:
05:05:03 <CRoemheld> error: expected ')' before ':' token
05:05:26 <graphitemaster> because asm statements need more than inputs
05:05:30 <graphitemaster> they also need outputs
05:05:33 <CRoemheld> I've never had that error before, but I guess it is something pretty banal
05:05:48 <_mjg_> you can start debugging by NOT using a macro
05:05:52 <_mjg_> but putting a call in place
05:05:56 <CRoemheld> Hmm, but the "=a" is the output
05:05:56 <_mjg_> and only then converting
05:06:32 <CRoemheld> because if I do this directly, without the macro, it works
05:06:50 <_mjg_> how do you use the macro
05:07:06 <CRoemheld> For example:
05:07:25 <CRoemheld> _callr("_cpuid_support", check);
05:07:37 <CRoemheld> where check is an uint32_t variable which should receive the result
05:07:49 <CRoemheld> and thus determining of cpuid is supported
05:08:03 <bcos> Wouldn't "_cpuid_support" be a char * pointer to a string?
05:09:20 <CRoemheld> Even if it is, does this matter in a macro?
05:09:43 <CRoemheld> As far as I remember, macros usually substitute the variables with whatever you put in
05:09:47 <CRoemheld> regardless the type
05:10:06 <CRoemheld> so the above macro should translate to
05:10:16 <CRoemheld> asm("_cpuid_support", check);
05:10:27 <CRoemheld> and this works if you do it directly without the _callr macro
05:10:44 <CRoemheld> So maybe you can understand my confusion here
05:11:04 <CRoemheld> sorry, I meant:
05:11:22 <CRoemheld> asm("_cpuid_support": "=a" (check)); of course
05:11:25 <_mjg_> i suspect this will work: _callr(_cpuid_support, check);
05:11:33 <bcos> No, for macros C evaluates the expressions and passes the results, so "_callr(&"Hello World"[6], check);" would be similar to "_callr("World", check);"
05:11:49 <_mjg_> and then glue it with " "'s
05:14:10 <_mjg_> if this fails, the strinfication hack should do it
05:14:48 <bcos> Should be able to ask compiler to preprocess only and look at the C after macros have been expanded
05:16:54 <_mjg_> well, well
05:16:54 * bcos is still trying to figure out what that macro is supposed to do - looks like it only defined a label and doesn't actually do anything
05:17:11 <_mjg_> #define _callr(function, result) asm(function: "=a" (result))
05:17:16 <_mjg_> _callr("cpuid", check);
05:17:19 <_mjg_> this actually works for me
05:17:23 <_mjg_> so i don't know what OP is doing
05:18:48 <CRoemheld> I don't really get it either
05:19:02 <CRoemheld> Thats whats so confusing right now
05:19:27 <_mjg_> wwait, what's '_cpuid_support'
05:19:49 <_mjg_> i typed cpuid for my case ofc, it worked fin
05:19:50 <_mjg_> e
05:20:07 <bcos> ?
05:20:24 <bcos> Would expand to:"cpuid":
05:20:39 <bcos> ..which isn't a sane name for a label
05:21:02 <CRoemheld> No I used a custom function which I declared as global
05:21:12 <_mjg_> http://dpaste.com/1X5EHHC
05:21:13 <bslsk05> ​dpaste.com: dpaste: 1X5EHHC
05:21:23 <_mjg_> the compiler has no problem with it, apart from the instruction not existing
05:21:41 <_mjg_> no macro-oriented issues
05:22:00 <_mjg_> CRoemheld: so i'm increasingly confused what you are trying to do here
05:22:07 <_mjg_> construct a testcase
05:23:29 <CRoemheld> Just call a custom assembly function in a separate .s file or something else which moves something into eax and try calling the function via the _callr macro
05:24:02 <_mjg_> why would you want the macro for that purpose
05:24:08 <_mjg_> just call the func
05:24:21 --- join: return0e (~return0e@5-198-102-244.static.kc.net.uk) joined #osdev
05:24:22 <bcos> Hrm - incompatible calling convention maybe
05:24:48 <_mjg_> compatible enough to obey callee-saved regs?
05:25:05 <CRoemheld> It was actually a spur of a moment thing, because using the macro would get rid of the output constraint as it is always "=a"
05:25:18 --- quit: qeos|2 (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
05:25:27 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
05:25:36 --- join: qeos (~qeos@ppp91-79-242-242.pppoe.mtu-net.ru) joined #osdev
05:25:39 <CRoemheld> Instead of always typing "=a" for simple functions
05:25:40 <_mjg_> again, not just call the function
05:26:01 <_mjg_> your abi probably expects the return value to be in eax anyway
05:26:29 <CRoemheld> Hm okay, maybe I should go with that then
05:26:35 <CRoemheld> Sorry, sorry for this confusion
05:26:49 <_mjg_> i should have asked first wtf _cpuid_support is
05:26:54 <_mjg_> i somehow autorecorected it to cpuid
05:27:10 <bcos> I'd assume the problem would be that ABI expects to need to save any "trashed by callee" registers, and when none are trashed it's a waste of time
05:27:37 <CRoemheld> @_mjg_ it is my function name for the long mode check if cpuid is supported
05:27:44 <CRoemheld> from the bare bones tutorial
05:27:48 <_mjg_> you still the return value
05:27:50 <_mjg_> erm,
05:27:52 <_mjg_> return address
05:28:07 <_mjg_> so this already did not work, unless there was supposed to be only one caller
05:28:37 <bcos> CRoemheld: How do you check if CPUID is supported?
05:29:14 <CRoemheld> I changed it to: uint32_t _cpuid_support(uint32_t result) asm("_cpuid_support");
05:29:18 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
05:29:52 <CRoemheld> because if my abi is expecting the return value in eax as stated by _mjg_, then this will do the same thing
05:30:16 <CRoemheld> And this also fixes the error and it still works
05:30:40 <bcos> ?
05:30:56 --- quit: cirno_ (Remote host closed the connection)
05:31:06 <bcos> Do you think there's an assembly language instruction called "_cpuid_support"?
05:31:30 <CRoemheld> @bcos: No, thats a custom function of mine
05:31:33 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
05:31:42 <_mjg_> how does it look like
05:31:44 <_mjg_> is it a macro?
05:31:49 <_mjg_> with some assembly code?
05:31:57 --- quit: Shikadi (Quit: Leaving)
05:32:04 <CRoemheld> It is a plain function
05:32:06 <bcos> CRoemheld: Are you trying to call that custom function; like "asm("call _cpuid_support");"?
05:32:09 <CRoemheld> wait:
05:32:16 --- join: Shikadi (~Shikadi@cpe-98-10-34-205.rochester.res.rr.com) joined #osdev
05:33:07 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
05:33:08 <CRoemheld> http://dpaste.com/1362RDM
05:33:09 <bslsk05> ​dpaste.com: dpaste: 1362RDM
05:33:53 --- join: awang (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
05:34:06 <bcos> In that case; I think you can forget about macros and just use "result = _cpuid_support();" in C
05:34:12 <_mjg_> yea
05:34:15 <_mjg_> just call the func
05:34:41 <CRoemheld> yes, thats what I'm doing now
05:35:02 <CRoemheld> I just thought as it was a "safer" way to use the constraints in asm()
05:35:07 <_mjg_> uint32_t _cpuid_support(uint32_t result) asm("_cpuid_support");
05:35:09 <_mjg_> remove this
05:35:19 <CRoemheld> because the return value being in eax is abi dependent
05:35:32 <_mjg_> uint32_t _cpuid_supprt(void);
05:35:39 <_mjg_> that's what you should have in the header
05:35:40 <_mjg_> no macros
05:35:48 <bcos> ..but a few macros, like "#define get_eflags" and "#define set_eflags" would let you implement the function in C; and would be more re-usable for other things
05:36:05 --- join: rain1 (~rain1@unaffiliated/rain1) joined #osdev
05:37:32 <bcos> Hrm - "set_eflags" would probably be a bad idea (without guards to preserve arithmetic flags)
05:37:46 <bcos> D'oh - or a clobber list
05:44:12 --- join: promach_ (~phung@155.69.206.255) joined #osdev
05:44:18 <promach_> could anyone help with https://www.reddit.com/r/cpp_questions/comments/8lr620/problem_debugging_xillybus_host_cpp_code_with/ ?
05:44:20 <bslsk05> ​www.reddit.com: Problem debugging xillybus host cpp code with fork() that terminates prematurely without any error printout : cpp_questions
05:47:29 --- quit: CRoemheld (Quit: Page closed)
05:49:27 --- quit: zeus1 (Ping timeout: 248 seconds)
05:49:32 <_mjg_> is that on linux?
05:49:35 <_mjg_> can you dmesg?
05:49:39 <_mjg_> chances are the kernel oopses
05:49:49 <_mjg_> this has a side effect of killing the offending thread
05:49:51 <promach_> _mjg_: ok, let me try
05:52:01 <promach_> I have this dmesg https://paste.ubuntu.com/p/cjy6ByMqzp/
05:52:01 <bslsk05> ​paste.ubuntu.com: Ubuntu Pastebin
05:52:48 <promach_> _mjg_: does this mean I need to debug https://github.com/torvalds/linux/tree/master/drivers/char/xillybus ?
05:52:49 <bslsk05> ​github.com: linux/drivers/char/xillybus at master · torvalds/linux · GitHub
05:54:16 <_mjg_> i don't see an oops, so now this is weird
05:54:27 <_mjg_> i would definitely start with putting a systemtap probe on the read routine
05:54:42 <promach_> systemtap probe ?
05:54:58 <_mjg_> probe kernel.function("do_prlimit") { printf("%s[%d] %d\n", execname(), tid(), $resource); print_backtrace();
05:55:01 <_mjg_> }
05:55:08 <_mjg_> stap -v crap.stap
05:55:14 <promach_> huh ?
05:55:18 <_mjg_> huh what
05:55:19 <promach_> I am new to this probe
05:55:39 <_mjg_> https://sourceware.org/systemtap/tutorial.pdf
05:56:04 <promach_> so put this code segment into the problematic cpp code ?
05:56:08 <_mjg_> this way you can trace exactly what's happening
05:56:10 <_mjg_> no
05:56:14 <_mjg_> read the tutorial
05:56:18 <promach_> ok
05:56:30 <bcos> What actually is the xillybus device? Looks like a DMA engine strapped onto an FPGA - a little like an empty black box where you can put whatever you want inside
05:57:00 <_mjg_> wait a sec
05:57:01 <_mjg_> printf("before read in else. \n");
05:57:01 <_mjg_> rd = read(fdr, rd_buf, image_width * image_height - num_of_pixels_received); // is a partially filled 128-bit stream (with less than 5 pixels)
05:57:03 <bcos> ..and if you put poo in the box, maybe you get timeouts
05:57:04 <_mjg_> //printf("break in else. \n");
05:57:09 <Mutabah> bcos: Sounds like it?
05:57:30 <_mjg_> timeouts don't explain supposed disappearnce of the target proc
05:57:50 <_mjg_> however, i see a distinct lalck of a debug printf after the return from read
05:58:10 <_mjg_> and the question in the reddit thread: What does it mean if read() does not return any value and terminate the program on its own ?
05:58:18 <promach_> let me upload the lastest code to gist
05:58:19 <_mjg_> perhaps is incorrect - read did return
05:58:29 <promach_> no, it did not
05:58:35 <_mjg_> how do you know?
05:58:43 <_mjg_> if it did not are you sure the reader is dead?
05:58:51 <_mjg_> perhaps you can find them all on ps
05:58:54 <_mjg_> stuck in the kernel
05:58:57 <promach_> see "after read()"
05:59:30 <_mjg_> can you ps auxw | grep progname
05:59:33 <promach_> _mjg_: refresh your gist page
05:59:45 <promach_> and you will see "after read()"
06:00:32 <_mjg_> ok
06:00:39 <_mjg_> so, is the sucker stuck in the kernel?
06:00:42 <_mjg_> ps auxw | grep
06:00:55 --- quit: cirno_ (Remote host closed the connection)
06:01:17 <promach_> ps auxw | grep <-- what are you trying to do ?
06:01:19 <bcos> If GDB says the program exited normally, then..
06:01:32 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-jmnwzzchakptusrr) joined #osdev
06:01:36 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
06:01:37 --- quit: S_Gautam (Remote host closed the connection)
06:01:50 <bcos> (then it can't be stuck in in kernel waiting forever or something like that)
06:01:53 <_mjg_> there is clearly something odd going on, for all i know he forked off
06:02:07 <_mjg_> and the one exited has no relevance
06:02:10 <lachlan_s> Do any of you have any experience with getting a logo designed for your os?
06:02:32 <_mjg_> promach_: can you please verify the process which was reading from the device is indeed dead
06:02:38 <promach_> _mjg_: I guess the last debug resort is to use systemtap probe as you had suggested ?
06:02:43 <_mjg_> promach_: and indeed did not get to print the 'read'?
06:02:50 <_mjg_> forget about stap for now
06:02:53 <promach_> how would I do that during runtime ?
06:03:16 <Mutabah> lachlan_s: Whack some shaes together with inkscape/gimp?
06:03:24 <promach_> can I get the pid of the read process during code runtime ?
06:03:34 <promach_> _mjg_
06:03:58 <promach_> pid is allocated randomly at runtime, right ?
06:04:09 --- quit: regreg (Ping timeout: 256 seconds)
06:04:14 <lachlan_s> Mutabah: Yeah, I'll give that a try
06:04:22 <promach_> I have used lsof /dev/xillybus_read_128
06:04:23 <_mjg_> not randomly
06:04:26 <lachlan_s> I'm just not sure what it should look like
06:04:27 <promach_> and it is not dead
06:04:30 --- join: jmill (~textual@2605:6000:1019:3ff:85ce:c566:230f:a26a) joined #osdev
06:04:34 <_mjg_> well one case i can think of is buffer overflow from read
06:04:40 <_mjg_> your process does return
06:04:52 <_mjg_> can you run the sucker under *strace*
06:04:55 <_mjg_> not gdb
06:05:01 <promach_> ok
06:05:29 <izabera> strace -f
06:06:06 <promach_> izabera: ok
06:06:07 <_mjg_> right
06:06:49 <Mutabah> ... why is your code forking anyway?
06:08:03 --- join: dennis95 (~dennis@mue-88-130-61-160.dsl.tropolys.de) joined #osdev
06:09:47 <promach_> for full duplex
06:10:05 <promach_> I have /dev/xillybus_read_128 and /dev/xillybus_write_128
06:11:04 <bcos> pthreads? asynch IO?
06:11:12 <promach_> I have different output at the hardware side when I use strace -f
06:11:25 <promach_> izabera _mjg_
06:11:46 <promach_> it seems like strace -f messes up the xillybus linux driver
06:12:09 <_mjg_> it affects timings, but that should be harmless
06:12:19 <_mjg_> i.e. things are slower under strace
06:12:29 <izabera> a broken driver is possible but my first guess would be pebkac
06:12:36 <promach_> it is not harmless, because it affects FPGA timing
06:13:26 <promach_> izabera : what pebkac ?
06:13:31 <Mutabah> uuuh... if your program is that sensitive to timing, there's probably other issues
06:13:32 <bcos> izabera: Hard for 'user error" to get read() to terminate a process
06:13:34 <_mjg_> timing of what? you already have no guarantee
06:13:56 <bcos> promach_: Erm. "timing sensitive" and "user-space process" don't sound very compatible to me..
06:13:58 <_mjg_> regardless of strace. it does add latency to syscall layer, but you may as well get some during normal operation
06:14:00 <promach_> _mjg_ : FPGA hardware timing.
06:14:13 <_mjg_> my point is, if strace makes things not work, the entire setup is already b0rked
06:14:22 <promach_> I am not getting right result at the FPGA when I use strace
06:14:37 <_mjg_> then your program already does not work in reliable manner
06:14:45 <_mjg_> regardless of strace or the bug you ran into
06:14:49 <promach_> "the entire setup" <-- what do you mean ?
06:15:00 <promach_> you mean xillybus linux driver
06:15:02 <promach_> /
06:15:04 <promach_> ?
06:15:28 <promach_> can I use systemtap probe instead of strace ?
06:15:31 <promach_> in this case
06:15:31 <_mjg_> i mean that running a random usersapce process against something timing sensitive is not reliable
06:15:51 <_mjg_> because you can get preempted at any point
06:15:51 <promach_> hmm...
06:16:00 <promach_> what about pthread ?
06:16:02 --- quit: cirno_ (Quit: WeeChat 2.1)
06:16:13 <bcos> You'd hope that the driver does buffering (so that user-space isn't timing sensitive)
06:16:17 <_mjg_> is this a student project? are you doing something for work?
06:16:29 <_mjg_> is this stupposed to actually work?
06:16:32 <bcos> ..basic "FIFO per stream" maybe
06:16:35 <promach_> I am working for a school project
06:16:47 <promach_> Xillybus has DMA buffer
06:17:08 <promach_> http://xillybus.com/downloads/doc/xillybus_host_programming_guide_linux.pdf#page=40
06:17:44 <Mutabah> promach_: A few tips
06:18:03 <Mutabah> promach_: #1 - `using namespace foo;` makes code REALLY hard to read
06:18:28 <Mutabah> promach_: #2 - Break your logic up into functions - e.g. one for the read process and one for the write process
06:18:32 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:18:57 <_mjg_> wait, if there are two different processes operating this
06:19:08 <_mjg_> how is that supposed to survive scheduling drift
06:19:11 <Mutabah> promach_: #3 - C++ supports for-loop variable declarations, use them
06:19:16 <izabera> bcos: pebkac also includes wrong error detection
06:19:29 <promach_> _mjg_ : operating this <--- what is "this" ?
06:19:31 <Mutabah> _mjg_: I'd assume one is a source, the other is a sink?
06:19:32 <_mjg_> here is a sanity check: does the code work under valgrind?
06:19:32 <izabera> and misunderstanding of what's going on
06:19:45 <promach_> valgrind gives no error
06:19:47 <_mjg_> i mean does valgrind report issues
06:19:49 <_mjg_> hm
06:20:20 <_mjg_> Mutabah: my point was that if latency added from strace is enough to cause trouble, how come running two different processes does not cause trouble already
06:20:58 <Mutabah> Good point.
06:21:26 <promach_> ok, it means I need to restructure my cpp coding ?
06:21:29 <promach_> but how ?
06:21:45 <Mutabah> promach_: #4 - The love of peace, tabs or spaces - pick one
06:21:58 <_mjg_> pick tabs
06:22:19 <promach_> :)
06:24:23 <promach_> does this imply the Xillybux linux driver perhaps hide some bugs ?
06:24:51 <promach_> _mjg_ : should I try systemtap probe if strace does not work for me ?
06:28:40 --- join: regreg (~regreg@85.121.54.224) joined #osdev
06:30:40 <_mjg_> can you tripple-fucking check none of the reading processes are running?
06:30:53 <_mjg_> given the timeouts in dmesg, i find it plausible they are all stuck
06:31:22 <promach_> wait, I only have ONE write process, ONE read process
06:32:58 <_mjg_> old one from previous attempts may be still around
06:33:00 <_mjg_> that's what i mean
06:33:08 --- join: zeus1 (~zeus@197.239.1.33) joined #osdev
06:34:14 <promach_> I have already done lsof /dev/xillybus_read_128
06:34:20 <promach_> before I run ./host
06:34:29 <Mutabah> and writers?
06:34:33 <promach_> yes too
06:35:02 <_mjg_> ps auxw | grep host
06:35:05 <_mjg_> is there anything or not
06:36:16 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:37:19 --- quit: JusticeEX (Quit: Lost terminal)
06:38:11 --- join: jmill (~textual@2605:6000:1019:3ff:85ce:c566:230f:a26a) joined #osdev
06:38:19 <promach_> see https://paste.ubuntu.com/p/5rQKkzJDbb/
06:38:19 <bslsk05> ​paste.ubuntu.com: Ubuntu Pastebin
06:38:49 <promach_> by the way, I am getting different mileage as which how much pixels can be received before the program terminates on its own
06:39:40 <promach_> I mean each run gave different "num_of_pixels_received" before it is terminated on its own
06:39:46 <promach_> _mjg_ Mutabah
06:40:37 <Mutabah> Try removing `-f sanitize=address` - If you read the error message at the bottom, it doesn't work well wth gdb
06:41:14 <_mjg_> how come it works under valgrind and not under strace?
06:41:32 <Mutabah> _mjg_: That's gdb+asan
06:42:10 <_mjg_> geez, i only looked at the bottom
06:42:15 <_mjg_> apologies :>
06:42:28 <Mutabah> _mjg_: Don't worry, I thought that at first too, smelled the same rat, and checked
06:43:13 <_mjg_> stop right there
06:43:13 <_mjg_> phung@UbuntuHW15:~/Documents/fpga_overlay/xillybus-eval-xl-virtexultrascale-2.0a/verilog/vivado/xillydemo.srcs/sources_1/imports/taylor$ lsof /dev/xillybus_read_128
06:43:17 <_mjg_> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
06:43:19 <_mjg_> host 26830 phung 3r CHR 240,0 0t0 506 /dev/xillybus_read_128
06:43:22 <_mjg_> phung@UbuntuHW15:~/Documents/fpga_overlay/xillybus-eval-xl-virtexultrascale-2.0a/verilog/vivado/xillydemo.srcs/sources_1/imports/taylor$ kill 26830
06:43:25 <_mjg_> why the kill
06:43:29 <_mjg_> so in fact there *is* a hanging process?
06:43:56 <promach_> there "was" a hanging process due to previous run
06:44:02 <promach_> it is not terminated properly :(
06:44:11 <promach_> now see https://paste.ubuntu.com/p/48vgcqDbY4/
06:44:11 <bslsk05> ​paste.ubuntu.com: Ubuntu Pastebin
06:44:31 <promach_> Mutabah: I have removed "-f sanitize=address"
06:44:39 <_mjg_> so to be clear, when you run the usual way
06:44:44 <_mjg_> and it fails
06:44:51 <_mjg_> there is NO process left?
06:45:11 <_mjg_> because so far it most definitely looks like there is
06:45:17 <promach_> no, ./host also gave hanging process
06:45:20 <Mutabah> My guess - gdb doesn't trace across forks, so the gdb exit is actually the writer terminating
06:45:23 <_mjg_> sigh
06:45:24 <_mjg_> so
06:45:26 <Mutabah> the the reader just sits there waiting for data, because there's no writer
06:45:29 <_mjg_> right now you got a hgning reader
06:45:43 <promach_> I suppose so
06:45:43 <_mjg_> Mutabah: yea
06:45:53 <Mutabah> so, izabera was right
06:45:53 <_mjg_> so if the reader sits there, it did not exit
06:45:59 <Mutabah> pebkac
06:46:02 <_mjg_> and there is no surprise you don't get a printf either
06:46:15 <promach_> check line 272 of my gist
06:46:48 <Mutabah> What, a commented-out return?
06:46:54 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
06:46:55 <promach_> https://gist.github.com/promach/9d185d35a6e6db0da10992a19c36f754#file-host-cpp-L272
06:46:56 <bslsk05> ​gist.github.com: C++ test code of HLS computation kernel for both Xillybus and RIFFA PCIe framework · GitHub
06:46:57 <promach_> yes
06:46:58 <Mutabah> Oh, tip #5 - Compiler warnings exit for a reason
06:47:11 <Mutabah> s/exit/exist/
06:47:26 <izabera> i'm always right
06:47:43 <_mjg_> calling pebkac is typically a safe bet though
06:47:43 <promach_> which specific compiler warnings are you referring ?
06:47:44 <_mjg_> 8)
06:48:09 <Mutabah> The one that tells you that you aren't returning a value from a non-void function
06:48:46 <Mutabah> Wait, why? Whyd din't it error?
06:48:49 <promach_> Mutabah: I cannot see any warning in https://paste.ubuntu.com/p/48vgcqDbY4/
06:49:12 <Mutabah> there's no return on one path... wha?
06:49:38 <promach_> to be honest, I have tried with the uncommenting the return path before
06:49:50 <promach_> both gave improper program termination
06:50:22 <_mjg_> this is return from main, perhaps it got special casedx
06:50:25 <_mjg_> anyway
06:50:44 <_mjg_> there is no mystery for "disappearing" read: it sits in the kernel
06:51:34 <promach_> special casedx ?
06:53:12 <Mutabah> promach_: You have your answer as to what your program is doing - The writing process terminates, the reading process is still running in the background
06:58:40 <promach_> but as to how should I deal with the timing difference between write and read processes
06:58:49 <promach_> Mutabah
07:00:57 --- quit: cirno_ (Remote host closed the connection)
07:01:34 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
07:03:39 --- quit: regreg (Ping timeout: 256 seconds)
07:15:42 --- quit: milesrout (Ping timeout: 240 seconds)
07:15:58 <_mjg_> i had a userspace bug once
07:16:19 <_mjg_> a buffer overflow which had a side effect of verwriting the return address
07:16:31 <_mjg_> to a sequence which would end up calling exit
07:16:56 --- join: milesrout (~milesrout@unaffiliated/milesrout) joined #osdev
07:17:34 --- join: [X-Scale] (~ARM@83.223.241.57) joined #osdev
07:17:43 --- quit: Humble (Ping timeout: 260 seconds)
07:18:49 --- quit: X-Scale (Ping timeout: 240 seconds)
07:18:49 --- nick: [X-Scale] -> X-Scale
07:19:57 --- join: regreg (~regreg@85.121.54.224) joined #osdev
07:20:39 --- join: Humble (~hchiramm@2405:204:d207:1d9f:2e83:78a:8e70:4f8) joined #osdev
07:21:43 --- quit: grouse (Quit: Leaving)
07:22:12 --- join: [X-Scale] (~ARM@83.223.227.200) joined #osdev
07:24:55 --- quit: X-Scale (Ping timeout: 256 seconds)
07:24:56 --- nick: [X-Scale] -> X-Scale
07:30:57 --- quit: cirno_ (Remote host closed the connection)
07:31:36 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
07:33:57 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:34:21 --- join: Asu (~sdelang@AMarseille-658-1-73-50.w86-203.abo.wanadoo.fr) joined #osdev
07:37:51 --- quit: xenos1984 (Quit: Leaving.)
07:37:53 --- quit: Humble (Read error: Connection reset by peer)
07:38:19 --- join: Humble (~hchiramm@2405:204:d207:1d9f:2e83:78a:8e70:4f8) joined #osdev
07:43:11 --- join: hmmmm (~sdfgsf@pool-72-79-164-159.sctnpa.east.verizon.net) joined #osdev
07:47:38 --- join: jmill (~textual@2605:6000:1019:3ff:85ce:c566:230f:a26a) joined #osdev
07:48:27 --- quit: bcos (Ping timeout: 240 seconds)
07:48:40 --- join: bcos (~bcos@101.172.24.70) joined #osdev
07:53:35 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
07:56:25 --- nick: promach__ -> promach2
07:57:26 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
07:58:34 <JonRob> Hi
07:58:57 <JonRob> I'm writing an ATA driver and so far it works in qemu with -machine pc but not q35, any idea what could cause this?
07:59:04 <JonRob> code: https://jonrob.net/repo/EspressOS/kernel/ata.s
07:59:04 <bslsk05> ​jonrob.net: ata.s
08:00:56 --- quit: cirno_ (Remote host closed the connection)
08:01:31 <JonRob> the bsy but stays on
08:01:35 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:05:31 --- join: JSquared (180a8b5a@gateway/web/freenode/ip.24.10.139.90) joined #osdev
08:08:43 --- quit: JSquared (Client Quit)
08:10:25 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:10:47 --- quit: oaken-source (Ping timeout: 248 seconds)
08:16:06 <promach2> _mjg_ : "a buffer overflow which had a side effect of verwriting the return address " ?
08:21:39 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
08:23:19 <promach2> Mutabah: just found http://sourceware.org/gdb/onlinedocs/gdb/Forks.html
08:23:19 * Mutabah is away (Sleep)
08:23:20 <bslsk05> ​sourceware.org: Debugging with GDB: Forks
08:23:35 <promach2> set detach-on-fork mode
08:26:12 --- join: hchiramm_ (~hchiramm@2405:204:d204:960b:70de:512b:fa5a:e801) joined #osdev
08:26:52 --- quit: Humble (Ping timeout: 245 seconds)
08:27:45 --- nick: Peetz0r -> peterHazenberg
08:29:25 --- nick: peterHazenberg -> Peetz0r
08:30:57 --- quit: cirno_ (Remote host closed the connection)
08:31:35 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:34:51 <promach2> _mjg_ Mutabah: do you think I should rewrite the code using pthread instead of fork() ?
08:34:59 <promach2> will that make a difference ?
08:37:13 <bcos> promach2: How much synchonisation will you need between reader and writer?
08:39:31 * bcos is imagining a situation where you want to write a command and then get results, with a slow/bloated mess (e.g. pipes) in the middle
08:39:50 <promach2> I am sending 512*512*3 bytes through /dev/xillybus_write_128 , to reach FPGA, and then I want to receive all computed 512*512*3 bytes back through /dev/xillybus_read_128
08:39:53 <bcos> (so separate reader and writer proceses can communicate)
08:40:42 <bcos> For that I'd be tempted to use a single thread (without any fork), and asych IO
08:40:56 <promach2> single thread ?
08:41:10 <bcos> http://man7.org/linux/man-pages/man7/aio.7.html
08:41:10 <bslsk05> ​man7.org: aio(7) - Linux manual page
08:41:12 <bcos> Yes
08:41:36 <promach2> both /dev/xillybus_write_128 and /dev/xillybus_read_128 in single thread ? I will try that tomorrow when I have access to the embedded machine
08:42:23 <promach2> both /dev/xillybus_write_128 and /dev/xillybus_write_128 are asynchronous device file
08:42:39 <promach2> both /dev/xillybus_write_128 and /dev/xillybus_read_128 are asynchronous device files
08:42:43 <promach2> bcos
08:42:59 <bcos> If the pattern is "write, then wait for FPGA, then read results" you don't really need 2 or more CPUs (and don't really need 2 or more threads or processes)
08:44:11 <promach2> ok, I got your idea. I will rewrite the code using your advice
08:44:22 --- quit: Asu (Remote host closed the connection)
08:51:27 --- quit: oaken-source (Ping timeout: 240 seconds)
08:53:12 --- join: Asu (~sdelang@AMarseille-658-1-73-50.w86-203.abo.wanadoo.fr) joined #osdev
08:53:23 --- quit: Asu (Client Quit)
08:54:10 --- join: Asu (~sdelang@AMarseille-658-1-73-50.w86-203.abo.wanadoo.fr) joined #osdev
08:54:30 --- join: daniele_athome (~daniele_a@5.170.124.137) joined #osdev
08:57:30 --- quit: Asu (Remote host closed the connection)
08:58:28 --- quit: m3nt4L (Remote host closed the connection)
08:59:44 <promach2> bcos: however, I am sending 512*512*3 bytes in multiple batches of 128 bits (or 16 bytes)
08:59:52 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:00:12 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
09:00:26 <promach2> this is a problem of achieving synchronization in full duplex cpp coding
09:00:56 --- quit: cirno_ (Remote host closed the connection)
09:01:03 <bcos> promach2: You can't send more at once? E.g. a single "write()" that sends the whole 512*512*3 bytes to the driver's buffer in kernel space?
09:01:37 <promach2> bcos: Xillybus device files are at most 256 bits (or 32 bytes)
09:02:16 <bcos> device files?
09:02:27 <promach2> /dev/xillybus_write_128
09:02:33 <promach2> /dev/xillybus_read_128
09:03:08 <bcos> From what I saw earlier, their main attraction was a seamless DMA engine
09:03:24 <promach2> yes, DMA buffer
09:03:27 <bcos> ...which doesn't make sense when you only allow a pathetic "few bytes per transfer"
09:03:57 <promach2> I am not sure why it is limited to 256 bits
09:04:50 <bcos> At 8 bytes transfer it'd be faster to transfer the data directly (PIO) and avoid the overhead/hassle of setup up a DMA transfer
09:05:26 <bcos> It just doesn't make sense...
09:05:46 <bcos> ..unless it's a stream of 128-bit items
09:06:07 <bcos> ..where you fill a buffer with 1234 GiB of stuff and the DMA engine transfers it all for you (at 128-bits at a time)
09:06:31 --- quit: daniele_athome (Ping timeout: 260 seconds)
09:07:11 --- quit: nj0rd (Ping timeout: 256 seconds)
09:08:05 --- join: Asu (~sdelang@AMarseille-658-1-73-50.w86-203.abo.wanadoo.fr) joined #osdev
09:08:24 <promach2> bcos: have you seen http://xillybus.com/downloads/doc/xillybus_host_programming_guide_linux.pdf#page=40 ?
09:09:19 --- join: jmill (~textual@2605:6000:1019:3ff:85ce:c566:230f:a26a) joined #osdev
09:09:44 --- join: NaNkeen (~nankeen@115.164.203.138) joined #osdev
09:13:36 <bcos> promach2: Page 43 looks more fun (for the read side at least)
09:14:33 <bcos> - specifically the part about "wait for up to 10 ms for more data (to limit the overhead to 100 read() calls per second)"
09:16:48 <bcos> Ah
09:17:51 <bcos> promach2: For writing; looks like you'll want to "write()" the whole 512*512*3 bytes (into the driver's buffer in RAM/kernels-space) and then do an explicit flush (to avoid a 10 ms delay)
09:18:45 <promach2> "write()" the whole 512*512*3 bytes <-- how am I suppose to do that ?
09:19:16 <bcos> "write(fd, myBuffer, 512*512*3);"
09:19:37 <promach2> xillybus fd supports maximum 256 bits
09:19:48 <bcos> Nonsense
09:20:21 <promach2> huh ? you mean xillybus linux driver will handle the writing
09:20:22 <bcos> The only thing write does is shift data from RAM (user-space) to RAM (kernel-space)
09:20:29 <promach2> I see
09:21:07 <bcos> ..and then the DMA engine pumps it from the buffer in kernel space to the device (probably at 128-bits at a time)
09:21:47 <promach2> I see, from programmer perspective, I can "write()" the whole 512*512*3 bytes and expects FPGA to receive 128-bits at a time ?
09:22:21 <bcos> The thing is; if you do a read() or write() for every 128 bits/16 bytes you'll spend 99% of CPU time on kernel system call overhead
09:22:23 <bcos> Yes
09:22:26 <bcos> (I'd hope)
09:22:55 --- quit: NaNkeen (Ping timeout: 264 seconds)
09:23:05 <promach2> so, the best way is "write()" the whole 512*512*3 bytes
09:23:40 <promach2> ok, I will try this method tomorrow when I have access to the embedded machine
09:25:15 <bcos> :-)
09:25:38 <promach2> bcos: thanks a lot for your advice. I got to go now. it is quite late here
09:25:59 <bcos> K - cya
09:27:35 --- quit: promach2 (Quit: WeeChat 2.1)
09:28:48 --- quit: Asu (Remote host closed the connection)
09:29:19 --- join: Asu (~sdelang@AMarseille-658-1-73-50.w86-203.abo.wanadoo.fr) joined #osdev
09:29:44 --- quit: stav (Quit: Leaving)
09:31:02 --- quit: Asu (Remote host closed the connection)
09:33:59 --- join: bender (uid106562@gateway/web/irccloud.com/x-bujoafoqjnxkgzve) joined #osdev
09:48:08 --- join: aalm (~aalm@37-219-100-76.nat.bb.dnainternet.fi) joined #osdev
09:48:18 --- quit: dennis95 (Quit: Leaving)
09:52:36 --- quit: magnificrab (Ping timeout: 260 seconds)
10:00:44 --- quit: BartAdv (Quit: Connection closed for inactivity)
10:02:19 --- join: MDead (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
10:03:07 --- quit: MDude (Ping timeout: 245 seconds)
10:03:10 --- nick: MDead -> MDude
10:05:45 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
10:05:59 --- join: blackandblue (~batdownh@gateway/tor-sasl/blackandblue) joined #osdev
10:10:45 --- quit: blackandblue (Client Quit)
10:10:56 --- join: blackandblue (~batdownh@gateway/tor-sasl/blackandblue) joined #osdev
10:11:13 --- quit: lachlan_s (Quit: Connection closed for inactivity)
10:12:55 --- quit: zeus1 (Ping timeout: 248 seconds)
10:16:26 --- quit: drakonis (Remote host closed the connection)
10:19:08 --- join: Asu (~sdelang@AMarseille-658-1-73-50.w86-203.abo.wanadoo.fr) joined #osdev
10:19:20 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
10:25:55 --- join: zeus1 (~zeus@197.239.1.75) joined #osdev
10:40:11 --- quit: vaibhav (Quit: Leaving)
10:49:54 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-yahlyuvjulrtziro) joined #osdev
10:51:33 --- join: ampotos_ (~ampotos@lew31-1-78-247-114-197.fbx.proxad.net) joined #osdev
10:53:31 --- quit: ampotos (Ping timeout: 264 seconds)
11:16:22 --- join: m3nt4L (~asvos@2a02:587:a001:6900:3285:a9ff:fe8f:665d) joined #osdev
11:16:23 --- quit: blackandblue (Ping timeout: 250 seconds)
11:37:11 --- quit: JonRob (Ping timeout: 248 seconds)
11:38:57 --- join: JonRob (~jon@host86-143-164-222.range86-143.btcentralplus.com) joined #osdev
11:40:37 --- join: z0ttel (~z0ttel@reuenthal.z0ttel.com) joined #osdev
11:41:43 --- quit: z0ttel (Remote host closed the connection)
11:44:24 --- join: z0ttel (~z0ttel@reuenthal.z0ttel.com) joined #osdev
11:45:02 --- join: tacco| (~tacco@i59F4FA60.versanet.de) joined #osdev
11:48:36 --- quit: dmh ()
11:54:14 --- join: _sfiguser (~sfigguser@95.141.40.107) joined #osdev
11:58:45 --- join: S_Gautam (~GautamS@unaffiliated/gautams) joined #osdev
12:06:40 --- join: SwiftMatt (~Objective@2601:282:4300:3e:8c8d:7d4f:d073:1720) joined #osdev
12:06:50 --- quit: tylerdmace (Ping timeout: 252 seconds)
12:07:51 --- quit: ChanServ (shutting down)
12:09:05 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
12:13:03 --- join: ChanServ (ChanServ@services.) joined #osdev
12:13:03 --- mode: verne.freenode.net set +o ChanServ
12:13:37 --- quit: bender (Quit: Connection closed for inactivity)
12:21:58 --- quit: ChanServ (shutting down)
12:25:37 --- quit: mlen (Quit: WeeChat 1.9.1)
12:27:20 --- join: mlen (~mlen@jay.aquila.re) joined #osdev
12:28:22 --- quit: m3nt4L (Remote host closed the connection)
12:30:58 --- join: ChanServ (ChanServ@services.) joined #osdev
12:30:58 --- mode: verne.freenode.net set +o ChanServ
12:31:01 --- join: tylerdmace (~tylerdmac@107.14.54.131) joined #osdev
12:34:20 --- nick: amj -> Guest51081
12:34:20 --- nick: talin -> Guest55350
12:34:20 --- nick: kbw -> Guest8827
12:34:20 --- nick: tktech -> Guest97770
12:34:21 --- nick: dwn -> Guest95153
12:34:21 --- nick: Stary -> Guest17294
12:34:21 --- nick: Staphylo -> Guest73762
12:34:22 --- nick: mawk -> Guest31421
12:34:24 --- nick: augustl -> Guest65775
12:34:24 --- nick: Youmu -> Guest89814
12:34:25 --- nick: EvilJStoker -> Guest41100
12:34:25 --- nick: AntiSpamMeta -> Guest85247
12:34:26 --- nick: aejsmith -> Guest57025
12:34:27 --- nick: ikonia -> Guest57044
12:34:27 --- nick: eren`` -> Guest2101
12:34:27 --- nick: acidx -> Guest42814
12:34:27 --- nick: M_D_K -> Guest24330
12:34:27 --- nick: XgF -> Guest61519
12:34:27 --- nick: alphawarrior -> Guest4708
12:34:28 --- nick: jfu -> Guest59339
12:34:28 --- nick: air -> Guest38480
12:34:28 --- nick: SirCmpwn -> Guest72864
12:34:28 --- nick: jack_rabbit -> Guest92985
12:34:29 --- nick: systmkor -> Guest81514
12:34:29 --- nick: mischief -> Guest21042
12:34:29 --- nick: shymega -> Guest43239
12:34:33 <stephennnn> um
12:34:36 <Guest21042> YAY
12:34:38 <Guest21042> fun times
12:34:41 --- quit: bitch (Changing host)
12:34:41 --- join: bitch (hctib@unaffiliated/bitch) joined #osdev
12:34:41 --- quit: bitch (Changing host)
12:34:41 --- join: bitch (hctib@gateway/shell/elitebnc/x-gbkjpuzkllxbmusk) joined #osdev
12:34:42 <stephennnn> what happened
12:35:17 --- join: oaken-source (~oaken-sou@p5DDB53DF.dip0.t-ipconnect.de) joined #osdev
12:35:26 --- nick: S_Gautam -> Guest99831
12:35:26 <stephennnn> Does anybody know how es:di works?
12:35:42 --- nick: Guest99831 -> S_Gautam
12:36:07 --- quit: pg12 (Quit: ZNC - http://znc.in)
12:36:12 --- nick: Guest21042 -> mischief
12:36:17 --- join: pg12 (~pg12@p200300DBFBC93D00D25099FFFEC37ACA.dip0.t-ipconnect.de) joined #osdev
12:36:48 <geist> well, nickserv apparently died
12:36:53 <bauen1> ^
12:37:00 <bauen1> regular maintenance
12:37:04 --- nick: Guest43239 -> shymega
12:37:06 --- quit: MindlessDrone (Ping timeout: 260 seconds)
12:37:08 <bauen1> should be back in a bit
12:37:11 <bauen1> like now
12:37:11 <stephennnn> ah okay
12:37:34 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
12:39:26 --- join: MindlessDrone (~MindlessD@unaffiliated/mindlessdrone) joined #osdev
12:40:03 --- quit: behalebabo (Quit: Farewell.)
12:40:14 --- join: behalebabo (~behalebab@unaffiliated/behalebabo) joined #osdev
12:45:59 * elevated elevated hey
12:47:21 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
12:47:44 --- nick: Guest85247 -> AntiSpamMeta
12:50:03 <stephennnn> In C, is there a way to specify a precise memory address, ignoring any offsets?
12:51:10 --- nick: Guest51081 -> amj_
12:52:27 <izabera> void *ptr = (void *)0x1234567
12:52:50 <stephennnn> And that 0x1234567 will be the same as any other 0x1234567 in my bootloader asm?
12:53:23 <_mjg_> what is this the offset to?
12:53:44 <stephennnn> What do you mean?
12:53:48 <izabera> maybe osdev isn't exactly the right chan for now
12:55:45 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
12:56:53 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
12:59:36 --- quit: lachlan_s (Quit: Connection closed for inactivity)
13:00:00 --- join: dbe (~dbe@155.4.14.33) joined #osdev
13:00:03 --- nick: Guest61519 -> XgF
13:00:05 --- quit: tylerdmace (Ping timeout: 256 seconds)
13:00:33 --- nick: XgF -> Guest15668
13:01:09 --- quit: Guest15668 (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
13:01:43 --- join: XgFgX (~quassel@magi1.paris.fr.node.e43.eu) joined #osdev
13:03:39 --- join: tylerdmace (~tylerdmac@64.9.245.129) joined #osdev
13:04:45 --- nick: XgFgX -> gay
13:06:39 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:08:28 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
13:08:39 --- quit: spare (Quit: leaving)
13:09:31 --- quit: mlen (Quit: WeeChat 1.9.1)
13:10:59 --- join: mlen (~mlen@jay.aquila.re) joined #osdev
13:14:46 --- nick: Guest42814 -> acidx
13:21:27 --- quit: quc (Read error: Connection reset by peer)
13:22:23 --- quit: drakonis (Remote host closed the connection)
13:26:16 --- nick: Guest8827 -> kbw
13:27:32 --- join: tylerdma1e (~tylerdmac@pool-98-113-217-137.nycmny.fios.verizon.net) joined #osdev
13:28:50 <doug16k> stephennnn, it depends on what mode the cpu is in, and how it is configured
13:29:09 <stephennnn> doug16k: I figured it out :)
13:29:21 <stephennnn> Happy to say I'm in 1024x768 can can draw boxes
13:29:22 --- quit: tylerdmace (Ping timeout: 245 seconds)
13:29:23 <doug16k> you can tell the compiler to produce an instruction that attempts that, but it might just fault
13:29:33 <doug16k> good
13:34:21 --- quit: Halofreak1990 (Ping timeout: 245 seconds)
13:35:26 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:37:12 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-ejegeynqsrqhexep) joined #osdev
13:40:01 --- join: quc (~quc@87.116.229.183) joined #osdev
13:50:17 --- join: jmill (~textual@2605:6000:1019:3ff:85ce:c566:230f:a26a) joined #osdev
13:52:29 --- quit: light2yellow (Quit: light2yellow)
13:56:47 <_mjg_> kind of embarassing imo https://github.com/openbsd/src/commit/fd327f069b5613e6e218ee7a3426ba82f53d373f
13:56:49 <bslsk05> ​github.com: Delay the vput() of the directory vnode until the vnode has been · openbsd/src@fd327f0 · GitHub
13:59:35 --- nick: Guest57025 -> aejsmith
14:00:17 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:01:10 <sortie> My latest OS release does not collect any personal information whatsoever and is equipped with state of the art security, such as having neither a network stack nor network drivers.
14:01:17 <sortie> #osdevgdpr
14:01:53 <_mjg_> you know what would be fun
14:02:19 <_mjg_> do an all-weekend event one day where people everyone contributes to a particular somewhat established os
14:02:26 * _mjg_ looks at openbsd
14:03:02 <sortie> OpenBSD does hold regular hackathons that's basically that
14:03:08 <_mjg_> i know
14:03:13 <_mjg_> i like the idea a lot actually
14:03:26 <sortie> One thing that osdev needs is more peer reviews
14:03:48 <sortie> I don't think people really want to work that much on each other's systems, but code reviews are really valuable
14:04:17 <sortie> I encourage y'all to post interesting commits here, or link your repository, if you want people to casually go take a look
14:04:23 <sortie> I can tell a lot about a person from their .h files.
14:04:24 <_mjg_> it's more in the form of hobby spelunking
14:05:01 <_mjg_> while i could not give even a partial fuck about contributing to StanleyOS
14:05:01 <geist> sortie: oh i thought you had a net stac
14:05:16 <_mjg_> i can muster some for a known os
14:05:23 <geist> if anything sortix would be the one that is most likely to actually need a terms of service
14:05:25 <sortie> geist: I'm being exact and saying 'latest release', the net stack isn't released (or even merged tyo mster)
14:05:30 <geist> ah
14:06:45 --- nick: Guest38480 -> air
14:09:58 --- join: nj0rd (~nj0rd@mue-88-130-48-024.dsl.tropolys.de) joined #osdev
14:12:07 <kbw> I think openbsd's dev culture is pretty peculier
14:12:40 <kbw> Like, instead of relying on outside contributions or corporate support, their development seems more in-house and self-sufficient
14:16:29 <sortie> That part of it seems alright and fine to me
14:16:42 <sortie> It's active enough to get stuff done
14:17:14 <sortie> geist: Yeah once you got a Sortix .iso, no ToS is really needed beyond the standard licenses.
14:17:29 <sortie> geist: But networking does introduce some caveats.
14:17:53 <_mjg_> kbw: that's not true
14:17:57 <sortie> DHCP autoconfiguration, possibly even ntp by default (if advertised by your router) is reasonable probably
14:18:19 <_mjg_> kbw: for one they heavily take the kms stuff from linux
14:18:28 <sortie> But automatic or manual updates that contacts my servers? That probably requires a ToS and raises questions about data.
14:18:32 <_mjg_> but they do it on their own if that's what you mnean
14:18:51 <kbw> _mjg_ pretty much
14:19:12 <_mjg_> there is very little paid work getting done
14:19:23 <_mjg_> but that's mostly because they don't have that much usage tobegin with
14:19:29 <kbw> a bigger feat would be writing the kms drivers using documentation only, but for what purpose when the code's out there and permissively licensed
14:19:29 <sortie> geist: So yeah, I need to think about the constraints of people interacting with my servers (manually and possibly automatically)
14:19:30 <_mjg_> very similar scenario in the netbsd land
14:20:54 <kbw> which is all the more impressive
14:21:09 --- join: lijero (~lijero@unaffiliated/lijero) joined #osdev
14:23:52 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
14:25:54 --- quit: Asu (Remote host closed the connection)
14:26:23 --- quit: oaken-source (Ping timeout: 245 seconds)
14:27:18 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
14:29:44 <pounce> So, should I load a new lvl 4 page table and invlpg every time I swap threads?
14:30:05 <pounce> and if not, how do I deal with process switching and thread switching differently
14:31:15 --- quit: lijero (Ping timeout: 276 seconds)
14:33:06 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
14:34:23 <geist> when you swap processes (which have their own address space)
14:34:49 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-rcytoirxltzqcqih) joined #osdev
14:35:24 <geist> it's no big deal generally
14:35:39 <geist> usually a process has N threads, where N is >=1
14:35:46 <geist> a process is associated with exactly 1 address space
14:35:57 <geist> so that means that any given thread is associated with at most 1 address space
14:36:29 <geist> so as you context switch threads you just compare the old address space from the old thread and the new one from the new thread and if they're not the same you swap it
14:36:46 <geist> otherwise you dont, because in that case you'd be switching from one thread within the same process to another
14:38:25 <lachlan_s> Are there any cases where a process has N <= 0 threads?
14:38:59 <lachlan_s> Aside from when a process has 2147483648 threads
14:40:15 <pounce> tbh I've been considering giving each userspace process one kernel thread, but that might turn out to be a nightmare later on
14:40:24 <geist> lachlan_s: i assume you're joking
14:40:30 <lachlan_s> Yep!
14:40:33 <geist> good
14:41:06 <Brnocrist> a thread joke
14:41:07 <geist> that being said, depending on hwo process creation works you can have a prcess with 0 threads. fuchsia goes through this path
14:41:19 <geist> posix however generally creates the process and the thread at the same time, via fork or spawn
14:41:35 <lachlan_s> Actually, yeah, nebulet can have a process with no threads
14:41:41 --- quit: Shamar (Quit: Lost terminal)
14:41:45 <lachlan_s> But once a process is started, a thread is automatically created
14:41:50 <Brnocrist> geist: fuchsia doesn't fork?
14:41:52 <geist> but then it's irrelevant with regards to scheduling in that case
14:42:01 <geist> Brnocrist: not at all
14:42:07 <pounce> how does it start then?
14:42:38 <pounce> I've been considering writing a posix wrapper for my OS when it's said and done, but tbh `fork()` keeps scaring me away
14:42:46 <Brnocrist> I should pull that code and enjoy the read
14:43:26 <geist> creating a new process in fuchsia is like assembling one from legos
14:43:39 <geist> you start by creating a new process object (if you have sufficient rights to the parent job)
14:44:15 <geist> which is now an empty shell, then you can populate it, map a user space loader, or directly load into it if you want. you can map stuff into a foreign process just as well as the local one, so populating the new process isn't hard
14:44:37 <Brnocrist> oh plan9
14:44:38 <geist> then you create an initial thread, construct a message with a set of info and handles to the new process for it to get started
14:44:49 <geist> then kick it off by resuming the first thread
14:45:03 <lachlan_s> Nebulet is kinda similar, you need a code object to create a process, and then you start it
14:45:30 <geist> right. note that the average process may or may not have the rights to even create one, since it requires a handle to a job object to create the process in that has sufficient rights
14:45:39 <geist> so it's just as easy to send an IPC to another service process to do it for you
14:45:53 <geist> which is probably how you'd do a fork style emulation if needed
14:46:30 <pounce> yeah but posix programs just abuse fork, so it would be very inefficient
14:46:55 <geist> of course. if you wanted to emulate fork on top of a design then you're making a series of tradeoffs and decisions about efficiency vs compatibility that you'd have to consider
14:47:04 <lachlan_s> copy-on-write is what makes fork efficient
14:47:16 <geist> in the case of fuchsia we are completey uninterested in doing posix process stuff
14:47:24 <geist> though it'd be *possible*
14:47:53 <geist> the hard part is adding the appropriate hooks into the VM to do a COW of an address space, but given a hook for that (clone-this-address-space syscall probably) then it'd be fairly straightforward
14:48:58 <geist> a lot of microkernel style stuff you start to treat the kernel as kind of like a RISC machine. you provide little functions and atoms of utility and you expect user space to assemble it in whatever pattern they need
14:50:20 --- quit: Guest23707 (Changing host)
14:50:20 --- join: Guest23707 (~user@unaffiliated/mrush) joined #osdev
14:50:44 <lachlan_s> That's an interesting way of looking at it
14:50:48 <lachlan_s> I like it
14:51:45 <doug16k> pounce, yes, load cr3, why invlpg?
14:53:24 <pounce> ah, I forgot that a cr3 load does that
14:53:25 --- quit: immibis (Ping timeout: 256 seconds)
14:54:02 <doug16k> yes, loading cr3 will flush all non-global mappings, assuming that you aren't using PCID
14:56:38 <lachlan_s> Can you do `mov cr3, cr3` to just flush the tlb?
14:57:00 <doug16k> you'd have to mov cr3 to a register, then move it to cr3, but yes
14:57:01 <geist> you have to load it into a register and write it back
14:57:08 <pounce> lachlan_s: I use https://docs.rs/x86_64/0.2.0-alpha-019/src/x86_64/instructions/tlb.rs.html#11-15 for reference
14:57:09 <bslsk05> ​docs.rs: tlb.rs.html -- source
14:57:24 <geist> that's one of the canonical ways to dump the TLB (modulo global pages)
14:57:40 <pounce> what are the other ways?
14:57:49 <doug16k> you can flush everything by toggling PGE in CR4
14:58:06 <doug16k> everything including global mappings
14:59:00 --- quit: sortie (Quit: Leaving)
14:59:03 <lachlan_s> I wont ever need too, but it's useful to know
15:00:12 <lachlan_s> Btw, pounce, do you use the page maping functionality of the x86_64 crate?
15:00:32 <doug16k> also, there is an invpcid instruction that has a few things to do partial or full flushes, but not all processors have it
15:00:40 <pounce> there's page mapping functionality OwO
15:01:02 <pounce> I keep my use of`x86_64` pretty low tbh
15:01:19 <lachlan_s> Yep, in the alpha version
15:01:19 <lachlan_s> https://docs.rs/x86_64/0.2.0-alpha-019/x86_64/structures/paging/struct.RecursivePageTable.html
15:01:20 <bslsk05> ​docs.rs: x86_64::structures::paging::RecursivePageTable - Rust
15:01:25 <lachlan_s> Phil and I wrote it
15:05:19 <pounce> that looks really nice! I have to take a look at what I want out of my VMM and we might switch to it
15:05:29 <pounce> Is the GDT cpu local?
15:05:35 <doug16k> yes
15:06:14 <lachlan_s> It's super useful to use
15:06:25 <lachlan_s> And it supports mapping 4k, 2mb, and 1gb pages
15:10:11 <doug16k> pounce, it doesn't make a lot of sense to have different GDTs per processor. it makes some sense to have different IDTs though - you can have up to ~220 IRQ vectors per processor that way, instead of ~220 for the whole machine
15:10:18 <doug16k> I don't know of any OS that does that though
15:11:06 <doug16k> 220 = 256 - 32 exceptions - ~4 for timer/apic spurious interrupt/etc
15:11:07 <pounce> yeah I think I'll stick to having a global IDT and stuff. I want to take spinlocks out of the kernel where I can though
15:13:06 <geist> yeah far as i know no one really does the per cpu IDT
15:14:56 <Brnocrist> what is the use case for it?
15:15:25 <pounce> no spinlocks >.>
15:16:02 <doug16k> Brnocrist, I just said a use case for it 5 minutes ago
15:16:39 <lachlan_s> Why would you need a spinlock around the idt?
15:16:43 <pounce> what really is the use case for an "operating system"
15:17:05 <lachlan_s> "operating" "systems"
15:17:24 <pounce> yes, what really is the use case for an "operating" "systems"
15:17:39 <lachlan_s> It operates systems
15:17:40 <geist> yeah, or "computers"
15:17:52 <pounce> all you really is is a good soldering iron and some grit
15:17:58 <pounce> really need*
15:18:50 <lachlan_s> and a 200 million usd fab lab
15:18:51 <aalm> you ppl seem bored, get hackin:P
15:19:34 <pounce> true I need to get preempting working, but I was waiting for my teammate to merge in my stuff so I wouldn't have to rebase
15:19:37 * pounce is lazy
15:20:09 * aalm is too
15:20:22 --- quit: S_Gautam (Quit: Leaving)
15:20:24 * _mjg_ is a hard worker
15:20:33 <aalm> but it's no excuse for being non-productive:p
15:21:45 <aalm> you could clean up the dirty hacks later, or add comments/do docs or whatever:P
15:21:46 <doug16k> I need to change the way per-cpu IRQs work in my OS. instead of inferring which queue it is from the vector, and having a separate vector per cpu, I should allocate a single vector, and infer which queue it is from the currently executing CPU in the IRQ handler
15:22:20 <doug16k> with high cpu counts, my nvme driver is wasting vectors
15:23:38 <pounce> So how do I tell if the page table changes? Do I hold a reference to my lvl 4 page table frame in the thread and do a compare on every switch?
15:25:02 * pounce grumbles about too many references
15:25:46 <aalm> optimize later? pessimism ftw.! :P
15:26:09 <lachlan_s> pounce: Yep, hold a pointer to the cr2
15:26:12 <lachlan_s> s/cr2/cr3
15:26:25 <doug16k> why would you need a reference? just compare the outgoing and incoming thread's cr3, or even just compare the outgoing and incoming process id
15:26:59 * pounce is stupid and confused his cr3 with the recursive address
15:28:33 <doug16k> or just unconditionally load cr3. x86 has extremely good page walker. you won't see a big difference
15:30:25 <pounce> lachlan_s: I forget, do you do cold/hot for codepaths in your kernel?
15:30:43 <geist> i just store a pointer to an object that represents the address space
15:30:56 <geist> which among other things holds the value of cr3
15:31:08 <geist> then you can basically tell if it's the same object that two threads have
15:31:08 <lachlan_s> pounce: Nope, I'll probably add those at some point
15:31:20 <lachlan_s> But I follow: "Make it work, make it right, make it fast"
15:31:27 <lachlan_s> in that order
15:31:54 <pounce> yeah me too. Rust's release mode is pretty good so I don't worry about that a lot
15:31:58 <geist> as a general rule A and B should generally be the same
15:32:08 <geist> or you'll pay for it in the long run. depends on the thing though
15:32:41 <Belxjander> the whole "slow is smooth", "smooth is fast" schtick ?
15:33:04 <lachlan_s> That's not to say I don't think about performance
15:33:49 <lachlan_s> I optimize the architecture for performance, not yet the code
15:40:10 <lachlan_s> Actually, I'm rethinking this now
15:40:31 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-mweukhpgicmygjah) joined #osdev
15:46:13 <pounce> I just want to be more vulnerable to spectre >.>
15:48:47 --- nick: Guest95153 -> dwn
15:49:11 <lachlan_s> Dude, nebulet is so fucking vulnerable to spectre, it's not even funny
15:51:30 <pounce> what's an operation I can do that will take a lot of time
15:51:37 <pounce> should I send, like, 50 bytes to an io port?
15:52:13 <doug16k> pounce, the cpuid instruction takes hundreds of cycles on most architectures
15:52:40 <lachlan_s> `*(uint8_t*)0 = 42;`
15:52:46 <lachlan_s> It'll take a while to restart the vm
15:52:50 <doug16k> IIRC ~120 cycles at best, far more on worse
15:53:06 <pounce> lachlan_s: >:[
15:53:28 <doug16k> if the cpu has rdrand it has an extremely high latency
15:53:49 <doug16k> as much as 2500 cycles
15:54:21 <doug16k> I/O reads are brutal too. they are serializing and cannot be posted to a queue
15:54:27 <lachlan_s> My method has a latency of around 20,000,000,000 cycles
15:56:29 <doug16k> if you want utterly ridiculously slow execution, execute code from uncacheable memory
15:57:31 <doug16k> every instruction will be serializing. the simplest instructions will take an unreasonable number of cycles
15:57:48 <aalm> pull the plug, and call it done
15:58:31 * doug16k took the opportunity to give advice on making execution as terribly slow as possible :P
16:00:40 <aalm> don't forget -g -O0
16:00:42 <doug16k> but cpus are so outrageously fast now, even if you get every instruction to be > 1000 cycles, you'll still have hundreds of MIPS, at least
16:01:28 <_mjg_> security researches are working on this part
16:02:00 <pounce> preempting working \o/
16:02:25 <pounce> (I wanted to delay my threads long enough so they'd release a lock so I could tell if multiple ones were printing)
16:02:45 <pounce> (100 `cpuid`s seems to do the trick most of the time)
16:03:53 <Belxjander> can't trigger a new Copy-On-Write Memory page per-process on each processor thread and hammer that with pre-filled cache content...
16:04:00 <Belxjander> then wipe it all ?
16:07:28 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
16:09:03 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
16:11:44 --- join: bemeurer (~bemeurer@stdcognition.static.monkeybrains.net) joined #osdev
16:15:11 --- nick: promach__ -> promach2
16:21:03 --- quit: xenos1984 (Quit: Leaving.)
16:22:16 --- quit: awang (Ping timeout: 256 seconds)
16:24:00 --- nick: Guest97770 -> tktech
16:35:43 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
16:41:25 <lachlan_s> pounce: Nice!
16:44:56 --- quit: CheckDavid (Quit: Connection closed for inactivity)
16:45:44 --- quit: epony (Remote host closed the connection)
16:47:09 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #osdev
16:48:14 --- join: Kimundi__ (~Kimundi@i577A9364.versanet.de) joined #osdev
16:51:51 --- quit: Kimundi_ (Ping timeout: 248 seconds)
17:01:58 --- quit: quc (Read error: Connection reset by peer)
17:03:56 --- quit: awang (Ping timeout: 245 seconds)
17:05:08 --- quit: bemeurer (Quit: WeeChat 2.1)
17:06:54 --- quit: booyah (Read error: Connection reset by peer)
17:08:03 --- join: booyah (~bb@193.25.1.157) joined #osdev
17:08:33 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
17:11:27 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
17:13:01 --- quit: awang (Ping timeout: 260 seconds)
17:18:18 --- quit: `Guest00000 (Ping timeout: 276 seconds)
17:23:34 --- quit: JonRob (Quit: Lost terminal)
17:25:00 --- join: quc (~quc@host-89-230-169-99.dynamic.mm.pl) joined #osdev
17:27:55 --- join: SwiftMatt (~Objective@2601:282:4300:3e:ad83:f5a8:ce85:a1dc) joined #osdev
17:34:36 --- join: Naergon (~Naergon@94.197.120.99.threembb.co.uk) joined #osdev
17:41:30 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
17:56:23 --- quit: Kimundi__ (Ping timeout: 248 seconds)
17:57:33 <pounce> me: ok LLVM, `mov rax, $1`, but $1 has to be an immediate or register... LLVM: `mov rax, cl` me: damn it
17:58:16 <Mutabah> Well, it picked a register
17:58:32 <Mutabah> Possibly also a smaller option too
17:58:50 <pounce> yeah, It's right it just doesn't compile
17:58:57 <Mutabah> Oh? wait, what?
17:59:31 <pounce> "error: invalid operand for instruction" so my compiler complains, at least
18:00:11 <Mutabah> try with `movz` (Or whatever the zero-extend opcode is)
18:01:26 <pounce> that works \o/ (`movzx`)
18:02:19 --- quit: quc (Ping timeout: 240 seconds)
18:03:25 <pounce> I mean, it'll probably try to fail to compile if I give it a 64bit operand, but I'm not planning on doing that
18:03:56 <Mutabah> I assume the input is an 8-bit literal?
18:03:57 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
18:04:20 --- quit: bork (Ping timeout: 252 seconds)
18:04:59 <geist> also is your syntax left to right or right to left?
18:05:09 <geist> the original instruction only makes sense right to left
18:05:10 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
18:10:47 <doug16k> pounce, it's not right. the destination is on the right
18:12:24 <doug16k> mov $1,%rax would be a wasteful way to put 1 into rax. mov $1,%eax would be good and would do the same thing with 1 less byte
18:12:27 --- quit: awang (Ping timeout: 240 seconds)
18:12:50 <geist> yah i'm assuming a decent assembler would pick the lesser version
18:13:14 <Mutabah> doug16k: From the syntax, I'd assume it's in intel mode
18:13:17 <doug16k> geist, yeah that thought crossed my mind. does it though?
18:13:24 <pounce> yeah it's intel
18:13:25 <doug16k> Mutabah, the $ though?
18:13:33 <Mutabah> doug16k: Referencing an inline assembly parameter
18:13:46 <doug16k> that would be %
18:14:13 <froggey> LLVM inline asm is different and uses $
18:14:16 <Mutabah> I _think_ llvm accepts either
18:14:24 <Mutabah> Or clang translates gcc into llvm
18:14:52 <pounce> in mine it only accepts $
18:15:29 <froggey> yeah, clang translates it. there are some other differences beyond % vs $
18:16:09 <doug16k> geist, gnu assembler doesn't drop rex -> https://godbolt.org/g/inrwgB
18:16:10 <bslsk05> ​godbolt.org: Compiler Explorer
18:16:33 <doug16k> I agree though, it should
18:17:24 <pounce> I like right to left asm >.>
18:17:41 <Mutabah> Ditto
18:17:50 <Mutabah> 1. it's intel's way, 2. it's the same order as C
18:17:55 <doug16k> I like asm that is not the opposite of 99.999% of the code/headers out there
18:17:57 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
18:17:59 <Mutabah> 3. arm also does it that way
18:18:17 --- quit: nur (Quit: Leaving)
18:18:26 <Mutabah> Also makes it easier to scan for the assignment of a variable
18:18:36 <Mutabah> s/variable/register/
18:19:37 <izabera> halp
18:19:50 <izabera> 409e5d85: 8b 0d 8c f7 d5 78 mov 0x78d5f78c,%ecx
18:19:52 <izabera> 409e5d8b: e9 70 a2 61 bf jmp 0x0
18:19:54 <izabera> 409e5d90: b9 f0 d4 fe f7 mov $0xf7fed4f0,%ecx
18:19:56 <izabera> that jmp
18:19:59 <izabera> i don't understand
18:20:07 <izabera> that's not jmp 0
18:20:33 <_mjg_> it probablly waits for relocation
18:20:40 <izabera> oooooooooooooh
18:20:45 <izabera> but
18:21:07 <izabera> still stupid
18:21:41 <doug16k> 0x409e5d90 + 0xbf61a270 = 0x100000000 which is zero if you truncate it to 32 bits
18:22:26 <izabera> _mjg_: doug16k just said that you're a dumbass
18:22:35 <izabera> doug16k: stop insulting _mjg_
18:22:40 <froggey> add the -r to objdump, it'll include any associated relocations
18:23:11 --- join: saml__ (~saml@cpe-72-229-235-241.nyc.res.rr.com) joined #osdev
18:23:43 <izabera> thank you guys
18:23:55 <doug16k> if it is 64 bit, then it is adding 0xffffffffbf61a270, which also equals zero
18:24:06 <izabera> it's 32 bit
18:24:07 --- quit: awang (Ping timeout: 248 seconds)
18:26:20 <Mutabah> izabera: Yeah... don't, that was a valid initial assumption
18:26:33 <pounce> >no print statement: panic. print statement: no panic
18:26:45 <pounce> I got myself a race condition, it looks like
18:27:07 <doug16k> izabera, if you objdump object files you'll get strange zeros for external symbols
18:27:20 <izabera> yeah
18:27:24 <pounce> if I trigger a software interrupt are interrupts disabled until the next iretq?
18:27:24 <izabera> i know that
18:27:34 <Mutabah> izabera: Does look odd, maybe it's a relocation funny? What's the original code?
18:27:36 <doug16k> pounce, only if it is an interrupt gate in the IDT
18:27:43 <Mutabah> pounce: depends on the IDT entry type
18:27:44 <izabera> that's jitted code
18:27:58 <lkurusa> good evening!
18:28:27 --- quit: saml__ (Remote host closed the connection)
18:28:28 <pounce> but by default it's disabled, right?
18:28:34 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
18:28:37 <latentprion> pounce: It depends on how you configure the idt
18:28:38 <doug16k> pounce, there is no default
18:28:57 <doug16k> it reads the gate type from the IDT
18:29:12 <doug16k> if you mean in real mode, then no, it doesn't disable interrupts
18:29:45 <pounce> I'm in x64 and my idt entry has bit 8 set to 0
18:31:56 <doug16k> bit 8 is an odd way to describe it, but yes, if that's 0 it is going to disable interrupts
18:32:23 <doug16k> it's bit 40 of the entry, starting from the beginning of the entry
18:32:44 --- join: sympt (~sympt@209.58.139.34) joined #osdev
18:34:09 <pounce> huh, don't know where this race condition is coming from then
18:34:26 <doug16k> and it isn't until iretq, it's until eflags is loaded with a value that has bit 9 set. if you load the original eflags by iretq without changing it then it will restore the interrupted code's interrupt flag
18:34:47 --- quit: epony (Quit: QUIT)
18:35:05 <doug16k> you could switch to another stack and iretq another context that had interrupts disabled, and it would restore that eflags value
18:36:27 --- quit: tacco| ()
18:37:36 --- quit: SwiftMatt (Ping timeout: 276 seconds)
18:38:34 --- quit: promach2 (Quit: WeeChat 2.1)
18:38:54 <pounce> makes sense
18:39:18 <pounce> Also yep, `movzx` failed to compile given an immediate XwX
18:40:05 <doug16k> mov to a 32 bit register already zero extends it to 64 bits
18:40:23 <doug16k> any write to a 32 bit register zero extends it, not just mov
18:40:27 * variable pounc es on dom96
18:40:35 <variable> * doug16k
18:41:18 <doug16k> mov to a 16 or 8 bit destination preserves all of the upper bits, all the way to bit 63
18:41:34 <doug16k> mov or any result write*
18:43:21 <geist> it's a bit irregular in the 8 and 16 cases but they had to maintain compatibility, but the zeroing effect of a 32bit op on the upper bits is a fairly common pattern for other 32/64 arches too
18:43:27 <geist> like arm64, or powerpc64
18:43:37 <variable> geist: https://pbs.twimg.com/media/Dd7uB8QU8AEcIBl.jpg:large
18:43:48 <geist> works fairly well, if the code doesn't know that there are additional bits, they just get silently zeroed (or sign extended in some cases)
18:44:08 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
18:44:49 <geist> i think in the case of ppc32 and 64 that's almost entirely the difference. i think there's a mode bit that needs to be set to tell it to set condition flags on bit 33 vs 65
18:44:51 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
18:45:06 <geist> in the case of riscv32 and riscv64 it looks like the 64bit ISA is purely just additional instructions
18:45:20 <geist> you can run 32bit riscv code on a 64bit machine and the 32bit code just doesn't know the registers keep going
18:45:35 <geist> very clean
18:46:33 <doug16k> geist, then how do you disambiguate loading a zero extended vs a sign extended immediate?
18:47:06 <doug16k> requires a gigantic immediate to load a full-width value?
18:47:10 <geist> if it's 32bit it doesn't matter, if it's 64bit it's a different load instruction
18:47:24 <geist> arm64 has the same thing. there's an unsigned and signed 32bit load
18:47:29 <doug16k> ah
18:47:37 --- quit: frolv (Remote host closed the connection)
18:47:50 <geist> really same with 16 and 8 bit loads too
18:50:19 <doug16k> I always found it odd how intel never had an encoding for smaller immediates for 32 bit destination. you'd think they'd make mov as good as possible, given how often it's used
18:50:54 <doug16k> for mov I mean. I know the arithmetic instructions can take a 1-byte immediate
18:52:58 <pounce> mov is the only instruction you need
18:53:03 <pounce> I'm going to write an OS in mov
18:53:17 <doug16k> yeah, if you cheat and use signals for control transfer :)
18:53:27 <latentprion> network drivers are just MOV instructions over a wirw
18:53:29 <latentprion> *wire
18:53:48 <latentprion> GPU drivers are just MOV instructions to a framebuffer
18:53:49 <pounce> (yeah, I'm not sure how to actually do it on bare metal, because you'd need to at least have a lidt)
18:54:01 <doug16k> don't get me wrong, the mov-only compiler is awesome, but it does cheat a bit, for obvious reasons
18:54:27 <latentprion> A mouse driver is just a MOV instruction from the laser to the GFX server
18:54:51 <latentprion> I'm seeing your innovation here
18:55:05 <latentprion> "Everything is a MOV"
19:09:52 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
19:10:07 --- quit: adam4813 (Quit: Connection closed for inactivity)
19:11:07 <_mjg_> https://lists.freebsd.org/pipermail/svn-src-all/2018-May/164318.html
19:11:09 <bslsk05> ​lists.freebsd.org: svn commit: r334197 - head/sys/kern
19:11:23 <stephennnn> ughhhhhhhhhhhhhh
19:11:26 <stephennnn> I don't think my GDT works
19:11:50 <stephennnn> I stumbled upon the weirdest bug, and commenting out a big array I'm not using right now fixes it
19:11:56 <stephennnn> So I think I've ran out of memory
19:12:32 <Mutabah> You're using a custom bootloader?
19:12:53 <stephennnn> Yes
19:13:03 --- quit: awang_ (Ping timeout: 245 seconds)
19:13:46 <stephennnn> wait a minute, all is not lost I don't think
19:14:41 <stephennnn> yaay
19:14:50 <stephennnn> So I was only loading 31 sectors from the bootloader
19:14:59 <stephennnn> And it turns out my kernel grew above that size
19:15:07 <stephennnn> So the problem was that some of my kernel wasn't loaded to memory
19:15:41 <Mutabah> yep!
19:15:55 <Mutabah> This is another reason to use a pre-made bootloader when early in a project
19:16:34 <stephennnn> Today I made my very own font
19:16:47 <stephennnn> In GIMP, and then I wrote a python program to convert it into a bit map
19:20:04 --- join: matlock (~matlock@2600-6c5a-6e7f-e7d2-21f8-e620-6dd4-59fe.dhcp6.chtrptr.net) joined #osdev
19:20:48 --- quit: ptx (Ping timeout: 265 seconds)
19:22:40 --- join: ptx (~ptx@563400ad.rev.stofanet.dk) joined #osdev
19:26:36 --- join: zlsyx (~zlsyx@193.2.224.100) joined #osdev
19:26:36 --- quit: JusticeEX (Ping timeout: 260 seconds)
19:29:17 <promach_> bcos: are you there ? Someone told me : For fork(), having the writing process of your program wait on the child (reading process) before exiting itself
19:29:29 <promach_> would this work ? and if it will, how do I implement this ?
19:29:35 <doug16k> stephennnn, there are tools that can produce a font texture atlas, here's an example: https://github.com/andryblack/fontbuilder It has unicode support, supports optimizing/packing the glyphs in the texture, and produces a metadata file that you can use for kerning and locating glyphs
19:29:36 <bslsk05> ​andryblack/fontbuilder - Bitmap font generator (74 forks/271 watchers)
19:30:00 <stephennnn> Oh well, too late now :)
19:30:44 <Mutabah> promach_: I'd suggest doing some research into that concept, there's plenty of samples on the internet
19:30:55 <Mutabah> Instead of asking one person who may or may not be awake
19:31:14 --- quit: zeus1 (Ping timeout: 252 seconds)
19:35:27 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
19:35:31 --- quit: matlock (Ping timeout: 260 seconds)
19:39:43 --- quit: MDude (Ping timeout: 264 seconds)
19:39:45 --- quit: zlsyx (Quit: Leaving...)
19:44:00 --- join: MDude (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
19:46:01 --- quit: Naergon (Ping timeout: 245 seconds)
19:48:26 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
19:49:52 <pounce> >comparison instead of assignment < well that's probably the error
19:51:19 --- quit: millerti (Ping timeout: 240 seconds)
19:55:57 --- quit: JusticeEX (Ping timeout: 240 seconds)
20:04:33 --- join: Jmabsd (~jmabsd@pcd247152.netvigator.com) joined #osdev
20:04:53 --- quit: variable (Quit: /dev/null is full)
20:06:19 --- quit: awang_ (Ping timeout: 260 seconds)
20:12:11 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-qauapigjfjljnuth) joined #osdev
20:13:18 --- join: dengke (~dengke@60.247.85.82) joined #osdev
20:15:48 <pounce> Ok I'm getting a double fault from a page fault with the write bit set and faulting address at 0x21ff0 and the faulting instruction is a call... None of those things should be possible
20:16:02 <Mutabah> Did you set `nx`?
20:16:14 <Mutabah> correct permission level?
20:16:25 <pounce> nx is set and I'm all in ring 0
20:16:33 <Mutabah> The DF sounds like a fun one, bad stack?
20:16:53 <pounce> I have a separate stack for my df
20:17:07 <geist> back stack
20:17:21 <geist> the call pushes a value o the stack, which then trips a write page fault, which then can't, so it DFs
20:17:26 <geist> bad even
20:19:50 <pounce> Even if I give myself more stack it happens
20:19:56 <pounce> oh, this could very much be in a new thread's stack
20:20:44 <pounce> wow, thanks geist giving my thread a bigger stack fixes it
20:20:50 --- quit: Jmabsd (Quit: Leaving)
20:21:06 <pounce> and omg Rust uses a lot of stack space to print stuff
20:21:26 <bcos> pounce: You should be able to see what "return ESP/RSP" was in the #DF handler
20:21:50 <pounce> the #DF handler doesn't run >.>
20:22:19 <bcos> pounce: You should be able to see what "return ESP/RSP" was in the emulators logs :-)
20:22:29 <pounce> I bet I set up the tss wrong >.<
20:22:55 <pounce> but yeah, it makes sense now why the faulting address was in the lower half because my stacks are
20:23:20 <bcos> You can almost guarantee ESP would have been 0x21FF0 though I guess
20:23:39 <promach_> bcos: hi
20:23:40 <pounce> bcos: (rsp == cr2)
20:23:47 <pounce> yep
20:23:58 <bcos> promach_: Hi :-)
20:24:07 <bcos> pounce: I'm confused now - a TSS, and RSP?
20:24:57 <pounce> I mean, the fact that this isn't the first time my #DF isn't being handled and I'm triple faulting probably goes to show that I didn't set up the TSS right
20:25:08 <pounce> or something else in my #DF handler
20:25:13 <bcos> Hrm - you meant "bad IST (in the TSS)"?
20:25:57 <pounce> yeah, that might be happening
20:26:01 <bcos> Anyway; would fix the double fault problem before trying to fix the page fault problem :-)
20:26:15 --- quit: elderK (Ping timeout: 248 seconds)
20:26:47 <pounce> fixing the page fault problem is just not having Rust print out stuff >.<
20:27:49 <lachlan_s> Haha, using the power of proc macros in rust to make my life easier:
20:27:49 <lachlan_s> https://gist.github.com/lachlansneff/50400aa5e8a85599db144053d29ad2ca
20:27:51 <bslsk05> ​gist.github.com: process_crate.rs · GitHub
20:31:12 <pounce> is your `Result<T>` like a normal `Result<(), T>`?
20:31:53 <promach_> bcos: sorry for jumping in. it appears that Xillybus intermediate FIFO could easily overflow with such huge amount of bytes from a single write() call
20:36:04 <lachlan_s> pounce: Yeah, it's defined in my `nabi` crate
20:36:27 <lachlan_s> Here's a shorter example: https://gist.github.com/lachlansneff/18fd644462adc2a815a63bfc14b4765d
20:36:28 <bslsk05> ​gist.github.com: output_test.rs · GitHub
20:37:14 --- join: awang_ (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
20:37:43 <pounce> are those functions you can call from wasm?
20:37:46 <lachlan_s> Yep
20:38:17 <bcos> promach_: Apparently the driver's buffers are configurable (sized determined at boot or something)
20:38:45 <bcos> pounce: ..but "write()" should never overflow the buffer - instead, the write should write what it can and then block and wait to write the rest
20:39:12 <pounce> ah cool, what's the attribute for?
20:39:24 <bcos> Attribute?
20:39:29 <pounce> promach_: ^^
20:39:43 --- quit: sympt (Remote host closed the connection)
20:39:48 <latentprion> Web ASM
20:39:56 <pounce> bcos: I think you pinged the wrong pounce :p
20:40:11 <bcos> Yes - tab completion fail :-)
20:40:17 <latentprion> I looked and behold, not one man upright in a thousand was among the web development community
20:40:43 <pounce> how does it change the function? I've been thinking about looking into attributes for some stuff in ESALP
20:41:05 <pounce> (or does it just export it so it's visible in wasm's function table)
20:41:10 <lachlan_s> pounce: It wraps the defined function, in another function that converts the result to a `u64`.
20:41:11 <latentprion> Lo, they corrupted themselves with java plugins and webgl
20:41:19 <lachlan_s> It doesn't put it in the wasm function table yet
20:41:26 <lachlan_s> That'd be nice, but more complicated
20:41:45 <promach_> bcos: driver's buffers are configurable ? <-- how do you know this ?
20:41:58 <pounce> did you have to write a compiler plugin to do it? How do you get those working?
20:42:07 --- quit: awang_ (Ping timeout: 264 seconds)
20:42:23 <lachlan_s> It's actually not too bad
20:42:30 <lachlan_s> one sec
20:42:51 <bcos> promach_: That "Xillybus host application programming guide for Linux" you linked to yesterday mentioned it somewhere
20:44:06 * pounce disappears back into triple-fault land
20:44:58 <promach_> bcos: ok, I will have to finish reading it then
20:45:04 <bcos> :-)
20:45:54 <lachlan_s> pounce: https://github.com/nebulet/nebulet/blob/master/lib/nebulet-derive/src/lib.rs
20:45:56 <bslsk05> ​github.com: nebulet/lib.rs at master · nebulet/nebulet · GitHub
20:46:02 <lachlan_s> There's the proc-macro implementation
20:47:35 <bcos> promach_: It was on page 19 - the paragraph starting with "The DMA buffers are allocated when the Xillybus driver is loaded (typically early in the boot process) and ...."
20:48:54 <pounce> it's too late at night for this magic
20:49:32 <promach_> bcos: ok
20:51:32 <lachlan_s> pounce: It's never too late for magic!
20:52:27 --- quit: drakonis (Remote host closed the connection)
20:53:39 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
20:54:35 * pounce baps his threads
20:54:39 <pounce> no! this is not how you cooperate
20:54:50 <pounce> if you keep acting like this I'll preempt you both
20:54:51 <Mutabah> Is one doing `for(;;);`?
20:55:30 --- quit: nj0rd (Ping timeout: 268 seconds)
20:55:39 <pounce> (I'm implementing thread_sleep, and for some reason they're getting two time slices per sleep instead of one)
20:55:56 <lachlan_s> I should probably do that, hmm
20:56:00 <lachlan_s> Do you have events yet?
20:57:11 <pounce> instead of a -> b *pause* -> a -> b... it's a -> b *pause* b -> a *pause* a -> b
20:57:33 <pounce> I have preempting
21:03:15 --- quit: korans (Ping timeout: 260 seconds)
21:06:39 <geist> i should fiddle around wit hthat little 386 system i was piddling wtih the other day
21:06:50 <geist> was thinking of using TSS for lulz
21:07:59 <bcos> geist: "fully cooperative, using hardware task switching" (so a process can just JMP to another, with no scheduler...)
21:09:55 <geist> sure
21:10:34 --- join: nj0rd (~nj0rd@i577BC00B.versanet.de) joined #osdev
21:11:17 --- join: sympt (~sympt@209.58.135.74) joined #osdev
21:16:25 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:18:12 --- quit: cirno_ (Client Quit)
21:18:25 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:21:26 --- join: sympt_ (~sympt@209.58.135.72) joined #osdev
21:24:22 --- quit: sympt (Ping timeout: 245 seconds)
21:30:57 --- quit: cirno_ (Remote host closed the connection)
21:31:43 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:33:19 --- quit: doug16k (Ping timeout: 240 seconds)
21:36:27 <promach_> bcos: on page 42, "This delay varies, but the overall design guarantees that a FIFO of 512 words will not overflow". My hardware FPGA device could not afford such large 512*128 fifo, it won't be able to fit into my fpga
21:37:54 <bcos> I guess it's lucky that FIFO is in host RAM's (in kernel space) then...
21:38:19 <promach_> bcos: FIFO is in fpga hardware, while DMA buffer is in host RAM
21:38:36 <bcos> Ok
21:40:08 <bcos> Mostly you've got up to three "FIFO buffers" - one in user-space (optional, potentially huge), one in kernel space (potentially 1 GiB) and one in the FPGA (likely tiny)
21:41:02 <bcos> ..with flow control between buffers (read() and write() that block, flushing, etc) to ensure that user-space never has to care about overflowing the tiny buffer in the FPGA
21:42:25 <pounce> sleeping is sort of working \o/
21:42:30 <pounce> which means I must... sleep
21:46:30 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
21:47:25 <bcos> pounce: Did you test if waking up after sleeping works? You wouldn't want to sleep forever..
21:48:07 <promach_> bcos: how is "user-space buffer" different from "kernel-space buffer" ?
21:48:21 <bcos> It's in user-space, not in kernel-space .. :-)
21:48:38 <promach_> what ?
21:49:04 <promach_> bcos: do I really need both "user-space buffer" and "kernel-space buffer" ?
21:49:48 <bcos> Kernel space buffers have to be "physically contiguous" (due to restrictions in the FPGA's DMA engine) and must be smaller than kernel space (e.g. smaller than 1 GiB if its a 32-bit system); and user-space buffers have neither of these restrictions
21:50:37 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
21:50:42 <pounce> bcos: yes :D I tested having two different threads sleep and wake up and print stuff, I also had my main thread sleep for the maximum amount of time and then wake up
21:50:49 <bcos> Heck - user-space buffer count be in swap space (don't even need actual RAM for that..)
21:50:53 <bcos> *could be
21:51:05 <pounce> so it sort of looks like "A B A B A B ........ kernel thread woke up .... A B A B A B"
21:51:12 <pounce> very exciting stuff XwX
21:51:25 <bcos> pounce: Cool :-)
21:51:27 <pounce> I made a delta queue like it says on the wiki
21:52:20 <pounce> (also I think this means I'm becoming Eleanore Semaphore)
21:53:24 --- join: xuzhongxing[m] (xuzhongxin@gateway/shell/matrix.org/x-ksxfwovlgwkrvbel) joined #osdev
21:54:07 <bcos> pounce: I wouldn't pay much attention to those "developer archetypes" wiki pages - an OS needs everything, so sometimes you'll be Eleanore and sometimes you'll be one of the others
21:54:41 <promach_> Kernel space buffers have to be "physically contiguous" <-- I am not quite sure about this since Xillybus DMA could be scatter-gather
21:55:16 <pounce> will keep that in mind :p
21:55:28 <promach_> bcos: and why is "user-space buffer" optional as you have mentioned ?
21:56:16 <bcos> pounce: Page 19 of the guide - "A potential problem with huge buffers is that since the DMA buffers are seen directly by hardware, they must occupy continous segments of physical RAM"
21:56:33 <bcos> ^ I assumed "no scatter gather" because of that
21:56:56 --- join: BartAdv (uid90451@gateway/web/irccloud.com/x-fcodazcthtqpafip) joined #osdev
21:57:33 --- join: oaken-source (~oaken-sou@p5DDB57F4.dip0.t-ipconnect.de) joined #osdev
21:57:36 <bcos> promach_: Realistically; if you have scatter gather, then you can DMA data directly from user-space to device - you don't need any buffer in kernel-space
21:59:20 <bcos> D'oh
22:00:03 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
22:00:05 <bcos> promach_: For "why is user-space buffer optional", see page 20 - the section that starts with "Fortapplications that require buffers larger than 512 MiB, it's recommended to do some of the buffering in user space RAM."
22:00:14 <bcos> *For applications
22:00:20 --- quit: pounce (Quit: WeeChat 2.1)
22:00:44 <promach_> bcos: ok
22:00:56 <promach_> I will read page 19 and 20 after my meal ;)
22:00:57 --- quit: cirno_ (Remote host closed the connection)
22:01:01 <bcos> :-)
22:01:32 <bcos> promach_: If you're only dealing with < 1 MiB of data (512*512*3 = 768 KiB) then you probably won't need user-space buffer
22:01:36 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
22:01:57 --- part: xuzhongxing[m] left #osdev
22:02:25 <Mutabah> promach_: are you implying that you haven't read the entire document?
22:03:26 <Mutabah> usually, you need to read a spec doc like that multiple times - Once to get an idea of where everything is and roughtly how to drive it, again once you have a draft implementation (to check for anything you didn't understand the first time around), and then every time something goes wrong (to find the quirk you forgot to account for)
22:05:23 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
22:30:53 --- quit: cirno_ (Quit: WeeChat 2.1)
22:32:54 --- join: xuzhongxing[m] (xuzhongxin@gateway/shell/matrix.org/x-ksxfwovlgwkrvbel) joined #osdev
22:41:03 --- quit: freakazoid0223 (Quit: Download IceChat at www.icechat.net)
22:43:02 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
22:49:51 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
22:52:57 --- join: MDead (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
22:53:48 --- quit: Guest89814 (Changing host)
22:53:49 --- join: Guest89814 (uid129469@unaffiliated/condy) joined #osdev
22:53:49 --- quit: Guest89814 (Changing host)
22:53:49 --- join: Guest89814 (uid129469@gateway/web/irccloud.com/x-xighgxdkfclpflty) joined #osdev
22:53:56 --- quit: MDude (Ping timeout: 245 seconds)
22:53:58 --- nick: MDead -> MDude
22:54:03 --- nick: Guest89814 -> Youmu
22:58:02 --- join: drsn0w (~drsn0w@unaffiliated/drsn0w) joined #osdev
23:11:58 --- quit: awang (Ping timeout: 256 seconds)
23:24:02 --- quit: lachlan_s (Quit: Connection closed for inactivity)
23:27:32 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
23:28:12 <promach_> bcos Mutabah: the code is stucked at https://gist.github.com/promach/9d185d35a6e6db0da10992a19c36f754#file-host-cpp-L273 forever ....
23:28:14 <bslsk05> ​gist.github.com: C++ test code of HLS computation kernel for both Xillybus and RIFFA PCIe framework · GitHub
23:28:22 --- quit: variable (Client Quit)
23:29:03 <promach_> due to read() which does not seem to return :|
23:30:00 <Mutabah> That read will only complete when there's data to read (I assume)
23:30:16 <Mutabah> or, when something interrupts it (e.g. a signal)
23:30:26 --- quit: sympt_ (Remote host closed the connection)
23:30:55 --- join: sympt (~sympt@209.58.135.72) joined #osdev
23:31:13 <promach_> this is really an ugly bug to chase for read() since it might involve my fpga hardware logic bug OR anything in between FPGA and this read() in this piece of cpp code
23:31:48 <bcos> Can you set the fd to "non-blocking"?
23:32:14 <Mutabah> or set a timeout on it (maybe using an alarm signal?)
23:32:16 --- quit: sympt (Read error: Connection reset by peer)
23:32:29 <promach_> ok
23:40:12 <promach_> bcos: which fd ?
23:40:30 <Mutabah> promach_: which one do you think?
23:40:34 <promach_> fdr ?
23:40:56 <promach_> if it is yes, then I have almost similar result
23:41:11 <promach_> non-blocking does not seem to solve the problem
23:41:35 <Mutabah> It's possible that the driver doesn't support nonblocking operation - maybe check its documentation for confirmation?
23:42:11 <promach_> read() failed: Resource temporarily unavailable
23:42:13 <promach_> *** Write process enters waiting status .....
23:42:15 <promach_> *** write process detects read process with pid 13919 was done ***
23:43:10 <promach_> same situation. read() can't receive all pixels back
23:46:02 <promach_> Mutabah: see slide 3 of https://goo.gl/6VcecM
23:46:03 <bslsk05> ​goo.gl: FPGA Overlay - Google Slides
23:48:14 <promach_> _mjg_ : in this case of read() not returning, is it time to use systemtap probe ?
23:49:42 <_mjg_> dawg, there was prtty serious confusion when you asked your question
23:50:00 <_mjg_> in particular you asserted that the process doing read *disappears*
23:50:29 <promach_> _mjg_ : sorry about saying that "the process doing read *disappears* "
23:50:32 <_mjg_> with the assertion being proven false after several attempts to sanity check the state
23:50:41 <_mjg_> with this in mind
23:50:55 <_mjg_> systemtap is a rather advanced tool for somewhat deeper inspection
23:51:11 <_mjg_> i highly recommend you *don't* try it out as you don't have any need in the first place
23:51:27 <_mjg_> basically it's not for programming beginners
23:51:29 --- quit: oaken-source (Quit: leaving)
23:51:41 <promach_> I see, okay
23:51:44 --- join: oaken-source (~oaken-sou@p5DDB57F4.dip0.t-ipconnect.de) joined #osdev
23:51:50 <_mjg_> perhaps i should not have suggested it without further tinkering
23:51:53 --- quit: Dreg (Quit: Dreg)
23:51:57 <_mjg_> regardless, see ^^
23:52:32 <_mjg_> what you should play with is strace
23:52:33 --- join: Dreg (~Dreg@fr33project.org) joined #osdev
23:52:54 <promach_> strace affects my final result
23:53:06 <_mjg_> i mean in general
23:53:12 <_mjg_> not for this particular assignment
23:53:19 <promach_> ok
23:55:51 --- join: zeus1 (~zeus@197.239.5.20) joined #osdev
23:58:13 <promach_> Mutabah bcos : how should I proceed with locating this bug ?
23:58:31 --- quit: oaken-source (Ping timeout: 245 seconds)
23:59:59 --- log: ended osdev/18.05.24