IRC channel logs

<damo22>im getting:

<damo22> Exit evaluation : _SB.PCI0._PRT

<damo22> Exit evaluation : _SB.INTD._CRS

<damo22>Empty _CRS IRQ Resource

<damo22>acpi parser is broken

<ZhaoM>morning

<damo22>somehow acpi_pci_link_check is not reading this:

<damo22> Name (IRQB, ResourceTemplate ()

<damo22> {

<damo22> IRQ (Level, ActiveLow, Shared, )

<damo22> {15}

<damo22> })

<damo22>_CRS does Return (IRQB)

<damo22>[ 1.0900050] ahcisata0: AHCI revision 1.30, 2 ports, 32 slots, CAP 0xf3309f01<PMD,ISS=0x3=Gen3,SCLO,SAL,SMPS,SSNTF,SNCQ,S64A>

<damo22> irq handler [11]: new delivery port f67fdcc0 entry f548eee0

<damo22> Enter evaluation : _SB.PCI0._PRT (Method)

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

<damo22> Exit evaluation : _SB.INTD._CRS

<damo22>Empty _CRS IRQ resource

<damo22>Error invalid _CRS resource

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

<Pellescours>is acpi table correct ?

<damo22>yes i think so

<damo22>the _CRS method says it returns IRQB and this is the contents:

<damo22>(02:43:21 PM) damo22: Name (IRQB, ResourceTemplate ()

<damo22>(02:43:21 PM) damo22: {

<damo22>(02:43:21 PM) damo22: IRQ (Level, ActiveLow, Shared, )

<damo22>(02:43:21 PM) damo22: {15}

<damo22>(02:43:21 PM) damo22: })

<damo22>my revised libacpica errors in qemu but falls back to irq 11

<damo22>so its consistent

<damo22>Pellescours: see https://git.zammit.org/libacpica-debian.git/log/?h=develop

<damo22>its a lot cleaner now and almost readable

<damo22>but something is failing when it reads _CRS

<damo22>the irq_resource it finds is empty

<Pellescours>is it a 32 or 64 addr length acpi table ?

<damo22>i think its RDSPv2

<damo22>but the inbuilt parsing should be agnostic to the width

<damo22>it finds _SB.PCI0._PRT and then finds _SB.INTD._CRS but says Empty _CRS IRQ resource

<damo22>is this valid ACPI?

<damo22> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings

<damo22> {

<damo22> CreateWordField (IRQB, One, IRQN)

<damo22> IRQN = (One << PIRD) /* \PIRD */

<damo22> Return (IRQB) /* \_SB_.IRQB */

<damo22> }

<azert>damo22: I don’t know anything about acpi, so take my word with a grain of salt, but don’t all os use the same acpica implementation? What would be the difference in the netbsd kernel, for instance?

<damo22>while the acpica is the same code, the implementation of how to call into it is different per OS, think of it like a library

<Pellescours>damo22: according to https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration.html « _CRS: Object that specifies a device’s current resource settings, or a control method that generates such an object. »

<Pellescours>I think you are in the case " a control method that generates such an object "

<damo22>Pellescours: its confusing to me, CreateWordField etc and the second line are not used

<damo22>it just returns IRQB

<damo22>which is a static object in the namespace

<damo22>ahh i get it

<damo22>CreateWordField creates a pointer to the actual IRQ and then updates it with the value from PIRx

<damo22>then the method returns the irq resource

<damo22>it looks valid

<damo22>but this is failing err = acpi_walk_resources(lnk, METHOD_NAME__CRS, acpi_pci_link_check, &irq)

<damo22>mm found this example code * DESCRIPTION: Display the _PRT/_CRS/_PRS resources for a device object.

<damo22>_SB.INTD._CRS

<damo22>Empty _CRS IRQ resources

<damo22>Error: Reached end tag with no IRQ resources

<damo22>just pushed to libacpica-debian c7440ec

<damo22>its still broken but getting closer

<Pellescours>damo22: it’s a patch so his lisibility is not clear but the while loop (while (index--), is just moving to the next resource, and the switch is after. Is it wanted? I think yes because you search for the resource you need

<damo22>it booted on my AMD without smp but it did not find the IRQ

<damo22>[ 1.5600050] wd0 at atabus0 drive 0

<damo22>yes that is supposed to skip the unwanted resources

<Pellescours>did you check that you do not loop one too many? (maybe print the type in the loop, to see if you see the IRQ one)

<damo22>it works on intel hw

<damo22>i think the parsing is better now but the AMD acpi is strange

<damo22>it falls back to 11 now

<damo22>so the only thing stopping it from booting is some rump smp thing

<Pellescours>the rump smp thing, wasn’t it the irq?

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

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

<gnu_srs>task (bin/sh(613)) increasing a bogus port 4 by 1, most probably a bug.

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

<gnu_srs>task (bin/sh(613)) looked up a bogus port 4 for 21000, most probably a bug.

<gnu_srs>Problems with gnumach, hurd, glibc, anything else?

<damo22>Pellescours: you might be right...

<damo22>but on the intel box, it found the ACPI irq but it still failed to identify the drive

<damo22>but seems to work fine with non-smp

<damo22>ah no, i just tested it with UP and apic, it fails to identify the drive but Found IRQ resource 11

<damo22>something is up with rump

<damo22>or the acpi irq

IRC channel logs

2024-12-26.log