Search logs:

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

Saturday, 17 November 2018

12:31:19 <mrvn> Whats a simple example to get a constructor on ARM for C/C++ (something in ._init_array)?
03:24:52 <eryjus> i hate debugging A when the problem is really in B....
03:25:53 <bcos> eryjus: That's why you should focus on debugging C
03:25:56 <bcos> ;-)
03:26:25 <eryjus> lol
03:54:19 <mischief> .theo
03:54:19 <glenda> I still think you are a loser.
04:09:00 <bluezinc> I'm not sure what to think when the OS compiles faster than the documentation for the OS...
04:09:17 <bluezinc> probably just that LaTeX is really slow...
04:09:31 <klange> Don't forget to run LaTeX twice to make sure all your references are correct.
04:10:17 <bluezinc> klange: I'm up to either 3 or 4 runs now.
04:10:20 <aalm> .theo
04:10:21 <glenda> Wow, so many crazy suggstions.
04:10:31 <klange> We really went off the deep end somewhere in compile times.
04:10:58 <bluezinc> I have to admit, LaTeX is the only language I've ever seen that you need to compile multiple times...
04:11:00 <klange> I can build a complete graphical OS from source in 10 seconds, but Qt5 takes four hours.
04:11:49 <klange> I have individual C++ files with cascading templates that take five minutes to build, and they're only a hundred or so lines.
04:11:59 <klange> Where did we go so wrong?
04:14:05 <izabera> is it the c++ part?
04:44:52 <AndrewBC> yes, in particular file accesses
05:44:39 <jjuran> Header-only libraries
05:45:53 <aalm> .roa
05:45:54 <glenda> 261 A wealthy man can afford anything except a conscience.
05:51:31 <pixelherodev> If I send the echo command to the PS/2 Keyboard command port and get 0xFA back instead of 0xEE, is that a problem?
05:52:03 <pixelherodev> Also, just to verify, I should read the response from the data port, not the command port, correct?
05:52:51 <Mutabah> data yes
05:52:56 <Mutabah> and iirc FA is ACK?
05:53:13 <pixelherodev> Yeah, but it says on the OSDev wiki that sending 0xEE (echo) should get 0xEE back
05:53:57 <pixelherodev> Am I supposed to delay between sending the command and reading?
05:54:31 <Mutabah> Don't always take the wiki as gospel
05:54:34 <pixelherodev> True
05:54:54 <pixelherodev> However, I commented out the `outb(KBD_COMMAND, 0xEE);` line and I still get 0xFA bacl
05:54:57 <pixelherodev> s/bacl/back/
05:55:03 <pixelherodev> Which causes me to suspect a problem
05:55:22 <Mutabah> If there's already a FA in the buffer, you'd get that :)
05:55:34 <pixelherodev> Yeah, but this is the first command I'm sending...
05:55:50 <Mutabah> Who knows what was sent before you
05:57:04 <pixelherodev> Is there a way to clear the buffer?
05:57:20 <pixelherodev> If I reset the keyboard, how long does it take to self-test?
05:58:13 <Mutabah> Read from the data port while the 'data available' bit is set
05:59:01 <pixelherodev> Ah, thanks for the tip
06:00:06 <Mutabah> It's worth remembering that there's two/three devices on those IO ports
06:00:18 <Mutabah> The PS2 controller and the keyboard/mouse/whatever
06:06:54 <pixelherodev> Still getting the same thing
06:07:44 <pixelherodev> Anyways, thanks for the help, I'll figure it out
06:07:46 <Mutabah> Even after flushing the recv fifo?
06:08:14 <pixelherodev> Yeah
06:08:30 <bcos> Even if you don't send "echo"?
06:08:31 <pixelherodev> while the lowest bit of `inb(KBD_COMMAND)` is set, reads from KBD_DATA
06:08:41 <pixelherodev> Yeah
06:08:46 <pixelherodev> Just tested that
06:08:49 <pixelherodev> Then again, this is in QEMU
06:08:55 <pixelherodev> Could that be it?
06:08:57 <Mutabah> And do you wait until that bit is set again before reading the echo response?
06:09:10 <pixelherodev> ... oops.
06:09:14 <pixelherodev> Thanks.
06:09:22 <Mutabah> quack
06:09:39 <Mutabah> actually, that's not rubber-duck debugging, unless it's a smart duck
06:13:04 <bcos> pixelherodev: Would recommend writing a small bunch of helper routines (e.g. "get byte from port A", "get byte from port B", "send byte to port A", ...) with time-outs, etc; then writing PS/2 controller initialisation; then writing keyboard driver
06:13:56 <pixelherodev> I have a working keyboard driver though
06:14:08 <pixelherodev> Data works fine
06:14:25 <bcos> It's only working until you try to write a mouse driver
06:14:32 <pixelherodev> That's not happening though
06:14:41 <pixelherodev> My kernel is a self-contained game
06:14:51 <pixelherodev> And that game doesn't want mouse input
06:18:21 <bcos> Wiggle the mouse during boot and see if that ruins your keyboard driver's initialisation..
06:18:24 <bcos> ;-)
06:19:07 <bcos> (mouse movement packets in response to "echo")
06:20:09 * pixelherodev palms face
06:20:28 <pixelherodev> Is the port the same for the controller as for the keyboard?
06:20:30 <pixelherodev> (for commands)
06:21:08 <Mutabah> yes iirc
06:21:12 <bcos> There's only one data port, and it can have data from "port A" or "port B"
06:21:33 <bcos> ..unless you disable one of the ports in the PS/2 controller
06:21:45 <pixelherodev> Wait, so commands for the device are written *to the data port*?
06:21:54 <bcos> Yes
06:22:01 <pixelherodev> There we go then
06:22:03 <pixelherodev> OOps
06:22:17 <pixelherodev> Yeah, works now
06:22:18 <pixelherodev> Thanks!
06:23:29 <pixelherodev> But yeah I see your point about initialization
06:23:46 <pixelherodev> even just typing while booting up causes a kernel panic
06:23:51 <pixelherodev> I'll fix that now
06:24:12 * bcos wrote this: https://wiki.osdev.org/%228042%22_PS/2_Controller#Initialising_the_PS.2F2_Controller
06:24:44 <pixelherodev> I know
06:24:47 <pixelherodev> I'm looking at it rn
06:24:48 <bcos> ..after months of testing on multiple computers and ending up with code that handles "hot-plug any device in any hole"
06:24:49 <pixelherodev> Thanks :)
06:24:57 <bcos> :-)
06:27:57 <pixelherodev> Is there a reasonable method of doing this without PCI or ACPI support?
06:28:32 <pixelherodev> s/PCI/PCI + USB/
06:29:58 <bcos> You'd only need to find a flag in an ACPI table (don't need PCI and don't need a full ACPI AML interpreter)
06:30:24 <pixelherodev> It says that USB needs to be initialized though?
06:30:39 <bcos> Ah
06:31:19 <bcos> USB needs to be detected and then "legacy emulation" disabled; but you don't need more than that
06:31:45 <bcos> (at least not for PS/2 - you'd need a lot more for USB keyboards)
06:32:05 <pixelherodev> Uh - I'm using PS/2 keyboards
06:32:10 <pixelherodev> Wait oops
06:32:10 <pixelherodev> USB*
06:32:14 <pixelherodev> I'm using USB keyboards
06:32:28 <pixelherodev> I'm sort of relying on that legacy emulation...
06:33:06 <pixelherodev> And I can't really afford to write a full USB KB driver now - esp. as I have 2 weeks left to work on this project
06:34:29 <bcos> In that case you've mostly got 3 choices: write USB controller + USB keyboard driver; initialise PS/2 controller properly and suffer from buggy PS/2 emulation in firmware; or don't initialise PS/2 controller properly and and risk problems caused by "under-initialisation"
06:34:44 <bcos> 2 weeks?
06:34:45 <pixelherodev> I'm going to have to go with choice two for now
06:34:46 <pixelherodev> Yeah
06:34:50 <pixelherodev> This is for a game jam :P
06:35:27 <bcos> Ah - in that case I'd suggest the last choice
06:35:40 <pixelherodev> Why?
06:36:48 <bcos> For game jam you don't need to care about things like hardware faults, or unusual computers, or reliability, or..
06:37:06 <bcos> (it might only need to work once on one computer!)
06:37:51 <pixelherodev> Not really - It needs to be able to be reliably emulated via any VM (QEMU, bochs, VirtualBox, etc), including the HTML5 one I plan on using for the page
06:37:55 <pixelherodev> s/page/webpage/
06:38:16 <pixelherodev> Also needs to be able to reliably run on any real hardware from CD/USB for those who want to use it that way
06:38:29 <pixelherodev> And option two doesn't really cost much to do
06:38:29 <bcos> 2 weeks?
06:38:38 <pixelherodev> Yeah?
06:38:50 <pixelherodev> It's mostly good to go - all that needs to be done is the game itself
06:39:11 <pixelherodev> malloc/free, VGA mode 3, (mostly) the keyboard, etc all work
06:39:30 <bcos> So.. 13 days doing PS/2 controller and keyboard initialisation, then the whole rest of the game done in 1 remaining day; or...?
06:39:48 <pixelherodev> It shouldn't take 13 days to do this
06:40:26 <pixelherodev> It shouldn't take more than 13 minutes if I focus AFAICT
06:41:24 <bcos> OK - 13 minutes starting from now! :-)
06:42:40 <mischief> like, game over, man
06:43:14 <aalm> .theo
06:43:14 <glenda> Oh are you just talking?
06:49:17 <pixelherodev> Done
06:49:37 <bcos> Plug the keyboard in "port B" (so there's nothing in "port A")..
06:49:49 <pixelherodev> Huh?
06:50:12 <bcos> PS/2 controller has 2 ports ("port A" and "port B") - you can plug the keyboard in any port..
06:50:24 <pixelherodev> Wait, what?
06:50:35 <pixelherodev> You can?
06:50:39 <bcos> Yes
06:50:40 <pixelherodev> But I'm using USB keyboards...
06:51:02 <bcos> How many computers did you test it on?
06:51:08 <pixelherodev> A few so far
06:51:12 <pixelherodev> Haven't tested the updated code yet
06:51:38 <pixelherodev> I plan on testing it on three computers later, one of which is a laptop, and one of which has an actual PS/2 kbd
06:51:38 <bcos> Would want to test it on several with USB keyboards + several with PS/2 keyboards
06:51:47 <bcos> Cool
06:51:54 <bcos> ..so not done yet
06:52:28 <pixelherodev> I can test the USB keyboard in the laptop and the computer that has the PS/2 kbd
06:52:44 <pixelherodev> But I only have one accessible computer with an actual PS/2 port
06:54:47 <bcos> Should probably also test on a computer that doesn't have any keyboard plugged in, to make sure you get a nice "No keyboard found, press F1 to continue"
06:55:31 <bcos> (which sounds like a joke, but isn't)
06:56:26 <bcos> ( https://www.reddit.com/r/pcmasterrace/comments/39wvgq/well_til_why_keyboard_not_found_press_f1_to/ )
06:59:30 <pixelherodev> I also found a bug in my memory allocation thanks to real HW testing
06:59:48 <pixelherodev> Apparently, GRUB on my server hands over the same block multiple times in the memory map
07:00:15 <pixelherodev> Which I realized when I got two "Warning, block containing kernel found, skipping 0xXXXXX bytes"
07:00:18 <pixelherodev> messages
07:00:48 <bcos> That's a bit.. hrm. GRUB mostly just forwards info from BIOS ("int 0x15, eax = 0xE820") without caring what it is
07:02:08 <pixelherodev> I know, it's weird
07:02:49 <pixelherodev> It's even weirder because based on those messages the two blocks are of differing sizes
07:03:05 <pixelherodev> I'm going to have to have it dump the mmap to get a better understanding of what's going on
07:03:27 <mischief> sometimes the e820 can be fucked up
07:03:37 <mischief> its best if you sort it and check for problems
07:04:19 <pixelherodev> Yeah
07:04:38 <pixelherodev> Unfortunately, as a server, this takes a minute to boot up, so I can't rapidly test it the way I can QEMU
07:05:14 <mischief> i mean, you can just write the code to do it and make sure it works in qemu.
07:05:26 <mischief> (and maybe patch qemu to hand off a bad e820)
07:05:34 <pixelherodev> *That's* not happening
07:05:44 <pixelherodev> I'm not getting into the QEMU internals
07:05:59 <mischief> its not that complicated.
07:06:05 <pixelherodev> That's not what worries me
07:06:07 <pixelherodev> I've already started played with compiler hacking lately (patched a SDCC bug)
07:06:11 <pixelherodev> I don't need to get distracted
07:16:30 <pixelherodev> That's odd
07:16:38 <pixelherodev> The last mmap is the entire address space
07:16:57 <pixelherodev> *and is marked with type 1 (usable)*
07:17:57 <pixelherodev> Well, it's 64GB, but that's definitely more RAM then I have...
07:30:52 <jjuran> Am I missing something, or is glibc's use of a flexible array member in cmsghdr broken?
07:40:01 <mrvn> bcos: the error message is still stupid. Should have said: Connect keyboard before power on
07:40:27 <bcos> It's hot-plug..
07:40:45 <bcos> (plug keyboard in, press F1 - no reboot)
07:40:54 <bcos> (or alternatively switch your KVM over)
07:41:02 <mrvn> bcos: no, it's not. PS/2 will easily fry your chip when you hot-plug it
07:41:31 <bcos> No, it won't (only a few rare and ancient computers were potentially borked)
07:43:24 <mischief> jjuran: whats the problem with it?
07:44:37 <jjuran> mischief: (a) Flexible array members aren't valid C++
07:45:19 <jjuran> (b) It breaks perfectly reasonable code like `struct foo { cmsghdr header; int data; };`
07:47:05 <jjuran> (c) It's not clear what value is purportedly being added.
07:51:22 <mrvn> jjuran: cmsghdr must only be accessed through the macros.
07:51:32 <mrvn> So `struct foo { cmsghdr header; int data; };` isn't valid code.
07:51:53 <jjuran> mrvn: Okay, how do I allocate one on the stack?
07:52:01 <mrvn> you can't
07:52:02 <jjuran> alloca()?
07:52:26 <jjuran> Okay, how do I allocate one at all?
07:52:29 <mrvn> jjuran: alloca() in c++?
07:53:19 <mrvn> you could use: uint8_t mem[CMSG_SPACE(lenght)];
07:53:46 <mrvn> But that might not have the right alignment. So you have to add CMSG_ALIGN(length) and align it
07:54:02 <mrvn> s/SPACE/LEN/
07:54:27 <jjuran> The definition of CMS_SPACE() I looked at uses __CMSG_ALIGN() internally.
07:55:48 <jjuran> So one fork of my hybrid solution will be a union with a cmsghdr and a spaced buffer.
07:56:15 <mrvn> jjuran: Look at the example in cmsg(3). A union is exactly what they use.
07:56:23 <jjuran> Unfortunately, Apple's g++ 4.0 thinks that `CMSG_SPACE(sizeof (int))` isn't a constant integer expression.
07:56:58 <mischief> (thanks apple)
07:57:18 <mrvn> because of sizeof() or CMSG_SPACE?
07:57:43 <jjuran> Who knows? Who cares?
07:57:50 <jjuran> But presumably the latter.
07:57:58 <mrvn> use a current gcc
07:58:39 <jjuran> No, for OS X development I use Apple's compiler.
08:01:34 <klange> "Apple's compiler" is clang.
08:01:40 <klange> > OS X
08:01:45 <klange> Use an actually modern OS, I would suggest.
08:02:49 <jjuran> I do.
08:06:29 <jjuran> Surely you weren't under the assumption that a person only uses and develops for exactly one OS?
08:06:56 <klange> No, I'm suggesting that you are three releases outdated.
08:07:36 <klange> That said, El Capitan does have an update from as late as June of this year, so perhaps I'm being overzealous.
08:08:17 <jjuran> Apple shipped g++ 4.0 with Mac OS X 10.4 and 10.5.
08:09:29 <klange> And here I thought you were reporting a clang version of 4.0, which would have made sense as it was released last year.
08:09:38 <geist> the last official version they shipped was 4.2.1, since that was the last gplv2
08:09:51 <geist> i think they held onto that gcc for a while until they were ready to flip over to clang
08:10:11 <jjuran> The reason I use g++ 4.0 in 10.5 is because the 4.2 was unusable.
08:10:27 <geist> and the reason you use 10.5? is this on a PPC box?
08:10:39 <klange> If you're seriously talking about 10.4 or 10.5 I assume you're on a PowerPC Mac.
08:10:52 <jjuran> You couldn't use a static class member function as a template parameter, because it's static! Get it?
08:10:52 <klange> In which case you're still talking about software that was last updated in 2009 and is definitely not modern.
08:11:47 <geist> released about 2006 or so
08:11:59 <geist> i think 10.5 was the last ppc version?
08:12:11 <geist> 10.4.something was the first x86 version i think
08:12:13 <jjuran> geist: I have one each PPC and x86 running 10.5, but mostly g++ 4.0 support is for PPCs running 10.4 plus Classic.
08:12:23 <klange> 10.5, last updated with 10.5.8 in August 2009, was the last release to support PowerPC.
08:12:36 <geist> word
08:13:27 <klange> Support for 10.5 ended... around when I started at Apple.
08:15:36 <geist> yah, i was at apple when they released the x86 build
08:15:59 <geist> most folks still had ppcs even a year afterwards
08:17:04 <jjuran> Alas, poor Metrowerks
09:08:16 <pixelherodev> I take back what I said
09:08:26 <pixelherodev> `It shouldn't take more than 13 minutes if I focus AFAICT` It works perfectly well under QEMU
09:08:37 <pixelherodev> But doesn't work right on either real computer I tried it on
09:08:49 <pixelherodev> Guess I'll stick with trusting the firmware
09:55:30 <geist> pixelherodev: i missed the context
10:01:07 <radens> hey are there slick scripts for debugging the linux kernel?
10:01:17 <radens> This experience just doesn't compare to windbg
10:08:47 <mrvn> radens: like attaching gdb to the kernel remotely?
10:14:17 <pixelherodev> geist, PS/2 keyboard initialization
10:14:35 <pixelherodev> Apparently, either 0xAA or 0xAB to the PS/2 controller on my server is causing the keyboard to stop working
10:14:39 <radens> mrvn: I've got qemu debugging set up on a vm
10:14:47 <pixelherodev> No idea why
10:15:07 <radens> shit's going off the rails and I have no clue why. I have symbols, but those are less help than I'd helped.
10:16:01 <pixelherodev> Can't you start qemu with `-S -s` and then attach gdb?
10:16:07 <pixelherodev> Ah
10:18:40 <pixelherodev> I can confirm that this resets https://wiki.osdev.org/%228042%22_PS/2_Controller#Step_6:_Perform_Controller_Self_Test
10:19:02 <pixelherodev> Does so on my 2007 server
10:20:10 <radens> pixelherodev: that's what I'm doing
10:20:25 <radens> I just want better insight into what's going on in the system
10:20:32 <pixelherodev> Yeah, I realized that hence the `Ah`
10:20:51 <pixelherodev> Oh, and I'm fairly certain my 2016 laptop gets reset by 0xAA also
10:21:22 <radens> for instance there's something at RIP=fffffe000000601e causing all sorts of problems. The symbols don't tell me anything. I have a hunch it's KPTI related, but I'm not sure.
10:24:37 <SopaXorzTaker> Does QEMU emulate rtl8168?
10:24:40 <SopaXorzTaker> If not, what does?
10:25:43 <radens> https://pastebin.osuosl.org/1291366/ Get a load of this code. It's got to be a syscall entry trampoline
10:25:53 <radens> they're moving cr3 to rsp
10:31:32 <SopaXorzTaker> I have some suspicion that rtl8168/9 is compatible with rtl8139
10:32:40 <radens> lol my hypervisor entry code doesn't handle mov rsp, cr3 properly. Shocking.
10:37:29 <SopaXorzTaker> Hmm, I wonder what happens if I try using an RTL8139 driver against a real, RTL8168 NIC
10:37:50 <lkurusa> cc: error: ../../binutils-2.31.1/gprof/flat_bl.m: Objective-C compiler not installed on this system
10:37:54 <lkurusa> wow wtf
10:39:11 <lkurusa> maybe i can disable gprof..
10:41:36 <pixelherodev> I thought Objective C was just a myth!
10:42:21 <pixelherodev> Yeah, PS/2 initialization works now
10:42:34 <pixelherodev> Just had to set the configuration byte manually after running the self-test
10:52:33 <olsner> lkurusa: that seems to be some kind of documentation, it should be converted to c files by a rule in the makefile
10:53:55 <lkurusa> i don't know... compiling on an exotic platform so something can break
10:54:01 <lkurusa> dragonflyBSD to be exact
11:26:41 <rakesh4545> hoy!
11:27:22 <rakesh4545> I want to know how the drivers for toaruos were created..
11:28:38 <klange> What do you mean?
11:29:23 <klange> My colleagues and I read specs... and wrote the drivers.
11:31:02 <rakesh4545> where you found specs.
11:31:58 <lkurusa> the ever wonderful google
11:32:45 <klange> The Internet? Specs for the NICs we have drivers for are all listed on the osdev wiki. The AC'97 driver links to some docs in a comment towards the top. The VM extension drivers were hacked together by reading sources of the VMs they're for, or by reading through reference implementations from the VM devs (mostly in the case of vmware)
11:33:53 <klange> Hm, darn, the AC'97 link is dead.
11:34:23 <klange> Though "intel ac97 spec" finds it elsewhere.
11:35:27 <lkurusa> it's amazing how far reading can get you :)
11:35:46 <lkurusa> rakesh4545: after a while, reading specs will become easier
11:36:08 <rakesh4545> Okay. I will try soon.
11:46:56 <ybden> Don't tell anyone. They are Batman.
02:24:26 <abysslurker> o/
05:40:45 <pixelherodev> Wait, *they* are batman? How can they *all* be Batman?
05:41:34 <aalm> .theo
05:41:34 <glenda> I think this will cause further damage.
05:41:38 <aalm> .roa
05:41:38 <glenda> 266 When in doubt, lie.
05:43:21 <aalm> batmen
05:51:50 <AndrewBC> .roa
05:51:50 <glenda> 203 New customers are like razor-toothed gree-worms. They can be succulent, but sometimes they bite back.
05:53:09 <aalm> .ken
05:53:10 <glenda> It's always good to take an orthogonal view of something. It develops ideas.
05:55:09 <pixelherodev> bcos, I updated step six in the wiki https://wiki.osdev.org/%228042%22_PS/2_Controller#Initialising_the_PS.2F2_Controller based on my testing
05:56:07 <bcos> pixelherodev: Cool :-)
06:01:18 <pixelherodev> Oh yeah, thanks for all the help last night, and thanks for writing that
06:01:22 <pixelherodev> Made finding the problem a lot easier
06:01:57 <bcos> :-)
06:31:16 * abysslurker yawns
06:33:24 <rakesh4545> heelo
06:41:27 <abysslurker> o/
06:41:51 <rakesh4545> \o
06:47:29 <rakesh4545> I was thinking about mk2018....
07:03:53 <bcos> I was thinking about "ISO" CD/DVD images
07:04:42 <bcos> (specifically, how hard it'd be to create CDs that can't be stored properly as a "sector contents with no metadata" ISO file)
07:30:16 <geist> SopaXorzTaker: they're not
07:30:24 <geist> 8139 and 8168
07:31:00 <geist> 8169 is much more of a proper descriptor based tx/rx design, basically required for 1gb
07:31:13 <geist> 8139 is a very old, pretty crummy design even for 100mbit
10:39:25 <andrewrk> what improvement can be made to `hang: b hang` on aarch64 for unused cores?
10:39:38 <andrewrk> is there a way to stall using low power or something?
10:50:55 <immibis> almost certainly, most architectures have one
11:12:50 <mrvn> Note to self: Don't clear .bss after setting up the page tables
11:13:20 <mrvn> andrewrk: ARM has a wfe/wfi as well as power management
11:13:46 <mrvn> unused cores should be powered down. idle cores should wfe/wfi
11:25:49 <radens> the linux kernel module loader inlines local_interrupts_enable. callq *0x0 becomes sti followed by a wide nop.
11:34:47 <andrewrk> mrvn, thanks. I'll try to figure out how to power down a core