IRC channel logs

2021-03-25.log

back to list of logs

***Server sets mode: +nt
<damo22>AliciaC: thats a good q
<damo22>let me try
<damo22>do i need to * Allocate contiguous memory below 16 MB.
<damo22>unable to allocate page
<damo22>privileged thread
<damo22>uint32_t memory_start = phystokv(vm_page_to_pa(vm_page_grab_contig(512*1024, VM_PAGE_SEL_DMA)));
<damo22>is there a way to search for ascii text in memory in gdb?
<damo22>ive mapped 0-1MB as a flat contig to C0200000
<damo22>i need to find the RSD PTR
<damo22>its not in the first meg of memory
<damo22>???
<Pellescours> https://wiki.osdev.org/RSDP it should
<damo22>(qemu) xp/2c 0xf5860
<damo22>00000000000f5860: 'R' 'S' 'D' ' ' 'P' 'T' 'R' ' '
<damo22>(gdb) x/8c memory_start + 0xf5860
<damo22>0xc02f5860: 1 '\001' 5 '\005' 6 '\006' -98 '\236' 5 '\005' 3 '\003' 0 '\000' 2 '\002'
<damo22>hmm
<damo22>phys_addr_t memory_start = phystokv(vm_page_to_pa(vm_page_grab_contig(1024*1024, VM_PAGE_SEL_DMA)));
<damo22>that did not work
<damo22>youpi: any ideas?
<youpi>is paging / segmenting properly initialized at that stage?
<youpi>also, the lower memory should already be available at 0xc00f5860
<damo22>i ca(gdb) x/8c 0xc0000000 + 0xf5860
<damo22>0xc00f5860: 82 'R' 83 'S' 68 'D' 32 ' ' 80 'P' 84 'T' 82 'R' 32 ' '
<damo22>phystokv(0xe0000) ?
<damo22>start from there?
<youpi>that's what the existing code does, doesn't it ?
<damo22>no it does rsdp = acpi_search_rsdp((void*) 0x0e0000, 0x100000 - 0x0e0000);
<damo22>i guess thats it
<damo22>i have no clue how it worked before then
<youpi>I'm not talking about the e000 part, but the EBDA part
<youpi>possibly the e000 part just never worked
<youpi>and the original author didn't notice because the EBDA part was working
<damo22>yes
<damo22>well that was also not using phystokv
<damo22>rsdp = acpi_search_rsdp((void*)base,1024);
<damo22>getting further
<damo22> http://paste.debian.net/plain/1190937
<damo22>smp_init does not fail anymore
<damo22>stepping over lapic_enable_timer(); causes that fault
<damo22>maybe i need to enable the timer a bit later?
<damo22>smp_init(); ioapic_configure(); lapic_enable_timer();
<damo22>or do i need to unmask the timer interrupt later?
***GeneralDuke1 is now known as GeneralDuke
<damo22>locore.S is confusing
<damo22>it seems that without the linux drivers, it is returning to the wrong stack from the clock interrupt
<damo22>i think that is because the clock used to be a linux thing?
<damo22>there are two types of interrupts, user ones and mach ones right?
<damo22>and we had a third, linux ones
<damo22>Thread 1 hit Breakpoint 1, hardclock (iunit=0, old_ipl=0, irq=0,
<damo22> ret_addr=0xc10077d9 <return_to_iret> "\272", regs=0xc10ae970 <_intstack+3936>)
<damo22>(gdb) p *regs
<damo22>$6 = {gs = 0, fs = 0, es = 16, ds = 16, edx = 0, ecx = 16, eax = -110542848, eip = -1056927147, cs = 8, efl = 662}
<damo22>calling clock_interrupt causes page fault above
<damo22>seems like it is interrupting from a thread stack in kernel mode
<damo22>but it tries to return to user stack?
<damo22>huh it page faults on timer_bump() in system mode
<damo22>got it, it cant bump the timer thread because thread = 0x0
<damo22>so &thread->system_timer does not exist yet
<damo22>deref null pointer
<damo22>found a bug in the kernel!
<damo22>now we are getting somewhere:
<damo22>ahcisata0 at pci0 dev 31 function 2: vendor 8086 product 2922 (rev. 0x02)
<damo22>irq handler [10]: new delivery port f5cb6a50 entry f55d7ec0
<damo22>hag
<damo22>hang
<damo22>no linux
<damo22>it could be failing because it doesnt know the correct APIC pin to use for the AHCI controller yet
<damo22>it assumes 10
<damo22>youpi: do you see any obvious errors with this? http://paste.debian.net/plain/1190947
<damo22>i created an array of user interrupt handler structs to hold the previous requests for user interrupt handlers
<damo22>youpi: ive got a branch of gnumach that boots to userspace with APIC/lapic timer but when you build it with linux drivers it breaks
<damo22>i'll have to rework it i guess until every combination still works
<damo22>smp/apic/linux, nosmp/pic/linux, smp/apic/nolinux and nosmp/pic/nolinux
<youpi>damo22: we definitely need to support several user handlers like the old linux code was doing
<youpi>I'd say don't try to bother with making acpi/lapi + linux work
<youpi>we want to get rid of linux drivers anyway
***c0le is now known as Guest99008
***TigerbotHesh is now known as Guest90279
***nckx[2] is now known as nckx
***Server sets mode: +nt
***commande1 is now known as commander
***swivel_ is now known as swivel
***cbaines_ is now known as cbaines
***davisr_ is now known as davisr
<damo22>(02:51:10) youpi: damo22: we definitely need to support several user handlers like the old linux code was doing
<damo22>did you mean, we need to allow sharing of the same interrupt with multiple user handlers?
<damo22>or one handler per irq
<youpi>multiple user handlers per irq line, yes
<damo22>really? why
<youpi>you can have several devices on the same irq
<damo22>ok i did not know that
<damo22>unfortunately, i will need to install yet another bootstrap translator before the disk will work with APIC
<damo22>acpi
<youpi>I was realizing that yesterday, yes :)
<damo22>because i need to fetch the APIC pin mapping to irq
<youpi>"should be" a matter of using libmachdev, now
<damo22>yes
<damo22>but i can test it without that, if i just implement a dummy stub that hardcodes the irq lookup
<damo22>as a new RPC
<damo22>the good news is that gnumach boots to userspace with APIC but i need to clean it up so i dont lose the old pic/linux pathway