IRC channel logs

<ZhaoM>i'm trying to fix vim test suite, it's harder than I expected :/

<damo22>im trying to fix acpi_get_irq_number()

<ZhaoM>is that related to SMP?

<damo22>found something theres another two types that are relevant ACPI_RESOURCE_TYPE_START_DEPENDENT and ACPI_RESOURCE_TYPE_END_DEPENDENT

<damo22>i updated my libacpica branch

<damo22>Found IRQ resource 3

<damo22>intnull(11)

<damo22>_CRS is broken on my bios, but _PRS has a list of them

<damo22>i guess i need to add support for switching them to one of the ones in the _PRS list with _SRS

<damo22>acpi is really annoying

<Pellescours>morning

<solid_black>morning :)

<Pellescours>it's lije uefi, firsts implementations were buggy

<ZhaoM>morning

<solid_black>hi ZhaoM!

<ZhaoM>hello solid_black!

<damo22>i have to hack my own implementation of subsetting _PRS to find a suitable IRQ to set and then call _SRS

<damo22>basically i get an array of structs that contain all the possible irqs for a device

<damo22>and i need to recreate the array with everything but only one irq setting

<Pellescours>ouch

<damo22>Warning missing _CRS

<damo22>Found IRQ resource 3

<damo22> Enter evaluation : _SB.INTD._PRS (Method)

<damo22> Exit evaluation : _SB.INTD._PRS

<damo22>Error setting _SRS

<damo22>irqhelp: tried acpi to get pci gsi and failed for 00:11.0

<damo22>but it falls back to old interrupt 11 and works in non-smp

<damo22> Exit evaluation : _SB.INTD._SRS

<damo22>intnull(11)

<damo22>i dont know, i think broken bios cannot have irqs reconfigured at runtime

<damo22>_SRS does not work

<damo22>i think im supposed to ignore ACPI PCI irqs if _CRS is empty

<damo22>and use MSI

<Pellescours>so, more stuff to dev... if you want to have something working on this amd one

<damo22>gah

<damo22>its literally looking up an integer

<damo22>why is this so hard

<damo22>it boots with non-smp now

<damo22>pushed to my libacpica-debian

<damo22>it should work now on non-broken bioses

<gnu_srs>(20:16:15) gnu_srs: This is strange: (another image does not report such problems)

<gnu_srs>(20:16:15) gnu_srs: task ((/bin/sh(613))) deallocating a bogus port 4, most probably a bug.

<gnu_srs>etc: Any ideas??

<gnu_srs>The output comes from gnumach: ipc/mach_port.c: line 596+: if (MACH_PORT_NAME_VALID (name) && space == current_space()) {printf("task %.*s deallocating a bogus port...

<solid_black>gnu_srs: yes, this is a Mach warning which happens when you try to deallocate a bogus port name

<solid_black>can you break on the warning and see the userland backtrace?

<gnu_srs>tks I'll try: Can this be due to some corrupted part of the image?

<ZhaoM>what's the correct method of fixing testsuites (for example the testsuites of vim)? Asking on the offical issue tracker?

<solid_black>if it is the testsuite that has a bug, it'd probably be best to submit the fix upstream, if they don't explicitly refuse having special cases for GNU/Hurd

<solid_black>if the testsuite is correct, but fails on the Hurd, the Hurd has to be fixed

<ZhaoM>OK

<Pellescours>damo22: good news, I don’t know which commit from your rumpkernel dev branch is fixing it but even with memory contention, the exception is not raised anymore (i.e. rump is not dying anymore). But the hang is still here

<damo22>ok

<gnu_srs>Is this as expected: cat /etc/hurd/runsystem.sysv; #!/bin/sh; exec /etc/hurd/runsystem.gnu init=/sbin/init $@

<gnu_srs>When booting in recovery mode shouldn't you get a single-user shell requesting the root password to continue?

<damo22>morning

IRC channel logs

2024-12-27.log