From: Grover, A. <and...@in...> - 2002-03-30 01:37:28
|
OK, a new release is on http://sourceforge.net/projects/acpi <http://sourceforge.net/projects/acpi> . While this release should fix some users' problems, I will not be sending it to Linus, or updating the Intel web site just yet -- immediately prior to release, we found an issue that required us to always enable CONFIG_ACPI_DEBUG. Hopefully we can squash that one early next week and then go all out. There's also another release of ospmd to play with, but it is still not ready for prime time (see release notes.) Regards -- Andy ---------------------------------------- Summary of changes for this release: 03_29_02 1) ACPI CA Core Subsystem Version 20020329: Implemented support for late evaluation of TermArg operands to Buffer and Package objects. This allows complex expressions to be used in the declarations of these object types. Fixed an ACPI 1.0 compatibility issue when reading Fields. In ACPI 1.0, if the field was larger than 32 bits, it was returned as a buffer - otherwise it was returned as an integer. In ACPI 2.0, the field is returned as a buffer only if the field is larger than 64 bits. The TableRevision is now considered when making this conversion to avoid incompatibility with existing ASL code. Implemented logical addressing for AcpiOsGetRootPointer. This allows an RSDP with either a logical or physical address. With this support, the host OS can now override all ACPI tables with one logical RSDP. Includes implementation of "typed" pointer support to allow a common data type for both physical and logical pointers internally. This required a change to the AcpiOsGetRootPointer interface. Implemented the use of ACPI 2.0 Generic Address Structures for all GPE, Fixed Event, and PM Timer I/O. This allows the use of memory mapped I/O for these ACPI features. Initialization now ignores not only non-required tables (All tables other than the FADT, FACS, DSDT, and SSDTs), but also does not validate the table headers of unrecognized tables. Fixed a problem where a notify handler could only be installed/removed on an object of type Device. All "notify" objects are now supported -- Devices, Processor, Power, and Thermal. Removed most verbosity from the ACPI_DB_INFO debug level. Only critical information is returned when this debug level is enabled. Code and Data Size: Current core subsystem library sizes are shown below. These are the code and data sizes for the acpica.lib produced by the Microsoft Visual C++ 6.0 compiler, and these values do not include any ACPI driver or OSPM code. The debug version of the code includes the debug output trace mechanism and has a larger code and data size. Note that these values will vary depending on the efficiency of the compiler and the compiler options used during generation. Previous Release Non-Debug Version: 65.4K Code, 6.2K Data, 71.6K Total Debug Version: 138.0K Code, 56.6K Data, 194.6K Total Current Release: Non-Debug Version: 66.6K Code, 6.5K Data, 73.1K Total Debug Version: 139.8K Code, 57.4K Data, 197.2K Total 2) Linux: The processor driver (acpi_processor.c) now supports ACPI 2.0-based processor performance control (e.g. Intel(R) SpeedStep(TM) technology). Note that older laptops that only have the Intel "applet" interface are not supported through this. The 'limit' and 'performance' interface (/proc) are fully functional. [Note that basic policy for controlling performance state transitions will be included in the next version of ospmd.] The idle handler was modified to more aggressively use C2, and PIIX4 errata handling underwent a complete overhaul (big thanks to Dominik Brodowski). Added support for ACPI-PCI device binding (acpi_pci_root.c). _ADR-based devices in the ACPI namespace are now dynamically bound (associated) with their PCI counterparts (e.g. PCI1- >01:00.0). This allows, among other things, ACPI to resolve bus numbers for subordinate PCI bridges. Enhanced PCI IRQ routing to get the proper bus number for _PRT entries defined underneath PCI bridges. Added IBM 600E to bad bios list due to invalid _ADR value for PIIX4 PCI-ISA bridge, resulting in improper PCI IRQ routing. Partial implementation of full MADT support (e.g. IOAPIC) for IA32 (acpi.c, mpparse.c). Added back visual differentiation between fixed-feature and control-method buttons in dmesg. Buttons are also subtyped (e.g. button/power/PWRF) to simplify button identification. We no longer use -Wno-unused when compiling debug. Please ignore any "_THIS_MODULE defined but not used" messages. Can now shut down the system using "magic sysrq" key. (Wolly) ----------------------------- Andrew Grover Intel Labs / Mobile Architecture and...@in... |
From: Ernst H. <ea...@ne...> - 2002-03-30 03:32:13
|
On Saturday, 30. March 2002 02:37, Grover, Andrew wrote: > OK, a new release is on http://sourceforge.net/projects/acpi > <http://sourceforge.net/projects/acpi> . > Patches successful SuSE 2.4.18, but does'n compile: [.....] make all_targets make[3]: Entering directory `/usr/src/linux-2.4.18.SuSE/drivers/acpi' gcc -D__KERNEL__ -I/usr/src/linux-2.4.18.SuSE/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -D_LINUX -I/usr/src/linux-2.4.18.SuSE/drivers/acpi/include -DACPI_DEBUG -DKBUILD_BASENAME=acpi_ksyms -DEXPORT_SYMTAB -c acpi_ksyms.c acpi_ksyms.c:31: unterminated `#if' conditional acpi_ksyms.c:97: `acpi_hw_register_bit_access' undeclared here (not in a function) acpi_ksyms.c:97: initializer element is not constant acpi_ksyms.c:97: (near initialization for `__ksymtab_acpi_hw_register_bit_access.value') acpi_ksyms.c:98: `acpi_hw_obtain_sleep_type_register_data' undeclared here (not in a function) acpi_ksyms.c:98: initializer element is not constant acpi_ksyms.c:98: (near initialization for `__ksymtab_acpi_hw_obtain_sleep_type_register_data.value') make[3]: *** [acpi_ksyms.o] Error 1 [......] Regards <Earny> |
From: Dominik B. <de...@br...> - 2002-03-30 08:34:12
|
Hi! Release looks quite good so far, I won't argue about /devices/root/{ACPI,root}/ during Easter time ;~). I'll address some minor issues with acpi_processor.c later. However, something doesn't work anymore: In "dmesg" appear a couple of lines like the following: PCI: No IRQ known for interrupt pin A of device 00:0c.0. Please try using pci=biosirq. System: PIIX4E, Gericom a.k.a. Clevo NB 3420, no APIC. Happy Easter time, Dominik |
From: Arndt S. <ab...@sr...> - 2002-03-30 23:39:49
Attachments:
dmesg.2.4.18+acpi-20020329
dmesg.2.4.18+acpi-20020308
|
On Sat, Mar 30, 2002 at 09:31:57AM +0100, Dominik Brodowski wrote: > [...] > In "dmesg" appear a couple of lines like the following: > PCI: No IRQ known for interrupt pin A of device 00:0c.0. Please try using > pci=biosirq. > [...] Same here with a Gericon 1st Supersonic M6-T laptop (which purportedly is a FIC A380 OEM), where the message line reads PCI: No IRQ known for interrupt pin C of device 00:07.5. Please try using pci=biosirq. With the 20020329 patch, the IRQs for some builtin devices don't seem to be found; usb-uhci still knows that it has IRQ 5, but AC97 sound and the builtin NIC think they have IRQ 0. This worked with both the 20020225 and the 20020308 patches, so I'll stick with acpi-20020308 for now. Attached you'll find two dmesg outputs of a 2.4.18 kernel after booting, first with acpi-20020329, second with acpi-20020308, in case you want to investigate this. Please tell me if you need more information. Thank you very much for your work, ACPI folks! Before I came across the ACPI patch, I couldn't run Linux on my laptop at all... Arndt -- Arndt Schoenewald <ab...@sr...> |
From: Jeff S. <je...@po...> - 2002-03-30 10:35:30
|
On Saturday 30 March 2002 1:37, Grover, Andrew wrote: > OK, a new release is on http://sourceforge.net/projects/acpi > <http://sourceforge.net/projects/acpi> . > > While this release should fix some users' problems, I will not be sending > it to Linus, or updating the Intel web site just yet -- immediately prior > to release, we found an issue that required us to always enable > CONFIG_ACPI_DEBUG. Hopefully we can squash that one early next week and > then go all out. Is there an incremental patch for this (20020308->20020329)? Thanks - Jeff Snyder |
From: David R. <dr...@no...> - 2002-03-30 16:30:58
|
Definitely seeing progress!!! Machine HP Pavilion n5425 AMD Mobile Athlon 900 Phoenix BIOS (Updated to latest version) Status Patch compiles cleanly for me S1 works!!!! 1st time it's worked. echo -n 1 > /proc/acpi/sleep puts the machine into standby. The power switch wakes it S3 doesn't work. Falls asleep, but doesn't wake S5 works, if it's supposed to be a hard power-off. S2 and S4 don't do anything. cat /proc/acpi/sleep says that we support S4, but not S2, but S4 doesn't do anything Battery, power and thermal status work USB still doesn't work. Both USB and ACPI are on IRQ 9 When loading the USB modules, it says usb_control/bulk_msg: timeout usb-ohci.c: unlink URB timeout usb.c: USB device not accepting new address=3 (error=-110) cat /proc/acpi/events doesn't show anything when hitting buttons. But, wake still works on S1 throttling seems to work, but I haven't benchmarked it yet. I set it to the highest throttling. A kernel compile feels slow. Even dmesg is annoyingly slow. So, I think it works. Can anyone send me valid values to use with the power state? echo -n ??? >/proc/acpi/processor/CPU0/power -Dave P.S. I can send debugging info (dsdt, dmesg, etc), if you want. |
From: Dominik B. <de...@br...> - 2002-03-30 17:21:35
|
David: > Can anyone send me valid values to use with the power state? > > echo -n ??? >/proc/acpi/processor/CPU0/power processor/.../power is a read-only file. Dominik |
From: John C. <jo...@de...> - 2002-04-03 04:58:09
|
On Sun, 31 Mar 2002, David Rudder wrote: > Definitely seeing progress!!! > > Machine > HP Pavilion n5425 > AMD Mobile Athlon 900 > Phoenix BIOS (Updated to latest version) .... > > USB still doesn't work. Both USB and ACPI are on IRQ 9 > When loading the USB modules, it says read http://www.deater.net/john/PavilionN5430.html, near the bottom, about USB, although you might find the whole page useful. john.c -- John Clemens http://www.deater.net/john jo...@de... ICQ: 7175925, IM: PianoManO8 "I Hate Quotes" -- Samuel L. Clemens |
From: Stephane D. <ste...@an...> - 2002-04-02 07:49:08
Attachments:
dmesg.txt
|
Hello, I tested the last patch on a Sony Vaio GR-214MP with a 2.4.18 kernel. Please see my dmesg.txt file attached for details on boot. So far so good, nearly happy about everything. I have only one (but quite important) problem. IRQs assigning which seems to be borked again. I use the integrated winmodem (connexant modem with rockwell chipset) on my laptop to connect through vpn & ssh. As i don't have winXP anymore on it, only linux will do. I've been running on kernel 2.4.17 + 20011218 ACPI patch + IRQ patch provided on this list which is the only combination able to detect my modem so far ... As soon as i apply another ACPI patch, wvdial says : tux3:~# wvdialconf /etc/wvdial.conf Scanning your serial ports for a modem. Port Scan<*1>: S0 ttyS0.orig<*1>: ATQ0 V1 E1 -- ATQ0 V1 E1 -- ATQ0 V1 E1 -- nothing. Port Scan<*1>: S1 S2 S3 Sorry, no modem was detected! Is it in use by another program? Furthermore, messages add : Apr 2 08:38:11 tux3 kernel: PCI: No IRQ known for interrupt pin C of device 00:1d.2. Any idea if i missed something ? Thanks for your help. Steph |