Re: Haswell, i3, fail to acpi_throttle fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/06/15 13:41, Jung-uk Kim wrote: > On 01/05/2015 22:57, Kevin Oberman wrote: >> On Mon, Jan 5, 2015 at 4:56 PM, Sean Bruno >> wrote: >> >>> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >>> >>> acpi_throttle0: on cpu0 acpi_throttle0: >>> P_CNT from P_BLK 0x1810 est0: >> Control> on cpu0 acpi_throttle1: on cpu1 >>> acpi_throttle1: failed to attach P_CNT device_attach: >>> acpi_throttle1 attach returned 6 est1: >> Frequency Control> on cpu1 acpi_throttle2: >> Throttling> on cpu2 acpi_throttle2: failed to attach P_CNT >>> device_attach: acpi_throttle2 attach returned 6 est2: >> SpeedStep Frequency Control> on cpu2 acpi_throttle3: >> Throttling> on cpu3 acpi_throttle3: failed to attach P_CNT >>> device_attach: acpi_throttle3 attach returned 6 est3: >> SpeedStep Frequency Control> on cpu3 >>> >>> >>> The call to acpi_bus_alloc_gas() in acpi_throttle.c seems to be >>> failing to attach. What should I be poking at here? >>> >> >> Excellent! Throttling is counter-productive and always has been. >> It's been at least 5 years since mav@ posted his excellent wiki >> article on power management which demonstrated the futility of >> throttling. More important, even if it was useful for power >> management, it has long since been superseded by TCC. Intel >> tried to make the purpose of TCC clear by the name: Thermal >> Control Circuit. So it is ineffective for power management and >> FreeBSD still tries to use it. Looks like the vendor broke ACPI >> so throttling won't work. Or, maybe, Intel simply removed it as >> unused legacy. >> >> Don't worry. Be happy! Make sure that >> hint.acpi_throttle.0.disabled=1 is set in /boot/loader.conf to >> disable it. I'd strongly urge that you also disable P4TCC with >> hint.p4tcc.0.disabled=1. It will trivially improve battery life >> and will seriously compromise performance if powerd is enabled. >> It can also cause hangs with elevated C-states on some systems. > > FYI, acpi_throttle and tcc have been disabled by default for a > while. > > https://svnweb.freebsd.org/changeset/base/265329 > > I guess Nathan forgot to MFC this commit? > > Jung-uk Kim > > Well, I'm running -current. I don't know, for my case, that an MFC is correct. Is it a bug that this stuff is appearing at all? sean FreeBSD bruno 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r276355M: Mon Jan 5 17:52:37 PST 2015 sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUrFzzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kZtgIANLbUDUly1KJgls/GHNGXuHE WdruuhibrIfHZuoaFSKtodL4SHtqKljfzTxk61ZazOqDixkhaMpyiDa6u23RxyGN 92PeBFmxBkVgdrPwaShOtGiPaREomfMbyB989/avBIBvbUHzKYyZ+PFxbf4In5M7 03ZcLoe7S9Y1Y6MMJkYJS4le80dIBM8XbGuz4qpC6Hq7ncBZPlxDDEtHqKbX0lCF 9izMAl+Ax42LbbqL7GsxXvNeE668AU2gbBOCsgX59MgdNieqm2q9mzq9t0+/DW9s vR7vQkJALhfrJAObm1i4of85lI+iEBt3rt9xWDALSjlixBL9eXDf6OF6ZrmjMQM= =oaxO -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Haswell, i3, fail to acpi_throttle fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1810 est0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 est1: on cpu1 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 est2: on cpu2 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 est3: on cpu3 The call to acpi_bus_alloc_gas() in acpi_throttle.c seems to be failing to attach. What should I be poking at here? sean -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUqzKGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kzA8IAI3M5ZKFrHuu8zGihSj3elar qzYqjLdLnflBkxgzrs0e4evJofXfMcVlhsyR+DZv2CPij95lioQ0YpX+BY3oPzxJ oljC9BiI7TYJ2yTrepC3r0SSLosLGAxp8XIxdSfuGujUYXGKaI55r4wB/dB6z2TR ItVsjd5PDQYaQskEF7XWb3frDcnAH29F3mik/js76TvS2u11Wz0wCtBsWKHB8ByW Im98OUmHAtycMDyab1t3JNUa7EaIRccchzEQ5o+rKbp1KZcV8rcMsS/QchDWFSFN jywStS20C7B40T+W6/x6DuzImRrqxTOxsXubNMcSITbl4URj4ncshIPBFPvMz3o= =A10d -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
[Lenovo x240] acpi_throttle fails to attach
x240 dsdt --> http://people.freebsd.org/~sbruno/acpi_dump_lenovo_x240.dsdt It sort of looks like we havn't implemented something for newer haswell cpus yet? acpi_throttle0: on cpu0 est0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 est1: on cpu1 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 est2: on cpu2 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 est3: on cpu3 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Missing: hw.acpi.thermal.tz%d._HOT
> > Just for curious minds: > > Afternoon and evenings bring direct sunlight to where the machine is. > And I guess that is showing? probably? > # sysctl dev.cpu | grep temp > dev.cpu.0.temperature: 16.8C > dev.cpu.1.temperature: 16.8C > dev.cpu.2.temperature: 16.8C > dev.cpu.3.temperature: 16.8C > dev.cpu.4.temperature: 16.8C > dev.cpu.5.temperature: 16.8C > dev.cpu.6.temperature: 16.8C > dev.cpu.7.temperature: 16.8C I have an FX-8150 based system similar, but a bit older that this one: Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M5A88-M Processor Information Socket Designation: AM3R2 Type: Central Processor Family: FX Manufacturer: AMD ID: 12 0F 60 00 FF FB 8B 17 Version: AMD FX(tm)-8150 Eight-Core Processor At idle, the machine reports pretty low temps: dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.core0.sensor0: 16.2C But when doing builds with all the cpus firing: dev.amdtemp.0.core0.sensor0: 49.5C ... dev.amdtemp.0.core0.sensor0: 52.3C ... dev.cpu.0.temperature: 53.0C Seems legit to me. sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
On Wed, 2014-06-04 at 15:32 -0700, Adrian Chadd wrote: > Hi, > > Please also document why it is/isn't working. It's only documented as > "suspend/resume doesn't work" :) > > > -a Well there's this that trasz updated to indicate that it works: https://wiki.freebsd.org/SuspendResume I just updated this to indicate the same information: https://wiki.freebsd.org/Laptops/Thinkpad_T61 sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
On Wed, 2014-06-04 at 09:35 -0700, Adrian Chadd wrote: > Which devices? > > > -a > > On 4 June 2014 09:07, Sean Bruno wrote: > > On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: > >> On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > >> > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > >> > > -BEGIN PGP SIGNED MESSAGE- > >> > > Hash: SHA1 > >> > > > >> > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > >> > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > >> > > > length of zero (and is thus invalid)? > >> > > > >> > > BTW, ACPI 5.0a (page 121) says: > >> > > > >> > > "This is an optional field; if this register block is not supported, > >> > > this field contains zero." > >> > > > >> > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > >> > > > >> > > Jung-uk Kim > >> > > >> > So, reverting John's changes and applying yours seems to do new things > >> > while not quieting the old error messages. Perhaps this is significant? > >> > > >> > real memory = 2147483648 (2048 MB) > >> > avail memory = 2007089152 (1914 MB) > >> > Event timer "LAPIC" quality 400 > >> > ACPI APIC Table: > >> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> > FreeBSD/SMP: 1 package(s) x 2 core(s) > >> > cpu0 (BSP): APIC ID: 0 > >> > cpu1 (AP): APIC ID: 1 > >> > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > >> > (20130823/tbfadt-601) > >> > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > >> > or length: 0x102C/0x0 (20130823/tbfadt-630) > >> > ioapic0: Changing APIC ID to 1 > >> > ioapic0 irqs 0-23 on motherboard > >> > random: initialized > >> > kbd1 at kbdmux0 > >> > acpi0: on motherboard > >> > CPU0: local APIC error 0x40 > >> > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to > >> > 15) - Ignoring GPE1 (20130823/evgpeinit-178) > >> > >> Actually, I think all these patches are changing nothing, and this actually > >> points out that I misread your FADT at the first. GPE1 should actually be > >> ignored since it does in fact overlap. Can you just try reverting all your > >> changes and seeing if suspend/resume works? > >> > > > > > > Boy oh boy ... talk about a waste of time. > > > > trasz@ and I have the same laptop and I just confirmed with him that the > > patch does nothing useful (as both of you suggested). The *ACTUAL* > > problem seems to be related to disabling devices in the Thinkpad BIOS. > > > > Disabling devices seems to cause the resume to not work correctly, but > > whatever. So none of these patches are actually needed. > > > > sean > > It looks like the on board modem is a bit touchy. sean hdacc1: at cad 1 on hdac0 unknown: at nid 2 on hdacc1 (no driver attached) ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
On Thu, 2014-05-29 at 09:30 -0400, John Baldwin wrote: > On Thursday, May 29, 2014 9:16:41 am Sean Bruno wrote: > > On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > > > length of zero (and is thus invalid)? > > > > > > BTW, ACPI 5.0a (page 121) says: > > > > > > "This is an optional field; if this register block is not supported, > > > this field contains zero." > > > > > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > > > > > > Jung-uk Kim > > > > So, reverting John's changes and applying yours seems to do new things > > while not quieting the old error messages. Perhaps this is significant? > > > > real memory = 2147483648 (2048 MB) > > avail memory = 2007089152 (1914 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > (20130823/tbfadt-601) > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > or length: 0x102C/0x0 (20130823/tbfadt-630) > > ioapic0: Changing APIC ID to 1 > > ioapic0 irqs 0-23 on motherboard > > random: initialized > > kbd1 at kbdmux0 > > acpi0: on motherboard > > CPU0: local APIC error 0x40 > > ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to > > 15) - Ignoring GPE1 (20130823/evgpeinit-178) > > Actually, I think all these patches are changing nothing, and this actually > points out that I misread your FADT at the first. GPE1 should actually be > ignored since it does in fact overlap. Can you just try reverting all your > changes and seeing if suspend/resume works? > Boy oh boy ... talk about a waste of time. trasz@ and I have the same laptop and I just confirmed with him that the patch does nothing useful (as both of you suggested). The *ACTUAL* problem seems to be related to disabling devices in the Thinkpad BIOS. Disabling devices seems to cause the resume to not work correctly, but whatever. So none of these patches are actually needed. sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
On Wed, 2014-05-28 at 18:43 -0400, Jung-uk Kim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2014-05-28 17:29:35 -0400, John Baldwin wrote: > > Err, I think it enables GPE1 as otherwise ACPICA assumes GPE1 has a > > length of zero (and is thus invalid)? > > BTW, ACPI 5.0a (page 121) says: > > "This is an optional field; if this register block is not supported, > this field contains zero." > > Therefore, we must assume X_GPE1_BLK it is NOT supported. > > Jung-uk Kim So, reverting John's changes and applying yours seems to do new things while not quieting the old error messages. Perhaps this is significant? real memory = 2147483648 (2048 MB) avail memory = 2007089152 (1914 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address or length: 0x102C/0x0 (20130823/tbfadt-630) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard CPU0: local APIC error 0x40 ACPI Error: GPE0 block (GPE 0 to 31) overlaps the GPE1 block (GPE 0 to 15) - Ignoring GPE1 (20130823/evgpeinit-178) acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7df0 (3) failed ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
On Wed, 2014-05-28 at 10:54 -0400, John Baldwin wrote:
> On Wednesday, May 28, 2014 7:08:36 am Sean Bruno wrote:
> > On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote:
> > > On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote:
> > > > On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote:
> > > > > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote:
> > > > > > Trying to figure out the failures on suspend resume for the T61 I
> > > > > > have.
> > > > > > I see a little acpi error at host startup, but I don't think its
> > > > > > related. However, I'm not sure what it means.
> > > > > >
> > > > > > sean
> > > > > >
> > > > > > --
> > > > > >
> > > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014
> > > > > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64
> > > > > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
> > > > > > VT: running with driver "vga".
> > > > > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz
> > > > > > K8-class CPU)
> > > > > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf
> > > > > > Stepping=10
> > > > > >
> > > > > > Features=0xbfebfbff
> > > > > >
> > > > > > Features2=0xe3bd
> > > > > > AMD Features=0x20100800
> > > > > > AMD Features2=0x1
> > > > > > TSC: P-state invariant, performance statistics
> > > > > > real memory = 2147483648 (2048 MB)
> > > > > > avail memory = 2007138304 (1914 MB)
> > > > > > Event timer "LAPIC" quality 400
> > > > > > ACPI APIC Table:
> > > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> > > > > > FreeBSD/SMP: 1 package(s) x 2 core(s)
> > > > > > cpu0 (BSP): APIC ID: 0
> > > > > > cpu1 (AP): APIC ID: 1
> > > > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block:
> > > > > > 0/32
> > > > > > (20130823/tbfadt-601)
> > > > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero
> > > > > > address
> > > > > > or length: 0x102C/0x0 (20130823/tbfadt-630)
> > > > >
> > > > > It might be related as Gpe1Block describes a register set that IIRC
> > > > > is used
> > > > > to enter sleep states. Can you put your acpidump -t somewhere? (No
> > > > > need
> > > > > for -d as this is in the FADT, not the DSDT.)
> > > > >
> > > >
> > > >
> > > > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt
> > >
> > > Ah, so the warning is due to the fact that the 'FACP' table has
> > > 'X_GPE1_BLOCK'
> > > but no 'GPE1_BLOCK'. (Note how it has both 'GPE0_BLOCK' and
> > > 'X_GPE0_BLOCK'
> > > which say the same thing.) Try this workaround to quiet the warning.
> > > I've
> > > no idea if it will help at all with suspend/resume.
> > >
> > > Index: sys/contrib/dev/acpica/components/tables/tbfadt.c
> > > ===
> > > --- tbfadt.c (revision 266442)
> > > +++ tbfadt.c (working copy)
> > > @@ -601,6 +601,10 @@ AcpiTbValidateFadt (
> > > ACPI_BIOS_WARNING ((AE_INFO,
> > > "32/64X length mismatch in FADT/%s: %u/%u",
> > > Name, ACPI_MUL_8 (Length), Address64->BitWidth));
> > > + if (Length == 0)
> > > + {
> > > + Length = ACPI_DIV_8 (Address64->BitWidth);
> > > + }
> > > }
> > >
> > > if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED)
> > >
> > >
> >
> > One warning went away, one remains, not sure if its meaningful or not.
> >
> > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32
> > (20130823/tbfadt-601)
>
> Yes, I didn't remove that warning, I just fixed it to use the 64-bit length
> when the 32-bit length was zero when that warning fires. Does this seem to
> have made any difference with anything on the laptop? (E.g. it might possibly
> affect hotkeys, etc.)
>
Believe it or not, but I just suspend/resumed on the thing, TWICE. Once
from the xfce menu -> suspend and once from
Fn->moonsymbolsuspendsleepthing on the F4 key.
Good grief. Thanks John.
sean
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
On Tue, 2014-05-27 at 16:14 -0400, John Baldwin wrote:
> On Tuesday, May 27, 2014 1:39:48 pm Sean Bruno wrote:
> > On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote:
> > > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote:
> > > > Trying to figure out the failures on suspend resume for the T61 I have.
> > > > I see a little acpi error at host startup, but I don't think its
> > > > related. However, I'm not sure what it means.
> > > >
> > > > sean
> > > >
> > > > --
> > > >
> > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014
> > > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64
> > > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
> > > > VT: running with driver "vga".
> > > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz
> > > > K8-class CPU)
> > > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10
> > > >
> > > > Features=0xbfebfbff
> > > >
> > > > Features2=0xe3bd
> > > > AMD Features=0x20100800
> > > > AMD Features2=0x1
> > > > TSC: P-state invariant, performance statistics
> > > > real memory = 2147483648 (2048 MB)
> > > > avail memory = 2007138304 (1914 MB)
> > > > Event timer "LAPIC" quality 400
> > > > ACPI APIC Table:
> > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> > > > FreeBSD/SMP: 1 package(s) x 2 core(s)
> > > > cpu0 (BSP): APIC ID: 0
> > > > cpu1 (AP): APIC ID: 1
> > > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32
> > > > (20130823/tbfadt-601)
> > > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address
> > > > or length: 0x102C/0x0 (20130823/tbfadt-630)
> > >
> > > It might be related as Gpe1Block describes a register set that IIRC is
> > > used
> > > to enter sleep states. Can you put your acpidump -t somewhere? (No need
> > > for -d as this is in the FADT, not the DSDT.)
> > >
> >
> >
> > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt
>
> Ah, so the warning is due to the fact that the 'FACP' table has 'X_GPE1_BLOCK'
> but no 'GPE1_BLOCK'. (Note how it has both 'GPE0_BLOCK' and 'X_GPE0_BLOCK'
> which say the same thing.) Try this workaround to quiet the warning. I've
> no idea if it will help at all with suspend/resume.
>
> Index: sys/contrib/dev/acpica/components/tables/tbfadt.c
> ===
> --- tbfadt.c (revision 266442)
> +++ tbfadt.c (working copy)
> @@ -601,6 +601,10 @@ AcpiTbValidateFadt (
> ACPI_BIOS_WARNING ((AE_INFO,
> "32/64X length mismatch in FADT/%s: %u/%u",
> Name, ACPI_MUL_8 (Length), Address64->BitWidth));
> + if (Length == 0)
> + {
> + Length = ACPI_DIV_8 (Address64->BitWidth);
> + }
> }
>
> if (FadtInfoTable[i].Type & ACPI_FADT_REQUIRED)
>
>
One warning went away, one remains, not sure if its meaningful or not.
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32
(20130823/tbfadt-601)
sean
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Investigating failed suspend/resume T61
On Tue, 2014-05-27 at 11:32 -0400, John Baldwin wrote: > On Friday, May 23, 2014 12:14:58 pm Sean Bruno wrote: > > Trying to figure out the failures on suspend resume for the T61 I have. > > I see a little acpi error at host startup, but I don't think its > > related. However, I'm not sure what it means. > > > > sean > > > > -- > > > > FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 > > sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 > > FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 > > VT: running with driver "vga". > > CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz > > K8-class CPU) > > Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 > > > > Features=0xbfebfbff > > > > Features2=0xe3bd > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant, performance statistics > > real memory = 2147483648 (2048 MB) > > avail memory = 2007138304 (1914 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 > > (20130823/tbfadt-601) > > ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address > > or length: 0x102C/0x0 (20130823/tbfadt-630) > > It might be related as Gpe1Block describes a register set that IIRC is used > to enter sleep states. Can you put your acpidump -t somewhere? (No need > for -d as this is in the FADT, not the DSDT.) > Here --> http://people.freebsd.org/~sbruno/T61_acpidump.txt sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Investigating failed suspend/resume T61
Trying to figure out the failures on suspend resume for the T61 I have. I see a little acpi error at host startup, but I don't think its related. However, I'm not sure what it means. sean -- FreeBSD 11.0-CURRENT #1 r265820: Sat May 10 15:13:37 PDT 2014 sbruno@bruno:/usr/obj/usr/src/sys/BRUNO amd64 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 VT: running with driver "vga". CPU: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (1995.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x6fa Family=0x6 Model=0xf Stepping=10 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2007138304 (1914 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address or length: 0x102C/0x0 (20130823/tbfadt-630) ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
device.hints -> hint.acpi_throttle.0.disabled="1
I found sys/dev/acpica/acpi_throttle.c today. Should I have this removed from a standard laptop configuration? I would think I would want the system to throttle itself when appropriate. Is this an older way of doing something like C-states or have I missed something? sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Sun, 2014-05-04 at 13:51 -0700, Adrian Chadd wrote: > I've tested it (-HEAD) on: > > * T43 > * T60 > * T60p > * T400 > * T500 > * T420 > * X220 > > I'm actively using the T60, T400 and X220 right now. > > T520, just works. Has for a while. I suspect disabling firewire and the eSATA port helps quite a bit. sean -arch for this. signature.asc Description: This is a digitally signed message part
Re: IPMI is broken on Intel S1200RP Board
On Fri, 2014-04-11 at 22:42 +0400, Vladimir Laskov wrote: > > > links > https://bitbucket.org/weec/docs/downloads/dmesg_verbose_boot.log > https://bitbucket.org/weec/docs/downloads/intel_s1200rp.dsdt > > Wanted to xpost this over to freebsd-acpi too. Since it looks to me that the IPMI driver isn't getting invoked, I assume that its because of a variance in ACPI parsing of the relevant IPMI section. sean > > On Fri, Apr 11, 2014 at 8:08 PM, Sean Bruno > wrote: > On Fri, 2014-04-11 at 07:47 +0400, venom wrote: > > ppc1: cannot reserve I/O port range > > pcib0: allocated type 4 (0x60-0x60) for rid 0 of atkbdc0 > > pcib0: allocated type 4 (0x64-0x64) for rid 1 of atkbdc0 > > atkbdc0: AT keyboard controller not found > > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > > ppc0: cannot reserve I/O port range > > pci0: driver added > > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > > domain=0, bus=0, slot=31, func=6 > > class=11-80-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci0: driver added > > found-> vendor=0x8086, dev=0x8c22, revid=0x05 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0143, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > found-> vendor=0x8086, dev=0x8c24, revid=0x05 > > domain=0, bus=0, slot=31, func=6 > > class=11-80-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > pci0:0:31:6: reprobing on driver added > > pci1: driver added > > pci2: driver added > > > > > > I don't see an attach here, so I assume that something is > "new" in the > acpi tables on this board. Can you dump the ACPI table > somewhere > "acpidump -dt > intel_s1200rp.dsdt" and post it somewhere we > can look at > it? > > freebsd.org mailing lists will strip attachments in most > cases, so a > pastebin or other link would be best. > > sean > > > signature.asc Description: This is a digitally signed message part
Re: Problems with amd FX 8 core and freq scaling
On Wed, 2013-11-13 at 18:35 -0500, Jung-uk Kim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2013-11-13 18:21:37 -0500, Adrian Chadd wrote: > > On 11 November 2013 13:47, Jung-uk Kim wrote: > > > >> Just in case, here I attached the uncommitted (and untested) > >> patch. > >> > > > > Would you mind describing everything that this patch does? > > The patch was written few years ago to fix crashes. However, I don't > remember too much detail any more, sorry. > Reviving this thread a bit. My AMD FX-8150 and Intel I7 seem to be happy with this patch. I guess, from my read, this is getting rid of some hard coded definitions for cpu throttling and doing a better job of reading from the ACPI throttling states (new data structure). If there's no objections, I'll bite the bullet and commit it. sean bcc jhb@ for commentary if needed. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Problems with amd FX 8 core and freq scaling
On Mon, 2013-11-11 at 16:47 -0500, Jung-uk Kim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote: > > On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote: > >> On 11 November 2013 12:00, Jung-uk Kim wrote: > >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >>> > >>> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: > But wouldn't this just disable frequency scaling and the > whole point of powerd? > >>> > >>> No. acpi_throttle (and p4tcc) controls T-state. "Frequency > >>> scaling" should be done by changing P-state. > > > >> Right. > > > >> IIRC, T-state is just for emergency temperature throttling. It > >> shouldn't be used outside of that. > > > > > > There have been a number of reports of throttling causing > > crashes. This setting does not prevent powerd from > > adjusting your CPU's clock, it just disables some arcane > > feature which pre-dates the modern power management > > methods. > > > >> .. did anyone ever figure out why crashes would be caused by > >> T-state adjustment? > > > > My memory is vague but I think it was not able to reject a broken > > FADT or _PTC table, or something like that. > > Just in case, here I attached the uncommitted (and untested) patch. > > Jung-uk Kim > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (FreeBSD) > > iQEcBAEBAgAGBQJSgVBgAAoJEHyflib82/FGACsIAJGDQGOYYO8dxvtQMw4BBnzl > BNbFkvalvHOzaSezJz+A4R0zeIMvkfJtu0Gb8qiTkxJF+REREFo6a7lmzC7hOMwa > 7PzRRRG34rtmnnHJro3Wc5qQwc1zBbmyFgYEJ45AkmIc62mpp9f0sZyNA1+aSpau > 2sY6H0dXktapc2pLR1uNyxfUlr1tRhoabceGSlGLYiB583FrMsvASkaTnuWQ2IfI > gytrJBKjMihu60KlwKauzUOVDrEuN3J/B1y7V/TrTXmcFmWgL9Wdw/gC7ToRdloT > JdF812Duj/xYvyoNEwkz1Rm0NT5r1ZTYqwMvkOPuMfK7IWX0O9UFO8VG+QnJXhU= > =/d/E > -END PGP SIGNATURE- > ___ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org" Up and running this patch now on my FX-8150. Anything interesting that I should gather report? sean signature.asc Description: This is a digitally signed message part
Re: Problems with amd FX 8 core and freq scaling
On Mon, 2013-11-11 at 16:47 -0500, Jung-uk Kim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2013-11-11 16:31:30 -0500, Jung-uk Kim wrote: > > On 2013-11-11 15:26:58 -0500, Adrian Chadd wrote: > >> On 11 November 2013 12:00, Jung-uk Kim wrote: > >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >>> > >>> On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: > But wouldn't this just disable frequency scaling and the > whole point of powerd? > >>> > >>> No. acpi_throttle (and p4tcc) controls T-state. "Frequency > >>> scaling" should be done by changing P-state. > > > >> Right. > > > >> IIRC, T-state is just for emergency temperature throttling. It > >> shouldn't be used outside of that. > > > > > > There have been a number of reports of throttling causing > > crashes. This setting does not prevent powerd from > > adjusting your CPU's clock, it just disables some arcane > > feature which pre-dates the modern power management > > methods. > > > >> .. did anyone ever figure out why crashes would be caused by > >> T-state adjustment? > > > > My memory is vague but I think it was not able to reject a broken > > FADT or _PTC table, or something like that. > > Just in case, here I attached the uncommitted (and untested) patch. > > Jung-uk Kim > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (FreeBSD) > > iQEcBAEBAgAGBQJSgVBgAAoJEHyflib82/FGACsIAJGDQGOYYO8dxvtQMw4BBnzl > BNbFkvalvHOzaSezJz+A4R0zeIMvkfJtu0Gb8qiTkxJF+REREFo6a7lmzC7hOMwa > 7PzRRRG34rtmnnHJro3Wc5qQwc1zBbmyFgYEJ45AkmIc62mpp9f0sZyNA1+aSpau > 2sY6H0dXktapc2pLR1uNyxfUlr1tRhoabceGSlGLYiB583FrMsvASkaTnuWQ2IfI > gytrJBKjMihu60KlwKauzUOVDrEuN3J/B1y7V/TrTXmcFmWgL9Wdw/gC7ToRdloT > JdF812Duj/xYvyoNEwkz1Rm0NT5r1ZTYqwMvkOPuMfK7IWX0O9UFO8VG+QnJXhU= > =/d/E > -END PGP SIGNATURE- > ___ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org" Let me test this on my fx-8150 tonight. What should I look for as a test failure/success? sean signature.asc Description: This is a digitally signed message part
RE: AMT Activation ACPI warnings
On Tue, 2013-08-20 at 19:20 +, Moore, Robert wrote: > We have seen at least one video vendor that uses a Buffer object > instead of the ACPI-required package object as the 4th _DSM argument. > > The T520 has a Nvidia thingy in it. Is this something we need to deal with in the BSD ACPI implementation or is this a vendor thing? Sean signature.asc Description: This is a digitally signed message part
AMT Activation ACPI warnings
ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130725/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130725/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130725/nsarguments-97) ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20130725/nsarguments-97) Since I activated AMT on my T520 laptop, I've been seeing these errors which I suspect are related to the KVM over IP capabilities. Not sure if they are meaningful in any way, but I thought I'd just see if they mean anything to anyone. Sean signature.asc Description: This is a digitally signed message part
ACPI Debugging
Been trying to get ACPI Debugging working via http://www.freebsd.org/doc/handbook/acpi-debug.html and am not getting any output. We've compiled with options ACPI_DEBUG, set debug.acpi.enable_debug_objects, debug.acpi.layer=ACPI_ALL_DRIVERS and debug.acpi.level=ACPI_LV_VERBOSE I'm not sure anything is happening as there doesn't appear to be anything further in the system logs. What obvious bit of sorcery am I missing here? Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: thinkpad keys T520
On Tue, 2013-03-12 at 15:56 -0700, Kevin Oberman wrote: > On Tue, Mar 12, 2013 at 2:57 PM, Sean Bruno > wrote: > the Fn key seems to send the system the same key command as > the power > button *should* send. This leads to many problems on this > machine. > > How can I start tracing code the key strokes for keys that are > not the > normal keyboard keys? e.g. the Fn key or vol up/down and the > power > button? > > If I load acpi_ibm(4), it doesn't seem to ever get used so I > am confused > as to where to start. > > Sean, > > I'm confused. I also have a T520, but the Fn key does not seem to > mis-behave on it at all. I have not gotten brightness adjustment to > work correctly to this point, but Fn has never triggered a power > operation for me. Your statement about acpi_ibm(4) is also baffling as > I have no problems with it with 9.1-Stable or head. It was broken in > some earlier versions before the Lenovo ID was added. > > Does your ThinkLight turn on and off if you set > dev.acpi_ibm.0.thinklight? When you press Fn+PgUp? Both work on my > T520. > > Perhaps I am not completely understanding the issue. > > -- > R. Kevin Oberman, Network Engineer > E-mail: rkober...@gmail.com On my T520, I do not need acpi_ibm(4) for the thinklight to function. It works with/without the module loaded. Hiren and I found adding this to the driver section of xorg.conf allows the fn-brightness keys to work: Option "RegistryDwords" "EnableBrightnessControl=1" The audio "mute" button actually seems to be working through the sound driver. The fn key seems to generate an unhandled APIC0 event, that is processed somewhere as a shutdown event. I'm using XFCE4 as my desktop and all the parts that come with it. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
thinkpad keys T520
the Fn key seems to send the system the same key command as the power button *should* send. This leads to many problems on this machine. How can I start tracing code the key strokes for keys that are not the normal keyboard keys? e.g. the Fn key or vol up/down and the power button? If I load acpi_ibm(4), it doesn't seem to ever get used so I am confused as to where to start. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: acpi error: ae_not_found
On Wed, 2013-03-06 at 16:01 -0800, Robert wrote: > Greetings > > Please CC me as I am not on this list. > > I was given a Toshiba L505D-LS5010 laptop I tried to load FreeBSD 9.1 > from Cd but got the following message (hand copied from picture): > > ACPI ERROR: [RSF] Namespace lookup failure, AE_NOT_FOUND > (20110527/psargs-392) > ACPI ERROR: Method parse/execution failure, > [\_GPE._L07] (Node 0xf002dc48), AE_NOT_FOUND (20110527/psparse-560) > ACPI EXCEPTION: AE_NOT_FOUND, while evaluating GPE method [_L07] > (2910527/evgpe-606) > > There were some earlier messages that were similar but with some > different data. The above keeps repeating until it dumps and reboots > and then starts all over. > > The bios is updated to the latest offered by Toshiba. I tried booting > with a 10.0 Current thumb drive snapshot but it failed sooner with a > different acpi message. > > I am able to install Xubuntu 12.10 but I do not care to have Linux on > this laptop. > > Any help would be greatly appreciated. > > Robert > ___ I think you may be in the position of taking photos of the screen while doing a boot verbose on it. Then post them somewhere we can see them. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: oh right, this one ...
On Tue, 2012-12-11 at 10:13 -0800, Sean Bruno wrote: > Finally got around to returning the Dell R620 series BIOS update that > breaks badly on FreeBSD. I suspect that there is an ACPI update going > on here that I need to figure out for -current. I'm going to disable > the pci bus that fails to attach via device hints and get an acpidump in > a bit. acpidump --> http://people.freebsd.org/~sbruno/r620_acpi.txt pciconf -lvcb --> http://people.freebsd.org/~sbruno/r620_pciconf.txt Problematic pci bus attach is on pcib6 pcib6: at device 28.0 on pci0 pcib6: domain0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: no prefetched decode device_attach: pcib6 attach returned 6 pcib6: irq 19 at device 28.7 on pci0 panic: Bad tailq NEXT(0x814f3318->tqh_last) != NULL A couple of comments here. It sure *looks* like the failure to attach doesn't clean up after itself, which then leads to a *reuse* of pcib6 data elements for pcib7! 1. we fail to attach to pcib6 2. we don't clean up properly on a failure to attach 3. we try to reuse the data structure that failed for the next pcib device. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
oh right, this one ...
Finally got around to returning the Dell R620 series BIOS update that breaks badly on FreeBSD. I suspect that there is an ACPI update going on here that I need to figure out for -current. I'm going to disable the pci bus that fails to attach via device hints and get an acpidump in a bit. pcib4: irq 53 at device 3.0 on pci0 pcib4: domain0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) pci0: at device 4.4 (no driver attached) pci0: at device 4.5 (no driver attached) pci0: at device 4.6 (no driver attached) pci0: at device 4.7 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 5.2 (no driver attached) pcib5: irq 16 at device 17.0 on pci0 pcib5: domain0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) ehci0: mem 0xdf8fe000-0xdf8fe3ff irq 23 at device 26.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 96 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached pcib6: at device 28.0 on pci0 pcib6: domain0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: no prefetched decode device_attach: pcib6 attach returned 6 pcib6: irq 19 at device 28.7 on pci0 panic: Bad tailq NEXT(0x814f3318->tqh_last) != NULL cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81bcb440 kdb_backtrace() at kdb_backtrace+0x39/frame 0x81bcb4f0 panic() at panic+0x174/frame 0x81bcb570 rman_init() at rman_init+0x166/frame 0x81bcb590 pcib_alloc_window() at pcib_alloc_window+0x87/frame 0x81bcb620 pcib_attach_common() at pcib_attach_common+0xaf9/frame 0x81bcb6b0 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x17/frame 0x81bcb6f0 device_attach() at device_attach+0x396/frame 0x81bcb740 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81bcb760 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x81bcb7b0 device_attach() at device_attach+0x396/frame 0x81bcb800 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81bcb820 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x81bcb870 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0x81bcb8c0 device_attach() at device_attach+0x396/frame 0x81bcb910 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81bcb930 acpi_attach() at acpi_attach+0xd58/frame 0x81bcb9f0 device_attach() at device_attach+0x396/frame 0x81bcba40 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81bcba60 nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0x81bcba90 device_attach() at device_attach+0x396/frame 0x81bcbae0 bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0x81bcbb10 bus_set_pass() at bus_set_pass+0x8f/frame 0x81bcbb40 configure() at configure+0xa/frame 0x81bcbb50 mi_startup() at mi_startup+0x118/frame 0x81bcbb70 btext() at btext+0x2c KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [rfc] bind curthread to target cpu for _CST change notification
On Thu, 2012-11-22 at 16:53 +0200, Andriy Gapon wrote: > I would like to propose the following patch which should kill two birds with > one > stone: > > - avoid race in acpi_cpu_cx_cst if more than one notifications occur in a > rapid > succession for the same CPU and end up being concurrently handled by ACPI > taskqeue > threads > - avoid race acpi_cpu_cx_cst and acpi_cpu_idle where the latter may access > resources being updated by the former > > What do you think? > > Index: sys/dev/acpica/acpi_cpu.c > === > --- sys/dev/acpica/acpi_cpu.c (revision 242854) > +++ sys/dev/acpica/acpi_cpu.c (working copy) > @@ -1047,7 +1047,16 @@ > return; > > /* Update the list of Cx states. */ > +thread_lock(curthread); > +sched_bind(curthread, sc->cpu_pcpu->pc_cpuid); > +thread_unlock(curthread); > +critical_enter(); > acpi_cpu_cx_cst(sc); > +critical_exit(); > +thread_lock(curthread); > +sched_unbind(curthread); > +thread_unlock(curthread); > + > acpi_cpu_cx_list(sc); > > ACPI_SERIAL_BEGIN(cpu); > Ack. This looks appropriate to me. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: Time to increase MAX_TASKS?
From: Andriy Gapon [a...@freebsd.org] Sent: Monday, November 12, 2012 10:06 AM To: sbr...@freebsd.org Cc: Sean Bruno; freebsd-acpi@freebsd.org Subject: Re: Time to increase MAX_TASKS? on 12/11/2012 19:24 Sean Bruno said the following: > This seems to "do the right thing" for now, any objections? Nope. Go for it. > Index: acpivar.h > === > --- acpivar.h (revision 242921) > +++ acpivar.h (working copy) > @@ -476,7 +476,7 @@ > > /* Default maximum number of tasks to enqueue. */ > #ifndef ACPI_MAX_TASKS > -#define ACPI_MAX_TASKS 32 > +#define ACPI_MAX_TASKS MAX(32, MAXCPU * 2) > #endif > > /* Default number of task queue threads to start. */ > > -- Andriy Gapon Done ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: Time to increase MAX_TASKS?
On Mon, 2012-08-13 at 11:54 -0700, Sean Bruno wrote: > > On Wed, 2012-08-08 at 10:23 -0700, Moore, Robert wrote: > > Just FYI, we've seen the AcpiOsExecute task Q get very large if > > There is a GPE flood that results in many, many notify operations. > > > > And in these cases, it was always related to the EC (Embedded Controller). > > > > Bob > > > > > For the time being, and because I don't know what I'm doing, I've bumped > my local freebsd9 version to use (MAX_CPU *2). > > I'm sure this means something horrific is about to happen to me that I > just don't know about yet. > > Sean > This seems to "do the right thing" for now, any objections? Index: acpivar.h === --- acpivar.h (revision 242921) +++ acpivar.h (working copy) @@ -476,7 +476,7 @@ /* Default maximum number of tasks to enqueue. */ #ifndef ACPI_MAX_TASKS -#defineACPI_MAX_TASKS 32 +#defineACPI_MAX_TASKS MAX(32, MAXCPU * 2) #endif /* Default number of task queue threads to start. */ ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: notify userland about C-state changes
On Wed, 2012-10-03 at 06:08 -0700, Andriy Gapon wrote: > > > > So quick question, does this happen a lot on a system with a > sporadic > > workload? Does this introduce overhead to the system to service the > > notification requests? > > I am not sure who can answer this question. It is up to ACPI platform > to decide > when it changes _available C-states_. OS doesn't have control over > that. > Hrm ... what changes to the machine would make this happen while the machine is running? things like the switching from battery to line power? > P.S. I hope you haven't confused this notification for a notification > about > _current_ C-state changing. I did have it confused. Thanks for putting this note in. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: notify userland about C-state changes
> The following patch adds only per-CPU notifications.
>
> acpi_cpu: explicitly notify userland about c-state changes
>
> diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c
> index 82e204a..15201f9 100644
> --- a/sys/dev/acpica/acpi_cpu.c
> +++ b/sys/dev/acpica/acpi_cpu.c
> @@ -1054,6 +1054,8 @@ acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void
> *context)
> ACPI_SERIAL_BEGIN(cpu);
> acpi_cpu_set_cx_lowest(sc);
> ACPI_SERIAL_END(cpu);
> +
> +acpi_UserNotify("PROCESSOR", sc->cpu_handle, notify);
> }
>
> static int
>
So quick question, does this happen a lot on a system with a sporadic
workload? Does this introduce overhead to the system to service the
notification requests?
Sean
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
RE: Time to increase MAX_TASKS?
On Wed, 2012-08-08 at 10:23 -0700, Moore, Robert wrote: > Just FYI, we've seen the AcpiOsExecute task Q get very large if > There is a GPE flood that results in many, many notify operations. > > And in these cases, it was always related to the EC (Embedded Controller). > > Bob > > For the time being, and because I don't know what I'm doing, I've bumped my local freebsd9 version to use (MAX_CPU *2). I'm sure this means something horrific is about to happen to me that I just don't know about yet. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Time to increase MAX_TASKS?
On Wed, 2012-08-08 at 04:25 -0700, John Baldwin wrote:
> I meant that with the limit jacked up to something that silences the
> warning
> (such as 128), what is the max number of tasks queued?
>
>
I set debug.acpi.max_tasks=128 and added a temp log message to
acpi_task_enqueue(). I see the system request *98* tasks according to
my test on this new Dell box. Is it possible that the queue really
isn't running yet or something?
AcpiOsExecute: acpi_task_count(98), acpi_max_tasks(128) max_threads(3)
code modified to generate log message:
for (at = NULL, i = 0; i < acpi_max_tasks; i++)
if (atomic_cmpset_int(&acpi_tasks[i].at_flag, ACPI_TASK_FREE,
ACPI_TASK_USED)) {
at = &acpi_tasks[i];
acpi_task_count++;
if (acpi_task_count > 63)
printf("AcpiOsExecute: acpi_task_count(%d),
acpi_max_tasks(%d) max_threads(%d)\n",
acpi_task_count, acpi_max_tasks,
acpi_max_threads);
break;
}
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Time to increase MAX_TASKS?
On Tue, 2012-08-07 at 14:30 -0700, John Baldwin wrote: > On Tuesday, August 07, 2012 2:43:17 pm Sean Bruno wrote: > > On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote: > > > On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > > > > I am currently running with a value of 128 and doing a bit of > > > > testing. > > > > > > > > I think it should be something like MAX(32, MAXCPU). > > > > > > Ah, that sounds WAY more reasonable. I shall test thusly. > > > > > > Sean > > > > > > > This did *not* work on a dual socket machine with MAXCPU at 64. > > Hmm, can you find out how many tasks it wanted? I know part of > it is a function of the number of CPUs (we queue a task for each > CPU at one point before tasks are running). > I extended the log message in acpi_task enqueue() with the current task count, max task setting and max thread setting when the error occurs. It appears that we are definitely going above max tasks from my review: AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable acpi_task_count(64), acpi_max_tasks(64) max_threads(3) I don't see any evidence that the log message in acpi_taskq_init() is firing at any point. "if (acpi_task_count > 0) ..." Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Time to increase MAX_TASKS?
On Tue, 2012-07-31 at 09:13 -0700, Sean Bruno wrote: > On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > > I am currently running with a value of 128 and doing a bit of > > testing. > > > > I think it should be something like MAX(32, MAXCPU). > > Ah, that sounds WAY more reasonable. I shall test thusly. > > Sean > This did *not* work on a dual socket machine with MAXCPU at 64. Amusing. sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Time to increase MAX_TASKS?
On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > I am currently running with a value of 128 and doing a bit of > testing. > > I think it should be something like MAX(32, MAXCPU). Ah, that sounds WAY more reasonable. I shall test thusly. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Time to increase MAX_TASKS?
The new Dell machines are doing a lot more of outstanding ACPI "things" currently. So much in fact, that they are exceeding ACPI_MAX_TASKS and are throwing errors indicating thing: vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable est0: on cpu0 .imecounters tick every 1.000 msec smbios: System Management BIOS version 2.7 Profiling kernel, textsize=6861200 [8029b190..80926320] usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ipmi0: IPMI device rev. 1, firmware rev. 1.10, version 2.0 ipmi0: Number of channels 6 ipmi0: Attached watchdog AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable mfid0 on mfi0 the current value in sys/dev/acpica/acpivar.h of 32 is no longer sufficient on the r420/r320 Sandybridge class of box. I am currently running with a value of 128 and doing a bit of testing. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: improve cx_lowest logic
On Tue, 2012-07-10 at 07:27 -0700, Ian Smith wrote: > I wonder if that explains why setting C3 on aforesaid T23 has no > effect > (in terms of dev.cpu.0.cx_usage indicating any time spent in C3) > unless > the machine happened to be booted up on battery, in which case C3 is > shown as working whenever its enabled, by power_profile or manually? > > silly question, did you set these in /etc/rc.conf ?? performance_cx_lowest="LOW" economy_cx_lowest="LOW" Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: improve cx_lowest logic
On Sun, 2012-07-08 at 03:22 -0700, Andriy Gapon wrote: > I would like to propose the following change for review and testing: > http://people.freebsd.org/~avg/acpi_cpu_cx_lowest.diff Very nice. After a review I went ahead and applied it for testing. All seems to be well on battery and A/C on my T520 so I'm very happy to see this go into the tree. Let me know if you want me to do the man page update for acpi_cpu(4) Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
[rethinking] Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
> > > > http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt > > Some sort of a review... > > First, going over what seems to be cosmetic changes in the patch. > > The change to etc/rc.d/power_profile seems to be a NOP, is it needed? > Ugh, well ... this was *supposed* to be a change to cx_lowest, not dev.cpu.0.freq. So, let me change that. +1 pointyhat to me. > New comment in the first hunk of acpi_cpu.c seems to be redundant and its > placement violates style(9). Right. *sigh* I'll adjust that. > > What do we achieve by renaming cpu_cx_lowest static file-scope variable to > global_lowest_cstate? I am not necessarily against the change, but it needs > to > be justified and it should likely be made in a separate commit. Besides it > breaks > an apparent (and perhaps useless) naming convention of prefixing everything > with > "cpu_". > Nothing gained other than my sanity. I suspect what I really want to do, is change the naming of all the global override values for ease of reading, but for now this is trivial and I'll revert it. > Other comments that you seem to have added as notes to self while working on > the > code - they are good, but better be done in a separate comments-only commit. > > Now to the essence of the patch. > > acpi_cpu_notify hunk - I am not sure if I completely follow the logic of the > current code in that function. For some reason that I can not grasp it > doesn't > update per-CPU cpu_cx_lowest if it is (was) equal or greater than the global > cpu_cx_lowest limit. Otherwise the per-CPU limit is set to the shallower of > the > global limit and the deepest available state. If I'm reading the code correctly, I'm assuming that each CPU will be notified via the ACPI handler here (denoted by the ACPI_SERIAL_BEGIN) and update its own cpu_cx_lowest via acpi_cpu_cx_cst/list() If the *new* lowest is greater than the global value, then we assume that the *old* global lowest is still valid and move on. I don't *think* that this is a problem currently. However if the per cpu list of cstates no longer has a value that corresponds to cpu_cx_lowest, I think that this *could* be a problem. > The patch seems to do something that make less sense in the latter case, it > tries > to set per-CPU cpu_cx_lowest based on a new C-state that resides at old > per-CPU > cpu_cx_lowest index. Essentially this means that (1) cpu_cx_lowest maybe > point to > a junk portion of cpu_cx_states after C-states change; (2) whatever the > change, if > we do not run into (1), then cpu_cx_lowest value won't change and the lowest > C-state would be whichever happens to be at that index. Ok, so the current method of using an index will always work to do something valid as opposed to my proposal which has the potential to go into a garbage part of the array and use values that are meaningless. I suspect that if I went from AC adapter to battery I would see some odd behavior on my laptop if I was to put the proper debug flags into place as the notify handler messed with the cpu_cx_states[] array per cpu. *sigh* ... back to the drawing board. > > About change in acpi_cpu_set_cx_lowest - I am not sure that it should fail if > the > exact match can not be found. Maybe cx_lowest should be set to the best > match in > that case? Where best match is the deepest state that is not deeper than the > requested state. I would prefer it to error in that case. I personally wouldn't want the code to do something "smart" in this case on my servers. I'd rather know that the Cstate isn't supported and look to see why. Most users aren't tweaking this directly, but it is being adjusted by devd/power_profile, so it should *know* the correct Cx state. > > Also, the ACPI spec permits multiple _CST entries with the same C-state type. > Not > sure if this ever happens in practice but wouldn't rule it out. > Previously they would be disambiguated by their indexes (perhaps incorrectly > from > ACPI point of view). I think that with the proposed change we need to have > some > policy on which of e.g. four C3 states to select as _the_ C3 state. This never occurred to me to be honest. I had to go back and read chap 8.4.2 of the ACPI spec to see what they were up to. I see no good reason for this to exist, but it is a possible configuration according to 8.4.2.1 ... This pains me a bit. :-) So, with that being said. This pretty much kills my entire implementation. :-) I didn't expect there to be multiple _CST entries for a single Cx state. Amusing. This also means that the control of the cx_lowest value is a bit trickier. If the user asks for C3, which one do we give them? :-) Also, I'm not clear that the code as it exists can handle this case gracefully. I'll ponder this one a bit. It would be good to find a box that does this to see how it behaves. > > acpi_cpu_global_cx_lowest_sysctl change - unlike the current code where > acpi_cpu_set_cx_lowest never fails, the new code may
acpi patches in gnats that are rotting
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F121504 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F135349 I think both of these are still relevant. Any objections to them? Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
On Wed, 2012-06-27 at 05:12 -0700, John Baldwin wrote: > On Tuesday, June 26, 2012 8:23:23 pm Sean Bruno wrote: > > Ok, version 2 now in effect. I removed the return of BUS_PROBE_DEFAULT > > and this seems to do the right thing in the cases I have. > > > > If there are no objections to this, I'll chuck it over into -head soonish. > > > > > > http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt > > Is this for a BIOS that is reporting non-contiguous Cx states or is this a > patch to let your custom Intel Cx driver work? If the latter, I would rather > have the driver export a contiguous range of virtual Cx states (what ACPI > actually does under the covers) rather than change our code to allow sparse > ACPI Cx states. > This patch is for the BIOS that reports non-contiguous ACPI Cx states. e.g. C1 and C3 with no C2. The Intel Mwaits/Cx State thing is still a work in progress and not dependent on this. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
[CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
Ok, version 2 now in effect. I removed the return of BUS_PROBE_DEFAULT and this seems to do the right thing in the cases I have. If there are no objections to this, I'll chuck it over into -head soonish. http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
On Wed, 2012-06-20 at 09:44 -0700, Sean Bruno wrote:
> On Tue, 2012-06-19 at 09:02 -0700, Sean Bruno wrote:
> > http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt
>
> also, I wanted to point out that I'm returning BUS_PROBE_GENERIC here.
>
> I want to emulate the Intel acpi_idle code that exists in linux-land and
> I *thought* that I could setup an acpi_cpu_idle module that would come
> in at a higher priority on Intel cpus, however there's some SYSINIT()
> hackery going on that I don't know how to handle gracefully. I'm not
> sure how to proceed with a different idle module here. thoughts?
>
> e.g.
>
> static void
> acpi_cpu_postattach(void *unused __unused)
> {
> device_t *devices;
> int err;
> int i, n;
>
> err = devclass_get_devices(acpi_cpu_devclass, &devices, &n);
> if (err != 0) {
> printf("devclass_get_devices(acpi_cpu_devclass) failed\n");
> return;
> }
> for (i = 0; i < n; i++)
> bus_generic_probe(devices[i]);
> for (i = 0; i < n; i++)
> bus_generic_attach(devices[i]);
> free(devices, M_TEMP);
> }
>
> SYSINIT(acpi_cpu, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE,
> acpi_cpu_postattach, NULL);
>
>
Ohh ... right. This entire idea is stupid and fully demonstrates my
lack of understanding. bus_probe/attach can't be used, there's no BUS
here. So, SYSINIT() to the rescue. Ok, that changes things around a
lot for me. This BUS_PROBE_GENERIC idea is a dud.
/me goes back to reading first and typing second
Sean
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
On Wed, 2012-06-20 at 13:18 -0700, Andriy Gapon wrote: > > I also, disagree with the idea of "FreeBSD C-states" as that is not > the > > intention of the code. The code, from my read, is trying to > interpret > > C-states as though they are always defined sequentially and > non-sparse. > > I seem to recall that this is an ACPI requirement. I could be > mistaken, but no > time to double-check at the moment. > > Just to check as I'm actively looking at this code I went and grabbed the December 6, 2011 ACPI spec. http://www.acpi.info/spec.htm chap 8.1 pretty clearly states that C2 and C3 are optional states. So it appears that you can have a C3 without a C2. So, I suspect that the idea that the index the cx_states array is always going to be 1 less that the ACPI Cstate value isn't by spec. Or something ... :-) Sean "I have no idea how computers work" Bruno ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
On Tue, 2012-06-19 at 09:02 -0700, Sean Bruno wrote:
> http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt
also, I wanted to point out that I'm returning BUS_PROBE_GENERIC here.
I want to emulate the Intel acpi_idle code that exists in linux-land and
I *thought* that I could setup an acpi_cpu_idle module that would come
in at a higher priority on Intel cpus, however there's some SYSINIT()
hackery going on that I don't know how to handle gracefully. I'm not
sure how to proceed with a different idle module here. thoughts?
e.g.
static void
acpi_cpu_postattach(void *unused __unused)
{
device_t *devices;
int err;
int i, n;
err = devclass_get_devices(acpi_cpu_devclass, &devices, &n);
if (err != 0) {
printf("devclass_get_devices(acpi_cpu_devclass) failed\n");
return;
}
for (i = 0; i < n; i++)
bus_generic_probe(devices[i]);
for (i = 0; i < n; i++)
bus_generic_attach(devices[i]);
free(devices, M_TEMP);
}
SYSINIT(acpi_cpu, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE,
acpi_cpu_postattach, NULL);
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
On Tue, 2012-06-19 at 22:00 -0700, Andriy Gapon wrote: > > I do not think that this is a real problem. A cosmetic one - most > likely. > >> > > Yes, most likely. Except that the code seems to think that the > index of > > the Cstates is good enough for a comparison to value. More over, > the > > sysctl's accept a value like "C3" and manipulate that into an index > into > > the Cstate array without checking for the Cstate value. > > > > The impact of this patch corrects this cosmetic display issue. > > If you accept that there are "FreeBSD C-states" and everything is done > in terms > of them, then there is no problem. > I once wrote this trivial patch to see more information about > FreeBSD-reported > C-states: > https://gitorious.org/~avg/freebsd/avgbsd/commit/043e9b0da5b46d389971e0166789fbee8a4e8622?format=patch > Since this patch changes the output of the sysctl format, I disagree with it. I also, disagree with the idea of "FreeBSD C-states" as that is not the intention of the code. The code, from my read, is trying to interpret C-states as though they are always defined sequentially and non-sparse. I am still of the opinion that my patch is correct at this point. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
On Tue, 2012-06-19 at 22:00 -0700, Andriy Gapon wrote: > > It seems that the rc.conf value of performance_cx_lowest="LOW" is > what I > > really want, not economy_cx_lowest. > > Yes. Could you please try this without using your patch? > > I get an impression that its effect was to actually request C2 when > cx_lowest is > set to C1. > > -- > Andriy Gapon Confirmed. If I set performance_cx_lowest="LOW" then the system sets the "C2" state and really implements C3 correctly. I see a 25 watt power saving without the patch on the Dell r410. sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
On Tue, 2012-06-19 at 14:07 -0700, Andriy Gapon wrote: > on 19/06/2012 19:02 Sean Bruno said the following: > > The first impact of this behavior is to list C3 as C2 in the list of > > Cstates when you retrieve the cx_supported sysctls for the cpus. > > I do not think that this is a real problem. A cosmetic one - most likely. > Yes, most likely. Except that the code seems to think that the index of the Cstates is good enough for a comparison to value. More over, the sysctl's accept a value like "C3" and manipulate that into an index into the Cstate array without checking for the Cstate value. The impact of this patch corrects this cosmetic display issue. > > The > > second impact is that the power_profile script never drops to a valid > > Cstate when you set the economy_lowest variable in rc.conf. > > Could you please explain if this somehow follows from your first observation > and > how? > If not, could you please share your finding on what exactly causes this to > happen? > > Also, are we talking about a laptop here? Namely, judging from the reference > to > 'economy_lowest', are AC state changes in play? > No, what I was attempting to do was configure a server such that it would attempt to use the C3 state at idle. Since the server gets configured by the power_state scripts via devd, the server is never configured with its global cx_lowest as anything other than C1. e.g: -bash-4.2$ sysctl -a|grep cx_lowest hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_lowest: C1 -bash-4.2$ sysctl -a|grep cx_supported dev.cpu.0.cx_supported: C1/1 C2/96 dev.cpu.1.cx_supported: C1/1 C2/96 It seems that the rc.conf value of performance_cx_lowest="LOW" is what I really want, not economy_cx_lowest. Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
[CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.
I've noted that a lot of servers/laptops are advertising Cstates C1 and C3, but not C2 nowadays. I'm not clear if the code is causing failures to drop into C3, but it sure doesn't look right to me. More or less, this is due to the code making assumptions that the index into the cpu's array of Cstates is complete and is non-sparse (e.g. element 0 is C1, element 1 is C2, element 2 is C3 ... etc). The first impact of this behavior is to list C3 as C2 in the list of Cstates when you retrieve the cx_supported sysctls for the cpus. The second impact is that the power_profile script never drops to a valid Cstate when you set the economy_lowest variable in rc.conf. I've attempted to patch this with the following patchset to acpi_cpu.c and to the power_profile rc.d script. With these patches, I can set my power_profile to economy and the system does indeed drop into C3 saving around 25watts as measured on a Dell R410 with stable/9. The attempt here is to try and eliminate the comparisons between the index in the array of Cstates and the value of the Cstate. This patchset is against HEAD and has been tested on the R410. Does this look right to you folks? http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt Sean ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
