Hi Devin, Dne 28. 09. 21 v 21:04 Devin Steffler napsal(a): Hello, I am using ACPICA to read battery information in QNX. That part is working great so far. However, now some code that is being used to make beeps via the PC speaker stopped working. Strangely, this code stops working on a few devices only after ACPICA runs. You mean same device with same mainboard / BIOS version? Maybe SMI and/or ACPI bytecode turns on 8254 clock gating? You can try to disassemble the ACPI DSDT/SSDT bytecode and look for it. What you can also do, is to try out to send ACPI enable SMI command without enabling ACPICA and see if it breaks. You can read the I/O port address and data enable command from FADT. To disassemble the ACPI tables use acpidump acpixtract and iasl utillites in linux. What could my ACPICA be doing (or failing to do) that could cause the beeps to stop working with the code below? Is the PIT being disabled somehow? I guess I'll need to learn more about the PIT and how to check its status to see if it's being disabled after ACPICA runs. Here's example code for QNX to generate a beep using the PC speaker: // ----------------------------------------------- #include <sys/neutrino.h> #include <hw/inout.h> #include <unistd.h> int main(void) { ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions // start a beep int freq = 1000; int scale = 1193046 / freq; out8(0x43, 0xb6); out8(0x42, scale & 0xff); out8(0x42, scale >> 8); out8(0x61, in8(0x61) | 3); you can also try to see if your assembly for out8 is correct and maybe not re-ordered by the compiler or that your asm clobber list is correct (same for in8) // let the beep play for a second delay(1000); delay is an OS service right? Thanks, Rudolf

Hello, I am using ACPICA to read battery information in QNX. That part is working great so far. However, now some code that is being used to make beeps via the PC speaker stopped working. Strangely, this code stops working on a few devices only after ACPICA runs. It works fine if I don't start ACPICA. The code is using I/O ports 0x43, 0x42, and 0x61 to generate beeps. This seems to be an industry standard way to make beeps on x86 based PCs using a Programmable Interval Timer (PIT). What could my ACPICA be doing (or failing to do) that could cause the beeps to stop working with the code below? Is the PIT being disabled somehow? I guess I'll need to learn more about the PIT and how to check its status to see if it's being disabled after ACPICA runs. Here's example code for QNX to generate a beep using the PC speaker: // ----------------------------------------------- #include <sys/neutrino.h> #include <hw/inout.h> #include <unistd.h> int main(void) { ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions // start a beep int freq = 1000; int scale = 1193046 / freq; out8(0x43, 0xb6); out8(0x42, scale & 0xff); out8(0x42, scale >> 8); out8(0x61, in8(0x61) | 3); // let the beep play for a second delay(1000); // stop the beep out8(0x61, in8(0x61) & ~3); return 0; } // ----------------------------------------------- Thanks, Devin

On 30. 09. 21 15:53, Devin Steffler wrote: > Hello, > > Will Miles suggested that I monitor AcpiOsRead* and AcpiOsWrite* calls. I observed the following: > ./test_sound # it plays fine > ./acpica > AcpiOsReadPort: read 0x0 from 0x1804 with width 16 > AcpiOsReadPort: read 0x0 from 0x1804 with width 16 > AcpiOsWritePort: write 0xa0 to 0xb2 with width 8 This is likely the SMI_CMD and ACPI_ENABLE see my other mail. > AcpiOsReadPort: read 0x1 from 0x1804 with width 16 > ./test_sound # it stops working > > To check if that write to 0xb2 is related, I modified AcpiOsWritePort to return AE_OK on all writes to Address 0xb2 without doing the actual write. I also modified AcpiOsReadPort to do a "fake read" of 1 when reading from port 0x1804 if there was a previous write to 0xb2. When I do this, then the beep continues to work and reading battery information via ACPI also continues to work (at least on this laptop, I haven't tested other devices yet). Try vice versa, do not enable/use the ACPICA at all and write 0xa0 to 0xb2 to see if it breaks it. > Looking at the PCH datasheet for the Intel i5 11357G CPU (what I'm using at the moment), it looks like writing to 0xb2 will trigger an SMI and set "APMC_EN =1" and is reported via APM_STS. Does this mean that it's supposed to activate power management and enable SMI interrupts for BIOS controlled power management (i.e. to be executed by ACPICA via SMI interrupt handlers)? It tells BIOS, hey I'm ACPI aware OS stop messing around. And basically BIOS runs some unknown code in SMM when you just write to 0xb2 the 0xA0 command. This unknown code can possibly enable the 8254 clock gating. >I'm not sure why that would break the PC speaker. Could it be that my OSL interrupt handling is broken and BIOS was relying on it to re-enable the devices needed to use the PC speaker? The PC speaker does not do anything with IRQs. The PIT has no architecturally defined way to be disabled. I don't know what Intel smokes but lets not inhale, intel invented the clock gating to make programers life more miserable (problem for TSC/lapic clock calibration when you have no HPET) > Or could APMC_EN=1 also "turn off some devices (that the PC speaker requires) to save power as they won't be used by this OS"? Should I instead be looking at the ACPI tables for this laptop to see if something is being turned off to save power and figure out how to turn them back on via ACPI calls? This is likely not the problem. The ACPI tables do not instruct the hardware, because you commented out above write. Also most hardware for chipset is memory mapped, not IOport mapped. Try what I wrote above. If it breaks, it confirms that BIOS is doing something behind the scene which is not even ACPICA related. > The same section (22.4.5 SMI#/SCI Generation) in the datasheet also states things like the following: > "The SCI is a level-mode interrupt that is typically handled by an ACPI-aware operating > system. In non-APIC systems (which is the default), the SCI IRQ is routed to one of > the 8259 interrupts (IRQ 9, 10, or 11). The 8259 interrupt controller must be > programmed to level mode for that interrupt." I don't think it is problem with SCI. See above. The 8254 clock gating will slow down the PIT frequency 16x and it will stop legacy IRQ 0 (on PIC/IOAPIC) generation as a symptom of clock gating. This is not documented but it behaves like that. Yes again intel did not stop the counter completely to detect it but slowed down. Sigh. Maybe it also affects PC speaker that it generates waveforms too slowly. You can also try to search BIOS option in setup menu for clock gating or try to disable C11 power state in there. Yes it is mess. Thanks, Rudolf