IRC channel logs


back to list of logs

<damo22>youpi: What is the architectural reason why PowerPC avoids the bottleneck of PCI for NV GPUs, over say x86?
<youpi>I haven't looked at the details, but that's probably that they basically integrated an NVlink connection on the memory controller
<youpi>at least the reason is that the gpu is directly connected to the host, without going through pci
<youpi>I just haven't looked at how they connected nvlink to the host
<youpi>(gpu-gpu NVlink works in both case, since the host is not involved)
<damo22>my guess is we will never convince our team to purchase powerpc
<youpi>depends what kind of software stack you have :)
<youpi>if it's all debian-only for instance, there is no valid reason to refuse powerpc :)
<youpi>but as soon as you have some existing proprietary software, the question is different
<damo22>we use CentOS mainly
<youpi>if they fear that nvidia is not on par with powerpc support, see which has a few nvidia/powerpc systems :)
<Gooberpatrol66> ?
<youpi>yes, that's what we see on such machines
<damo22>i cant spot any error in my APIC stuff for arrays, could it be some kind of cache locking?
<damo22>jrtc27 suggested it earlier
<youpi>that could be yes
<damo22>i need to look up the manual for qemu to inspect the ioapic
<damo22>then i can prove my timer is working etc
<damo22>i believe i have it on a 100Hz periodic timer
<damo22>calibrated via pit
<damo22>lapic i meant
***Server sets mode: +nt
***Server sets mode: +nt
<damo22>we dont have the IT resources to support 2x architectures for our servers apparently
<damo22>not sure why they dont package all the source into rpms
<damo22>how do i force qemu to give me access to the memory of the apic?
<damo22>it says cannot access memory at 0xf9693000 for example
<damo22>which is a virtual mapped address in the kernel
<Pellescours>info lapic maybe ?
<Pellescours> it comes from there
<Pellescours>I don’t know if that’s what you want
<damo22>yes perfect thank you!
<damo22>my timer is working
<damo22>LVTT 0x00020030 active-hi edge periodic Fixed (vec 48)
<damo22>Timer DCR=0x3 (divide by 16) initial_count = 796 current_count = 91
<damo22>lapic on cpu0 gets configured, but the lapic on cpu1 stays unconfigured
<damo22>how do i run the lapic configuration on the second cpu?
<damo22>damn i cant see the top of qemu console it scrolls off the screen in curses
<youpi>use a serial console
<damo22>module 1: exec /hurd/exec $(exec-task=task-create)
<damo22>2 multiboot modules
<damo22>{cpu0} ../kern/slab.c:1021: kmem_cache_free_to_slab assertion failed
<damo22>i tried again with rumpdisk and arbiter and it lists all the tasks
<damo22>where do i put the timer value? its currently a global in ioapic.c, but i have a feeling something needs to know the value
<damo22>it counts down from 796 to 0 and then triggers interrupt 0
<damo22> pin 0 0x0000000000000032 dest=0 vec=50 active-hi edge fixed physical
<damo22> pin 1 0x0000000000010031 dest=0 vec=49 active-hi edge masked fixed physical
<damo22> pin 2 0x0000000000010000 dest=0 vec=0 active-hi edge masked fixed physical
<damo22> pin 3 0x0000000000010033 dest=0 vec=51 active-hi edge masked fixed physical
<damo22>.... counts up from 52
<damo22>not sure if that is normal
<damo22>but my timer assumes its on pin 0
<damo22>but the vector is not mapped at all
<damo22>are timers usually on pin 2?
<jbgg>damo22: the information of the interrupt pin of the timer (for PIC) is given in
<damo22>thanks jbgg!
<damo22>fixed the mappings!
<damo22> pin 0 0x0000000000000030 dest=0 vec=48 active-hi edge fixed physical
<damo22> pin 1 0x0000000000010031 dest=0 vec=49 active-hi edge masked fixed physica
<gnu_srs2>Hi, any ideas? I'm upgrading an old image by manually installing, dpkg-deb -x, latest hurd, glibc and gnumach. Boot hangs at ... exec. Which additional packages do I need?
<damo22>err it booted with an APIC but no keyboard working
<gnu_srs2>damo22: Congrats again :)
<jbgg>damo22: pin 1 (kbd) is masked on ioapic? it should be configured on ioapic to unmask it?
<damo22>i see yes
<damo22>hmm, somehow the keyboard driver needs to unmask its irq
<jbgg>damo22: yeap
<jbgg>after initizalize it
<damo22>it detects ctrl-alt-D for debugger
<damo22>but nothing else
<damo22>then i can type in debugger
<jbgg>have you tested sendkey command in qemu monitor? just for try
<damo22>hmm it unmasked irq 9 not 1
<damo22>maybe the linux_init is fiddling with PIC
<damo22>no more tonight, made good progress though
<AliciaC>I'm just following from the sidelines but this progress is very exciting :)
<jbgg>damo22: I will check it, thanks for the link
<damo22>AliciaC: yes, last night it was exciting, i got it to boot using lapic timer and ioapic interrupts
<damo22>alas i must work now
<AliciaC>I meant more generally. I don't fully understand last night's issues and progress, but booting on real hardware is something I understand and it's awesome :)
<damo22>this will enable a new generation (the current x86) to boot hurd when it's completed
<damo22>and hopefully pave the way to x86_64 support