klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
sdfgsdfg has joined #osdev
Lugar has joined #osdev
garrit has quit [Ping timeout: 256 seconds]
freakazoid12345 has joined #osdev
freakazoid343 has quit [Ping timeout: 250 seconds]
<geist> nom on fush
<klange> oof how many relocations am I getting in these object files...
<klange> I handle three for x86-64... but I've got a dozen on aarch64 and most of them are instruction immediate rewrites...
[itchyjunk] has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
gog has quit [Quit: byee]
freakazoid12345 has quit [Ping timeout: 250 seconds]
CryptoDavid has quit [Quit: Connection closed for inactivity]
<Lugar> so ive been trying to fix a bug for a day now in one of my irqs and i finally found the source of the issue
<Lugar> when i am about to iretq out of the interrupt i noticed that the CS entry in the stack is wrong
<Lugar> so ive been getting #GP'd
<Lugar> i thought it was getting called wrong
<Lugar> but i now realize its gcc putting some weird shit in front of my code
<Lugar> i dont trust __attribute__((interrupt)) anymore
<clever> Lugar: __attribute__((interrupt)) doesnt work on every arch, and will silently turn into a no-op
<clever> either use a .S file to control it yourself, or review the asm that gcc generates for your arch
<Lugar> il make a separate file for it
<Lugar> in asm
<Lugar> here wait il send a screenshot
<Lugar> it seemingly randomly writes to the stack for no reason and messes up my iretq
<clever> lets see, first it pushes 3 regs, so the stack has moved down by 3 x $nativesize
<clever> then it subtracts 0x20 from the stack, to make room for local vars
<clever> and sets the basepointer to be the sp+0x20, the mid-point between the saved args and the 0x20 bytes of local vars
<Lugar> heres the code btw
<Lugar> __asm__("1: jmp 1b");
<Lugar> ++timerticks;
<Lugar> piceoi(FALSE);
<Lugar> for the irq
<clever> ah, i was going to ask, why do i see an infinite loop
<Lugar> just for a point to halt when i debug
<clever> yeah
<clever> i'm a bit confused as to why its writing to bp+0x20
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
srjek has quit [Ping timeout: 240 seconds]
sdfgsdfg has joined #osdev
ElectronApps has joined #osdev
Lugar has quit [Quit: Bye]
<geist> yah surprised attribute interrupt worked for x86. this is x86 right? (i see the jmp instruction)
<geist> it used to be unimplemented there, but have seen it on some of the riscy machines
troseman has quit [Ping timeout: 256 seconds]
<geist> i guess it could be trying to write into the iframe somewhere?
<geist> i wonder why though
<geist> reading from it, maybe
<geist> also it had just pushed 3 words, so i guess it's really writing to whatever was saved in rax
<geist> anyway, strange strange codegen
<geist> in general it doesn't seem to be doing the right thing anyweay: it should have saved all the callee saved regs prior to making the call
<geist> otherwise it'd trash them
<zid> they added at it some point but you need -mgeneral-regs-only
nyah has quit [Ping timeout: 256 seconds]
freakazoid333 has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
k8yun has joined #osdev
MiningMarsh has quit [Ping timeout: 256 seconds]
<zid> coffee (n): Someone covered in spit
bauen1 has quit [Ping timeout: 256 seconds]
garrit has joined #osdev
MiningMarsh has joined #osdev
ekathva has joined #osdev
masoudd has joined #osdev
bauen1 has joined #osdev
nick64 has joined #osdev
k8yun has quit [Quit: Leaving]
ekathva has quit [Quit: Leaving]
ekathva has joined #osdev
<nick64> I don't think this should bother a software developer, but I can't see how PCIe config space is a separate address space. To me it looks like a hole in the same old address space
<nick64> "The IOMMU is configured and controlled via two sets of registers. One in the PCI configuration space and another set mapped in system address space."
<nick64> So PCI configuration space is not carved out from the system address space?
<Mutabah> PIC config space is different to PCIe
<Mutabah> With PCI, it was a separate address space accessed via a pair of registers
<Mutabah> With PCIe, it was given its own mapping into the main memory bus
<nick64> Ah! Makes sense. So how would the system know a write to a PCI config register is a PCI config write and not a memory write?
<Mutabah> For which case?
<Mutabah> For legacy, you did IO writes to x86 IO ports 0xCF8 and 0xCFC
<Mutabah> (The first had the address, the second was the data read/write port)
<Mutabah> For PCIe, it's just a bus transaction
<Mutabah> (Electricall) you can put anything on the bus - RAM, ROM, Devices, ...
<nick64> Oh okay, so the "config space" for PCI is the port IO space? Got it
<Mutabah> It's accessed _via_ the IO port space
<nick64> That answers my question indirectly, system knows it is PCI write and not memory write since to write I have to issue in/out instrs instead of mov
<Mutabah> It kinda does, and kinda doesn't
<Mutabah> For legacy, the PCI bus interface/bridge controller is listening on the IO port bus for accesses to CF8/CFC
<Mutabah> and translates any access of CFC into config bus accesses (using the address written to CF8)
<Mutabah> These busses are best thought of as a very simple message passing system
<Mutabah> A write is a mesage going out saying "IO port write @0xCF8, value 0xC000_0004"
<Mutabah> So the way the system knows that it's PCI config write is via the contents of these messages
<Belxjander> nick64: you either have PCI ConfigSpace mapped as 2 IOports by x86 "IOport" Space to write an address then read/write the content at that address, XOR MemoryMapped where the ConfigSpace for each PCI+PCI-Express "device" is mapped within the "ConfigSpace" mapping of the Primary PCI/PCIe Bridge device... (this means the
<Belxjander> location where ConfigSpace actually is may* be a configurable block of memory... and having each device "ConfigSpace" being a fixed size...
<nick64> Okay.. I think I was able to soak a good ~90% of that. Thanks folks
<Belxjander> also allows for read/writes within that single "ConfigSpace" Memory Mapping also to be "device select" based on segmentation... "ConfigSpace" for a single device being 256 bytes fixed size means an arbitrary segment size of 8bits within a device and "segment selection" of additional address lines doubles as "Device Select" within the ConfigSpace region as a whole
<nick64> Got it.. address segments for b,d,f
<Belxjander> nick64: nope... ALL bridges / cards and "functions" within a card are all "device"s... and individually addressable as "dev N" from 0 upwards
<nick64> I didn't get that, could you show an example instruction?
<Belxjander> PCI/PCI-Express "Device 0" is *always* going to be the primary Bridge controller which provides PCI/PCI-Express to begin with... and *may* include a mapping option where you can decide where the device is actually mapped in Memory *if* MemoryMapped is an option
<nick64> in CF8, <addr>
<nick64> in CFC, <value>
<nick64> With <addr> being segmented as bus ID, Device ID, Function ID, register ID, right?
<nick64> (pseudo assembly code)
* nick64 AFK
<Belxjander> nick64: yeah... the Bus/Device/Functions are always counting a selection in steps of 256 with the register being offset within the specific devices register space (32 or 64bit registers for everything according to the PCI 2.1 spec document I have here)
garrit1 has joined #osdev
gog has joined #osdev
kkd has quit [Ping timeout: 252 seconds]
kkd has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
V has quit [Ping timeout: 268 seconds]
<nick64> What's the difference between `intel_iommu=off` and `intel_iommu=pt`?
<nick64> I read about `intel_iommu=pt` and it really sounds like no iommu at all scenario. What am I missing?
garrit has quit [Read error: Connection reset by peer]
garrit1 has quit [Ping timeout: 256 seconds]
pretty_dumm_guy has joined #osdev
<geist> good question. you're talking about linux command line switches?
<geist> i'd start by digging through the linux source and see where it's picked out
dormito has quit [Quit: WeeChat 3.3]
<geist> hmm, this pcie serial card i have has a 32KB prefetchable BAR
<geist> that's strange. it's an XR16850 (according to linux) which seems to not really do that
bauen1 has quit [Ping timeout: 240 seconds]
<bslsk05> ​www.wch-ic.com: PCI-Express based Dual UARTs and printer port chip CH382 - NanjingQinhengMicroelectronics
<geist> nice it has a datasheet too. i'll get to the endo f this!
<gog> omg we have cereal
masoudd has quit [Ping timeout: 240 seconds]
<geist> huh the data sheet only talks about bar 0 and 2
<geist> bar 1 is not used, but that's where 32K of prefetchable is
<kazinsal> oho
<geist> thought it was strange to see a prefetchable bar on anything but a gfx framebuffer really
<gog> maybe the controller on the board has prefetch capability but not the circuitry
<geist> and then on a serial port itself
<gog> and there's a different version that does
<geist> yah
<geist> i supose the4y could map the internal fifo into memory or something, but you dont need 32K for that
<geist> well digging through the linux code it just has a table that says use BAR0, io port, offset 0xc0 for the first uart, each successive uart 8 ports away
<geist> which is exactly how it works. *shrug*
<gog> im doing it im gonna start using -std=c2x
<j`ey> :o
<gog> how to git revert without making it look like i fucked up because i fucked up
* gog facepalms
<j`ey> rebase!
<klange> rebase, squash, and force push :)
<gog> ok lemme look into that lol
<gog> i want to hide this mistake
<gog> no discrepancy
masoudd has joined #osdev
<gog> hah! excelllent
<gog> my reputation will be untarnished by this in particular. can't do much about the other things
<j`ey> rebase <3
<gog> ok ctype.h is allegedly supposed to be available in the draft standard but i think my toolchain pre-dates that change
GeDaMo has joined #osdev
<gog> in freestanding
<gog> oh nevermind it's a proposal
garrit1 has joined #osdev
<bslsk05> ​handwiki.org: Software:C character classification - HandWiki
dormito has joined #osdev
<kingoffrance> I :/ because iswctype() and others are only for wide chars
<kingoffrance> not that i care, was wondering if something new was being added
<gog> yeah the proposal i read was for C locale only
<gog> no wctype.h would still be hosted i imagine
<kingoffrance> i just mean im so far gone it doesnt matter :D but i still see what other ppl are up to
<gog> i only need a subset of the isx functions so i may just do the cheap macro version and be careful not to do any of the things that might break it lol
<gog> alternatively, same implementation as the macros but as static inlines because i think that would avoid the double-evaluation issue?
<GeDaMo> I think gcc has a table of flag bits for each character
<GeDaMo> I seem to remember it's a 16 bit value
<zid> You're talking about wide chars? glad I was afk :P
masoudd_ has joined #osdev
masoudd has quit [Ping timeout: 250 seconds]
<klange> I'm iffy about having things in freestanding. Even the headers from the compiler with nothing more than typedefs have caused me some headaches.
<klange> And often when something is "available in freestanding" it really means "you have to make it available in freestanding".
<gog> hm fair
<kingoffrance> im more disturbing than that zid. im talking trash -- why do i need wide chars for custom char class?
<kingoffrance> :D
bauen1 has joined #osdev
bauen1 has quit [Client Quit]
bauen1 has joined #osdev
bauen1 has quit [Client Quit]
bauen1 has joined #osdev
CoffeeMuffinCake has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<kingoffrance> if a program cant rewrite its own code, what good is it? he asked
<kingoffrance> what would mel do
V has joined #osdev
dennis95 has joined #osdev
masoudd_ has quit [Remote host closed the connection]
garrit1 has quit [Quit: WeeChat 3.4]
masoudd has joined #osdev
Lugar has joined #osdev
Belxjander has quit [Ping timeout: 240 seconds]
gmodena has quit [Ping timeout: 240 seconds]
grange_c has quit [Quit: Ping timeout (120 seconds)]
grange_c has joined #osdev
buffet has quit [Quit: Ping timeout (120 seconds)]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
buffet has joined #osdev
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
asymptotically has quit [Ping timeout: 240 seconds]
asymptot1cally has joined #osdev
asymptot1cally has quit [Client Quit]
nyah has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
blockhead has quit []
gwizon has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
masoudd has quit [Ping timeout: 256 seconds]
srjek has joined #osdev
ElectronApps has quit [Remote host closed the connection]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
myon98 has quit [Quit: Bouncer maintainance...]
CoffeeMuffinCake has quit [Quit: WeeChat 3.4]
masoudd has joined #osdev
nick64 has quit [Quit: Connection closed for inactivity]
[itchyjunk] has joined #osdev
mahmutov has joined #osdev
jason1234 has joined #osdev
<jason1234> hello
<GeDaMo> Hi jason1234 :)
<jason1234> is LittleKernel too working on 68k alike atari 520 and amiga 500 machines?
<jason1234> GeDaMo: Hi
<GeDaMo> I don't see 68K on the LK github https://github.com/littlekernel/lk
<bslsk05> ​littlekernel/lk - LK embedded kernel (504 forks/2522 stargazers/NOASSERTION)
<bslsk05> ​github.com: lk/arch/m68k at master · littlekernel/lk · GitHub
<GeDaMo> Oh, well there you are then :P
<j`ey> but it only afaik supports qemu virt m68k
k8yun has joined #osdev
<GeDaMo> Yeah, looks like
<jason1234> it is impressive
<jason1234> there is today no single OS that can support x86 i486, ... m68k, and arm/amd64/686 for low mem machines. <16mb - 24mb
<jason1234> except lk.
<jason1234> kinda crazy os changes.
MiningMarsh is now known as mim
<j`ey> because 99.9999999% of people arent using those machines anymore :P
<zid> and they don't need any of the code improvements from running new linux
<zid> and old linux still works
<zid> nobody needs a hyper modern scheduler designed for 1024 threads and drivers for 8k video decoders on an amiga
<zid> modern linux is too big to even fit into memory on most of these I imagine, even allnoconfig
Terlisimo has quit [Quit: Connection reset by beer]
<CompanionCube> inb4 netbsd?
<sham1> Well I would think that NetBSD would support it
<zid> hmm considering starting a new long mode project in qemu..
<zid> so now I have the fun part where I have to figure out how I wanna boot the fucking thing
<zid> because qemu and grub both can't
Terlisimo has joined #osdev
ekathva has quit [Ping timeout: 250 seconds]
<jason1234> netbsd is not working on those. i ased, missing mmcu
* zid completely fails to boot something with -kernel
<jason1234> sham1: they said taht atari st is not supported. see minix, but minix neither, wont support.
<zid> gog you're better than me at this, teach me
dude12312414 has joined #osdev
<jason1234> zid: which os you try to boot?
<zid> jmp $
<zid> qemu's just crashing at EIP=A0000 so it's presumably nop sledding from somewhere lower, instead of running my kernel
<eryjus> zid: 64-bit elf?
<zid> nope, can't -kernel those
<eryjus> well, that kills my theory
<zid> entry in elf header is 0x10000c like it should be, program header 1 loads .text to 0x100000 and the jmp is at offset C (the rest being multiboot header)
<zid> I should go back to floppy disks they work better
<gog> zid: what's the kernel linked to? i had trouble with that before and just used grub instead
<gog> but i did get it work, you just have to have a physical address hint
<gog> oh wait duh
<gog> entry 0x10000c
<bslsk05> ​gist.github.com: kernel.txt · GitHub
masoudd has quit [Ping timeout: 256 seconds]
<gog> what's that at 0x74?
<gog> second phdr
<zid> oh, empty data, I wonder if qemu gets confused
* zid adds a byte
<zid> lol that fixes it, thanks gog
<gog> :D
<bslsk05> ​gist.github.com: kernel.txt · GitHub
<gog> yeah the qemu elf loader is fucky
<zid> 'section .data; empty db 0'
<gog> god help you if you try to do a higher-half loaded with -kernel becase it'll want the physical address hint
<gog> and that was a pita
<gog> i guess it's the same with grub
<zid> now.. can I use -initrd with this to cheat my 64bit kernel into memory I wonder
<zid> considering -kernel is not a bzImage and doesn't use the linux boot proto
<zid> failing that I will just embed one into the other like an idiot :D
<gog> -kernel acts like a multiboot loader
<zid> -kernel autodetects
<gog> ah ok
<zid> it either boots bzImages or multiboots
<zid> technically multiboot supports modules, but I don't think qemu supports them
<zid> I was just being too lazy to use grub, which does
<gog> i can't remember if it does
<gog> why not just use UEFI like a loser
<zid> oh -device supports files
<zid> never done uefi and I don't hve a toolchain for it anyway
<gog> you can cheat and use gnu-efi
<zid> -device loader,file=module.bin,addr=0x101000
<zid> would work lol
<bslsk05> ​github.com: sophia/Makefile at main · adachristine/sophia · GitHub
<bslsk05> ​github.com: sophia/efi.mk at main · adachristine/sophia · GitHub
<zid> what bfd target do I need
<zid> and where do I get libefi.so
<gog> you'll have to build it with git
<gog> also i did a funky thing to get i686 and x86_64 simultaneously
<zid> yea I am just going to embed one elf into the other I think
<gog> ¯\_(ツ)_/¯
<gog> idk why i did it, i don't even need i686 because i don't think i'll ever support it
<zid> It's kinda bizzare that most of the major projects just.. don't support the normal cpu mode
<zid> I assume it's just because they don't wanna set up paging
<zid> and tbh it's kind of hard to get yourself out of the paging catch-22 if someone else dumps you into a minimally mapped paging env
<zid> like if all I map is your .text and .data and give you a pointer to the e820.. good luck
dennis95 has quit [Quit: Leaving]
ekathva has joined #osdev
<gog> i guess it depends if you know the virtual address of the image in advance
<gog> if you don't that's harder to deal with
<zid> how does that help? The point is you can't allocate new page tables because you can't allocate memory to use for page tables.
<gog> you could create static page tables and stuff them in the data section
<zid> You'd probably need at least 3 scratch pages in bss you can overwrite or something
<gog> or that too
<zid> the bootstrap from there would still be painful af
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<gog> yeah i tried something similar in the past
<gog> it declared it a failed experiment and moved on to something else
<gog> it might be doable if during boot time there's a window with fractally mapped tables
<zid> yea I think you'd have to do the single page looking glass thing
<zid> like, a bounce buffer but for mappings
<gog> i sort of have that in mine rn
<gog> idk how i feel about it
<gog> it's a 2M page
<gog> and i use it for temporary mappings
<zid> I just mapped all of physical memory into some random >500 pml4e
<zid> probably super bad for perf on making new contexts, but makes the allocator nice and fast/simple at least
<gog> it's that tradeoff
<gog> simplicity/speed
<zid> with global mappings it'd still be fst for new contexts
<gog> but with the simplicity you get a polluted TLB
<zid> but I think spectre says you're not supposed to do that anymore?
<gog> yeah
<zid> I think there might be microcode to despectre my cpu a little but I couldn't even get the test program to work
<zid> that was trying to do it
<gog> even with the latest microcode mine is vulnerable to both variants of the attack
<gog> but the mitigations are very costly on this weak little cpu
<zid> mine is but I think it's like.. less?
<zid> It's simpler to just rowhammer anyway
<zid> hmm latest chrome completely kills the spectre in javascript demo
<gog> kills it as in averts it?
<zid> yea
<gog> neat
<zid> I think they were making it so the timers only gave rounded off results or something at some point
<zid> I guess that's now mainline
<zid> and the demo doesn't run in my normal ancient-firefox-fork :p
<zid> CompileError: at offset 230: invalid inline block type
<zid> it used to be able to get all the steps to work on my cpu, but the final 'actually do spectre' attack could never get the secret
k8yun has quit [Quit: Leaving]
<mahmutov> hi, i am playing lk kernel, i have two kernel instances in an internal network, i am trying to move a running thread to another one. what is the proper way for this, i asked also in lk channel for spesific answer
masoudd has joined #osdev
<mahmutov> just curious to generalised way of this stuff
<mahmutov> i have simple an app that listens socket and responses, namely it is a kernel thread
k8yun has joined #osdev
<nomagno> Do CPUs essentially need to have additional micro-ops per instruction to be able to detect writes?
<GeDaMo> "detect writes"?
<nomagno> Like, to be able to tell (specially communicating between CPU and I/O) when an address has been written to / read from
<nomagno> Let me stop with hypotheticals. I need to be able to detect in my VM, for QoL purposes, which addresses have been read from / written to this cycle. Is there any other way than manually inserting in each instruction extra code to note these things down?
<GeDaMo> Are you talking about the cache needing to update main memory?
<nomagno> Say, only print new output when the output memory map of the IO device is written to
<zid> the devices do that
<zid> the write goes onto the memory bus
<zid> the device 'listens' to the memory bus, and if it sees a write for an address it 'owns', it does something
<nomagno> ... If it's all emulated and I don't have concurrency available, I kinda have to note down writes on the CPU side don't I?
<nomagno> Else I can only detect changes in memory, which isn't very practical
<zid> did you forget to mention a shit load of context here
<zid> it sounds like you're trying to write an emulator or something
<nomagno> I'm writing a virtual machine for a custom architecture. The relevant details here is output is printed (if needed) after every cycle is executed, but I currently don't have any mechanisms for detecting writes to output addresses
<zid> Your virtual machine will need to wrap x if you intend to analyze x yes
<zid> where x is anything, reads, writes, adds, divides
<nomagno> Well, bit of performance goes down the drain but no biggie. For input I already do pre-execution analyzing of instruction operands
<nomagno> Because else I'd need to add a callback to the VM for getting input, and too cumbersome
masoudd_ has joined #osdev
gog has left #osdev [byee]
masoudd has quit [*.net *.split]
freakazoid333 has quit [*.net *.split]
phr3ak has quit [*.net *.split]
manawyrm has quit [*.net *.split]
g1n has quit [*.net *.split]
amj has quit [*.net *.split]
j00ru has quit [*.net *.split]
simpl_e has quit [*.net *.split]
k4m1 has quit [*.net *.split]
particleflux has quit [*.net *.split]
bleb has quit [*.net *.split]
Benjojo has quit [*.net *.split]
phr3ak has joined #osdev
g1n has joined #osdev
k4m1 has joined #osdev
freakazoid333 has joined #osdev
j00ru has joined #osdev
Benjojo has joined #osdev
particleflux has joined #osdev
bleb has joined #osdev
manawyrm has joined #osdev
gog has joined #osdev
amj has joined #osdev
nopenope[m] has quit [Ping timeout: 245 seconds]
nomagno has quit [Ping timeout: 250 seconds]
paulusASol has quit [Ping timeout: 256 seconds]
junon has quit [Ping timeout: 250 seconds]
Irvise_ has quit [Ping timeout: 268 seconds]
nature has joined #osdev
masoudd_ has quit [Quit: Leaving]
ekathva has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
paulusASol has joined #osdev
kaitsh has joined #osdev
junon has joined #osdev
nopenope[m] has joined #osdev
Irvise_ has joined #osdev
Raito_Bezarius has quit [Ping timeout: 250 seconds]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
Raito_Bezarius has joined #osdev
<geist> gog: fwiw i've been using c11 (or maybe gnu11) for a while and it seems like a nice compromise
<bslsk05> ​netxs-group/vtm - Terminal multiplexer with window manager and session sharing (19 forks/591 stargazers/MIT)
<geist> jason1234: yah i have 68k for lk, though i haven't merged it back into mainlie
<geist> VAX too
<geist> i should endeavor to do that
<geist> porting it to some real hardware with 68k would probably be fairly easy but i'd need that actual hardware, or an emulator of it. i guess there are amiga emulators out there
nature has quit [Ping timeout: 240 seconds]
dormito has quit [Quit: WeeChat 3.3]
nopenope[m] has quit [Read error: Connection reset by peer]
Irvise_ has quit [Write error: Connection reset by peer]
paulusASol has quit [Read error: Connection reset by peer]
junon has quit [Write error: Connection reset by peer]
GeDaMo has quit [Remote host closed the connection]
Irvise_ has joined #osdev
dude12312414 has joined #osdev
paulusASol has joined #osdev
junon has joined #osdev
nopenope[m] has joined #osdev
dormito has joined #osdev
dormito has quit [Ping timeout: 240 seconds]
freakazoid333 has quit [Ping timeout: 260 seconds]
sdfgsdfg has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
sheb has quit [Ping timeout: 256 seconds]
_xor has quit [Quit: WeeChat 3.4]
freakazoid343 has joined #osdev
kaitsh has quit [Quit: WeeChat 3.3]
_xor has joined #osdev
gwizon has quit [Ping timeout: 256 seconds]
k8yun_ has joined #osdev
k8yun has quit [Ping timeout: 240 seconds]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev