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=19&m=5&d=18

Saturday, 18 May 2019

12:09:01 <robert_> doug16k: Updated my code.
12:09:32 <robert_> you mean kind of like that?
12:10:11 <robert_> thanks, btw. :D
12:10:12 <Kazinsal> Weird thought: Everyone likes to write a Unix as their first "serious" OS. I have not. Maybe I should write a Unix... for the IBM PC/XT.
12:10:53 <robert_> haha
12:11:08 <robert_> I'm writing an ELF-based knockoff of Windows NT 3/4
12:12:20 <robert_> I find early Windows fascinating and wonder what it could have been if you had basically done that but with ELF instead of PE
12:32:09 <adu> wow
12:32:57 <robert_> because I'm a masochist apparently, haha
12:33:08 <adu> well, I want UEFI in ELF
12:33:26 <adu> not too crazy, I suppose
12:36:32 <adu> I've learned so much about A20 I need to brain dump
12:45:38 <robert_> haha
12:45:45 <robert_> trying to get people to help out :p
12:46:07 <adu> The worst implementation I've seen is himem.sys
12:46:36 <adu> It's got like 6 implementations of A20
12:47:34 <robert_> lmao yeah
12:47:56 <robert_> if you PM me, I can tell you what I'm trying to accomplish. :p
12:48:01 <robert_> (brb though)
12:50:44 <adu> a20_bios() || a20_pc_at_kbc_slow() || a20_pc_at_kbc_slower() || a20_ps2_kbc_fast() || a20_att_6300() || a20_hp_vectra()
12:51:01 <adu> for some reason, no kernels seem to implement the last 2 methods, anymore
01:14:52 <doug16k> robert_, yeah that looks good
01:15:11 <doug16k> some might argue writable and executable at the same time is a bad idea and shouldn't be allowed
01:15:29 <doug16k> i.e., if writable it is automatically not executable
01:15:38 <robert_> oh
01:15:44 <doug16k> but it's ok as is
01:15:50 <robert_> yeah
01:15:53 <doug16k> just a bit permissive
01:15:56 <robert_> probably will toggle that
01:15:57 <robert_> yeah
01:16:10 <robert_> My first order of business is understanding this mess
01:16:26 <robert_> and then I'll get around to writing an idealized variant of it :p
01:17:09 <robert_> huh, the Vectra has an A20 different from the spec?
01:17:15 <robert_> adu ^
01:18:27 <doug16k> I vaguely remember trying vectra thing on some machines locks it up
01:18:46 <doug16k> overall I'd say screw vectra, find a balcony with concrete and nobody standing below
01:19:14 <doug16k> would any be working anymore? what year is that
01:19:57 <robert_> lmao
01:20:44 <robert_> what is the Vectra anyway, a 386?
01:20:50 <doug16k> ya
01:20:58 <robert_> ah that explains it
01:21:18 <doug16k> the vectra has a nonstandard a20 and it doesn't support the bios method?
01:21:42 <doug16k> I guess "send microsoft an email" was their way of handling the a20 thing?
01:22:30 <doug16k> nuts
01:22:33 <robert_> besides if our A20 doesn't work on some randomly obscure piece of hardware running like freedos (because originally, I want something I can use to test my code in "production", yeah?) then fuckit
01:23:04 <robert_> my development style is iterative, not going "whole-hog"
01:23:16 <doug16k> you can't actually test a20 code properly in qemu unless you build a custom seabios that defaults to a20 off
01:23:26 <robert_> besides if I can coopt the dos bootsector to do my coding, then yeah
01:23:35 <robert_> humm
01:23:52 <robert_> guess we'll have to do that then
01:23:56 <doug16k> don't worry about a20, realistically your code will check a20 and it is on and never thinks about a20 again
01:24:14 <doug16k> only fairly old machines could have it off
01:24:47 <robert_> yeah my target machines for code that could exist on freedos could have it disabled, though
01:25:04 <doug16k> ya freedos is trying to be "old" on purpose
01:25:39 <doug16k> er not freedos, I mean, emulators for dos era machines are being old on purpose
01:25:48 <robert_> (386 and 486 machines, the advanced NT-clone stuff, I'll require Pentium II on purpose, to avoid things like CMPXCH8B)
01:26:12 <doug16k> ya, 686 is a reasonable expectation
01:26:21 <robert_> basically we'll be looking for PAE
01:26:28 <doug16k> need cmov to avoid branching every decision point in the program
01:26:33 <robert_> if you don't have it, you ain't running it haha
01:26:36 <robert_> yes
01:27:12 <robert_> anyway
01:27:14 <robert_> so hm
01:27:23 <doug16k> I have a check for 8088, 80286, 80386, 80486 without cpuid, and specifically say it can't run this OS :)
01:27:31 <robert_> yeah :p
01:27:42 <doug16k> for a laugh. realistically they can't boot off the boot media unless you help it
01:28:24 <doug16k> 286 won't boot from a CD
01:28:56 <robert_> and the kernel though is a microkernel; meaning I want to keep it stupidly simple. Basically it exists to be a target for the PIT, handle memory allocations and manage paging. And that's IT. Everything else will live as a POSIX service
01:29:16 <robert_> and the graphical environment will live alongside that
01:29:16 <doug16k> threads
01:29:36 <robert_> "a target for the PIT"
01:29:44 <doug16k> PIT?
01:29:52 <doug16k> APIC timer is far superior
01:30:15 <robert_> I lump it all together under the umbrella PIT term :p
01:30:17 <doug16k> how can PIT do multiple CPUs?
01:30:31 <doug16k> other than horribly :D
01:30:36 <robert_> :p
01:30:57 <robert_> but yeah APIC will be used specifically, but it's still technically a PIT
01:32:08 <doug16k> oh ok
01:32:15 <doug16k> I've been adding timeout to my condition variable wait
01:32:36 <doug16k> I realized that sleeping and suspended are redundant states for a thread. suspended indefinitely should just be an infinite sleep
01:44:09 <adu> robert_: yes
01:45:52 <adu> doug16k: I would say screw the PC/AT slow KBC way, in the UEFI/EDK2 source code, they only do a20_bios() || a20_ps2_kbc_fast()
01:47:42 <adu> and I suspect that when they get rid of of the CSM that they will probably only do a20_ps2_kbc_fast()
02:02:06 <doug16k> not all processors even have a20 hardware
02:02:13 <doug16k> on many machines it is on because there is no off
02:05:23 <adu> on which machines?
02:05:37 <doug16k> intel machines since about haswell
02:05:59 <doug16k> or was it nehalem
02:06:10 <doug16k> nehalem I think actually
02:06:22 <doug16k> ~2007?
02:07:11 <adu> "Support for the A20 gate was changed in the Nehalem microarchitecture (some sources incorrectly claim that A20 support was removed)"
02:07:17 <adu> is that what you're talking about?
02:07:30 <adu> -- <https://en.wikipedia.org/wiki/A20_line>
02:07:30 <doug16k> yes
02:08:16 <doug16k> ah so both of my memories were about right. it started to get iffy at nehalem and gone in haswell
02:08:37 <adu> not supported and gone are not the same thing
02:08:43 <doug16k> they are
02:08:59 <doug16k> if the internal caches aren't doing it, it is gone
02:09:49 <doug16k> why are we arguing about irrelevant historical details?
02:10:01 <doug16k> realistically A20 check will say A20 already on and you do nothing
02:10:50 <doug16k> if A20 is off, print "you won the A20 lotterly, please email xxx to claim your prize", and turn it on and off when you go into and out of your protected mode code
02:12:10 <doug16k> I actually tried it
02:12:32 <doug16k> I have a DOS 6.22 partition on my ryzen 2700x machine
02:13:00 <doug16k> works but screws up win 3.1
02:13:03 <doug16k> doom works
02:13:41 <doug16k> 3.1 standard mode works
02:14:08 <doug16k> can't load emm386.exe
02:14:22 <doug16k> try it
02:14:43 <doug16k> I mean on some newish machine you have kicking around
02:15:32 <adu> huh, the pin is gone
02:16:03 <doug16k> it isn't needed anymore. you can emulate it with paging and v86
02:17:54 <doug16k> you should see win 3.1 load @ 3.9 - 4.25 GHz on nvme 960 pro ssd. you type "win", hit enter, and that very instant, it is finished and program manager is waiting for you to do something
02:18:12 <adu> I have a Intel® Core™ i3-3220 (3rd-gen, Ivy Bridge)
02:18:51 <doug16k> would be just as instant I think
02:19:05 <adu> but that was pre-haswell
02:19:30 <doug16k> sure, but do you really think some old 64KB bios is doing wraparound tricks to save cycles?
02:20:11 <adu> oh no, I mean the a20_ps2_kbc_fast() method would probably work fine
02:20:12 <doug16k> I'll be amazed if you tell me your code sees A20 off at boot time
02:20:29 <doug16k> it would work fine if you even call it
02:20:34 <doug16k> A20 will be on already, almost for sure
02:20:48 <doug16k> don't touch A20 if it was already on
02:20:50 <adu> I don't know, worth a try, I'm still working on all the rest, sfdisk/nasm mumbo jumbo
02:21:00 <doug16k> check whether it is already on. it is? ok don't touch A20 ever
02:21:12 <doug16k> don't even mention it to the bios
02:22:46 <doug16k> it is not a good idea to poke at the "keyboard controller" (almost certainly nonexistent other than some legacy support emulated SMI crap) unless you have a reason to touch it
02:24:18 <doug16k> it looks like you have all the freedom in the world to do whatever, but realistically, machines will only reliably support the things needed to boot windows
02:24:36 <doug16k> if windows doesn't do it, you're on your own, nobody tested that
02:25:42 <adu> I don't own windows
02:25:58 <doug16k> good. too bad computer manufacturers think windows is the only OS
02:26:18 <doug16k> er, have for the last 30 years
02:26:42 <adu> I have 3 macs, 2 linux boxen, and 3 non-functional laptops
02:26:59 <adu> on and 1 chromebook
02:27:05 <adu> on -> oh,
02:46:42 <adu> "everything is deeply intertwingled"
02:49:03 <adu> what's the in memory structure called that glibc malloc uses?
03:24:36 <adu> huh
03:25:29 <immibis> i don't know, look up glibc malloc
03:25:58 <adu> it's very simple, it seems to be called ptmalloc_chunk
03:26:48 <adu> start/length where 3 bits of the length are used for special purposes, which required 8 byte alignment
03:27:36 <adu> I was just wondering about that HP "The Machine" thing where you have 1 million TB of ram and no HD
03:28:06 <adu> there would be no difference between malloc and touch
03:28:49 <adu> and so perhaps someone will write mallocfs someday, so I figured I'd get started on that
03:29:56 <adu> conversely, maybe someone might want to mount their memory for debugging purposes
03:39:33 <immibis> isn't mallocfs just called tmpfs?
03:41:14 <bcos> "The Machine" is mostly likely designed for persistent objects ("objects" in the OOP sense); and not designed for anything written in C or C++, and not having file systems and not having malloc
03:42:47 <adu> I wonder how hard it would be to implement a tmpfs_malloc
03:45:21 <bcos> adu: Where you use tempfs to allocate file system space, and then need to use something like malloc to figure out where you can map that space into your own process?
05:19:05 <Kazinsal> Anyone have a recommended self-hosting 8086 assembler? Looking to do a little something weird for a PC/XT.
05:53:57 <adu> bcos: perhaps
09:06:38 <doug16k> Kazinsal, I have fond memories of turbo c. tasm
09:07:14 <doug16k> they aren't kidding about turbo either, amazingly quick for that awful cpu
09:08:06 <doug16k> I had one. it's the I/O delays that kill it, the cpu isn't bad
04:22:27 <johnjay> hmm any suggestions for investigating how grub handles the MBR?
04:22:37 <johnjay> i want to test it in a virtual machine after i foobar'd my system yesterday
04:22:51 <johnjay> fortunately i managed to repair it
04:23:51 <bcos> Handles the MBR how
04:23:52 <bcos> ?
04:24:08 <bcos> (like, when GRUB is installed?)
04:24:57 <johnjay> just in general
04:25:07 <johnjay> i think what i did wrong is i deleted the first partition in grub's list
04:25:22 <johnjay> so then i couldn't boot at all and grub rescue i couldn't get to work
04:25:30 <bcos> That shouldn't effect GRUB itself, or the MBR
04:25:49 <johnjay> well ok i'll tell you what i did and you can give me your best guess then
04:25:53 <bcos> Even deleting the first partition in the MBR's partition table wouldn't effect GRUB
04:26:04 <johnjay> i have 2 windows partitions on drive 1 and a linux partition on drive 2 (not sure if GPT or not)
04:26:35 <johnjay> i used the freebsd installer to delete everything on drive 2 and then install freebsd to one of several partitions on it
04:26:50 <clever> i think it may cause more harm if you renumber the partitions
04:26:54 <johnjay> restart, grub gives an error about not finding an ID and goes to rescue mode
04:27:21 <johnjay> i also changed drive 2 to GPT explicitly
04:27:24 <johnjay> not sure what it was before
04:27:28 <johnjay> maybe mbr
04:27:31 <clever> i think it has the partition# of the /boot/ partition in the stubs
04:27:38 <clever> GPT also needs a bios boot partition
04:27:57 <johnjay> hmm. i was about to try rebooting and see if i can use the UEFI to boot from drive 2
04:28:08 <johnjay> the thing is i'm not sure how i can get into freebsd
04:28:17 <bcos> GPT needs a BIOS boot partition (GRUB needs)?
04:28:30 <johnjay> i installed ubuntu to drive 2 in another part and forced it to write a MBR on drive 1
04:28:30 <bcos> (UEFI needs a UEFI system partition?)
04:28:32 <clever> yeah, any legacy bootloader really
04:28:42 <johnjay> but the resulting grub menu only shows windows and linux, not the freebsd
04:29:10 <bcos> johnjay: Ok - sounds normal so far
04:29:31 <johnjay> by the way the freebsd installer forces you to make a small 512K boot partition for some reason. :/
04:29:32 <clever> johnjay: another way you could break things with MBR, is if you dont leave a gap after sector 0
04:30:23 <johnjay> but the layout of drive 2 is like 64GB ext4, 32GB, 32 GB, 512K, 32GB, 4.0GB, 32GB...
04:30:36 <johnjay> that 512K, 32GB, 4.0GB is what freebsd installed to
04:30:48 <johnjay> was that 512K supposed to be at the start of the drive?
04:30:53 <johnjay> i think that's the size of the MBR...
04:31:22 <clever> the MBR is only 512 bytes, and is always at sector 0
04:31:25 <bcos> That 512K would probalby just be a freeBSD partition (mounted at "/boot/")
04:31:26 <johnjay> ok
04:31:39 <johnjay> so how did my system die then?
04:31:49 <johnjay> the error was something like cannot find partition id 23493-3-43-43-4-34-33
04:31:52 <bcos> Which what died?
04:32:02 <johnjay> i couldn't boot and grub went to rescue mode
04:32:16 <johnjay> so i had to install ubuntu and force the mbr repair to get back into windows
04:32:28 <bcos> After you deleted the old Linux on drive 2, it couldn't find the old Linux with partition id 23493-3-43-43-4-34-33 ?
04:32:48 <clever> oh
04:32:51 <johnjay> bcos: i'm not sure, that's why i wanted to know more about how grub works.
04:32:59 <clever> it could be that you where chain-loading windows, via the /boot/ partition of linux
04:33:04 <clever> and when you deleted /boot/ you broke grub
04:33:06 <johnjay> i think so yes
04:33:13 <johnjay> but the thing is
04:33:20 <bcos> Eww
04:33:25 <johnjay> i thought grub was installed to drive 1. and i deleted the linux partition on drive 2
04:33:29 <johnjay> so i was confused why i couldn't boot
04:33:38 <clever> any time i'm installing an OS i dont fully control, i unplug all other boot devices
04:33:43 <clever> so they remain seperate
04:34:02 <johnjay> that's not bad idea
04:34:40 <johnjay> clever: so the best guess is that i had grub on the mbr of drive 1. chain loading linux on drive 2 and windows on drive 1
04:34:40 <clever> if you dont know exactly what its going to do, dont give it enough rope to hang itself :P
04:34:45 <johnjay> and deleting drive 2 caused it to fail?
04:34:56 <clever> that is possible
04:35:12 <johnjay> drive 1 is my windows drive and drive 2 is an SSD for linux stuff
04:35:14 <johnjay> if i didn't make that clear
04:35:33 <clever> i have had a similar mess before, when i was dual-booting both from 1 drive
04:35:38 <clever> and then later migrated linux to its own disk
04:36:28 <johnjay> when you say grub needs /boot... does that mean a literal file system with a /boot mount folder?
04:37:04 <johnjay> i could see (hd0,msdos5) in the grub rescue menu but i couldn't get the syntax to make it boot windows for me
04:37:18 <clever> when you run grub-install, the uuid of the /boot partition is baked into a blob outside any partition
04:37:40 <johnjay> uuid meaning from the linux you're running in? is that why i can't grub-install from a ubuntu live cd?
04:37:59 <clever> -rw-r--r-- 1 root root 26K Sep 17 2018 core.img
04:38:08 <clever> the uuid of the /boot filesystem
04:38:16 <clever> -rw-r--r-- 1 root root 3.5K Sep 17 2018 chain.mod
04:38:31 <clever> it then needs things like chain.mod, to even know how to chainload windows
04:38:35 <clever> which it will find on /boot/
04:39:59 <johnjay> hrm... so do i need to use a different approach like fixmbr
04:40:07 <johnjay> if i'm on a ubuntu live cd trying to fix a broken grub?
04:40:31 <clever> you cant fix the grub mbr until you have a filesystem with the rest of the grub files, which you will treat as /boot/
04:40:52 <clever> if you dont want to involve linux, you could tell windows to (somehow) fix the mbr, and then windows will be back in control of that disk
04:40:55 <johnjay> hence why installing ubuntu onto the second drive brought it back, gotcha
04:41:03 <clever> https://gist.github.com/cleverca22/10101fc45a2b53056bdc07f3ff1e9837
04:41:14 <clever> at the start of everything, you have the boot code in sector 0, which is 512 bytes long
04:42:30 <clever> the code in that MBR, comes from https://github.com/coreos/grub/blob/2.02-coreos/grub-core/boot/i386/pc/boot.S
04:42:55 <clever> https://github.com/coreos/grub/blob/2.02-coreos/grub-core/boot/i386/pc/diskboot.S
04:42:58 <clever> or possibly here
04:43:01 <clever> floppy vs hdd
04:43:43 <clever> [root@amd-nixos:~]$ dd if=/dev/sda of=sda-mbr bs=1 count=512
04:43:51 <clever> this will read the MBR into a dedicated file
04:44:04 <johnjay> ah yeah that's very small
04:44:12 <johnjay> no wonder the whole grub program can't fit in there
04:44:33 <clever> objdump -D -b binary -mi386 -Maddr16,data16 sda-mbr
04:44:38 <clever> and this will then dis-assemble it
04:45:02 <johnjay> i probably can't do that on this box though. it's a raspi3
04:45:10 <johnjay> so i'd need to go back to ubuntu
04:45:32 <clever> you would need to install a cross-compiler, and get a copy of an x86 MBR to disassemble with the cross-compiler
04:45:57 <johnjay> i didn't think cross compilers disassembled
04:46:42 <clever> the tools go both ways
04:47:02 <clever> you just need the binutils that target x86, its objdump can also disassemble x86
04:47:04 <clever> https://github.com/coreos/grub/blob/2.02-coreos/grub-core/boot/i386/pc/diskboot.S#L412-L419
04:47:15 <clever> the key part, is these lines of the MBR code
04:47:36 <clever> when you run grub-install, it will copy a stage 1.5 somewhere else (not in the MBR), and then put the address of that into the MBR, at those offsets
04:47:50 <johnjay> objdump is part of gcc?
04:47:58 <zid> binutils
04:48:02 <johnjay> i need to master my linux tools more
04:48:04 <johnjay> ok
04:48:46 <clever> comparing my disassembly to the original diskboot.S, i can see the ret from line 397 landed at address 0x1af
04:49:00 <clever> which is line 26 of my gist
04:49:52 <zid> this is a shit lot of real mode assembly
04:50:07 <zid> oh this is grub
04:51:12 <clever> in my case, this is an MBR disk, so no bios boot partition
04:51:25 <johnjay> hmm yeah i'm just reading that comment
04:51:34 <johnjay> about how the list of sectors grows down and this section grows up
04:51:55 <zid> I've never actually looked into how the superblock stuff worked
04:52:09 <clever> -rw-r--r-- 1 root root 512 Sep 17 2018 /boot/grub/i386-pc/boot.img
04:52:23 <clever> this is the "original" MBR stub, before grub has inserted the offsets of stage 1.5
04:52:24 <zid> is it space that's free because of how the dos partition system works, or is it jammed into the partition somewhere?
04:52:44 <clever> zid: its unused space, caused as a side-effect of aligning the 1st partition
04:52:51 <zid> makes sense
04:52:55 <clever> Device Boot Start End Sectors Size Id Type
04:52:58 <clever> /dev/sda1 2048 146341887 146339840 69.8G 7 HPFS/NTFS/exFAT
04:53:00 <zid> How much space do ou get?
04:53:09 <clever> 2047 sectors in this case
04:53:15 <clever> sector 0 was used by the MBR
04:53:19 <zid> Oh, huge
04:53:26 <zid> You could have an entire splash image in that
04:53:31 <clever> ~1mb
04:53:46 <zid> presumably that isn't true on all disks though
04:53:54 <zid> see: 4MB hard drives :P
04:54:06 <bcos> zid: Depends on how the 1st partition is aligned - typically a minimum of 63 sectors (including MBR), but then assholes polluted random sectors with Windows crap that shouldn't be allowed to touch anything outside a valid partition
04:54:11 <clever> and the reason you align partitions, is because what if the real disk had 1mb blocks
04:54:15 <clever> and your fs had 1mb blocks
04:54:16 <zid> bcos: 63 sounds more reasonable
04:54:20 <clever> but your partition started at 512kb
04:54:32 <clever> then every fs block, covers half of 2 disk blocks
04:54:36 <clever> and your performance tanks, massively
04:55:22 <clever> [root@amd-nixos:~]$ hexdump -C sda-mbr > sda-mbr.hex
04:55:22 <bcos> The partition alignment was originally to make sure partitions start at "start of track" (because OSs suck and were too stupid to have a "start of track offset")
04:55:35 <clever> [root@amd-nixos:~]$ hexdump -C /boot/grub/i386-pc/boot.img > boot.img.hex
04:55:48 <bcos> ...then when people started going for 4 KiB sectors most people decided to bump it up to in case
04:55:50 <clever> bcos: yeah, thats back from the CHS days
04:56:05 <zid> Yea 1MB is nothing now, might as well, 1MB alignment minimum then
04:56:07 <zid> nobody's going to miss it
04:56:23 <clever> zid: but then GPT started using more then the 1st sector
04:56:29 <zid> than*
04:56:33 <zid> we're talking dos, not gpt
04:56:35 <clever> and grub cant easily know how far into the "unused" space to go
04:56:37 <johnjay> as fascinating as this is i don't think i know enough asm to appreciate your example well clever
04:56:54 <zid> I'm yet to own a drive which is GPT partitioned
04:57:09 <clever> zid: i do gpt for all new installs i do
04:57:15 <zid> grats
04:57:31 <clever> johnjay: https://gist.github.com/cleverca22/10101fc45a2b53056bdc07f3ff1e9837#file-gistfile1-txt-L53
04:57:44 <clever> johnjay: this is a diff between boot.img, and my actual mbr, revealing what grub modified, and how it merged with my real partition table
04:58:03 <clever> somewhere in there, is the LBA# for stage 1.5
04:58:09 <zid> I'd be tempted to flash the win 9x bootsector to my drives
04:58:34 <zid> then nobody can accidentally overwrite it with something they shouldn't, and it'd boot on a taito type-x arcade machine
04:59:10 <bcos> Hrm
04:59:31 <clever> partition table spans from 1be, to ~1fd i think
04:59:34 <bcos> clever: GPT makes "location of stage 1.5" more nasty because GPT's partition table is in the way at start of disk
04:59:47 <zid> bcos: looks like you could invent a 'grub' guid though?
04:59:54 <zid> and just have it be a partition
05:00:24 <bcos> In that case; why not make it a UEFI system partition?
05:00:31 <clever> thats what the bios boot partition handles
05:00:42 <clever> the bios boot partition is just a clearly "used" area of the disk, that contains raw assembly code
05:00:48 <bcos> (at least that way when user switches between BIOS and UEFI you have half a hope of it working)
05:00:51 <zid> I hope it doesn't contain assembly
05:00:58 <clever> the boot stub doesnt care if you use it, and still has the LBA#
05:01:04 <clever> zid: assembled assembly
05:01:51 <clever> bcos: the stub in the MBR cant understand filesystems, so it needs the LBA# and size of a blob to just load+execute, and filesystems complicate that
05:01:52 <zid> I suppose if you're uefi booting it doesn't matter, and if such a bios partition guid exists, as long as the code isn't hardcoded incorrectly it could fall-down to it okay
05:01:58 <zid> or the bios routines could translate I guess
05:02:14 <clever> the bios also doesnt really do anything with the bios-boot-partition
05:02:21 <bcos> clever: Yeah - give it the LBA of a blob that happens to be a file in a FAT32 in a UEFI system partition and...
05:02:32 <clever> bcos: defragmentation
05:02:34 <zid> I wonder why they didn't do either sensible thing when they designed this
05:02:57 <clever> bcos: lilo had this issue, you could brick the machine if the file was moved the wrong way
05:03:18 <bcos> And you think you won't brick the machine if someone moves a partition?
05:03:44 <johnjay> clever: i'm not sure exactly how the LBA is used but i think i have my win drive MBR with grub and the linux drive GPT
05:03:46 <clever> that happens a lot less often, and i would expect the admin to know not to do that :P
05:03:53 <bcos> (ideally the MBR's code should search and not use LBA, but space is tiny)
05:03:54 <johnjay> so there is a bios boot partition on drive 2 now?
05:04:04 <johnjay> well i did that
05:04:15 <johnjay> or i guess i deleted the grub /boot partition. :D
05:04:18 <clever> johnjay: run `fdisk -l` against the linux drive, and pastebin it
05:08:59 <johnjay> clever: i'm on windows with a cygwin install... not sure i can do that
05:09:04 <johnjay> let me reboot into ubuntu, brb
05:16:53 <johnjay> oh crap
05:16:58 <johnjay> ok i'm here
05:17:58 <clever> johnjay: fdisk -l on each disk, and then pastebin it
05:19:21 <johnjay> ah ubuntu 18 isn't letting me do it
05:19:28 <johnjay> there's no sda,b, or c in /dev
05:19:31 <johnjay> just ram1, ram2, ram3
05:19:31 <clever> as root?
05:19:38 <johnjay> i can see some stuff in /dev/block though
05:19:42 <clever> johnjay: what does `df -h` return?
05:20:05 <johnjay> just the info for this individual ubuntu partition i installed to
05:20:16 <johnjay> i know i can load the other disks though bc i can see them on my desktop
05:20:19 <clever> johnjay: and what is the device it mounted?
05:21:00 <johnjay> /dev/mmcblk0p1 is /boot and / is /dev/root
05:21:16 <clever> ls -l /dev/root
05:21:18 <johnjay> i just split the GPT thing into 32GB sections plus the bsd
05:21:22 <clever> and you appear to be booting from an SD card
05:22:05 <zid> I bet perf on that is amazing
05:22:35 <johnjay> oh i'm sorry i'm being stupid
05:22:48 <johnjay> i was in my ssh raspi not ubuntu itself
05:22:58 <johnjay> http://paste.ubuntu.com/p/MVJyYxjhyX/
05:23:46 <clever> johnjay: and what does `df -h` report is actually mounted?
05:26:20 <johnjay> er
05:26:34 <johnjay> yes /dev/sdc2
05:26:39 <johnjay> sorry
05:26:57 <johnjay> which makes sense i installed ubuntu to the second partition on the linux drive
05:26:59 <clever> i'm guessing sdc4 might be a bios boot, if its not mounted
05:27:23 <clever> i also notice, sdc1 starts at sector 40, which feels off
05:27:43 <johnjay> i told the freebsd boot thing which was text only no mouse so it was awkward
05:27:49 <johnjay> but i told it to first delete everything. then make GPT
05:27:55 <zid> 20k should be enough for anyone
05:28:05 <johnjay> then make 64GB, 32GB, 32GB, then those 3 bsd partitions, then again 32GB for the rest
05:28:09 <clever> zid: alignment and real sector size could become an issue
05:28:19 <johnjay> did the freebsd formatter mess it up somehow?
05:28:23 <johnjay> it's an ssd
05:29:19 <clever> johnjay: if the erase blocks are greater then 4096 bytes on the SSD, then sdc1 may have reduced performance
05:29:40 <zid> 20k alignment is 5x 4k alignment
05:29:45 <zid> which is what ssds tell you to use
05:29:59 <clever> Sector size (logical/physical): 512 bytes / 512 bytes
05:30:05 <clever> i dont trust that report though
05:30:14 <clever> because SSD's have started to lie, due to OS bugs
05:33:49 <johnjay> so it might not be 20k bytes?
05:33:59 <johnjay> how to tell, maybe with that hexdump command or something?
05:34:37 <clever> not entirely sure
05:37:41 <johnjay> well at least i can use grub now right to see what the /boot thing is?
05:38:19 <johnjay> yeah i think the stackoverflow question said to edit grub.cfg
05:38:24 <johnjay> then run grub-update... I think? or os-prober
05:39:04 <johnjay> hrm the instructions say not to edit the file... >_>
05:47:16 <johnjay> thanks for the advice though
05:49:06 <mlugg> How would you go about sending an init IPI / SIPI to individual APs if you have more than 8 LAPICs? You'd normally use logical destination mode, but I assume the LDR can't be accessed from outside of its own CPU. Do you just have to broadcast to all CPUs instead?
05:52:16 <zid> doug16k you're up
05:53:18 <johnjay> mlugg: i didn't understand anything you said but gl with that question
05:53:36 <mlugg> johnjay: Why thank you! :P
05:53:50 <mlugg> Ngl I didn't understand half of it either
05:54:00 <mlugg> There are too many acronyms in x86
06:02:45 <johnjay> there's some skit on youube i thougth about that
06:03:40 <johnjay> can't find it, oh well
06:14:06 <mquy90> hi, do you know how to install grub-install on mac os?
06:25:41 <alberinfo_osdev> hi, i have a question. A few days ago, i passed from using multiboot 1 to multiboot 2, but now, i cant use some header tags(which says that are unsupported), for e.g, if i ask for rsdp, then grub says: "error:unsupported tag 0xe". what could it be? i didnt find anything in google or in the multiboot 2 specification. Thanks in advance
06:26:05 <zid> stop trying to use tag 0xe then?
06:27:49 <alberinfo_osdev> well, its about more than just that. acpi 1.0, 2.0 mem information, framebuffer information, and others that i dont really use dont actually work, just an "unsupported tag <the tag(s) that says unsupported>". but i can actually switch video modes, for example
06:28:21 <bcos> alberinfo_osdev: On UEFI systems there is no RSDP, so..
06:28:24 <zid> I haven't understood a word you've said
06:30:29 <alberinfo_osdev> zid: i cant use some tags, and other yes. bcos:yes, but i cant make it work in any enviroment. it doesnt work on a real pc(which has a bios with rsdp), also tested on qemu and bochs, and they don't work.
06:31:15 <bcos> alberinfo_osdev: Are you sure there's isn't a bug/quirk in whatever code you're using to create the tags?
06:31:47 <alberinfo_osdev> the code it's fine(in theory), following the multiboot 2 specification
06:33:17 <bcos> Hrm - there's an "ACPI old RSDP" (type = 14) and then an "ACPI new RSDP" (type = 15)
06:34:00 <bcos> ^ might need both depending on how old the computer is
06:34:39 <alberinfo_osdev> bcos: yes, but see that bochs haves acpi 1.0, and says unsupported tag 0xe(acpi 1.0 tag)
06:35:38 <bcos> Try them both anyway, for fun!
06:37:49 <alberinfo_osdev> they dont work, the acpi 1.0 tag neither the acpi 2.0 tag
06:43:30 <mlugg> alberinfo_osdev: The ACPI tags aren't things you request
06:43:51 <mlugg> They're always given as part of the Multiboot structure
06:44:52 <alberinfo_osdev> AFAIK i have to pass the tag with type 14 to have a copy of rsdp(in this case by acpi 1.0, type = 15 to have acpi 2.0)
06:45:14 <mlugg> No, they're always provided (when present) as part of the information structure
06:45:21 <mlugg> See https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html#Boot-information-format
06:46:21 <alberinfo_osdev> mlugg: thanks, ill try
06:47:02 <mlugg> So you don't need to pass any tags (In ym Multiboot2 loader, I don't pass any tags at all), you just have to find the right thing in the structure you get in %ebx
07:26:42 <mlugg> (wrt my earlier question) Ah, after digging through the specs it seems the destination field is actually 8 bits (56-63) on any modern system
07:28:43 <mlugg> And with x2APIC you can do 32-bit addressing through the MSR
07:46:17 <johnjay> getting grub to boot freebsd was actually pretty easy
07:46:28 <johnjay> just had to edit 40_custom with a few lines and update-grub
07:46:41 <johnjay> the trick was you don't tell it the freebsd boot partition you tell it the / partition
08:10:18 <bauen1> there's this special next level debugging of adding -d to make in gitlab-ci to figure out why caches aren't working
08:13:26 <bauen1> oh actually everything is working alright, but using git clone means the patch is newer than the cache leading to make (correctly) rebuilding everything ._.
08:16:31 <bauen1> how are caches with make for ci are even usefull then, git will always 'touch' everything that is checked out, so everything has to be rebuild anyway and caches are useless
08:49:40 <doug16k> touch? doesn't it set the last modified date correctly?
08:50:36 <doug16k> clone something pushed 6 months ago and file dates are 6 months ago I hope
08:53:39 <doug16k> wow, it does touch everything. asinine
10:42:47 <jjuran> Caching should be based on input content, not modification date
10:58:07 <doug16k> ah, so the magic in chrono is the ratio class? when you convert from one to another you take the inverse of the source period times the destination period, get the ::type of that to reduce to lowest terms, and do a muldiv against the new ratio?
11:22:51 <doug16k> so 1/1e+6 converted from 1/1e+9 = ratio<1e+6, 1e+9>::type == ratio<1, 1000> so you multiply by 1 then divide by 1000 to convert
11:24:03 <doug16k> where "1e+6" or "1e+9" are counts per second unit
11:24:39 <doug16k> 1/1e+9 of a second for example