IRC channel logs


back to list of logs

<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
<Pellescours>it seems that mutex initialization is never done
<Pellescours>damo22: acpi_ut_mutex_initialize ?
<Pellescours>(in utmutex)
<damo22>ok i think the initialize_subsystem call needs to be done before initialize_tables
<damo22>in the acpi_init() function
<damo22>i wrote acpi_init.c
<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>maybe units should be 0?
<damo22>unless the code relies on a timed semaphore
<damo22>and expects it to time out
<damo22>i have implemented wait forever
<AliciaC>acpi_os_wait_semaphore doesn't appear to use the units parameter?
<damo22>yeah i assumed it was 1
<damo22>maybe i will try trywait
<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>i think i fixed it
<damo22>i got a massive output log
<damo22>it crashed at inw
<damo22>because no ioperm
<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)
<damo22>OUCH! where = 4
<damo22>i pushed this commit
***Server sets mode: +nt
<damo22>ah yes i tried that
<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
<damo22>yeah not sure
<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>i have a handle to the root
<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>IRQ for 00:1f.2 = 10
<damo22>thats with static mode only, it doesnt quite look up the LNK yet
<damo22>getting there!
<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
<damo22>to compile the lib for us
<gnu_srs>damo22: Did you see: (05:44:02 PM): I got to the same conclusion as Pellescours.
<gnu_srs>srs: Debugging acpi_init shows: PM)
<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>gnu_srs: i did not see that
<damo22>i almost have completed a function that will retrieve the IRQ
<damo22>for any device
<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>and return the value
<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>its completely bonkers
<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
<youpi>for instance yes
<damo22>youpi: subsystem pci 39000; what number do i use for ACPI
<damo22>i have written 2 rpcs
<damo22>a third one is coming
<youpi>see grep subsystem * | sort -k 3
<youpi>the last shutdown subsystem was 40000, you can take 41000
<damo22>ok will check too
<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
<damo22>kern_return_t acpi_get_irq
<youpi>what's tyhe content?
<damo22>its a stub
<youpi>but what is in there?
<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>no idea
<youpi>documentation knows
<youpi>previous code knows
<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>i took it from rumpkernel
<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>but it would be nice i suppose
<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