<damo22>#2 0x08048e68 in acpi_os_wait_semaphore (handle=0x0, units=1, timeout=65535) <damo22> at ../../libacpica/acpi_init.c:166 <damo22>#3 0x0804b5c3 in acpi_ut_acquire_mutex (mutex_id=2) at ../../libacpica/utmutex.c:239 <Pellescours>damo22: i found the issue I think. put a break at `utmutex.c:239` and do a step, I’m in `acpi_os_acquire_mutex` <damo22>#define acpi_os_acquire_mutex(handle,time) acpi_os_wait_semaphore (handle, 1, time) <damo22>it tries to wait on a semaphore that isnt initialised yet <damo22>maybe there is a function i need to call in acpi_init.c that initialises the global semaphores <damo22>ok i think the initialize_subsystem call needs to be done before initialize_tables <damo22>now it hangs waiting on a real semaphore <damo22>#4 0x08048d38 in acpi_os_wait_semaphore (timeout=0, units=1, handle=0x100016f0) at ../../libacpica/acpi_init.c:166 <damo22>unless the code relies on a timed semaphore <AliciaC>acpi_os_wait_semaphore doesn't appear to use the units parameter? <damo22>then if it cant work straight away it will fail <AliciaC>I mean its value won't matter if it's not used (within that function anyway, might matter to the caller) <damo22>otherwise i will need to implement timeouts with absolute epochs <damo22>now there is a pointer to 0x2 that it cannot deref <damo22> hwacpi-0072 hw_set_mode : Attempting to enable ACPI mode <damo22>ACPI Error: Hardware did not change modes (20210105/hwacpi-114) <damo22>ACPI Error: Could not transition to ACPI mode (20210105/evxfevnt-58) <damo22>ACPI Warning: AcpiEnable failed (20210105/utxfinit-133) ***Server sets mode: +nt
<damo22>it still fails but looks better than before i think <Pellescours>ACPI Error: AE_ERROR, during \_SB.PCI0.PRES._INI execution (20210105/nsinit-656) <<< I don’t know if it’s normal or not <Pellescours>damo22: I think the bug is in the acpi_os_write_memory <damo22>im trying to figure out how to walk the pci tree in acpi <damo22>because to get the _PRT routing table you need to know the parent handle of the pci bus <damo22>but its mostly attached to the southbridge right? <damo22>i guess i need to know which device i am trying to look up the irq for, and walk the tree until i hit the device, then go up one level to the parent bus to get the handle to the _PRT <damo22>thats with static mode only, it doesnt quite look up the LNK yet <damo22>Pellescours: i just pushed more commits <damo22>youpi: i am ready to send in another round of patches for acpi, but how do you want to manage the library? should it be a separate lib from hurd tree? <damo22>if so, i need to refactor it such that it compiles without the hurd specific routines? <damo22>Pellescours: i think i fixed the error with _INI <damo22>ideally we can upstream everything needed for libacpica into acpica itself <damo22>we should be able to modify acpica-tools debian package <gnu_srs>damo22: Did you see: (05:44:02 PM): I got to the same conclusion as Pellescours. <gnu_srs>srs: Looks like the whole acpi_gbl_mutex_info() array is not initialized. <gnu_srs>You and Pellescours made more progress during the night. Good work :) <damo22>i almost have completed a function that will retrieve the IRQ <damo22>i need to parse the LNK found from the _PRT <damo22>look up the _CRS resource list for possible IRQs and then set the IRQ with _SRS method <damo22>apparently the irq is configurable in software <damo22>but the actual method needed to set particular value is stored in the DSDT on every machine <damo22>so thats why you still need ACPI to do it <damo22>acpi_os_enter_sleep() is a hook that is called before a sleep state is entered, we are not supposed to implement the sleep entering <damo22>it is designed to allow a function to be called before you shut the machine down or enter a sleep mode <damo22>although im not sure how the sleep mode is supposed to be triggered with acpica <damo22>we can just keep our existing shutdown method, and read the _SLP states from the acpica <damo22>so we dont have to guess them anymore <damo22>disappear_via_acpi() should call an RPC on the FADT table file <youpi>damo22: I'd say the library should rather be handled upstream yes. What do you mean by "without the hurd-specific routines"? Upstream can take hurd-specific code, just like parted does <damo22>its difficult to develop the rest of the code without the lib existing <damo22>im refactoring the shutdown code so it works on all machines <damo22>i assume the design will be that acpi server will link to the libacpica <damo22>youpi: subsystem pci 39000; what number do i use for ACPI <youpi>see grep subsystem * | sort -k 3 <youpi>the last shutdown subsystem was 40000, you can take 41000 <damo22>does that mean i have to recompile glibc? <youpi>you can build the RPC stubs by hand with a couple hurd Makefile rules, we have done that in the past already <youpi>I'd hope that the various people that did it documented it somewhere? <damo22>so mig can generate the headers without recompiling glibc <youpi>glibc providfes the stubs in libhruduser, but you can just as well compile them <damo22>ive generated some stubs but they dont have S_ <damo22>what is the correct mig flag to introduce S_ as the server prefix? <youpi>you generated the client stubs perhaps? <damo22>cat makeit | gcc -E -x c - -o - | mig -cc cat - /dev/null -subrprefix __ -server acpiServer.c -header acpi_S.h <youpi>so it looks like th server part. does it not call S_* functions? <youpi>I don't think there is any need to specify anything to get a S_ prefix, I guess it's simply the mere default <youpi>to make sure whether it's client or server code in there <youpi>possiubly it's simply the client part <youpi>because somehow it's not thnking it has to produce server code <AliciaC>any chance -server is position-dependent? <youpi>what I'm usre of is that doing things randomly usually can't work <youpi>thus taking existing things that already work, and reproduce it <damo22>but it was for client and i changed the params <youpi>that's what I call "doing things randomly" <youpi>I have no idea by heart how it should be done, so I wouldn't ever dare doing it this way <damo22>so one day hurd build deps will require acpica-tools ? <Pellescours>damo22: I suppose we want to have acpi_enable_subsystem enable and working? <damo22>Pellescours: i dont think it is strictly needed yet, we only need to parse the DSDT to get the pci interrupts currently <damo22>ive force pushed to my branch and added more rpcs and other goodies <youpi>damo22: not necessarily require, but for supporting some acpi functionalities, yes, and that's fine, just like our libstore uses libparted to support partitions <damo22>youpi: for booting with APIC it is required <youpi>for booting partitioned systems, libparted is required :) ***c0le is now known as Guest63990
***nckx is now known as jorts