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=11&d=5
12:01:01 <klange> that is not part of the fbdev interface
12:01:06 <klange> that's the console interface
12:01:11 <jjuran> true
12:02:39 <klange> I think the answer there is "tough tits" - applications I'm aware of with fbdev backends typically recommend disabling the cursor and such manually. (setterm -cursor off, setterm -blank 0)
12:04:06 <ybyourmom> Not too tough, I hope
12:04:24 <klange> those are controlled with escape sequences, so you can probably just try to output them yourself: -blank 0 is \[9;0]
12:04:32 <klange> \[[9;0] rather*
12:05:11 <jjuran> I was hoping that an fd could carry the necessarily privileges, but no. I'll have to write a coprocess that runs as root and hangs around to restore the console mode.
12:05:16 <jjuran> klange: Is there any way to query those settings so as to restore them later?
12:06:10 <klange> I'm not sure.
12:07:02 <klange> For cursor, you can just turn it back on - or throw out a reset.
12:07:17 <jjuran> I want to restore things to the way they were.
12:07:20 <klange> For screensaver, instead of turning it off you can occasionally 'poke' it
12:08:05 <jjuran> In the meantime, I already have `kdtext` and `kdgraphics` one-call programs that are suitable for setuid-root use.
12:11:03 <klange> https://github.com/karelzak/util-linux/blob/master/term-utils/setterm.c#L727
12:24:31 <nohop> Section "4.8.2 Data-Segment Descriptors" of the AMD 64 prog. manual vol. 2 Confuses me.
12:24:36 <nohop> It states: "The expand-down (E), writable (W), and accessed (A) type-field attributes are ignored"
12:24:55 <nohop> But, when I don't set the 'W' bit, it faults.
12:25:35 <nohop> Is there some context I'm missing?
12:26:31 <geist> no but there's some context we're missing
12:27:03 <nohop> what do you mean?
12:27:23 <nohop> Does, what I'm reading really mean that I can set that 'W' bit either way, and it shouldn't make a difference?
12:28:43 <geist> it means, depends on what you're trying to do precisely
12:28:47 <geist> and thus we're missing context
12:29:16 <geist> and including potential bugs in your implementation
12:29:24 <nohop> Sure. I understand that.
12:29:26 <nohop> Ok.
12:29:43 <geist> i'm fairly certain the W bit is absolutely used in some cases
12:29:50 <geist> but there are many types of descriptors
12:29:58 <geist> and in some of those the W bit may be ignored
12:30:17 <geist> but you are right to look at the docs
12:30:19 <dormito> geist: ist some/all of those bits ignored in long mode?
12:30:30 <geist> yes
12:30:37 <geist> many more of them are ignored for 64bit descriptors
12:30:57 <nohop> I'm trying to setup the GDT for the second time (I'm doing it in my 32 -> long mode 'loader'. And, since that was still in 32 bit comp. mode, I needed more fields. Not i'm in long-mode and in my kernel, so I'm setting it up again (Also because now there's an IDT and such). But I'm getting tripple faults if I don't set the 'W' bit in that descriptor.
12:31:04 <nohop> <geist> i'm fairly certain the W bit is absolutely used in some cases
12:31:26 <geist> yep. oherwise there wouldn't be a W bit
12:31:26 <nohop> That's what I thought, but the manual seems to say otherwise. But I might be mis-reading it or just overlooking something.
12:31:39 <nohop> What I'm trying to do is simply setting up the data segment.
12:31:47 <geist> again, the context matters. i'm saying 'there arre some types of descriptors in some modes where the W bit means something'
12:31:49 <bcos_> 'W' is used for the 32-bit and 16-bit sub-modes of long mode
12:31:52 <geist> and then i need more context
12:31:54 <nohop> I mean, everything works fine. I just don't understand what the manual is trying to say.
12:32:00 <geist> in 64bit i'm fairly certain it isn't used
12:32:13 <geist> but it may also be rolled up into the descriptor type
12:32:25 <geist> ie, the W bit may be recycled into a type number, depending on how you squint at it. iirc
12:32:31 <geist> but i dont remember the details off the top of my head
12:32:39 <nohop> It happens when a software interrupt is fired.
12:32:57 <nohop> Since it's the data-seg, i'm guessing it's probably a stack-access related thing, but I'm not sure.
12:33:08 * geist nods
12:33:30 <geist> my guess is it's something else, and there's some sort of subtle bug there that makes it work differently than you think you're making it work
12:33:39 <geist> verify everything
12:33:55 <geist> there can be a difference between what you think you're telling it to do and what is happening
12:36:11 <geist> but you're right, the docs do say that
12:36:20 <nohop> So, that bit really shouldn't matter in long mode? Even during an interrupt?
12:36:35 <nohop> Yeah, I must be setting something else up wrong for this to fail then....
12:36:51 <geist> from my reading on it, yes
12:36:55 <geist> should not matter
12:37:38 <geist> interresting though taht in my code i specifically have the W bit set
12:37:49 <geist> it's possible this is a case where AMD and intel differ
12:37:55 <geist> sometimes one will be more strict than the other
12:38:10 <nohop> Hmm... What happens when you reset it?
12:38:10 <geist> .byte 0b10010010 /* P(1) DPL(00) S(1) 0 E(0) W(1) A(0) */
12:38:58 <geist> system crashes
12:39:13 <geist> #GPF on that, errorcode 0x18 (the data segment)
12:39:37 <nohop> No shit.
12:40:11 <nohop> kernel.cpp:281:2: internal compiler error: in process_init_constructor_array, at cp/typeck2.c:1308
12:40:16 <nohop> Please submit a full bug report,
12:40:24 <nohop> Hah! Now it's extra broken :)
12:40:25 <klange> ouch
12:40:58 <geist> lets see if i ru that on an AMD machine...
12:42:27 <geist> it may also be that the text is still correct
12:42:41 <geist> and it may be ignored during writes, but it is till checked for validity on load (ie, an exception)
12:43:20 <geist> yah GPFs on an AMD machine too
12:44:50 <geist> hmm, that is an interesting conundrum
12:44:53 <nohop> Hmm.. That statement in the manual seems to suggest that it's ignored. period.
12:45:04 <geist> agreed. i haven't seen anything to that effect in the intel manual
12:46:10 <nohop> So.... maybe I should be using tutorials for my information, and not get information from official manuals? ;)
12:46:14 <geist> furrthermore EWA being 0 is a perfectly valid segment in regular mode. it's just a read only data segment
12:47:23 <nohop> Very weird.
12:47:46 <nohop> Oh well.. Let's figure out why my compiler suddenly stopped working.. :)
12:48:45 <geist> the intel manul is extremely terse about this stuff
12:49:00 <geist> it's very much like 'here's a segment' 'oh and in ia32e it's mostly not used'
12:49:02 <geist> and not very precise
12:49:34 <nohop> I haven't looked at it at all yet. Figured it's really AMD64 anyways. Didn't even know Intel had a manual.
12:49:47 <nohop> Plus I found the AMD manual pretty useful, so far.
12:49:58 <geist> agreed. i kind of like how it reads, and it tends to be somewhat more precise sometimes
12:49:59 <nohop> For things I couldn't find in 2 minutes with a simple google search :)
12:50:13 <geist> though in this case i suspect it's one of those cases where the two compaies disagree
12:50:39 <geist> i know, for example, that the inner page table entries differ on intel and amd with regards to unused bits
12:50:49 <geist> intel says do not care, amd says must be zero
12:52:17 <geist> anyway, good find
12:52:46 <nohop> Can't beliece I had to find it. I have no fucking clue what I'm doing.
12:53:06 <geist> also figured 4-21 is interesting, because it's sort of wrong on a few levels
12:53:15 <geist> for example, it points out that bit 12 is 1 but is ignored
12:53:28 <geist> which isn't true at all, otherwise it'd be interpreted as a system segment
12:53:47 <nohop> I know. I actually found that out the hard way, too.
12:54:28 <nohop> that 'greyed out' part makes it very confusing. Apparently that only signifies the parts that are ignore when it comes to "ignored in 64-bit mode when the descriptor is
12:54:30 <nohop> used during a memory reference"
12:54:35 <nohop> (sorry, bas paste)
12:54:39 <nohop> s/bas/bad/
12:54:39 <geist> it's unclear, but i think their logic is that it's ignored once things are up and running, but since it's still interpreted by the logic that loads it in
12:54:42 <geist> then it can still be bad
12:54:59 <geist> i suspect the answer is that when loaded into SS via an exception, it probably Must Be Writable
12:55:07 <nohop> Except that my earlier fault only ocurred later.
12:55:14 <nohop> Oh, right
12:55:17 <geist> at an exception which is when it would reload SS
12:55:26 <nohop> AH, found the compiler bug, too.
12:55:39 <geist> same with this test in zircon, it ended up faulting somewhere along the way, proibably the first interrupt
12:55:43 <nohop> For some reason gcc forgot how to initialize structs with structs... amazing.
12:56:28 <nohop> Yeah. Funny. It was kinda annoying to find. Ended up just enabling bits until it worked :)
12:57:24 <geist> hmm, long mode exceptions load a null SS selector though
12:57:58 <geist> on priviledge switches that is
12:59:32 <geist> ah it happens on iretq, so it's switching back to user space, and thus probably rreloading the segment register
01:05:20 <geist> ah hah, foun dit
01:05:34 <geist> in the description of iretq, there's a note that says that it'll #GP if:
01:05:48 <geist> "If the stack segment is not a writable data segment."
01:05:59 <nohop> Alright then.
01:06:08 <geist> that's in the intel manual, so now lets see wat the amd manual says
01:06:14 <nohop> Still seems contradictory
01:06:44 <geist> hang on, lemme see if amd manual says it
01:06:55 <geist> i dont think it precisely is, but it's still subtle and silly
01:08:03 <geist> yah AMD manual says the same thing in the iret description
01:08:54 <geist> so i think they're technically correct, it's just extremely subtle
01:09:17 <geist> noe that intel doesn't even say anything about this. it doesnt mention precisely which bits are ignored, it just says that base and length are ignored generally in 64bit stuff
01:09:29 <geist> AMD specifically tries to call out those bits, but in a clumsy and subtle way
01:10:23 <nohop> Yeah, that didn't help me at all :)
01:10:57 <geist> hah i ceased trying to help you a while ago. i'm now going down this rabbit hole for my own edification
01:11:17 <nohop> So, they are ignored during a 'memory reference', and only then?
01:11:31 <geist> precisely this: priviledge checks when segment descriptors are loaded
01:11:38 <geist> such as... during an iret
01:12:04 <geist> it does say that though the bits arre ignoed for the purposes of memory checks, they are still loaded and presumably processed
01:12:08 <geist> so that was the wiggle room they gave you
01:12:27 <geist> so eally, the part that's confusing is that gives the impression that the bits are simply ignored, which isn't the case at all
01:12:34 <geist> they're just not used once they're loaded and validated
01:13:23 <geist> the intel manual gives you no such rope to hang yourself. it simply says generically that base/length are't used in 64bit, but it does not call out unused bits in the descriptor
01:14:01 <nohop> I understand. Guess you have to be a lawyer :)
01:14:17 <nohop> Also -- <geist> hah i ceased trying to help you a while ago -- What!? :)
01:14:23 <geist> my guess is the reasoning here is that when loading a data or stack segment, the cpu doesn't know what mode they're going to be used in
01:14:34 <geist> 16 or 32 or 64
01:14:46 <geist> so it must do the full validation of the bits as it says it does usually
01:14:52 <nohop> I guess that makes sense.
01:15:03 <nohop> It felt weird anyways, that it would be completely ignored...
01:15:12 <geist> you could be loading up ds/es/fs/gs/ss and then switching to 32bit via some far call
01:15:26 <geist> so it must always load and validate bits from the descriptors, even if they aren't immediately used
01:16:09 <geist> anyway, this horse is dead
01:16:54 <nohop> Thanks though, for helping to shed some light on this... greyness...
01:17:00 <geist> no prob
03:18:51 <nohop> Yay! Lazy page allocation works on my kernel's malloc implementation.
03:25:04 <ybyourmom> Noice
05:23:23 <geist> nohop: nice
05:23:35 <geist> note that demand paging kernel data structures may be a fairly bad idea, so be careful
05:56:44 <lkurusa> never page out the paging code
05:56:50 <lkurusa> that would be....
05:56:55 <lkurusa> quite catastrophic
06:41:19 <_mjg> nohop: you sure it does? do you also do it from interrupt context?
11:06:22 <jfo> hello all, I was told that embedded is on topic for this channel and I have a question about avr assembly if anyone has a moment and might be able to help me. Details here: https://github.com/jfo/avr-sandbox/blob/master/question.md
12:13:14 <clever> jfo: i think something about origin and _start is missing from that image
12:16:28 <clever> jfo: and also the reset vector
12:24:28 <jfo> @clever it doesn't seem to change the described behavior if I set .org 0x0000 jmp main and then .org 0x00f0 main: , I had assumed the interrupt points would just be ignored in such a simple program, is that what you mean?
12:25:04 <clever> jfo: i think the reset vector is at the top of the address space, and must be filled in
12:25:59 <clever> ah, the getting started page on http://avrbeginners.net/ implies its at the bottom, the first opcode
12:26:27 <jfo> yes, if I set it there explicitly the behavior doesn't change, yeah, so it's implicitly 0x0000 without anything else
12:26:38 <clever> so if you omit the proper reset vector table, it just starts running at the first opcode
12:26:43 <jfo> yes
12:27:26 <clever> i'm not sure why the jmp and rjmp are disassembling weird like that, i usually just use c and avr-libc on my AVR's
12:28:15 <jfo> also I have found some information about how rjmp stores it's jump (as an offset to the instruction after the rjmp), which is interesting but still doesn't seem to make sense given this output.
12:28:49 <clever> jfo: oh, i have another thought, are you setting portb at all?
12:28:55 <jfo> yeah I'm not either... when I look directly at the data with xxd it seems to agree with the disassembler, it's just not what I would expect.
12:28:57 <jfo> no just portd
12:29:09 <clever> try setting both DDRD and PORTD to 0xff
12:29:25 <clever> PORTD may be 0 at bootup, so setting the pin as output makes it out 0
12:29:42 <clever> the led may have been on because it was input with pullup resistor
12:29:55 <clever> and setting DDRD is what turned it off
12:30:13 <jfo> ok brb
12:35:14 <mischief> maybe compile an example c file and dump it for comparison..
12:36:29 <jfo> clever: doesn't seem to affect the behavior either... I set both DDRD and PORTD to 0xff, jmp is still disassebling weird.
12:36:51 <clever> jfo: and no effect on the led?
12:37:13 <jfo> mischief: I can try that- my hope was that using only the assembler would be easier to understand though, that's what I'm going for anyway
12:37:57 <jfo> clever: no iiuc setting DDRD to out sets portd to 1 implicitly too.
12:38:37 <jfo> from that tutorial: "The reason why we first switch it off is that it was already on when entering the loop for the first time: After reset, all port data bits are zero. By setting bit 3 in DDRB we configured portB.3 as an output and switched the LED on."
12:38:51 <jfo> (B is D on my board)
12:39:23 * clever reads http://ww1.microchip.com/downloads/en/devicedoc/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf
12:40:05 <jfo> the port addresses are on page 417
12:41:20 <jfo> I realize this is just such a trivial example, butI simply don't understand why the assembler isn't doing what I would expect it to, that is to say, properly inlining jmp target addresses based on the labels I'm using.
12:41:28 <clever> jfo: 0x0d is DDRE
12:42:01 <clever> DDRD is 0x0a
12:42:04 <jfo> I'm setting 0x0a and 0x0b
12:42:21 <jfo> led is on d6
12:42:39 <clever> and the led is the right way around, with a resistor?
12:43:06 <jfo> it seems to be, if you mean it lights when d6 is set to output and high
12:43:19 <jfo> (thanks btw!)
12:43:34 <clever> all working now?
12:43:55 <jfo> well, the led was working before, it's the jumps not behaving how I expect that is perplexing
12:47:26 <jfo> the assembler seems to be assigning the value 0 to all the labels
01:03:30 <jfo> well, in any case, I am trying another assembler and the output seems to line up with what I would expect, so I guess I'll have to blame avr-as for this strangeness, which feels like the wrong thing to do (https://blog.plover.com/prog/compiler-error.html) but here we are. thank you for your thoughts clever and mischief.
01:04:09 <jfo> (the other assembler is http://avra.sourceforge.net/)
02:13:46 <aalm> .roa
02:13:46 <glenda> 1 Once you have their money, you never give it back.
02:20:27 <lkurusa> .ken
02:20:27 <glenda> What is or is not implemented in the kernel represents both a great responsibility and a great power
02:26:36 <aalm> .theo
02:26:36 <glenda> That's nice.
02:27:28 <mischief> :))
02:28:02 <lkurusa> :)
03:04:34 <Brnocrist> .theo
03:04:34 <glenda> I really don't give a shit what you admire or not.
03:04:40 <Brnocrist> <3
03:06:18 <lkurusa> i wish the bots would tell us where the quotes are from :)
03:06:26 <lkurusa> a link to the mailing list would be great
03:06:57 <izabera> http://openbsd-archive.7691.n7.nabble.com/msttcorefonts-fontconfig-workaround-td141526.html
03:07:17 <izabera> that took me a whole 7 seconds of google
03:08:09 <lkurusa> duckduckgo didn't turn up anything useful :(
03:08:18 <izabera> wow
03:08:19 <lkurusa> i tend to forget i'm using ddg
03:08:24 <izabera> that never happens, right?
03:08:45 <lkurusa> well - it's usually fine
03:09:33 <izabera> it's almost as if creating a google level search engine was somehow hard
03:10:50 <lkurusa> the bang commands and the privacy benefits usually outweight the quality of results for me
03:12:21 <mischief> i am fairly confident every line in the 9front theo fortune is from the mailing list
03:12:35 <mischief> and almost always theo berating someone on misc⊙oo
03:36:02 <aalm> .theo
03:36:02 <glenda> I wish more people would find real bugs to fix.
03:36:16 <aalm> .roa
03:36:16 <glenda> 19 Satisfaction is not guaranteed.
03:36:17 <glauxosdever> .theo
03:36:31 <glauxosdever> Race conditions?
03:36:40 <mischief> rate limited.
03:36:41 <aalm> i won
03:36:47 <glauxosdever> .theo
03:36:47 <glenda> Funny.
03:36:53 <glauxosdever> Indeed! :-)
03:38:21 <lkurusa> The bot seems to have AI i swear
03:39:53 <glauxosdever> .theo
03:39:53 <glenda> can you not read the prompt?
03:40:10 <glauxosdever> There was no prompt here, therefore no AI
03:41:02 <aalm> weak
03:41:04 <aalm> .theo
03:41:04 <glenda> I am so bloody dissapointed in the community that uses our stuff.
04:26:40 <abysslurker> o/
05:37:48 * geist yawns
05:41:50 <mrvn> geist: Hey, no putting me to sleep. I've got work to do.
07:31:13 * geist yawns harder
07:31:24 <geist> actually i have coffee now, so no more yawning
08:03:34 <klys> geist, would you know who I should ask about building garnet? I've been trying for a couple of days.
08:03:50 <geist> well, start off on #fuchsia for one
08:04:08 <geist> where there are lots of folks on the team present
08:04:15 <geist> some of which may actually help depending on exactly when
08:04:23 <geist> right now is likely to be quiet since it's middle of lunch in the US
08:05:30 <_mjg> time to become a sleazy salesman
08:06:15 <klys> .theo
08:06:15 <glenda> That is not right.
08:15:15 <geist> klys: you still there?
08:16:06 <klys> y
08:55:25 <SzateX> bcos_, I have any other idea... In intel book i read that ports are mapped to memory in PCI
08:56:18 <bcos_> SzateX: That doesn't sound right (sounds like a misinterpretation maybe)
08:56:41 <SzateX> https://01.org/sites/default/files/documentation/ilk_ihd_os_vol3_part1r2_0.pdf#page=18&zoom=auto,-265,770
08:56:42 <SzateX> here
08:57:54 <SzateX> and PCI has base addres on 14h offset
08:58:51 <bcos_> That's more... "Registers may be mapped to IO ports or mapped to physical addresses"
08:59:57 <SzateX> yeah... but we can check is computer system support mapping, and check is video card there
09:02:15 <bcos_> In general (for all modern PCI video devices) there's a native interface where registers use memory mapped IO (that's controlled by PCI BARs, etc), and there's "legacy emulation" where it uses IO ports to emulate obsolete stuff
09:02:42 <bcos_> ..for a native video driver you'd never use "legacy emulation" - it's horribly restrictive and doesn't work when there's 2 or more video devices
09:03:38 <SzateX> so it look... i will never had 13h mode
09:03:49 <SzateX> because registers doing fucking stuff
09:05:56 <bcos_> I'm not sure I understand
09:07:53 <bcos_> If the firmware is BIOS and if the video device is in "legacy emulation mode" (which is likely if it's the primary video device for compatibility reasons) then the video device "should in theory" emulate VGA enough to allow you to set up "320*200 * 256-colour" with code designed for VGA
09:10:14 <bcos_> ..the main problems are that "should in theory" isn't quite the same as "guaranteed in practice"; and that BIOS is being replaced by UEFI and "legacy emulation" is being discarded and nobody wants "320*200 with 256 colours" and everyone wants 1920*1600 with millions of colours..
09:10:16 <bcos_> ;-)
09:10:32 <mrvn> and DOS is dead and windows has it's own drivers
09:11:16 <mrvn> SzateX: are you setting the video mode using the bios?
09:11:47 <SzateX> mrvn, no i can't do it in kernel - i'm in protected mode
09:12:01 <mrvn> SzateX: do it before switching to protected mode
09:12:05 <SzateX> for checks i set by bios but in bootloader
09:12:18 <mrvn> and in the bootloader it works?
09:13:10 <bcos_> mrvn: I think this a continuation of yesterday; where SzateX is/was setting mode 0x13 in boot loader and then trying to read VGA registers later in protected mode; and nobody could figure out why the code to read VGA registers caused "black screen" when it shouldn't have caused anything
09:13:18 <dormito> mrvn: ironically DOS isn't dead. some modern BIOS vendors provide BIOS update utilitise via DOS :(
09:13:45 <mrvn> dormito: some provide windows images that then start linload to start linux to flash the bios
09:14:24 <mrvn> SzateX: the cards might emulate the bios calls but not the full register set.
09:14:39 <mrvn> or you simply are doing something wrong.
09:14:53 <mrvn> wrong for that card that is
09:16:20 <SzateX> mrvn, but i think i can't gdb my second pc... and wrong set of register (which should not be changed while reading) can destoy hardware
09:17:00 <mrvn> I would try out the VGA code in bochs and kvm first.
09:17:55 <SzateX> we tried on bochs and vbox - the same issue
09:18:33 <mrvn> keep reading the docs and try again. At least in bochs/vbox you can't destroy any hardware
09:19:26 <SzateX> what i'm doing for... week?
09:20:02 <mrvn> also note that some VGA registers can't be read at all.
09:21:06 <SzateX> docs doesn't say anything about can't read Attribute Registers
09:24:49 <mrvn> anyone know if an RPi3 can run ARM64 Xen?
09:36:36 <mrvn> hmm, here is an idea for a cool qemu feature. Why not build support for different arm boards dynamically from the device tree like: qemu-system-arm64 --machine dtb --dtbfile helios.dtb
09:38:21 <mrvn> back to the salt mine
09:49:31 <aalm> .roa
09:49:31 <glenda> 74 Knowledge equals profit.
11:35:52 <aalm> .roa
11:35:52 <glenda> 12 Anything worth selling is worth selling twice.
11:57:53 <geist> mrvn: since the timer and interrupt controller are nonstandard on RPI, if it did support it it'd require explicit Xen support