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=22

Tuesday, 22 May 2018

00:00:00 --- log: started osdev/18.05.22
00:00:51 --- quit: cirno_ (Remote host closed the connection)
00:01:02 --- join: sixand1 (~Thunderbi@113.201.117.110) joined #osdev
00:01:29 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:01:49 --- quit: sixand (Ping timeout: 245 seconds)
00:02:33 --- quit: Neo (Read error: Connection reset by peer)
00:04:02 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
00:05:07 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
00:05:19 --- quit: sixand1 (Ping timeout: 240 seconds)
00:05:40 --- quit: sdk93 (Quit: Connection closed for inactivity)
00:06:47 --- quit: zeus1 (Ping timeout: 256 seconds)
00:09:12 --- quit: sprocklem (Quit: [])
00:09:32 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
00:11:53 --- quit: NaNkeen (Ping timeout: 256 seconds)
00:12:45 --- quit: DeepIO (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
00:13:28 --- join: DeepIO (~DeepIO@dyndsl-085-016-234-254.ewe-ip-backbone.de) joined #osdev
00:13:29 --- quit: DeepIO (Max SendQ exceeded)
00:14:52 --- quit: elevated (Quit: bye)
00:16:22 --- mode: ChanServ set -o klange
00:18:28 --- join: NaNkeen (~nankeen@122.0.31.67) joined #osdev
00:23:58 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
00:30:52 --- quit: cirno_ (Remote host closed the connection)
00:31:31 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:33:02 --- join: bauen1 (~bauen1@ANancy-655-1-125-134.w90-6.abo.wanadoo.fr) joined #osdev
00:35:22 --- quit: adam4813 (Quit: Connection closed for inactivity)
00:38:18 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
00:39:42 --- join: DeepIO (~DeepIO@dyndsl-085-016-234-254.ewe-ip-backbone.de) joined #osdev
00:39:59 --- quit: DeepIO (Client Quit)
00:44:54 --- quit: S_Gautam (Quit: Page closed)
00:50:29 --- join: zeus1 (~zeus@197.239.7.105) joined #osdev
00:52:57 --- join: quc (~quc@87.116.229.183) joined #osdev
01:00:04 --- quit: Goplat (Remote host closed the connection)
01:00:52 --- quit: cirno_ (Remote host closed the connection)
01:01:28 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
01:02:05 --- join: kimundi (~Kimundi@ip-109-40-0-68.web.vodafone.de) joined #osdev
01:02:32 --- quit: kimundi (Read error: Connection reset by peer)
01:12:57 <_mjg_> ----------------
01:12:57 <_mjg_> ffffffff813f1a30 B cpuset_root
01:12:57 <_mjg_> ffffffff813f1a38 B sigio_lock
01:12:57 <_mjg_> ----------------
01:13:01 <_mjg_> :D
01:15:58 --- quit: NaNkeen (Ping timeout: 245 seconds)
01:18:58 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
01:27:12 --- quit: oaken-source (Ping timeout: 252 seconds)
01:27:34 --- quit: Salek (Ping timeout: 252 seconds)
01:30:33 --- quit: w41 (Ping timeout: 245 seconds)
01:30:43 --- quit: return0e (Ping timeout: 264 seconds)
01:30:51 --- quit: cirno_ (Remote host closed the connection)
01:31:33 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
01:31:39 --- quit: cirno_ (Client Quit)
01:31:58 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
01:36:50 --- quit: variable (Quit: /dev/null is full)
01:41:06 --- quit: CheckDavid (Quit: Connection closed for inactivity)
01:42:41 --- quit: `Guest00000 (Ping timeout: 260 seconds)
01:42:51 --- quit: hmmmm (Remote host closed the connection)
01:55:06 --- join: sympt (~sympt@209.58.135.74) joined #osdev
01:56:02 --- join: vaibhav (~vnagare@125.16.97.122) joined #osdev
01:57:57 --- join: oaken-source (~oaken-sou@141.89.226.146) joined #osdev
01:58:32 --- quit: zeus1 (Ping timeout: 245 seconds)
02:00:51 --- quit: cirno_ (Remote host closed the connection)
02:01:38 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
02:12:18 --- join: stav (~stavvvv@athedsl-13130.home.otenet.gr) joined #osdev
02:12:29 --- join: S_Gautam (~GautamS@unaffiliated/gautams) joined #osdev
02:12:41 --- part: stav left #osdev
02:14:16 --- join: `Guest00000 (~user@37.113.160.53) joined #osdev
02:20:31 --- quit: bauen1 (Ping timeout: 256 seconds)
02:20:39 --- join: bauen1 (~bauen1@ANancy-655-1-125-134.w90-6.abo.wanadoo.fr) joined #osdev
02:25:08 --- quit: bauen1 (Ping timeout: 252 seconds)
02:30:51 --- quit: cirno_ (Remote host closed the connection)
02:31:27 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-wtzbimfwpfdkxfhc) joined #osdev
02:31:34 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
02:46:01 --- quit: hppavilion[1] (Ping timeout: 256 seconds)
03:00:52 --- quit: cirno_ (Remote host closed the connection)
03:01:27 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
03:02:25 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
03:12:42 --- quit: MindlessDrone (Ping timeout: 245 seconds)
03:15:19 --- quit: sixand (Remote host closed the connection)
03:16:02 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
03:16:47 --- join: MindlessDrone (~MindlessD@unaffiliated/mindlessdrone) joined #osdev
03:19:08 --- quit: raphaelsc (Remote host closed the connection)
03:21:04 --- quit: sixand (Remote host closed the connection)
03:24:47 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
03:26:17 --- quit: zaquest (Quit: Leaving)
03:29:09 --- join: zaquest (~notzaques@5.128.210.30) joined #osdev
03:30:51 --- quit: cirno_ (Remote host closed the connection)
03:31:29 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
03:57:42 --- quit: sympt (Remote host closed the connection)
04:00:53 --- quit: cirno_ (Remote host closed the connection)
04:01:38 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:02:20 --- quit: doug16k (Read error: Connection reset by peer)
04:05:14 --- quit: baschdel (Ping timeout: 256 seconds)
04:08:54 --- join: DeepIO (~DeepIO@dyndsl-085-016-234-254.ewe-ip-backbone.de) joined #osdev
04:08:55 --- quit: DeepIO (Max SendQ exceeded)
04:12:58 --- quit: MaryJaneInChain (Remote host closed the connection)
04:18:58 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
04:18:59 --- quit: doug16k (Max SendQ exceeded)
04:19:23 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
04:20:13 --- join: kimundi (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
04:30:52 --- quit: cirno_ (Remote host closed the connection)
04:31:28 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
04:36:24 --- quit: oaken-source (Ping timeout: 252 seconds)
04:44:22 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
04:51:57 --- quit: glfernando (Ping timeout: 276 seconds)
05:00:03 --- join: zeus1 (~zeus@197.239.7.105) joined #osdev
05:00:52 --- quit: cirno_ (Remote host closed the connection)
05:01:32 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
05:01:47 --- join: sdk93 (uid290141@gateway/web/irccloud.com/x-ckgvrrfnqzqsxxaw) joined #osdev
05:03:14 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-xcvdeiuwgostnnvk) joined #osdev
05:06:06 --- join: glfernando (~glfernand@104.132.1.76) joined #osdev
05:08:06 --- join: useruser (b29555e5@gateway/web/freenode/ip.178.149.85.229) joined #osdev
05:08:28 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
05:09:09 <useruser> Hi
05:09:17 <useruser> I have a problem with interrupts in real mode
05:09:40 --- part: pclj left #osdev
05:09:50 <useruser> I have tested the conditions just before execution of interrupt in Bochsdbg
05:09:57 <useruser> Everything is just like it needs to be
05:10:21 <useruser> But inside interrupt gets in a endless loop of undefined instructions
05:10:34 --- quit: immibis (Ping timeout: 245 seconds)
05:10:42 <useruser> I thought it's probably memory corruption in first 0x500 bytes of memory
05:11:04 --- join: oaken-source (~oaken-sou@p5DDB5171.dip0.t-ipconnect.de) joined #osdev
05:11:10 <useruser> Anyone?
05:11:51 <useruser> Nobody seems to be online . . .
05:12:05 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:13:02 <useruser> What can it be?
05:13:53 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
05:14:17 <useruser> Hey
05:14:28 <useruser> I have a problem with interrupts in real mode
05:14:38 <useruser> I have tested the conditions just before execution of interrupt 0x10 in Bochsdbg
05:14:43 --- quit: baschdel (Ping timeout: 245 seconds)
05:14:56 <useruser> But inside the interrupt it gets in the endless loop of undefined instructions
05:15:14 <useruser> I thought it's probably memory corruption in first 0x500 bytes of memory
05:15:20 <useruser> What can it be else?
05:16:26 <useruser> It actually works in 0x7C00 bootloader but after I make a far jump to 0x8000 (which contains other code) it seems to fuck up.
05:16:28 <ALowther_> Hey bud :). Your messages are here, somebody who can help will respond when they can :).
05:17:15 <useruser> Thanks for a response... I'll wait then, and try to go further on this on my own
05:18:23 <ALowther_> That sounds like a good plan. This channel has many wonderful people whom I am sure will be happy to help when they can.
05:18:57 --- quit: cirno_ (Ping timeout: 250 seconds)
05:20:15 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
05:20:39 --- quit: S_Gautam (Quit: brb - changing font?)
05:21:11 --- join: S_Gautam (~GautamS@unaffiliated/gautams) joined #osdev
05:22:54 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:28:02 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
05:30:52 --- quit: cirno_ (Remote host closed the connection)
05:31:36 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
05:36:29 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-lqmxhuniewbxmxam) joined #osdev
05:37:11 <lf94> any operating systems written in prolog? :V
05:38:51 <klange> Can't say I know of any.
05:39:05 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
05:39:36 <Love4Boobies> Not really its strong suite.
05:39:46 <Love4Boobies> suit*
05:40:12 --- quit: sixand (Ping timeout: 252 seconds)
05:40:13 --- nick: sixand1 -> sixand
05:40:30 --- quit: useruser (Quit: Page closed)
05:41:27 <Love4Boobies> It's not really natural to express an operating system solely in terms of relationships between things.
05:42:16 <Love4Boobies> (Some things can be expressed quite nicely, though.)
05:44:05 --- join: vmlinuz (vmlinuz@nat/ibm.br/x-vmciuunozdlxqcev) joined #osdev
05:44:06 --- quit: vmlinuz (Changing host)
05:44:06 --- join: vmlinuz (vmlinuz@unaffiliated/vmlinuz) joined #osdev
05:44:16 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
05:46:02 --- join: bauen1 (~bauen1@ANancy-655-1-116-21.w90-6.abo.wanadoo.fr) joined #osdev
05:46:27 --- quit: sixand (Ping timeout: 245 seconds)
05:46:27 --- nick: sixand1 -> sixand
05:55:44 --- join: mra90 (~Martin@host-85-202-159-241.sta.tvknaszapraca.pl) joined #osdev
05:55:51 --- quit: glfernando (Ping timeout: 256 seconds)
05:56:13 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
05:59:03 --- join: m3nt4L (~asvos@2a02:587:a023:f000:3285:a9ff:fe8f:665d) joined #osdev
05:59:21 --- quit: m3nt4L (Remote host closed the connection)
05:59:55 --- join: m3nt4L (~asvos@2a02:587:a023:f000:3285:a9ff:fe8f:665d) joined #osdev
06:00:07 --- quit: sixand (Ping timeout: 248 seconds)
06:00:53 --- quit: cirno_ (Remote host closed the connection)
06:01:35 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
06:01:49 --- join: jmill (~textual@2605:6000:1019:3ff:a525:7b28:4149:babe) joined #osdev
06:02:14 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
06:04:29 --- join: glauxosdever (~alex@ppp-94-64-153-168.home.otenet.gr) joined #osdev
06:20:30 --- join: Asu (~sdelang@204.15.136.77.rev.sfr.net) joined #osdev
06:23:30 --- join: light2yellow (~l2y@217.30.64.102) joined #osdev
06:30:51 --- quit: cirno_ (Remote host closed the connection)
06:31:27 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
06:44:50 --- quit: CWiz (Quit: WeeChat 2.1)
06:47:03 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:48:41 --- join: CWiz (~cipherwiz@216.21.169.52) joined #osdev
06:51:51 --- join: X-Scale (~ARM@83.223.240.120) joined #osdev
07:00:10 --- join: Kimundi_ (~Kimundi@dynip-129-217-067-155.wifi.tu-dortmund.de) joined #osdev
07:00:23 --- quit: kimundi (Ping timeout: 248 seconds)
07:00:52 --- quit: cirno_ (Remote host closed the connection)
07:01:41 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
07:03:02 --- quit: CWiz (Quit: WeeChat 2.1)
07:05:34 --- join: CWiz (~cipherwiz@216.21.169.52) joined #osdev
07:05:43 --- quit: dude12312414 (Ping timeout: 240 seconds)
07:06:38 --- quit: zeus1 (Read error: Connection reset by peer)
07:07:05 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
07:08:03 --- join: dude12312414 (None@gateway/shell/elitebnc/x-xoljkbvazgbopiqf) joined #osdev
07:09:43 --- quit: sixand (Ping timeout: 245 seconds)
07:09:44 --- nick: sixand1 -> sixand
07:09:59 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
07:10:16 --- quit: banisterfiend (Client Quit)
07:21:04 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
07:21:24 --- join: zeus1 (~zeus@197.239.1.51) joined #osdev
07:22:54 --- quit: lachlan_s (Quit: Connection closed for inactivity)
07:29:11 --- quit: MDude (Ping timeout: 248 seconds)
07:30:52 --- quit: cirno_ (Remote host closed the connection)
07:31:34 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
07:32:54 --- join: hmmmm (~sdfgsf@pool-72-79-160-158.sctnpa.east.verizon.net) joined #osdev
07:35:45 --- quit: elevated (Quit: bye)
07:42:35 --- quit: xenos1984 (Quit: Leaving.)
07:46:25 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
07:47:25 --- quit: sixand (Remote host closed the connection)
07:48:03 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
07:58:36 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
07:58:47 --- nick: promach__ -> promach2
08:00:52 --- quit: cirno_ (Remote host closed the connection)
08:01:29 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:01:38 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
08:01:49 --- quit: zeus1 (Ping timeout: 240 seconds)
08:03:54 --- join: MDude (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
08:03:56 --- join: MDead (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
08:11:30 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:14:26 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
08:15:19 --- quit: sixand (Ping timeout: 260 seconds)
08:15:20 --- nick: sixand1 -> sixand
08:19:06 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
08:21:07 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
08:21:54 --- quit: sixand (Ping timeout: 252 seconds)
08:21:54 --- nick: sixand1 -> sixand
08:24:50 --- quit: elevated (Quit: bye)
08:28:02 --- quit: nur (Quit: Leaving)
08:30:49 --- join: nur (~hussein@175.142.120.67) joined #osdev
08:30:53 --- quit: cirno_ (Remote host closed the connection)
08:31:07 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
08:31:37 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:33:37 --- quit: sixand (Remote host closed the connection)
08:34:54 --- join: sixand (~Thunderbi@219.145.113.142) joined #osdev
08:36:02 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
08:38:46 --- quit: Kimundi_ (Ping timeout: 252 seconds)
08:39:12 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
08:39:16 --- quit: Asu (Quit: Konversation terminated!)
08:39:32 --- join: Asu (~sdelang@204.15.136.77.rev.sfr.net) joined #osdev
08:41:53 --- join: zesterer (~zesterer@37.152.255.164) joined #osdev
08:42:19 --- quit: sixand (Ping timeout: 240 seconds)
08:42:19 --- nick: sixand1 -> sixand
08:45:13 --- join: zeus1 (~zeus@197.239.1.51) joined #osdev
08:45:35 --- quit: grouse (Quit: Leaving)
08:51:42 --- quit: zeus1 (Ping timeout: 268 seconds)
08:52:45 --- quit: CheckDavid (Quit: Connection closed for inactivity)
08:53:48 --- quit: MDude (Quit: Going offline, see ya! (www.adiirc.com))
08:53:57 --- nick: MDead -> MDude
08:56:57 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
09:00:24 <bauen1> klange: do you have intrest in making your bootloader capeable of booting from a harddrive ? (iso-hybrid, partition parsing)
09:00:56 --- quit: cirno_ (Remote host closed the connection)
09:01:23 <bauen1> *capable
09:09:41 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
09:12:18 --- join: Kimundi_ (~Kimundi@i577A97A3.versanet.de) joined #osdev
09:24:13 --- join: daniele_athome (~daniele_a@5.170.128.22) joined #osdev
09:24:38 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
09:31:00 --- join: dennis95 (~dennis@mue-88-130-61-041.dsl.tropolys.de) joined #osdev
09:33:37 --- nick: janemba_ -> janemba
09:35:44 --- join: zeus1 (~zeus@197.239.1.51) joined #osdev
09:36:48 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-ckrdynryemlxfrzf) joined #osdev
09:37:27 --- quit: hppavilion[1] (Ping timeout: 260 seconds)
09:41:37 --- quit: promach2 (Remote host closed the connection)
09:44:30 --- join: bemeurer (~bemeurer@185.236.200.248) joined #osdev
09:45:23 --- quit: vmlinuz (Ping timeout: 260 seconds)
09:46:57 --- quit: zeus1 (Ping timeout: 240 seconds)
09:57:43 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
09:58:58 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
10:00:58 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
10:01:31 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:01:53 --- join: nick8325 (~nick@h-141-248.A336.priv.bahnhof.se) joined #osdev
10:06:48 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
10:07:33 --- quit: BartAdv (Quit: Connection closed for inactivity)
10:20:23 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
10:24:22 --- quit: S_Gautam (Ping timeout: 252 seconds)
10:24:43 * geist wakes up, yawns
10:29:25 --- quit: nick8325 (Quit: Leaving.)
10:31:15 --- quit: vaibhav (Quit: Leaving)
10:31:57 --- join: zeus1 (~zeus@197.239.1.51) joined #osdev
10:33:07 --- quit: vmlinuz (Ping timeout: 245 seconds)
10:39:48 --- join: vmlinuz (vmlinuz@nat/ibm.br/x-cermplmudnspvrlk) joined #osdev
10:39:48 --- quit: vmlinuz (Changing host)
10:39:48 --- join: vmlinuz (vmlinuz@unaffiliated/vmlinuz) joined #osdev
10:44:10 --- quit: zeus1 (Ping timeout: 252 seconds)
10:46:24 --- quit: baschdel (Ping timeout: 245 seconds)
10:50:53 --- join: glfernando (~glfernand@104.132.0.77) joined #osdev
10:52:14 --- quit: hppavilion[1] (Ping timeout: 252 seconds)
10:55:54 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
10:56:52 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
11:02:26 --- join: return0e_ (~return0e@5-198-102-244.static.kc.net.uk) joined #osdev
11:04:22 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
11:05:36 --- quit: eremitah (Quit: quit)
11:05:36 --- nick: eremitah_ -> eremitah
11:05:48 --- join: quul (~weechat@unaffiliated/icetooth) joined #osdev
11:10:58 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
11:16:54 --- quit: lf94 (Quit: Leaving)
11:22:28 --- quit: gwoplock (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
11:24:05 --- quit: Lucretia (Remote host closed the connection)
11:25:54 --- join: gwoplock (~quassel@cpe-76-183-186-15.tx.res.rr.com) joined #osdev
11:26:41 --- join: Lucretia (~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5) joined #osdev
11:26:41 --- quit: Lucretia (Changing host)
11:26:41 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
11:27:48 --- quit: hppavilion[1] (Ping timeout: 252 seconds)
11:33:30 --- join: tacco| (~tacco@i59F4A960.versanet.de) joined #osdev
11:38:29 --- join: zeus1 (~zeus@197.239.1.51) joined #osdev
11:40:28 --- quit: drakonis (Remote host closed the connection)
11:41:46 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
11:48:03 --- quit: bauen1 (Ping timeout: 245 seconds)
11:49:44 --- quit: jmill (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:50:53 --- quit: elevated (Quit: bye)
11:53:43 --- quit: JusticeEX (Ping timeout: 260 seconds)
11:58:50 --- join: macdonag (~macdonag@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
12:00:04 --- join: bauen1 (~bauen1@ANancy-655-1-116-21.w90-6.abo.wanadoo.fr) joined #osdev
12:01:14 --- join: Asu` (~sdelang@80.83.136.77.rev.sfr.net) joined #osdev
12:04:22 --- quit: Asu (Ping timeout: 245 seconds)
12:05:19 --- quit: vmlinuz (Ping timeout: 256 seconds)
12:05:41 --- join: vmlinuz (~vmlinuz@32.104.18.202) joined #osdev
12:05:41 --- quit: vmlinuz (Changing host)
12:05:41 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
12:07:04 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:07:49 --- quit: hppavilion[1] (Ping timeout: 240 seconds)
12:11:44 --- quit: mavhq (Read error: Connection reset by peer)
12:11:49 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
12:12:57 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
12:19:12 --- join: matlock (~matlock@2600-6c5a-6e7f-e7d2-89f0-2b0f-fd25-8650.dhcp6.chtrptr.net) joined #osdev
12:20:21 --- quit: AverageJ0e (Quit: Leaving)
12:20:22 --- quit: janemba (Read error: Connection reset by peer)
12:21:00 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
12:28:31 --- quit: janemba (Read error: Connection reset by peer)
12:29:20 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
12:30:39 --- quit: janemba (Read error: Connection reset by peer)
12:31:40 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
12:35:09 --- join: xerpi (~xerpi@164.red-83-45-197.dynamicip.rima-tde.net) joined #osdev
12:35:16 <pounce> Should I not give my idle thread any stack space? (for efficiency) or would that mess things up
12:35:33 --- quit: Asu` (Ping timeout: 245 seconds)
12:37:29 <_mjg_> what efficiency
12:37:37 <_mjg_> also, what stack do you expect it to use/
12:37:54 <pounce> yeah now that I think of it I don't know how it would interrupt out if it didn't have a stack
12:38:39 <geist> the simplest thing to do is treat the idle thread like any other, and give it a kernel stack as well
12:38:58 <_mjg_> besides, as the name suggests, the idle thread can sometimes do useful work as well
12:39:03 <geist> it's possible to do some special casing for idle, but honestly i think that's a microoptimization later on
12:39:07 --- quit: davxy (Ping timeout: 264 seconds)
12:39:17 <geist> also this is all based on the idea that each kernel thread has it's own stack, which most OSes do
12:39:26 <geist> vs a stack per cpu, or a pool of stacks and continuations, etc
12:39:46 <_mjg_> a shared iidle/interrupt stack for given cpu may be viable
12:39:53 <_mjg_> but then, how much of an optimisation is it
12:40:17 <pounce> yeah, I'm not sure what's going to happen to my main kernel stack after I jump to the userspace, so I can give that to the idle thread.
12:40:39 <_mjg_> just don't play with it for the time being, there is enough breakage elsewhere 8)
12:40:44 <pounce> Since I'm saving my thread state on the kernel stack, I think it's best to keep things that way
12:41:06 <geist> well, in general the idea is the kernel stack for a thread only has data on it while the thread is in kernel space
12:41:17 <geist> once you go to user space it isn't useful at all, there's nothing saved there
12:41:40 <geist> and when you reenter the kernel via a syscall or irq the TSS/arch-specific-mechanism restores the kernel stack poitner to the top
12:41:54 --- join: davxy (~davxy@unaffiliated/davxy) joined #osdev
12:42:07 <_mjg_> info leaks are there1
12:42:28 <pounce> Do I have to change the kernel stack in the TSS every time I context switch?
12:42:52 <pounce> Right now I only have a special stack for the double fault
12:44:08 <pounce> ah... I guess if I have different userspace and kernel stacks I'd have to
12:44:26 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
12:45:57 <geist> pounce: yes
12:46:07 <geist> though technically it doesn't matter at all until you exit to ring > 0
12:46:17 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
12:46:27 <geist> but typicaklly it's just one of the things you swap when you context switch between threads, since it's just a memory write
12:46:33 <pounce> yeah I'm not going to work on that with my KThreads right now
12:46:34 --- quit: drakonis (Ping timeout: 256 seconds)
12:47:06 <geist> this is why, of course, you need a separate TSS per cpu, because each one of them is tracking a different current thread independently
12:47:41 <pounce> yep, after the scheduler, CPU local variables will be the next thing I work on
12:48:40 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
12:48:49 <pounce> I think most of the things I've worked on so far are cpu local
12:49:24 <pounce> although, now that I think about it, how do things like the PS/2 keyboard work and serial port work in SMP? Are interrupts sent to all CPUs?
12:49:37 <doug16k> pounce, re the idle thread: what do you expect to happen if an IRQ happens while the idle thread is in hlt? it will use the idle thread's stack
12:50:47 <doug16k> pounce, you control where IRQs go. if you are using PIC, all IRQs will go to the bootstrap CPU
12:50:53 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
12:51:30 <doug16k> if you are using IOAPIC or MSI, then you can send the IRQ to any CPU
12:52:08 <geist> also a thing you probably shouldn't worry about for a while. having all the irqs get delivered to cpu 0 is fine for quite some time
12:52:29 <pounce> Why isn't there an RSP3 in the tss?
12:52:32 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
12:52:51 <geist> pounce: think about it. if it consults the TSS when switching to a lower ring, then....
12:54:07 <pounce> It would make the address in the `iretq` redundant?
12:54:21 <geist> well, what ring could you switch from to get you to ring 3?
12:54:53 <doug16k> it only reads the stack pointer from the TSS when going from a higher ring (number) to a lower ring (number). ring 3 will never be a "lower ring"
12:57:14 --- join: jmill (~textual@2605:6000:1019:3ff:a525:7b28:4149:babe) joined #osdev
12:57:16 <doug16k> ring 0 can't trust ring 1 thru 3. ring 1 can't trust ring 2 thru 3, ring 2 cant trust ring 3. for this reason, it switches to a known good stack when it goes from a lower privilege (higher ring) to a higher privilege (lower ring)
12:57:56 <doug16k> so if ring 3 loads some ridiculous stack pointer that will fault, it won't explode if an interrupt or exception happens
12:58:03 --- quit: bauen1 (Ping timeout: 245 seconds)
12:59:05 <doug16k> interrupt and exception handlers MUST have a valid stack, no exceptions (pun intended)
13:00:08 --- join: bauen1 (~bauen1@ANancy-655-1-92-118.w86-197.abo.wanadoo.fr) joined #osdev
13:00:15 <pounce> heh
13:02:12 <pounce> How does one join the osdev wiki group?
13:03:00 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-bblbfkcdkcbgdlqp) joined #osdev
13:05:11 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:06:10 <sortie> pounce: Join the osdev forums and then go to your forum profile and add yourself to the osdev wiki group
13:07:56 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
13:10:09 --- quit: hppavilion[1] (Ping timeout: 245 seconds)
13:12:16 --- quit: janemba (Read error: Connection reset by peer)
13:12:45 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
13:13:58 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
13:20:59 --- quit: divine (Ping timeout: 256 seconds)
13:28:04 --- join: divine (~divine@2001:470:8247:2::1000) joined #osdev
13:34:31 --- quit: bemeurer (Quit: WeeChat 2.2-dev)
13:36:24 --- quit: oaken-source (Ping timeout: 245 seconds)
13:37:18 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
13:39:55 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
13:40:37 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:45:08 --- join: Asu (~sdelang@42.204.136.77.rev.sfr.net) joined #osdev
13:47:59 --- quit: Boreeas (Quit: User terminated)
13:50:55 --- join: sixand1 (~Thunderbi@219.145.113.142) joined #osdev
13:50:59 --- quit: sixand (Ping timeout: 245 seconds)
13:50:59 --- nick: sixand1 -> sixand
13:53:33 --- quit: hppavilion[1] (Ping timeout: 256 seconds)
13:54:48 --- quit: vmlinuz (Quit: Leaving)
13:57:03 --- quit: m3nt4L (Remote host closed the connection)
13:59:11 <geist> oh didn't know the wiki memebership was tied tot he forum
13:59:19 --- quit: quc (Remote host closed the connection)
14:00:00 <Love4Boobies> Integration level over 9000
14:00:33 --- quit: bauen1 (Ping timeout: 245 seconds)
14:00:45 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
14:03:24 <sortie> geist: Yeah it's a primitive but surprisingly effective anti-spam measure
14:13:27 --- join: SwiftMatt (~Objective@c-71-205-200-158.hsd1.co.comcast.net) joined #osdev
14:15:06 --- quit: hppavilion[1] (Remote host closed the connection)
14:15:37 --- join: hppavilion[1] (~dosgmowdo@74-114-87-80.dynamic.asdk12.org) joined #osdev
14:18:25 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
14:19:31 --- quit: glauxosdever (Quit: leaving)
14:21:36 --- quit: daniele_athome (Ping timeout: 252 seconds)
14:28:34 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
14:31:58 --- quit: baschdel (Ping timeout: 256 seconds)
14:33:57 <geist> i dont remember having to do it, but i think i registered for the wiki foreverago
14:37:36 --- quit: sortie (Quit: Leaving)
14:40:30 --- join: xiphias (~xiphffff@xiphffff.net) joined #osdev
14:43:48 --- quit: xerpi (Quit: Leaving)
14:44:39 --- quit: xiphias (Client Quit)
14:45:04 --- join: xiphias (~xiphffff@xiphffff.net) joined #osdev
14:45:39 --- join: SwiftMatt (~Objective@2601:282:4300:3e:c447:df13:e0f2:6099) joined #osdev
14:54:19 --- quit: immibis (Ping timeout: 240 seconds)
14:54:20 --- quit: Asu (Remote host closed the connection)
14:57:17 --- quit: Salek (Ping timeout: 245 seconds)
14:58:21 --- quit: dennis95 (Quit: Leaving)
14:59:04 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:04:23 --- quit: Kimundi_ (Ping timeout: 256 seconds)
15:04:56 --- quit: matlock (Read error: Connection reset by peer)
15:06:02 --- quit: macdonag (Quit: macdonag)
15:06:07 --- quit: hppavilion[1] (Ping timeout: 264 seconds)
15:06:45 --- quit: light2yellow (Quit: light2yellow)
15:07:43 --- quit: zeus1 (Read error: Connection reset by peer)
15:11:50 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
15:13:52 --- quit: adam4813 (Quit: Connection closed for inactivity)
15:18:54 --- quit: bork (Read error: Connection reset by peer)
15:21:47 --- quit: rain1 (Quit: Leaving)
15:24:21 --- quit: spare (Quit: leaving)
15:24:57 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
15:25:06 --- join: stee (~junk@66.252.139.92) joined #osdev
15:26:14 --- join: SwiftMatt (~Objective@2601:282:4300:3e:c447:df13:e0f2:6099) joined #osdev
15:27:02 --- quit: Shamar (Quit: leaving)
15:28:07 --- quit: stee3 (Ping timeout: 248 seconds)
15:31:00 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
15:33:13 --- quit: xenos1984 (Quit: Leaving.)
15:40:18 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:45:12 --- quit: stee (Ping timeout: 245 seconds)
15:46:30 --- quit: Tazmain (Quit: Leaving)
15:55:40 --- join: SwiftMatt (~Objective@2601:282:4300:3e:c447:df13:e0f2:6099) joined #osdev
15:55:58 --- join: stee (~junk@66.252.139.92) joined #osdev
16:09:06 --- join: Guest70701 (~dk@cpc103046-sgyl39-2-0-cust267.18-2.cable.virginm.net) joined #osdev
16:09:47 --- quit: Salek (Ping timeout: 245 seconds)
16:12:02 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
16:25:33 --- quit: MDude (Ping timeout: 245 seconds)
16:25:50 --- quit: Guest70701 (Quit: Mutter: www.mutterirc.com)
16:26:36 --- join: dijksterhuis (~dijksterh@cpc103046-sgyl39-2-0-cust267.18-2.cable.virginm.net) joined #osdev
16:34:32 --- quit: zesterer (Quit: Leaving)
16:34:41 --- join: MDude (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
16:37:57 --- quit: mra90 (Read error: Connection reset by peer)
16:47:27 --- join: radens` (836b9f73@gateway/web/freenode/ip.131.107.159.115) joined #osdev
16:48:11 --- join: rain1 (~rain1@unaffiliated/rain1) joined #osdev
16:52:59 --- quit: dijksterhuis (Quit: Mutter: www.mutterirc.com)
17:03:57 --- quit: awang (Ping timeout: 245 seconds)
17:04:38 --- quit: quul (Quit: WeeChat 2.0.1)
17:08:04 --- quit: AverageJ0e (Ping timeout: 245 seconds)
17:11:51 --- quit: mavhq (Read error: Connection reset by peer)
17:13:09 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
17:20:51 <exezin> for some reason, unless I set bit 7 in my page entries, qemu goes into a boot cycle
17:21:56 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
17:25:49 --- quit: lachlan_s (Quit: Connection closed for inactivity)
17:30:26 <geist> well, sounds like you should look at what bit 7 does
17:30:38 <exezin> sets large page tables right
17:30:43 <geist> i dunno, you tell me
17:30:47 <exezin> so 2MB instead of 4KB
17:30:49 <geist> i dont have the bits memorized
17:31:01 <geist> okay, so did you enable large page support?
17:31:08 <exezin> which leads me to beleive that 2MB in total of identity paging isnt enough to cover everything
17:31:18 <exezin> geist: PAE?
17:31:26 <geist> no, i think it's PSE
17:32:10 <exezin> I did not
17:32:12 <exezin> just PAE
17:32:25 * geist nods
17:32:48 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
17:33:16 <exezin> well 2MB should certainly be enough to cover everything
17:33:31 <exezin> but I start at a physical address of1MB
17:33:43 <geist> okay, so still need to enable large page support before you use 2MB pages
17:33:50 <exezin> perhaps I need to adjust for that (otherwise I'm identity-mapping the first 1MB of physical address space even though its not used?)
17:34:04 <geist> or start by enabling large page support before you use large pages
17:34:11 <exezin> I dont want to use large pages :(
17:34:18 <geist> but you were just using them
17:34:29 <exezin> I was saying that, its only large pages that work
17:34:46 <exezin> if I do normal 4KB pages, I get an endless boot cycle in qemu
17:34:51 <geist> well, time to debug it
17:34:57 <exezin> but if I enable the large pages bit in each page entry, it works fine .-.
17:35:14 <geist> so what does bit 7 mean on a terminal entry?
17:35:18 <geist> ie, a 4KB page entry?
17:35:26 <exezin> 2MB pages?
17:35:39 <geist> no, on a 4Kb page entry. does bit 7 have a different meaning?
17:36:01 <exezin> I see global on the osdev wiki
17:36:11 <geist> are you sure?
17:36:21 <exezin> wait, dirty
17:36:23 <exezin> miscounted
17:36:41 <geist> no, it's PAT
17:36:49 <exezin> what
17:37:46 <exezin> you've lost me :p
17:37:54 <geist> it's PAT. the PAT bit
17:38:03 <exezin> I see no reference to a 'PAT' bit anywhere?
17:38:04 <geist> bit 7 is the PAT bit on the last level page table entry
17:38:23 <geist> http://sandpile.org/x86/paging.htm
17:38:25 <bslsk05> ​sandpile.org: sandpile.org -- x86 architecture -- paging
17:39:01 <exezin> what am I looking at here
17:39:03 <exezin> these tables always confuse me
17:39:26 <exezin> oh I see
17:39:30 <exezin> what on earth is PAT
17:39:54 <exezin> geist: i think maybe I got lost because this is the 2nd level
17:40:14 <geist> if you set bit 7 on anything but the terminal page table level, it tries to select a large page
17:40:15 --- join: jakogut (~jakogut_@68.116.64.178) joined #osdev
17:40:25 <geist> i dunno what mode you're in or how many levels you have
17:40:27 <exezin> right, so I assume its setting a large page
17:40:30 <exezin> I have 4 levels
17:40:39 --- quit: jakogut (Remote host closed the connection)
17:40:44 <geist> dont think that's valid
17:40:48 <exezin> why?
17:41:01 --- join: jakogut (~jakogut_@68.116.64.178) joined #osdev
17:41:19 <geist> okay, what do you mean by '2nd level' in this case?
17:41:23 <geist> 2nd from top or from bottom?
17:41:34 <exezin> from the bottom, if you're going by the generic naming scheme
17:41:39 <exezin> 4th level being the root
17:41:44 <geist> then that's a 2MB page, yes
17:41:45 <exezin> or base or whatever
17:41:48 <exezin> right
17:41:59 <geist> 2nd from the top would be a 1GB page, and your cpu needs to support that, etc
17:42:03 <geist> not all do
17:42:03 <doug16k> you have to check CPUID for support for 1GB or 2MB pages
17:42:06 <exezin> so that takes me back to "maybe 2MB isnt covering enough address space in total"
17:42:22 <geist> well, debug why it crashes and you wont have to keep guessing
17:42:28 <exezin> im trying to
17:42:31 <geist> step 1: run qemu with -d int and see where your triple fault is happening
17:42:33 <doug16k> also, 2MB pages must be 2MB aligned, 1GB pages must be 1GB aligned
17:42:35 <exezin> and I've checked CPUID for the stuff I need
17:42:42 <geist> then that usually gives you some amount of hint as to why it crashed
17:42:47 <doug16k> if they aren't, you'll get a reserved-bit-set page fault
17:43:28 <exezin> I'm doing align 4096 because I'm using 4KB pages
17:43:50 <doug16k> I am referring to the physical address above when I say "aligned"
17:46:27 <exezin> doug16k: I'll make sure to align it to 4KB then
17:47:34 <doug16k> exezin, ok I think I get the confusion. you're saying large pages is working and it reboot loops when you try to use 4KB paging?
17:47:41 <exezin> correct
17:48:04 <doug16k> do you know how to attach gdb to qemu and place a breakpoint?
17:48:12 <exezin> I do not
17:48:41 <doug16k> ok, was going to suggest you place a breakpoint on the instruction after you enable paging, and in qemu monitor, do this: info tlb
17:48:49 <doug16k> it will print out your page tables to the console
17:49:11 <exezin> I see, I'll look into that
17:53:44 <pounce> I think I asked this before, but what value should I give the flags when going to a new thread? (x64)
17:54:11 <doug16k> pounce, depends on whether you want interrupts enabled
17:54:47 <pounce> I do
17:55:03 <doug16k> probably 0x202, which is IF + bit 1 which is permanently set
17:55:51 <doug16k> and that has DF=0, which is important
17:56:12 <exezin> 4KB pages work if I dont enable long mode
17:56:25 <doug16k> exezin, are your page table entries 64 bits?
17:56:31 <exezin> yes
17:56:49 <pounce> doug16k: does anybody use DF=1?
17:57:00 <pounce> What sort of instructions does that change?
17:57:01 <doug16k> pounce, yes to memmove
17:57:12 <doug16k> it makes rep string instructions go backward in memory
17:57:22 <doug16k> "direction flag"
17:57:58 <geist> theoretically the compiler could use it, but i dont know if i've ever seen it
17:58:00 <doug16k> ELF abi requires it to be zero at the entry to every function - compiler will be assuming DF=0
17:58:10 <pounce> I think for a new thread DF=0 is sane though
17:58:24 <doug16k> yes, definitely
17:59:14 <doug16k> exezin, do you know how to enter qemu monitor commands?
17:59:49 <pounce> is the `stack_segment` in the exception stack frame a TSS index?
17:59:56 <exezin> derp
17:59:59 <exezin> doug16k: figured it out
18:00:12 <exezin> its something stupid...I'll go fix it
18:00:16 <doug16k> pounce, it's a data segment
18:00:29 <exezin> anyone have a spare wall I can bang my head against
18:00:31 --- quit: promach__ (Quit: WeeChat 2.1)
18:00:36 <pounce> I don't use segmentation in my OS, do I need to worry about that?
18:00:42 <doug16k> yes
18:01:06 <pounce> :( how so?
18:01:10 <doug16k> pounce, yes in user mode you have to worry
18:01:35 <doug16k> SS DPL must == CS DPL in user mode
18:01:46 <pounce> ah makes sense
18:01:59 <doug16k> pounce, do you mean 32 bit or 64 bit though?
18:02:05 <pounce> Right now I'm just doing kthreading. x64
18:02:20 <doug16k> cpu ignores ss in ring 0 long mode
18:02:23 <exezin> it works \o/
18:02:33 <exezin> I was operating on p2 thinking it was p1
18:02:42 <exezin> because p2 basically becomes p1 if you enable large pages
18:03:00 <doug16k> exezin, the official naming of the levels is backwards
18:03:04 <geist> right, it terminates the page walk basically
18:03:14 <doug16k> I don't care what intel says, I call PML4 level 0
18:03:15 <exezin> doug16k: p1 being the 4kb
18:03:20 <geist> and yeah i hate the naming convention, i like to personally number from the top, level 0, level 1, etc
18:03:22 <exezin> p2 being 2mb, p3 being 512 something? idk
18:03:27 <exezin> oh god
18:03:29 <geist> i think of it as the order the cpu walks
18:03:35 <doug16k> geist, exactly
18:03:36 <exezin> I drew it on paper, p4 is the "one on the left" to me :p
18:03:53 <geist> that's basically what ARM does in their docs
18:04:16 <exezin> either way, my problem was if you enable large pages on p2 (my p2), then it skips the lowest level page tables and maps directly to physical chunks as if it where the lowest level page table
18:04:31 <geist> i try to never use the x86 naming convention (PDE, PMPL4, etc etc) because it tends to imply that each level is special and unique
18:04:38 <geist> they're not, really
18:04:46 <exezin> they're confusing
18:06:16 <doug16k> what's the new level called? PML5?
18:06:29 <exezin> yes
18:06:43 <doug16k> ya, so backwards. what was intel thinking
18:07:10 <exezin> p4 as the root table that cr3 points to makes sense to *me* because p4 is the "top" of the tree
18:07:30 <exezin> (yes that makes no sense, logically :p)
18:07:31 <doug16k> exezin, it makes no sense to me because it is the opposite of how it is used
18:07:50 <doug16k> the cpu first looks up in PML4, then in PDPT, then in PD, then in PT
18:07:58 <exezin> true
18:08:07 <exezin> I think it makes sense to me because I map it visually in my head from left to right
18:08:32 <exezin> and PT is sort of the primary table that actually does the physical mapping so it makes sense to me to call it 0
18:08:46 <latentprion> Hmph. Peasants.
18:08:47 <doug16k> yeah, if it even participates
18:08:49 <exezin> (as you cant go past PD, but there could always be more past PML4 (PML5 now))
18:09:44 <doug16k> you can't go past PDPT (1GB paging), and you can't go past PD (2MB paging)
18:10:07 <exezin> what about PML4/5?
18:10:19 <doug16k> you can't have 512G page
18:10:39 <exezin> oh you mean like that
18:10:42 <exezin> I mean like logically, it exists
18:11:03 <exezin> the tree doesnt extend past PT, but it does extend past PML4 with future hardware
18:11:22 <exezin> (in the other direction, that is..)
18:11:50 <doug16k> qemu has 5 level paging now
18:12:12 <exezin> thats one too many levels for me
18:12:20 <izabera> that's not even their final form
18:12:27 * exezin wishes it was
18:13:14 <doug16k> exezin, why do you call the 4KB level "level 1". don't programmers start counting at zero? :P
18:13:27 <exezin> 4 level paging suddenly becomes 3 level paging with large pages, confusing ;-;
18:13:45 <exezin> doug16k: uuh
18:14:11 <exezin> because its '4 level' paging and my mind just starts from 1 in that case lmao
18:14:29 <exezin> not big on like, counting and numbers and stuff
18:17:33 <doug16k> geist, I say PML4, PDPT, PD, PT for the same reason I spell "queue" q u e u e. it's stupid, what can you do? I only use them when I want to disambiguate the order of them :(
18:18:24 <latentprion> Wait what's wrong with spelling queue as queue
18:18:24 <exezin> now that I know people use P1-4 in the reverse order to what I use them
18:18:29 <exezin> saying PML4/etc makes sense
18:19:05 <exezin> one more step and im in *full* long mode \o/
18:20:36 <doug16k> I call PMP4 level 0, PDPT level 1, PD level 2, and PT level 3. in code you iterate 0 to 3. I can see why someone might call *that* backwards, because the address is walked in the other direction
18:20:55 <exezin> .-.
18:21:31 <exezin> Literally everyone has a different name for it, that would have been nice to know a while ago
18:21:33 <doug16k> | PLM4 | PDPT | PD | PT | 12 zeros | <-- the address, MSB on the left
18:21:53 <exezin> when I first started reading about 4-level paging, the term PML4 was confusing as hell and I found very few references online
18:21:57 <exezin> doug16k: MSB?
18:22:02 <doug16k> most significant bit
18:22:04 <exezin> oh
18:22:15 --- quit: drakonis_ (Remote host closed the connection)
18:22:45 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
18:23:44 <doug16k> I remember being confused until I realized, the PD level is like the 32 bit page directory, and PML4 was the one CR3 points to, PT obviously corresponds to the (4KB) page table, then by elimination it's obvious where PDPT goes
18:24:00 --- join: oaken-source (~oaken-sou@p5DDB5171.dip0.t-ipconnect.de) joined #osdev
18:24:08 <exezin> I had no idea that CR3 pointed to the top-most/first table initially
18:24:20 <exezin> I thought it would always point to PDPT :p
18:24:59 <exezin> it all seems so simple now that I understand it. Funny, that
18:25:30 <doug16k> reminds me of the (politically incorrect) mnemonic for the resistor colour code :)
18:25:36 --- quit: drakonis_ (Remote host closed the connection)
18:26:04 <exezin> oh god I just googled that
18:26:05 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
18:26:21 <doug16k> ... but violet gives willingly... get some
18:26:36 <exezin> good idea for a mnemonic to be honest
18:26:40 <exezin> not like you'll ever forget it
18:26:47 <doug16k> you will never forget it
18:27:11 <exezin> I still refer to the 4 cardinal directions as 'never eat shredded wheat'
18:29:07 --- quit: drakonis_ (Remote host closed the connection)
18:29:35 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
18:29:55 --- quit: oaken-source (Ping timeout: 260 seconds)
18:32:32 --- quit: drakonis_ (Remote host closed the connection)
18:32:55 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
18:33:58 <pounce> the one I learned in grade school was even worse XwX
18:35:37 <latentprion> They taught you XwX in school?
18:35:41 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
18:35:56 <pounce> yes
18:36:08 <pounce> first day we learned OwO and XwX. I've used them ever since
18:36:14 <latentprion> lol
18:36:18 <drakonis_> notices bulge
18:36:22 <drakonis_> OwO what is this
18:36:30 <pounce> the second year we learned more complex faces such as èwé
18:36:51 <pounce> and úwù
18:37:06 <latentprion> lennyface was the national exam
18:37:12 --- join: sympt (~sympt@209.58.135.120) joined #osdev
18:37:27 <pounce> oh man I still can't type than one from scratch. Same with the shruggy one
18:38:23 <doug16k> every time I see lennyface in an online game, I die a little inside
18:38:50 <graphitemaster> could be worse, could be that scary guy face
18:41:56 <pounce> I've probably written the most unsafe rust I've ever written in my life for this thread creation function
18:42:49 <drakonis_> rust can't be unsafe unless you disable the safeties
18:43:04 <pounce> yeah well this is all in a big `unsafe { ... }` block
18:43:42 --- quit: `Guest00000 (Ping timeout: 268 seconds)
18:43:56 <latentprion> "I love a man who's willing to take risks"
18:44:15 <latentprion> "You'll be happy to know I once wrote an unsafe function in Rust"
18:44:26 <pounce> oh yeah, and the unsafe block returns an unbounded lifetime
18:44:50 <pounce> so it's more like `let foo: &static _ = unsafe { ... }`
18:45:50 --- quit: Shikadi (Read error: Connection reset by peer)
19:06:07 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
19:06:50 --- quit: tacco| ()
19:12:57 --- quit: Brain (Read error: Connection reset by peer)
19:15:14 --- join: lijero (~lijero@unaffiliated/lijero) joined #osdev
19:27:46 --- quit: awang (Ping timeout: 252 seconds)
19:34:42 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
19:35:15 --- quit: drakonis_ (Remote host closed the connection)
19:35:45 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
19:35:45 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
19:36:28 <geist> XwX.... that's a new one
19:38:32 --- quit: drakonis_ (Remote host closed the connection)
19:39:01 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
19:42:01 --- quit: drakonis_ (Remote host closed the connection)
19:42:32 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
19:45:31 --- quit: drakonis_ (Remote host closed the connection)
19:46:02 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
19:49:01 --- quit: drakonis_ (Remote host closed the connection)
19:49:22 --- nick: uplime -> klime
19:49:30 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
19:54:29 * izabera checks if #osdev is now a furry community
19:54:52 <pounce> no I think it's just me
19:54:53 --- nick: klime -> uplime
19:55:03 <pounce> at least I hope so
19:56:27 <exezin> success, in true long mode \o/
19:56:35 <izabera> congrats
19:56:38 <geist> longcat mode
19:59:13 <pounce> The moment of truth is about to come for my threading implementation
19:59:24 <izabera> *drum roll*
20:00:12 --- quit: awang (Ping timeout: 245 seconds)
20:02:20 <exezin> heh, it even boots on my laptop from a usb \o/
20:02:26 <exezin> wasn't expecting that
20:02:32 <geist> woot
20:03:41 <pounce> Yeah I was happy when I got mine to boot on actual hardware (I did it to test qemu)
20:03:57 <pounce> Turns out my assumption that my system has less than 128mb of ram was stupid though
20:04:09 <exezin> so I've connected gbd to qemu
20:04:15 <exezin> What was the command to print tables?
20:04:27 <geist> page tables? info mmu, i believe
20:04:29 <pounce> oh shit is there a command to print tables? I made a gdb macro for that
20:04:29 <geist> or info tlb
20:04:41 <exezin> maybe I did it wrong, neither exist
20:04:51 <exezin> no command mmu or tlb when i do info tlb etc
20:04:52 <geist> well, via gdb i guess you have to use monitor first
20:04:56 <doug16k> qemu monitor
20:05:03 <doug16k> not gdb
20:05:04 <exezin> wait what
20:05:08 <exezin> how do I get that up?
20:05:09 <geist> yah i dunno how to do it via gdb
20:05:25 <doug16k> exezin, in the pull down menus of the vm window
20:05:28 <geist> though i think there's some sort of passthrough in general, i think if you type monitor before the command gdb tries to pass it through?
20:05:34 <exezin> my qemu has no menus
20:05:43 <doug16k> that's the default way. there are better ways
20:05:51 <geist> or if you run it without a graphic console via --nographic
20:06:03 <geist> then it's ctrl-a c to get into the monitor
20:06:06 <doug16k> I use telnet
20:06:11 <geist> or that
20:06:25 <geist> i think you can do -monitor stdio on the command line and it routes it there even with a gui
20:06:34 <exezin> ctrl+a c actually does nothing for me
20:06:42 <klange> monitor can be set to stdio, is available in a tab in the GTK interface, can be switched to in the SDL interface through a keyboard command I forgot....
20:06:44 <doug16k> -chardev socket,id=qemu-monitor,host=localhost,port=7777,server,nowait,telnet
20:06:50 <geist> ah yes. --monitor stdio does it
20:06:50 <doug16k> then telnet localhost 7777
20:06:59 <exezin> -monitor stdio does it
20:07:04 <exezin> so I still need to have gdb attached?
20:07:10 <doug16k> oh plus: -mon qemu-monitor,mode=readline
20:07:11 <klange> Ctrl-Alt-2 in the SDL interface.
20:07:42 --- quit: drakonis_ (Read error: Connection reset by peer)
20:07:49 <geist> the monitor is completely different from gdb
20:07:54 <exezin> oh
20:07:58 <exezin> right
20:08:23 <exezin> I get a load of output like "0000000000000000: 0000000000000000 --------W"
20:08:27 <doug16k> if you set up telnet, then you can use this script to run a monitor command from the terminal and grep it: https://github.com/doug65536/dgos/blob/master/qemu_monitor_cmd
20:08:28 <bslsk05> ​github.com: dgos/qemu_monitor_cmd at master · doug65536/dgos · GitHub
20:08:30 --- join: robwgla (~robwgla@91-114-157-47.adsl.highway.telekom.at) joined #osdev
20:08:41 --- quit: JusticeEX (Ping timeout: 256 seconds)
20:08:41 <exezin> so is that just the table and its flags?
20:08:43 <doug16k> or use watch to have it automagically keep running a command while you debug
20:08:55 <geist> exezin: yep. one of them is the virtual, one is the physical, and then the flags
20:09:10 <exezin> ah, left is virtual right is physical or whatever
20:09:11 <geist> as it is interpreted by the cpu right now
20:09:14 <exezin> and flags, i get it
20:09:17 <geist> yep
20:09:18 <doug16k> exezin, info mem will give you a summary if you are overwhelmed with info tlb info
20:09:19 <exezin> awesome
20:09:35 <exezin> 2MB -rw doug16k
20:09:41 <exezin> neat :D
20:09:51 <geist> ah mem, yeah it was one of those. sadly that info isn't available on all archiectures. i wish it were available on arm64. i should see about adding that feature
20:09:56 <exezin> doug16k: wait is that showing me the rough virtual chunks that are mapped to physical addresses
20:10:12 <exezin> 0000000000000000-0000000000200000 0000000000200000 -rw
20:10:12 <geist> it's really entertaining to break into something like linux and see how its laid out
20:10:15 <doug16k> exezin, yes. it gives you a high level overview of the address space
20:10:21 <exezin> thats awesome
20:10:35 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
20:10:45 <geist> yep. qemu is fairly neat if you spend the time trying to learn it
20:10:58 <geist> i'm just fiddling with it here to emulate riscv32
20:11:19 <geist> neat thing is it acts basically the same way, so once you get the hang of it, other arches are pretty much the same deal
20:11:19 <klange> still wish there was an easier way to get the QEMU display to match its window size ;-;
20:11:41 <geist> klange: you ever look into virtio-gpu?
20:11:43 <klange> I even had a hacked together script to work with the SDL interface under X11 to communicate it via serial to a daemon in my OS
20:11:52 <geist> you can definitely resize the window and create separate ones, which is nice
20:12:17 <exezin> crap now im getting a boot cycle what did I do lol
20:12:32 <geist> -d int
20:12:34 <doug16k> exezin, yeah, OSdev is regression city at first :P
20:12:38 <exezin> oh borked my makefile, dope
20:13:09 <geist> yah i have a little binary here that prints 'abc' to the serial port. almost dont want to ruin it by fiddling with it more
20:13:18 <geist> it's all downhill from here
20:13:24 <klange> I have support for the thing VirtualBox does https://github.com/klange/toaru-nih/blob/master/modules/vboxguest.c#L130
20:13:26 <bslsk05> ​github.com: toaru-nih/vboxguest.c at master · klange/toaru-nih · GitHub
20:13:38 <exezin> I'm surprised I've made it this far with so few incidents, not really sure what to do next
20:13:43 <exezin> I figured this would take me a week, not a few hours
20:14:15 <klange> (it has a "guest device" that communicates various things, and the resolution and mouse cursor stuff are through a simple communication pipe; more advanced stuff like clipboard is through a complicated shared memory interface)
20:14:41 <pounce> exezin: `-d int --no-reboot` is best for bootloops (I have it in my makefile)
20:15:06 <exezin> whats -d int actually doing?
20:15:17 <exezin> oh it prints registers
20:15:18 <doug16k> exezin, printing output every time an interrupt occurs
20:15:23 <exezin> I see
20:15:25 <doug16k> exceptions are interrupts
20:15:42 <doug16k> v=x <-- x is the interrupt number
20:15:57 <doug16k> "vector" actually
20:16:04 <exezin> any idea why the page im reading on the wiki just sets all segment registers (except cs) to the data descriptor?
20:16:24 <doug16k> exezin, what else would it put in the data segment registers?
20:16:32 <exezin> oh true
20:16:43 <exezin> its just a way to get segmentation to shut up right
20:16:57 <exezin> like, have them all overlapping
20:16:59 <doug16k> ya base=0 limit=infinite means shut up segmentation, exactly
20:17:23 <geist> also iirc there's a switch to tell it to halt on triple fault
20:17:26 <exezin> long mode in ~300 lines of asm, nice
20:17:30 <exezin> (thanks grub)
20:17:37 <geist> so if your system is blowing up and triple faulting, run with -d int and whatever that switch is
20:17:49 <exezin> ah alright, I've added it to the makefile for now
20:17:57 <geist> -no-reboot i think
20:18:05 <exezin> yeah added that also :p
20:18:39 <geist> triple faults are nice because it's a definitive explosion, and -d int usually has enough context to show you where it went completely wrong
20:19:26 <exezin> would be nice if -d int had like a few line breaks between each output :p
20:19:26 <geist> there are more interesting traces too, but it generates a crazy firehose of info
20:19:41 <geist> -d cpu,exec,int is pretty much a huge firehose, tracing more or less everything that happens
20:19:52 <doug16k> exezin, pipe through sed?
20:20:03 <geist> i usually route it into a file and then edit it after the fact, add in spaces and commentary as i debug it
20:20:14 <exezin> the file idea is good, I'll do that
20:20:33 <geist> this is also where you really get to test the mettle of your editor: can it open a multi GB file in a few seconds
20:20:38 <exezin> my next step is getting C to work, oh boy
20:20:42 <geist> hint: vim can
20:20:49 <exezin> lol
20:20:54 <doug16k> exezin, C was born for this, shouldn't be hard
20:20:54 <exezin> sublime is generally pretty good
20:21:24 <exezin> doug16k: I'm writing for x86_64 (and developing from the same arch) so I dont even need a cross-compiler do I?
20:21:34 <doug16k> should use cross compiler
20:21:40 <pounce> (If you actually want to spend a long time getting it to work you can use Rust...)
20:21:46 <exezin> doug16k: bleh
20:21:58 <pounce> yeah there's reason to cross compile
20:21:59 <exezin> that means I'll need to compile gcc
20:22:10 <geist> or find one that someone else has made already
20:22:21 <exezin> what would I even be looking for?
20:22:24 <geist> there should be a bunch linked on the osdev wiki
20:22:55 <exezin> ah, i see
20:23:16 <doug16k> exezin, system compilers are heavily screwed with by distros. they make tons of changes
20:23:17 <exezin> the YMMV makes me consider just compiling it myself
20:23:38 <geist> if you'd like. i have a script to compile one if you'd like to automate it
20:23:56 <exezin> bash script or?
20:24:03 <geist> does it matter?
20:24:04 <doug16k> exezin, I made one based on geist's script
20:24:09 <geist> https://github.com/travisg/toolchains
20:24:10 <bslsk05> ​travisg/toolchains - Shell script to build gcc for various architectures (24 forks/33 watchers)
20:24:11 <exezin> well I like to read through scripts before I run them :p
20:24:30 <geist> i haven't updated it to 8.1 yet, the old patches dont apply because the MULTILIB stuff changed completely in the arm codes
20:24:37 <exezin> doug16k: dope, I'll try that then
20:24:42 <geist> but it's set to 7.2.0
20:24:58 <geist> er 7.3
20:25:10 <doug16k> this is what I came up with: https://github.com/doug65536/dgos/blob/master/build-crossgcc.sh
20:25:12 <bslsk05> ​github.com: dgos/build-crossgcc.sh at master · doug65536/dgos · GitHub
20:25:36 <exezin> whats the difference between that and geist's original?
20:25:43 <klange> Hm, virtio-gpu responds to bge commands
20:26:22 <klange> bga*
20:26:33 <geist> like 30 years too late, looks like gcc 8.1 finally got naked attribute on x86
20:28:06 <doug16k> exezin, nothing major. a few things: --enable-initfini-array to use ctors dtors intead of archaic init/fini, enables multilib 32/64 bit compiler and libs. enables gold linker. enables LTO. enables gdb python plugins. mostly configure changes
20:28:32 <exezin> ill give it a shot
20:28:34 <geist> ah i should look at that and steal some of those flags back
20:29:23 <doug16k> geist, please do. after line 265
20:29:26 <exezin> are ctors/dtors preferable over init/fini?
20:29:42 <exezin> (and why?)
20:29:48 <geist> there's some tiny difference. i think we tweaked it on fuchsia as wel
20:30:10 <geist> honestly i dunno, it's some minutae, but one of them is the future and one is old. so...
20:30:32 <exezin> what am I passing as flags to thos doug16k
20:30:39 <exezin> whats the prefix directory? :p
20:31:02 <doug16k> prefix is where to install it. preferably somewhere in your home directory. I use ~/cross-elf
20:31:02 <pounce> the true osdev album: https://masterbootrecord.bandcamp.com/album/interrupt-request
20:31:09 <bslsk05> ​masterbootrecord.bandcamp.com: INTERRUPT REQUEST | MASTER BOOT RECORD
20:31:16 <exezin> doug16k: then what is the output directory lol
20:31:19 <geist> but in the long run the prefix doesn't matter
20:31:26 <doug16k> exezin, output directory is where to compile
20:31:30 <exezin> ooh ok
20:31:43 <pounce> unless someone finds an album called "Undefined behavior"
20:31:59 <exezin> doug16k: what you linked is missing extra scripts?
20:32:08 <doug16k> yeah a couple of files
20:32:22 <exezin> .-.
20:32:27 <doug16k> https://github.com/doug65536/dgos/blob/master/build-crossgcc-versions and https://github.com/doug65536/dgos/blob/master/build-crossgcc-gcc.patch
20:32:30 <bslsk05> ​github.com: dgos/build-crossgcc-versions at master · doug65536/dgos · GitHub
20:32:31 <bslsk05> ​github.com: dgos/build-crossgcc-gcc.patch at master · doug65536/dgos · GitHub
20:32:49 <geist> ie, git clone it first
20:32:54 <exezin> brrr patches
20:33:04 <geist> doug16k: they're so demanding huh?
20:33:10 <doug16k> geist, lol
20:33:16 * exezin clones geist's one
20:33:26 <doug16k> exezin, it has to, to build libgcc with -mno-red-zone
20:33:26 <geist> doug16k: oh dizzzzam you just got shunned
20:33:42 <doug16k> exezin, geist's patches it too :P
20:33:57 <exezin> ye but I dont need to do anything :p
20:34:11 <exezin> you really expect me to like, type stuff?
20:34:12 <doug16k> you could have cloned whole repo
20:34:14 <exezin> pssh
20:34:25 <exezin> the whole repo is huge though lol
20:34:26 <geist> the best part is when you spend like 100 hours of constantally compiling and tweaking something like this and then some punk comes along and disses it because they were too lazy to git clone it
20:34:27 --- join: AverageJ0e (~joe@ip98-167-200-207.ph.ph.cox.net) joined #osdev
20:34:31 <exezin> you should stick it in a different repo
20:34:53 --- quit: SlyFawkes (Remote host closed the connection)
20:35:01 <exezin> I mean I'd clone it but the repo appears to contain your OS or whatever :p
20:35:16 <geist> yeah okay, that makes sense
20:35:19 <doug16k> yeah and you can't have that taking up your 40MB hard drive, can you? lol
20:35:28 <exezin> as it is im already fighting for storage space
20:35:33 <exezin> doug16k: eh I didnt check how big it was
20:35:42 <exezin> I have 1.5G free currently
20:35:59 <geist> be careful, building the toolchain may exceed that
20:36:06 --- join: SwiftMatt (~Objective@2601:282:4300:3e:6d06:cb3e:182a:d6d3) joined #osdev
20:36:06 <exezin> ill whip out another ssd
20:36:17 --- join: SlyFawkes (5166c138@gateway/web/cgi-irc/kiwiirc.com/ip.81.102.193.56) joined #osdev
20:36:26 <exezin> my server(pi) recently borked so I've got stuff running on my main rig I otherwise wouldnt, taking up space
20:36:30 <geist> the result is something like 200-300MB, but the intermediates are probably many times that
20:36:32 <doug16k> ~55.6MB including .git and probably a bit of junk that isn't checked in
20:36:34 <exezin> (namely my ps2 game server)
20:37:15 <exezin> and away we go
20:37:28 <exezin> I should really invest in a NAS
20:37:36 <doug16k> exezin, how many cpus do you have? including HT?
20:37:45 <exezin> HT?
20:37:50 <doug16k> hyperthreading
20:38:06 <exezin> 4 cores, 8 threads
20:38:15 <doug16k> you should pass -j 8 to that script
20:38:15 <exezin> (hyperthreading yes)
20:38:19 <exezin> 2late :(
20:38:23 <doug16k> or it will take forever
20:38:26 <exezin> lol ok
20:38:28 <exezin> ill do it
20:38:40 <geist> also -s i think which strips it at the end
20:38:47 <exezin> strips?
20:38:47 <geist> makes for smaller output
20:38:58 <exezin> ah
20:39:10 <doug16k> oh I added a thing to do clean build in my script too
20:39:10 <exezin> ./doit -f -a "x86_64" -j 8 -s
20:39:13 <exezin> is what I did
20:39:19 <geist> legit
20:39:21 <exezin> doug16k: yeah I was wondering if geist's had that feature
20:39:30 <doug16k> not that I know of
20:40:15 <doug16k> I put in a safety feature that prevents it rm -r something that isn't the build too :) - I don't trust bash scripts
20:40:37 <exezin> I have a habit of doing -rf and never double checking
20:40:46 <exezin> I've run dd on my main drives far to many times
20:41:10 <doug16k> yeah, I have a friend that does reckless recursive deletions and I recoil in horror when I watch him do that
20:41:24 <exezin> I did dd once for some iso that was intended to go to a usb
20:41:29 <exezin> cancelled it as fast as I could
20:41:34 <geist> there's a ./cleanit script
20:41:36 <exezin> now that drive has the label "soup" and I dont know why
20:41:52 <geist> but i specifically dont want to clean it because in general it's used multiple times to build different architectures in a row
20:42:09 <exezin> right, I suppose its only an issue if not-cleaning causes..issues
20:42:14 <doug16k> yeah the clean is mostly good when you are testing changes to the script
20:42:21 <geist> right
20:42:41 <exezin> im not overly fond of the new github home layout
20:42:57 <exezin> its very..mobile
20:43:40 <doug16k> I'm looking at getting one of those "enterprise" 12TB drives soon
20:43:48 <exezin> yikes
20:43:59 <exezin> I've installed a load of those for CCTV and the like before
20:44:07 <exezin> rather expensive :p
20:44:14 <exezin> woot geist's script is done
20:44:15 <exezin> that was fast
20:44:16 <pounce> (now just sched::yield() to execute before I start on preempting)
20:44:26 <pounce> (I really hope this doesn't just crash, but it probably will)
20:46:17 <doug16k> I want to get one of those sata port multiplier backplanes and add support for port multiplier in my ahci driver
20:46:39 <pounce> geist: do you ever test your OS with a real serial port?
20:46:58 <doug16k> pounce, I do
20:47:06 <geist> absolutely
20:47:10 <geist> it's the first thing you bring up
20:47:12 <pounce> I don't think I have one on either of my computers
20:47:25 <geist> it's definitely harder to find on a PC
20:47:33 <doug16k> pounce, you almost certainly have a header for one to go into a slot on the motherboard
20:47:34 <pounce> (although the serial driver works rather well on them, which is odd considering I don't know if it actually exists)
20:47:40 <geist> though there are pci serial cards too
20:47:54 <pounce> would I need to implement pci for that?
20:48:00 <exezin> is it normal for a gcc build to take literally a few minutes
20:48:06 <exezin> that seemed unnaturally short
20:48:12 <geist> doug16k: wouldn't say that actuakly. my experience lately is about 1/3 of the mobos have the COM header
20:48:18 <geist> ASUS is pretty good about it
20:48:25 <doug16k> ya? my new ryzen system did
20:48:27 <doug16k> ya it's asus
20:48:30 <geist> but i've been picking machines to testing precisely because of the presence of COM headers
20:48:47 <geist> when i got the threadripper machine i could only find one mobo with it
20:48:51 --- quit: robwgla (Quit: robwgla)
20:48:53 <doug16k> on the other end it's a laptop running linux with a usb com port dongle
20:49:24 --- join: robwgla (~robwgla@91-114-157-47.adsl.highway.telekom.at) joined #osdev
20:50:03 --- quit: Love4Boobies (Ping timeout: 256 seconds)
20:50:18 <doug16k> geist, ever seen a usb debug port in real life? I wish I could find one
20:50:38 <doug16k> it would be awesome to have megabits xfer for my gdb stub
20:50:58 <pounce> you could debug over the network >.>
20:50:58 <geist> actually yes. there's an extension to xhci that most modern intel machines support that lets you debug over it
20:51:09 <geist> it's fiddly, but we actually brought it up on zircon. you can shove tons of data over it
20:51:15 <geist> requires a special cable, but they're not too expensive
20:51:21 <doug16k> yeah I mean the special cable
20:51:31 <geist> yeah but it's not super expensive
20:52:18 --- quit: robwgla (Client Quit)
20:53:04 <doug16k> I recently added range stepping in my gdb stub, perf went through the roof, but still, it would be cool to support usb debug
20:54:18 <doug16k> range stepping = a way for gdb to say "repeatedly step, but stop when you hit a single step outside this range of addresses"
20:54:22 <doug16k> makes line step fly
20:54:42 <geist> ah
20:56:54 --- join: hmmmmm (~sdfgsf@pool-72-79-162-171.sctnpa.east.verizon.net) joined #osdev
20:57:06 --- quit: hmmmm (Ping timeout: 260 seconds)
20:58:57 --- quit: nj0rd (Ping timeout: 245 seconds)
21:03:05 <pounce> til yield is a reserved keyword in Rust
21:03:11 <pounce> so no sched::yield() for me
21:03:38 --- join: lnnb (~weechat@unaffiliated/icetooth) joined #osdev
21:04:48 <_mjg_> you are coding on os in rust?
21:04:53 <_mjg_> hipster
21:05:08 <pounce> the thesaurus gives me "defer","concede" and "go with the flow"... maybe I should use one of those
21:05:15 <pounce> yep, it's a nightmare right now
21:06:59 <klange> yiëld()
21:07:45 <doug16k> yield_
21:07:45 <geist> wuss_out(;
21:08:03 <geist> give_into_peer_pressure();
21:08:05 <klange> you_know_what_i_didnt_need_the_rest_of_that_time_slice_anyway();
21:08:42 <geist> here_take_all_the_goddamn_time_slices_are_you_happy();
21:09:11 <pounce> klange: "non-ascii idents are not fully supported"
21:09:26 <klange> yiiiiield()
21:09:42 <geist> yæld
21:09:52 <klange> ^ but make sure it's extended ascii and not unicode
21:10:04 <geist> yîél∂
21:11:16 <geist> ÿîéÎ∂
21:13:31 <pounce> wow, you found a name so terrible that even when I enable a feature for non-ascii idents it fails
21:14:05 --- join: nj0rd (~nj0rd@mue-88-130-48-053.dsl.tropolys.de) joined #osdev
21:15:41 <geist> Î is the truly weird one that i dunno what it is
21:15:46 <geist> shift-alt-d on mac
21:16:01 <geist> ÍÎÏ
21:16:22 <pounce> I can get it with <compose>+I+^
21:16:48 <pounce> but the rust parser just breaks at the partial symbol
21:16:52 <geist> ah apparently letters in romanian and some other ones
21:18:30 <pounce> I do a lot of project euler in Rust, and it got mad at me when I tried to name a function φ
21:22:53 --- quit: unixpickle (Quit: Peace out)
21:24:18 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:29:18 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
21:33:57 --- quit: Salek (Ping timeout: 245 seconds)
21:34:32 <doug16k> stop_killing_battery()
21:37:24 --- join: sympt_ (~sympt@209.58.135.108) joined #osdev
21:37:25 --- quit: lijero (Remote host closed the connection)
21:37:35 --- join: quc (~quc@87.116.229.183) joined #osdev
21:38:27 <pounce> Ok I've been fighting with this function for almost an hour so I think I'm going to head off
21:38:29 <pounce> night <3
21:39:18 --- quit: sympt (Ping timeout: 245 seconds)
21:50:39 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
21:51:31 --- quit: valerius (Quit: ZNC - http://znc.sourceforge.net)
21:52:49 --- quit: pounce (Quit: WeeChat 2.1)
22:00:56 --- join: valerius (~valerius@2a01:4f8:d16:2052::2) joined #osdev
22:00:59 --- quit: freakazoid0223 (Quit: Friends help you move. Real friends help you move bodies.)
22:07:56 --- join: jjuran_ (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
22:09:42 --- quit: sympt_ (Quit: Leaving...)
22:11:18 --- quit: jjuran (Ping timeout: 276 seconds)
22:11:18 --- nick: jjuran_ -> jjuran
22:14:26 --- quit: ALowther_ (Remote host closed the connection)
22:15:23 --- quit: hmmmmm (Read error: Connection reset by peer)
22:30:02 --- join: hmmmm (~sdfgsf@pool-72-79-164-159.sctnpa.east.verizon.net) joined #osdev
22:40:18 <exezin> geist: are there flags I can pass to your toolchain script so I can set without-headers and without redzone etc?
22:48:58 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
22:51:16 --- quit: eremitah (Ping timeout: 252 seconds)
22:51:16 --- nick: eremitah_ -> eremitah
22:54:29 --- quit: lnnb (Remote host closed the connection)
22:57:50 --- join: DeepIO (~DeepIO@dyndsl-080-228-181-201.ewe-ip-backbone.de) joined #osdev
23:03:56 --- quit: DeepIO (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
23:06:37 --- quit: epony (Ping timeout: 256 seconds)
23:10:28 --- quit: Colin_M_ (Quit: Colin_M_)
23:11:12 --- quit: nur (Quit: Leaving)
23:14:07 <geist> exezin: not really, no
23:14:22 <exezin> damn
23:14:24 <geist> well, the no redzone is not something you should worry about
23:14:34 <geist> because it just builds both versions of the libgcc
23:14:42 <exezin> what about without headers? :p
23:14:45 <geist> the headers, well, dont use em. what do you mean by 'headers'?
23:14:58 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #osdev
23:14:58 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
23:15:08 <geist> the only headers that come with the toolchain are ones you pretty much do want to include
23:15:11 <geist> stdint.c, etc
23:15:13 <exezin> the --without-headers flag tells gcc not to rely on any standard lib headers
23:15:22 <geist> it dosen't as far as i know
23:15:33 <exezin> huh, its even stated on the osdev cross-compiling page
23:15:52 <geist> okay, well i dont use that switch and i have not ended up with any 'standard lib headers'
23:15:58 <geist> depends a whole lot on what that precisely means
23:16:19 <exezin> "Tells GCC not use any target headers from a libc when building a cross compiler. When crossing to GNU/Linux, you need the headers so GCC can build the exception handling for libgcc. "
23:16:20 <geist> might make a difference if it build libstdc++ or whatnot, but it doesn't
23:16:26 <exezin> from the man pages of gcc ^
23:16:35 <exezin> well, website
23:16:40 <geist> ah. dunno then. i dont use any exception handling libgcc stuff so it doesn't matter to me
23:16:48 <exezin> alright
23:16:52 <exezin> I guess I could also just modify the script
23:16:57 <geist> sure. feel free
23:17:16 <exezin> *if* I run into issues that is, cant be bothered to re-compile :p
23:17:33 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
23:18:16 <exezin> geist: why should I not worry about red zones?
23:18:22 <exezin> its x86_64 after all
23:19:12 <exezin> "So while your kernel works just fine the methods in libgcc may mess things up by accident. The solution is simple - rebuild libgcc with -mno-red-zone. Fortunately GCC supports this in a straight forward way by providing multilib support inside it's source tree. "
23:19:40 <geist> right
23:20:02 <exezin> looks like the flag works while using gcc anyway, so I guess thats fine
23:20:13 <exezin> could get ugly if someone forgets it, though
23:20:26 <geist> yes, but the question is does it end up with a multilib libgcc
23:20:57 <geist> without patches. perhaps they changed that in a recent one, but the patch there was specifically to tell it to build a multilib libgcc. one with and without red zone
23:21:08 <geist> previously it wouldn't in the default -elf target
23:22:31 <exezin> "Assuming you're using GCC to link your kernel you're probably fine. All that's needed is to make sure -mno-red-zone is in your LDFLAGS when doing the final linker call. "
23:22:47 <exezin> hmm
23:23:13 <geist> look, if you wanna go it alone, have at it
23:23:17 <geist> i'm not here to double check everything you do
23:23:19 <exezin> what
23:23:21 <exezin> lol
23:23:56 <geist> all i'm telling you is what i know. sometimes things change, somethings things are wrong. its up to you to decide
23:24:15 <geist> last i tried, with gcc 6 you definitely needed the red zone patches if you want a proper multilib libgcc
23:24:25 <geist> but if you dont do it, it'll 'probably work'
23:24:34 <geist> and it'll likely work for quite a while, up until it doesn't.
23:24:36 <exezin> I dont really understand what you mean by patches but ok
23:24:46 <geist> the .patch file in the repo
23:24:53 <exezin> oh
23:25:00 <geist> it specifically adds the redzone multilib (and some arm stuff yuo dont care about)
23:25:30 <geist> https://github.com/travisg/toolchains/blob/master/patches/gcc-patch.txt#L70 etc
23:25:32 <bslsk05> ​github.com: toolchains/gcc-patch.txt at master · travisg/toolchains · GitHub
23:25:34 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:25:38 <exezin> right
23:25:57 <geist> that and the thing below it cause it to build special versions of libgcc for redzone and 32bit. that's handy
23:26:12 <exezin> 'for redzone' you mean redzoneless?
23:26:16 <geist> if you dont use it, then you end up with a redzone libgcc linked against a non redzone kernel., which probably works most of the time
23:26:24 <geist> yes non redzone libgcc
23:26:27 <exezin> alright
23:26:46 <geist> that's why that's there. if you dont link libgcc with your kernel (which is also possible) then the problem doesn't exist
23:27:00 <geist> we dont link libgcc with the fuchsia kernel, for example. neither does linux
23:27:10 <geist> you just avoid doing anything that would cause a libgcc requirement
23:27:18 <geist> easy on 64bit
23:27:35 <exezin> ah ok, I'm not even 100% what would be a libgcc requirement to be honest
23:28:11 <geist> on a 32bit machine doing a 64bit divide, for example
23:28:19 <geist> or a machine without floating point using floating point
23:28:21 <exezin> ah
23:28:25 <geist> on a 64bit machine it's somewhat harder
23:28:34 <geist> doing 128 bit divide i suppose
23:28:38 <exezin> linking libgcc with the kernel != linking it with gcc right
23:28:58 <geist> correct. libgcc.a is just a set of routines for things that the compiler doesn't want to implement inline
23:29:10 <exezin> oh right, I guess thats where the confusion lies
23:29:12 <geist> tradtionally you link it against whatever binary you have so that everything is cool
23:29:43 --- quit: ALowther (Ping timeout: 248 seconds)
23:30:04 <geist> hence why you need a separate version for if you're compiling code with red zone
23:30:23 <geist> that's what the 'multilib' stuff is all about. it instructs gcc to build different variants of libgcc with various sets of compiler switches
23:30:33 <exezin> ah I see
23:30:57 <geist> so this patch is instructing the plain -elf variant of the toolchain to build a libgcc with and without red zone
23:31:09 <geist> most of the time no one cares since the vast majority of code in the world is user space and uses red zone
23:31:48 <exezin> so its only really an issue if I link my kernel with libgcc, and it ends up using the red zone in kernal space *somehow*
23:32:15 <geist> no, it matters if you link it against the kernel and you *dont* use red zone
23:32:18 <geist> which you should not for kernel code
23:32:41 <geist> without the patch the libgcc.a would have been compiled with red zone, and thus you're mixing red zone and no red zone
23:33:23 <geist> the default codegen is with the red zone, since it's part of the x86-64 defaault abi
23:33:29 <geist> the only code that wont use red zone is kernel code
23:34:04 <exezin> what I mean is, if I use some libgcc stuffs in the kernel and that libgcc stuff ends up using the redzone for something, it could cause issues
23:34:09 <exezin> is my understanding of the issue, anyway
23:34:11 <geist> correct
23:34:14 <exezin> alright
23:34:16 <exezin> got it, thanks :p
23:34:31 <geist> you should look up what the red zone is. basically it's a feature of the ABI that is incompatible with receiving hardware interrupts
23:34:49 <geist> it's fine for user space, since irqs aren't dropped onto a user space stack. but in kernel space it's a problem
23:34:55 <exezin> yeah, because the hardware interrupts will overwrite your crap below the original place of the stack pointer
23:35:04 <geist> exactly
23:35:08 <exezin> so when it returns to your subroutine, the stuff you used in the redzone is rip
23:35:10 <exezin> yeah
23:35:16 <geist> so, if you're using libgcc code that is compiled with red zone, and you happent o get an interrupt while it's inside of one of those routines...
23:35:24 <exezin> boom
23:35:40 * exezin notes down "red zone bad in kernal space"
23:36:05 <geist> if your kernel is non reentrant i suppose that problem doesn't exist
23:36:06 <geist> it's AFAIK only a x86-64 thing. no red zone like thing exists for the other arches i've fiddled with at least, and i've played with quite a few
23:36:32 <exezin> yeah I did see it say its specifically an x86_64 thing and nothing else
23:36:42 <geist> dunno if anyone has actually done any real analysis of if it's a win or not, but whoever designed the x86-64 ABI thought it was a good idea. probably someone's pet idea
23:36:52 --- quit: regreg_ (Ping timeout: 245 seconds)
23:36:59 <geist> presumably someone at AMD, since they got the chance to define it
23:37:37 <geist> ah according to the internet, OpenRISC ABI defines it too
23:38:44 <exezin> it appears that -mno-red-zone works as a gcc flag so I can just make sure to compile kernel code with that flag and not worry about re-compiling gcc..I think
23:39:04 <geist> correct
23:39:18 <geist> it's simply something you pass the compiler when compiling for the kernel
23:40:23 <exezin> ez pz
23:42:03 --- quit: mavhq (Read error: Connection reset by peer)
23:42:19 <geist> note that windows or mac or whatnot may use a different ABI. the ABI that we're talking about with the red zone is the system V abi
23:42:32 <geist> and most unixy systems use it, linux, bsds, etc
23:42:47 <exezin> yeah
23:43:02 <geist> windows abi is completely different, and i dont think has the red zone
23:43:18 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
23:44:02 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
23:45:16 <geist> looks a lot cleaner: 4 args passed in rcx,rdx,r8,r9
23:45:55 <geist> rax, rcx,rdx,r8-r11 are trashed, r12-r15,rbx,rbp,rdi,rsi are saved
23:45:58 <geist> that seems a lot easier to remember
23:47:44 --- quit: sixand (Ping timeout: 252 seconds)
23:56:35 --- quit: dbittman_ (Ping timeout: 260 seconds)
23:59:59 --- log: ended osdev/18.05.22