Re: About acpi0: reservation of ... failed message in `dmesg`
Nate Lawson wrote: avatar Lin wrote: Our customers are concerned about the following messages in `dmesg` output. === acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bff0 (3) failed === Please help to clarify this issue. Or , in other direction, where to find official document to convince our customers that these messages are ignorable ? It is related to the sysresource acpi memory objects. It means that something was using the system resource before acpi allocated it. For #1, that looks like lowmem up to the VGA range. For #2, it looks like option ROMs. The BIOS has configured the devices beforehand so as long as everything works, the msgs can be ignored. Actually, to handle non-ACPI systems and ACPI systems that do not list system memory in the system resource objects, I added a 'ram0' device which uses the SMAP table and allocates address space for all of memory to perform a similar function to ACPI system resource objects. Often this message triggers now because the ram0 device has claimed the resources before ACPI gets a chance. You can certainly ignore these messages. If you look in 'devinfo -ur' you will probably find that these resource ranges are allocated by the ram0 device. -- John Baldwin ___ 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: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc wake memory
The following reply was made to PR kern/120515; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: bug-follo...@freebsd.org, arthur.hart...@nokia.com Cc: Subject: Re: kern/120515: [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc wake memory Date: Wed, 02 Jun 2010 09:08:14 -0400 Can you verify that this issue is resolved in 7.2 or later? -- John Baldwin ___ 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: kern/119356: [acpi]: i386 ACPI wakeup not work due resource exhaustion
The following reply was made to PR kern/119356; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: bug-follo...@freebsd.org, d...@obluda.cz Cc: Subject: Re: kern/119356: [acpi]: i386 ACPI wakeup not work due resource exhaustion Date: Wed, 02 Jun 2010 09:08:50 -0400 Can you verify that this issue is fixed in 7.2 or a newer release? -- John Baldwin ___ 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: Problem network devices Acer Extensa 5635G
On Thursday 10 June 2010 7:45:32 am subgeometer wrote: boot -v output for acer 5635z (sorry about the delay) Ok, it is the PCI bridge resource issue. :( -- John Baldwin ___ 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: bin/151616: [acpi]: FreeBSD 8 panic on boot.
The following reply was made to PR bin/151616; it has been noted by GNATS. From: John Baldwin j...@freebsd.org To: bug-follo...@freebsd.org, dam...@gmail.com Cc: Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Thu, 21 Oct 2010 07:43:07 -0400 Can you get capture the messages before the panic, ideally from a verbose boot? If you can compile a kernel with DDB and get a stack trace that would also be very helpful. You can use a digital camera if you can't hook up a serial console (and don't want to write the messages down by hand). -- John Baldwin ___ 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: bin/151616: [acpi]: FreeBSD 8 panic on boot.
On Wednesday, October 27, 2010 7:20:07 am Andriy Gapon wrote: The following reply was made to PR bin/151616; it has been noted by GNATS. From: Andriy Gapon a...@icyb.net.ua To: =?UTF-8?B?IkRhbWlhbiBTLiBLb8WCb2R6aWVqY3p5ayI=?= dam...@gmail.com Cc: bug-follo...@freebsd.org Subject: Re: bin/151616: [acpi]: FreeBSD 8 panic on boot. Date: Wed, 27 Oct 2010 14:10:52 +0300 on 27/10/2010 13:40 Damian S. KoÅodziejczyk said the following: Here is verbose boot: http://img43.imageshack.us/img43/225/zdjcie030g.jpg Would it be possible to scroll up and take the pictures of all the messages since the start of boot ? Thank you. Actually, it seems that apic_alloc_vector() is what is failing. Can you do 'show apic' in DDB and capture that output via your camera? -- John Baldwin ___ 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: Removing acpi.ko support
On Thursday, October 28, 2010 2:50:42 pm Scott Long wrote: On Thu, 28 Oct 2010, John Baldwin wrote: On Thursday, October 28, 2010 1:01:24 pm Scott Long wrote: On Oct 28, 2010, at 10:54 AM, John Baldwin wrote: [ cc'ing acpi@ to be safe, but I think the topic warrants the wider audience of arch@ ] I think we should drop support for having acpi load as a module for i386. It adds extra complication and hacks to the i386 APIC and interrupt code that are gratuitously different from amd64 as a result. Originally it was made a module so that GENERIC on i386 did not include ACPI by default but would only use up memory to hold ACPI-related code if the machine supported ACPI. Now that acpi is part of GENERIC on i386 in 8.0 and later this argument is no longer relevant. I'd like to remove support for ACPI as a module to remove the various hacks on i386 and reduce differences with amd64. Just to be clear, it'll still be an optional kernel device, it just won't be a KLD anymore, right? If you do that, what will happen with the evil bootloader code that gropes around for the AML tables and auto-loads the module? Is there any reason to keep that around for compatibility? If it goes away, don't forget to also update the bootforth code that knows how to manipulate it. It already does the right thing in this case (it did regardless, but that was part of the testing before enabling 'device acpi' in GENERIC for 8.0). If we remove the KLD support then we can now remove that code from the loader and Forth scripts as they will no longer be needed. You lost me, what is the right thing. What I'm asking is whether there will be any surprises to people upgrading from 8.0 to 8.x with regard to the bootloader no longer autoloading acpi.ko, and will there be any surprises to those who update their bootblocks but maybe switch back and forth between old and new kernels? The loader code just sets 'acpi_load=YES'. If acpi is compiled into the kernel or it is not present it just silently fails. This was already considered and tested during the 8.0 release cycle. I am only proposing making this change for 9, FYI, not to MFC it. If we were to remove the code from the loader that sets acpi_load in 9 and someone booted an 8.x or 7.x kernel that did not include 'device acpi', then acpi.ko would not be autoloaded. We could easily leave the code in the loader around until 10.0 so there is one release branch worth of compatibility, though the fact that GENERIC i386 in 8 ships with acpi compiled in and not a module on i386 is probably already giving us a release branch of compatibility as it is. That is, a GENERIC 8.0 i386 kernel would work fine with a loader that removed the ACPI bits, only a 7.x GENERIC kernel would fail to autoload acpi.ko with a modified loader. Given that we don't generally support 7.x - 9.0 upgrades, I really think it would be ok to remove the loader support from 9. However, what I really care about are the kernel changes, not the loader changes. The loader changes could wait until 10 if really necessary. -- John Baldwin ___ 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: MacBookPro 5,1
On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: on 29/10/2010 08:51 Andriy Gapon said the following: I guess that a general problem here is that it is incorrect to merely use memcpy/bcopy to create a copy of a resource if the resource has ACPI_RESOURCE_SOURCE field in it. Hans, could you please test the following patch? diff --git a/sys/dev/acpica/acpi_pci_link.c b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 --- a/sys/dev/acpica/acpi_pci_link.c +++ b/sys/dev/acpica/acpi_pci_link.c @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs link-l_irq; else resptr-Data.ExtendedIrq.Interrupts[0] = 0; + memset(resptr-Data.ExtendedIrq.ResourceSource, 0, + sizeof(ACPI_RESOURCE_SOURCE)); link++; i++; break; Hmm... Very interesting. Can you please try this, too? Linux doesn't set the resource source bits up at all when doing _SRS, so I'd rather just do that. I think what I'd prefer is that we not use the prs_template, perhaps just save the type of the resource and build a new resource object from scratch where the resource is zero'd, the appropriate bits are set and then that resource is appended to the buffer being built. -- John Baldwin ___ 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: MacBookPro 5,1
On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: on 29/10/2010 08:51 Andriy Gapon said the following: I guess that a general problem here is that it is incorrect to merely use memcpy/bcopy to create a copy of a resource if the resource has ACPI_RESOURCE_SOURCE field in it. Hans, could you please test the following patch? diff --git a/sys/dev/acpica/acpi_pci_link.c b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 --- a/sys/dev/acpica/acpi_pci_link.c +++ b/sys/dev/acpica/acpi_pci_link.c @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs link-l_irq; else resptr-Data.ExtendedIrq.Interrupts[0] = 0; + memset(resptr-Data.ExtendedIrq.ResourceSource, 0, + sizeof(ACPI_RESOURCE_SOURCE)); link++; i++; break; Hmm... Very interesting. Can you please try this, too? Linux doesn't set the resource source bits up at all when doing _SRS, so I'd rather just do that. I think what I'd prefer is that we not use the prs_template, perhaps just save the type of the resource and build a new resource object from scratch where the resource is zero'd, the appropriate bits are set and then that resource is appended to the buffer being built. Linux doesn't do it is wrong if I am reading the spec. correctly, i.e., _CRS, _PRS and _SRS must have the same format and size. Umm, but we aren't setting up the raw bits for _SRS. We are creating a list of ACPI_RESOURCE objects that ACPICA then encodes into a buffer to send to _SRS. -- John Baldwin ___ 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: MacBookPro 5,1
On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: on 29/10/2010 08:51 Andriy Gapon said the following: I guess that a general problem here is that it is incorrect to merely use memcpy/bcopy to create a copy of a resource if the resource has ACPI_RESOURCE_SOURCE field in it. Hans, could you please test the following patch? diff --git a/sys/dev/acpica/acpi_pci_link.c b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 --- a/sys/dev/acpica/acpi_pci_link.c +++ b/sys/dev/acpica/acpi_pci_link.c @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs link-l_irq; else resptr-Data.ExtendedIrq.Interrupts[0] = 0; + memset(resptr-Data.ExtendedIrq.ResourceSource, 0, + sizeof(ACPI_RESOURCE_SOURCE)); link++; i++; break; Hmm... Very interesting. Can you please try this, too? Linux doesn't set the resource source bits up at all when doing _SRS, so I'd rather just do that. I think what I'd prefer is that we not use the prs_template, perhaps just save the type of the resource and build a new resource object from scratch where the resource is zero'd, the appropriate bits are set and then that resource is appended to the buffer being built. Linux doesn't do it is wrong if I am reading the spec. correctly, i.e., _CRS, _PRS and _SRS must have the same format and size. Umm, but we aren't setting up the raw bits for _SRS. We are creating a list of ACPI_RESOURCE objects that ACPICA then encodes into a buffer to send to _SRS. Yes, I understand. However, ACPICA is expecting the same size of buffer *including* the optional parts if I am reading the code right. Besides, I don't think there is any harm in doing the right thing. ;-) To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero it, then set the type and the IRQ and that's it. Leave the ResourceSource bits as zero. The size will still be set based on the actual type (or if needed we can use the cached size from the template copy we save from _PRS). The point would be to start from a zero structure instead of from a copy of what we got from _PRS. -- John Baldwin ___ 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: MacBookPro 5,1
On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: on 29/10/2010 08:51 Andriy Gapon said the following: I guess that a general problem here is that it is incorrect to merely use memcpy/bcopy to create a copy of a resource if the resource has ACPI_RESOURCE_SOURCE field in it. Hans, could you please test the following patch? diff --git a/sys/dev/acpica/acpi_pci_link.c b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 --- a/sys/dev/acpica/acpi_pci_link.c +++ b/sys/dev/acpica/acpi_pci_link.c @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs link-l_irq; else resptr-Data.ExtendedIrq.Interrupts[0] = 0; + memset(resptr-Data.ExtendedIrq.ResourceSource, 0, + sizeof(ACPI_RESOURCE_SOURCE)); link++; i++; break; Hmm... Very interesting. Can you please try this, too? Linux doesn't set the resource source bits up at all when doing _SRS, so I'd rather just do that. I think what I'd prefer is that we not use the prs_template, perhaps just save the type of the resource and build a new resource object from scratch where the resource is zero'd, the appropriate bits are set and then that resource is appended to the buffer being built. Linux doesn't do it is wrong if I am reading the spec. correctly, i.e., _CRS, _PRS and _SRS must have the same format and size. Umm, but we aren't setting up the raw bits for _SRS. We are creating a list of ACPI_RESOURCE objects that ACPICA then encodes into a buffer to send to _SRS. Yes, I understand. However, ACPICA is expecting the same size of buffer *including* the optional parts if I am reading the code right. Besides, I don't think there is any harm in doing the right thing. ;-) To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero it, then set the type and the IRQ and that's it. Leave the ResourceSource bits as zero. The size will still be set based on the actual type (or if needed we can use the cached size from the template copy we save from _PRS). The point would be to start from a zero structure instead of from a copy of what we got from _PRS. It may work if we don't use l_prs_template. Well, we still need much of the info from the _PRS resource (the type, etc.), but I think we should not blindly use the template directly when building the buffer for _SRS. -- John Baldwin ___ 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: MacBookPro 5,1
On Wednesday, November 03, 2010 12:25:37 pm Jung-uk Kim wrote: On Wednesday 03 November 2010 08:28 am, John Baldwin wrote: On Tuesday, November 02, 2010 6:32:12 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 05:26 pm, John Baldwin wrote: On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote: On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote: On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote: On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote: on 29/10/2010 08:51 Andriy Gapon said the following: I guess that a general problem here is that it is incorrect to merely use memcpy/bcopy to create a copy of a resource if the resource has ACPI_RESOURCE_SOURCE field in it. Hans, could you please test the following patch? diff --git a/sys/dev/acpica/acpi_pci_link.c b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635 100644 --- a/sys/dev/acpica/acpi_pci_link.c +++ b/sys/dev/acpica/acpi_pci_link.c @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs link-l_irq; else resptr-Data.ExtendedIrq.Interrupts[0] = 0; + memset(resptr-Data.ExtendedIrq.ResourceSource , 0, + sizeof(ACPI_RESOURCE_SOURCE)); link++; i++; break; Hmm... Very interesting. Can you please try this, too? Linux doesn't set the resource source bits up at all when doing _SRS, so I'd rather just do that. I think what I'd prefer is that we not use the prs_template, perhaps just save the type of the resource and build a new resource object from scratch where the resource is zero'd, the appropriate bits are set and then that resource is appended to the buffer being built. Linux doesn't do it is wrong if I am reading the spec. correctly, i.e., _CRS, _PRS and _SRS must have the same format and size. Umm, but we aren't setting up the raw bits for _SRS. We are creating a list of ACPI_RESOURCE objects that ACPICA then encodes into a buffer to send to _SRS. Yes, I understand. However, ACPICA is expecting the same size of buffer *including* the optional parts if I am reading the code right. Besides, I don't think there is any harm in doing the right thing. ;-) To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero it, then set the type and the IRQ and that's it. Leave the ResourceSource bits as zero. The size will still be set based on the actual type (or if needed we can use the cached size from the template copy we save from _PRS). The point would be to start from a zero structure instead of from a copy of what we got from _PRS. It may work if we don't use l_prs_template. Well, we still need much of the info from the _PRS resource (the type, etc.), but I think we should not blindly use the template directly when building the buffer for _SRS. Actually, I think we should get the information directly from _CRS as ACPI spec. is suggesting. I would be fine with that, but that does not work if _CRS doesn't work (the acpi_pci_link_srs_from_links() case). Are we allowed to modify the buffer ACPICA gives us from _CRS and then pass that back to _SRS? -- John Baldwin ___ 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: Tyan S3992-E: hpet no longer working
On Thursday, January 06, 2011 5:32:08 pm Arno J. Klaassen wrote:
John Baldwin j...@freebsd.org writes:
On Wednesday, January 05, 2011 4:39:24 pm Arno J. Klaassen wrote:
Hello,
I have (a long-lasting) problem to get hpet attached to a Tyan S3992-E
MB. My last known working kernel is 7.1-PRERELEASE Sep 2 2008 , I
rarely cared about this board for a while...
At that time the dmesg said :
acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff
on acpi0
Timecounter HPET frequency 2500 Hz quality 900
now it says (debug.acpi.hpet_test=1, debug.acpi.layer=ACPI_TIMER,
debug.acpi.level=ACPI_LV_ALL_EXCEPTIONS enabled) :
hpet0: High Precision Event Timer iomem 0xfed0-0xfed03fff on
acpi0
hpet0: vendor 0x, rev 0xff, 232831Hz 64bit, 32 timers, legacy route
hpet0: t0: irqs 0x (31), MSI, 64bit, periodic
hpet0: t1: irqs 0x (31), MSI, 64bit, periodic
hpet0: t2: irqs 0x (31), MSI, 64bit, periodic
hpet0: t3: irqs 0x (31), MSI, 64bit, periodic
hpet0: t4: irqs 0x (31), MSI, 64bit, periodic
hpet0: t5: irqs 0x (31), MSI, 64bit, periodic
hpet0: t6: irqs 0x (31), MSI, 64bit, periodic
hpet0: t7: irqs 0x (31), MSI, 64bit, periodic
hpet0: t8: irqs 0x (31), MSI, 64bit, periodic
hpet0: t9: irqs 0x (31), MSI, 64bit, periodic
hpet0: t10: irqs 0x (31), MSI, 64bit, periodic
hpet0: t11: irqs 0x (31), MSI, 64bit, periodic
hpet0: t12: irqs 0x (31), MSI, 64bit, periodic
hpet0: t13: irqs 0x (31), MSI, 64bit, periodic
hpet0: t14: irqs 0x (31), MSI, 64bit, periodic
hpet0: t15: irqs 0x (31), MSI, 64bit, periodic
hpet0: t16: irqs 0x (31), MSI, 64bit, periodic
hpet0: t17: irqs 0x (31), MSI, 64bit, periodic
hpet0: t18: irqs 0x (31), MSI, 64bit, periodic
hpet0: t19: irqs 0x (31), MSI, 64bit, periodic
hpet0: t20: irqs 0x (31), MSI, 64bit, periodic
hpet0: t21: irqs 0x (31), MSI, 64bit, periodic
hpet0: t22: irqs 0x (31), MSI, 64bit, periodic
hpet0: t23: irqs 0x (31), MSI, 64bit, periodic
hpet0: t24: irqs 0x (31), MSI, 64bit, periodic
hpet0: t25: irqs 0x (31), MSI, 64bit, periodic
hpet0: t26: irqs 0x (31), MSI, 64bit, periodic
hpet0: t27: irqs 0x (31), MSI, 64bit, periodic
hpet0: t28: irqs 0x (31), MSI, 64bit, periodic
hpet0: t29: irqs 0x (31), MSI, 64bit, periodic
hpet0: t30: irqs 0x (31), MSI, 64bit, periodic
hpet0: t31: irqs 0x (31), MSI, 64bit, periodic
hpet0: 0.0: 4294967295 ... 4294967295 = 0
hpet0: time per call: 0 ns
hpet0: HPET never increments, disabling
device_attach: hpet0 attach returned 6
Some things strike me :
'vendor 0x, rev 0xf' and '4294967295 (== 0x)' as well
as 232831Hz
the change in iomem range :
OK : iomem 0xfed0-0xfed003ff
KO : iomem 0xfed0-0xfed03fff
I can provide full dmesg and/or other extra needed info.
Arno sent me his acpidump which includes this:
Device (HPET)
{
Name (_HID, EisaId (PNP0103))
Name (_UID, 0x34)
Method (_STA, 0, NotSerialized)
{
Return (0x0F)
}
Method (_CRS, 0, NotSerialized)
{
Return (ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xFED0, // Address Base
0x4000, // Address Length
)
})
}
}
So it does look like we are doing what the DSDT tells us in terms
of the memory address.
yop. That said, I made yet another copy-paste error: the last known
working kernel is 8.0-CURRENT Mar 1 2009 and the hpet says :
acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff
on acpi0
Timecounter HPET frequency 14318180 Hz quality 900
[only the frequency differs, the memory range indeed then was reported as
0x400 and not 0x4000 ]
Arno, are there any BIOS options that mention the HPET or have you updated
your BIOS since you booted the 7.1 kernel?
yes .. I now use BIOS 1.06 released 06/09/09.
Can I somehow 'overide' the bios and force the driver to use 0X400 as
'Address Length' in order to test if that makes the driver attach again?
Changing the length wouldn't make a difference as we would still read the same
registers since the start address is identical. I
Re: Atheros 9285 Atheros AR8131
On Saturday, March 26, 2011 1:13:45 pm Ксензов Алексей wrote: Network cards do not work. Tried on systems 8.0, 8.1, and 8.2. Notebook Aser Extenza 5635ZG. Tried to change Wi-Fi adapter on the other, but the situation has not changed. In all kinds of windows and linux, works fine. ath0: Atheros 9285 irq 19 at device 0.0 on pci7 ath0: 0x1 bytes of rid 0x10 res 3 failed (0, 0x). ath0: cannot map register space device_attach: ath0 attach returned 6 alc0: Atheros AR8131 PCIe Gigabit Ethernet irq 17 at device 0.0 on pci9 alc0: 0x4 bytes of rid 0x10 res 3 failed (0, 0x). alc0: cannot allocate memory resources. device_attach: alc0 attach returned 6 Attached: dmesg, sysctl hw.acpi and acpidump -t -d This is probably due to a problem FreeBSD has with ACPI initialization sometimes wiping out the state in PCI-PCI bridges for resource windows and not gracefully recovering from that. I have some early work in progress to address this, but it will be a while before I have something ready for testing. -- John Baldwin ___ 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: Atheros 9285 Atheros AR8131
On Monday, March 28, 2011 12:46:02 pm Ксензов Алексей wrote: 2011/3/29 Sergio de Almeida Lenzi lenzi.ser...@gmail.com This is probably due to a problem FreeBSD has with ACPI initialization sometimes wiping out the state in PCI-PCI bridges for resource windows and not gracefully recovering from that. I have some early work in progress to address this, but it will be a while before I have something ready for testing. it is the acer bios that is does not follow acpi standard... I have the same problem in an old acer 5050 no solution still... I had to install linux in that notebook. My advice is not to buy acer... they are cheap any good... Well let's wait for the Baldwin fix maybe this can be corrected by editing the ASL? We've never figured out what is zeroing the registers in the PCI-PCI bridges. I suspect it is not something in the ASL, but is a side effect of some BIOS code that runs in SMM when ACPI is turned on. -- John Baldwin ___ 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: Atheros 9285 Atheros AR8131
On 4/7/11 1:25 PM, Nate Lawson wrote: On 4/7/2011 6:53 AM, John Baldwin wrote: On 4/6/11 5:51 PM, Nate Lawson wrote: Wow, awesome work. This is really useful for fixing a common problem. Should bus_adjust_resource() be a DEVMETHOD or is this something that should be done automatically within rman_alloc_resource(), possibly based on a device flag? Hmm, I had only thought of it as being a wrapper around rman_adjust_resource(). I'm not sure what you mean by adjusting it inside another method? Note that one of the reasons I have the current method is that different devices may have different restrictions on how resources can grow. For example, the PCI-PCI memory windows are aligned on 1MB boundaries and are allocated in 1MB chunks while the I/O port windows are aligned and allocated in 4K chunks. I also plan to make use of rman_adjust_resource() for PCI bus renumbering, but in that case resources would only grow at the end, etc. Given that, I want to keep the logic to determine which kind of adjustment to perform in the relevant driver rather than having rman attempt to use a generic algorithm for expanding a resource and associated rman used for suballocation (if that makes sense). Yes, that makes sense. It's a question of complexity -- do you push a set of rules to rman and have it apply them? Or do you do the adjusting in the driver itself, which knows its own restrictions but may end up replicating some general purpose code for applying those restrictions? This seems great for now. I don't have any complaints, just musing about the future. Ahh, ok. So far my current plans for other places using rmans don't involve the same set of rules. However, I would be happy for their to eventually be a more general version of pcib_grow_window() if we find a need for it in the future. I think you could have a helper function at that level of granularity perhaps. -- John Baldwin ___ 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
[PATCH] Change acpi_parse_resources() to use AcpiWalkResources()
, int count,
+acpi_res_set_irq(device_t dev, void *context, uint8_t *irq, int count,
int trig, int pol)
{
struct acpi_res_context*cp = (struct acpi_res_context *)context;
@@ -600,7 +545,7 @@
}
static void
-acpi_res_set_ext_irq(device_t dev, void *context, u_int32_t *irq, int count,
+acpi_res_set_ext_irq(device_t dev, void *context, uint32_t *irq, int count,
int trig, int pol)
{
struct acpi_res_context*cp = (struct acpi_res_context *)context;
@@ -616,7 +561,7 @@
}
static void
-acpi_res_set_drq(device_t dev, void *context, u_int8_t *drq, int count)
+acpi_res_set_drq(device_t dev, void *context, uint8_t *drq, int count)
{
struct acpi_res_context*cp = (struct acpi_res_context *)context;
--- //depot/vendor/freebsd/src/sys/dev/acpica/acpivar.h 2011-04-04
18:40:20.0
+++ //depot/projects/pci/sys/dev/acpica/acpivar.h 2011-04-16
03:08:21.0
@@ -355,19 +355,19 @@
struct acpi_parse_resource_set {
void (*set_init)(device_t dev, void *arg, void **context);
void (*set_done)(device_t dev, void *context);
-void (*set_ioport)(device_t dev, void *context, uint32_t base,
- uint32_t length);
-void (*set_iorange)(device_t dev, void *context, uint32_t low,
- uint32_t high, uint32_t length, uint32_t align);
-void (*set_memory)(device_t dev, void *context, uint32_t base,
- uint32_t length);
-void (*set_memoryrange)(device_t dev, void *context, uint32_t low,
- uint32_t high, uint32_t length, uint32_t align);
-void (*set_irq)(device_t dev, void *context, u_int8_t *irq,
+void (*set_ioport)(device_t dev, void *context, uint64_t base,
+ uint64_t length);
+void (*set_iorange)(device_t dev, void *context, uint64_t low,
+ uint64_t high, uint64_t length, uint64_t align);
+void (*set_memory)(device_t dev, void *context, uint64_t base,
+ uint64_t length);
+void (*set_memoryrange)(device_t dev, void *context, uint64_t low,
+ uint64_t high, uint64_t length, uint64_t align);
+void (*set_irq)(device_t dev, void *context, uint8_t *irq,
int count, int trig, int pol);
-void (*set_ext_irq)(device_t dev, void *context, u_int32_t *irq,
+void (*set_ext_irq)(device_t dev, void *context, uint32_t *irq,
int count, int trig, int pol);
-void (*set_drq)(device_t dev, void *context, u_int8_t *drq,
+void (*set_drq)(device_t dev, void *context, uint8_t *drq,
int count);
void (*set_start_dependent)(device_t dev, void *context,
int preference);
--
John Baldwin
___
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: kern/91594: [em] FreeBSD gt; 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression]
On Tuesday, June 07, 2011 10:20:08 am Rudolf Polzer wrote: The following reply was made to PR kern/91594; it has been noted by GNATS. From: Rudolf Polzer rpol...@mucke-novak.de To: bug-follo...@freebsd.org bug-follo...@freebsd.org, b...@bsd.de b...@bsd.de Cc: Subject: Re: kern/91594: [em] FreeBSD gt; 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] Date: Tue, 7 Jun 2011 16:10:44 +0200 Hi, I just tried this on a such a server, and get the same issue even with the = snapshot of 8-STABLE on the freebsd ftp server. However, 9-CURRENT kernel p= anics from a possibly related, possibly unrelated issue: The trace is: kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 rman_init() at rman_init+0x17c pcib_alloc_window() at pcib_allow_window+0x9f pcib_attach_common() at pcib_attach_common+0x457 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x1c device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a Can you get the panic message? This seems really odd as rman_init() will only panic if rm_type is set to an invalid setting, but it should always be correct in this case: w-rman.rm_type = RMAN_ARRAY; snprintf(buf, sizeof(buf), %s %s window, device_get_nameunit(sc-dev), w-name); w-rman.rm_descr = strdup(buf, M_DEVBUF); error = rman_init(w-rman); -- John Baldwin ___ 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
Only attach device_t objects to ACPI devices with a _HID
)) {
- /*
-* The TabletPC TC1000 has a second PCI-ISA bridge
-* that has a _HID for an acpi_sysresource device.
-* In that case, leave ACPI-CA's device data pointing
-* at the ACPI-enumerated device.
-*/
- device_printf(child,
- Conflicts with PCI device %d:%d:%d\n,
- pci_get_bus(pci_child), pci_get_slot(pci_child),
- pci_get_function(pci_child));
- return;
- }
KASSERT(device_get_parent(child) ==
devclass_get_device(devclass_find(acpi), 0),
(%s: child (%s)'s parent is not acpi0, __func__,
acpi_name(handle)));
- device_delete_child(device_get_parent(child), child);
+ return;
}
/*
* Update ACPI-CA to use the PCI enumerated device_t for this handle.
*/
- status = AcpiDetachData(handle, acpi_fake_objhandler);
- if (ACPI_FAILURE(status))
- printf(WARNING: Unable to detach object data from %s - %s\n,
- acpi_name(handle), AcpiFormatException(status));
status = AcpiAttachData(handle, acpi_fake_objhandler, pci_child);
if (ACPI_FAILURE(status))
printf(WARNING: Unable to attach object data to %s - %s\n,
--
John Baldwin
___
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: i386/122887: [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immediately when switching VGA port at BladeCenter
On Monday, October 24, 2011 10:31:23 am re...@freebsd.org wrote: Synopsis: [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immediately when switching VGA port at BladeCenter Responsible-Changed-From-To: freebsd-i386-freebsd-acpi Responsible-Changed-By: remko Responsible-Changed-When: Mon Oct 24 14:30:45 UTC 2011 Responsible-Changed-Why: This didn't get solved in the i386 category, since Volker also suggests that -acpi might be one that could fix this, assign it there and try to get someone to look at this :) Unfortunately the link to a backtrace in the PR no longer works. It would be interesting to see if this still occurs in 8 and later since they will let the ACPI instance of atkbdc claim the ISA hint. -- John Baldwin ___ 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: Suspend and resume on Dell E6520
On Monday, November 28, 2011 12:15:25 pm Jung-uk Kim wrote: On Thursday 24 November 2011 01:33 am, Sebastian Chmielewski wrote: On Wed, 23 Nov 2011 20:50:58 -0500 Jung-uk Kim j...@freebsd.org wrote: Usually, we cannot resume console on NVIDIA graphics, which often times lack or has incomplete VBE save/restore state function. I had kldunload nvidia in rc.suspend. Isn't that enough? No, it doesn't (can't) save/restore GPU state. In fact, nvidia.ko may help when you are suspending from X11. At least in theory, it should be able to save/restore GPU state correctly. However, a NVIDIA engineer once told me that the code path wasn't tested well because he couldn't find a right laptop to test at the time. It was long ago, though. Yes, the nvidia folks would probably work on fixing suspend and resume of nvidia GPUs if we could point them at a laptop for which suspend and resume otherwise worked. -- John Baldwin ___ 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: kern/162578: 9.0-RC2's regression in power management on VIA Samuel 2
On Wednesday, November 23, 2011 4:09:25 pm kron wrote:
On 2011/11/23 07:57, kron wrote:
Hello,
I'm bringing this to -acpi@ as suggested by jhb@.
Some time ago while testing 9.0-RC2 I noticed that power management
got broken (powerd doesn't start, Cx states disappeared) on a specific
class of our minirouters. I created kern/162578, bisected the issue
down to r216674 and I contacted the author - jhb@. John was kind to do
a further analysis. Verbose boots before and after r216674 differ this
way:
-Calibrating TSC clock ... TSC clock: 532647138 Hz
+Calibrating TSC clock ... TSC clock: 532648183 Hz
-ACPI timer: 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/4 - 0
-Timecounter ACPI-safe frequency 3579545 Hz quality 850
-acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0
+acpi_timer0: couldn't allocate resource (port 0x4008)
-acpi_throttle0: P_CNT from P_BLK 0x4010
+acpi_throttle0: failed to attach P_CNT
+device_attach: acpi_throttle0 attach returned 6
John's comment:
So this is the issue, and it seems what happens is that your
BIOS assigns the resources for this range to the pcib0 device
when we expect them to be assigned as a system resource (if
at all):
pcib0: ACPI Host-PCI bridge port
0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f
on acpi0
You could try hacking your ASL to not list the 0x4000-0x407f range
for now, but the real fix is probably to make resources attached
to Host-PCI bridge devices be treated as if they were system
resources and put into the ACPI system resource rman instead.
That requires a fair bit of work however.
John also suggested to involve jkim@ and -acpi@.
I'm going to experiment with ASL because it would be an acceptable
solution to me and the real fix is way above my skills ATM.
As promised, I fiddled with ASL. I did found something which
resembled 0x4000-0x407f:
...
DefinitionBlock (/tmp/acpidump.aml, DSDT, 1, VIA601, AWRDACPI,
0x1000)
{
Scope (\_SB)
{
...
Device (PCI0)
{
...
Method (_CRS, 0, NotSerialized)
{
...
Name (BUF0, ResourceTemplate ()
{
...
IO (Decode16,
0x4000, // Range Minimum
0x4000, // Range Maximum
0x01, // Alignment
0x80, // Length
)
...
I removed the IO block, compiled, installed the AML, rebooted
and voila - I have my power management back even with r216674.
Big thanks to jhb@ for guiding me.
As always, big thanks to all the good souls who write the
Handbook, too. It helped me with ASL and AML.
As
1. this hack is good enough for me, and
2. the real fix John suggested is above my skills
I think the PR can be closed.
Can you try an updated HEAD and see if a stock ASL works?
--
John Baldwin
___
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 caused by broken asl, how to fix?
On Friday, February 03, 2012 11:18:22 am jakob...@gmail.com wrote: Hi John, Thank you for your reply. The more I look the less confident I am that this will in fact fix my wifi, but if it does it is just an added bonus. I will submit a separate report to mobile@freebsd and focus on suspend/resume issues in this thread or at least a cleaner dmesg. The laptop suspends, but screen remains black and I need to hold down the power button to cut power. When restarting it just does a normal boot, suggesting unclean shutdown. Ugh, that makes it a good bit harder to debug. You can try removing as many drivers from your kernel as you can while still having a functional system (so no networking, etc.). Then see if that can resume in single user. If it does, then you can start adding back in drivers to narrow down one that causes the hang. You can also try setting the 'hw.acpi.reset_video' sysctl to see if that helps your screen come back on during resume. -Original Message- From: John Baldwin Sent: 03/02/2012 2:42:58 pm To: freebsd-acpi@freebsd.org Cc: Jakob Pedersen Subject: Re: ACPI error caused by broken asl, how to fix? On Thursday, February 02, 2012 5:23:25 am Jakob Pedersen wrote: Hello there, I am running PCBSD 9.0 on a Packard Bell R1926 and having the following problems: - Suspend resume does put the machine asleep, but it doesn't resume. - I am having strange issues with my wifi card, which disconnects if more than 2 metres away from the router. Several linux distros seem to suggest a general problem with wifi is caused by acpi problems (under linux either WiFi works OR USB). My wifi card is RALINK rc61/R2561s using the ral0 driver. Full specs of the laptop can be found here: http://dl.dropbox.com/u/7820484/PackardBell-R1926-bios-info.txt For trouble shooting I extracted the ASL of the bios and recompiled it using iasl. This gave the following error: Intel ACPI Component Architecture ASL Optimizing Compiler version 20110527-32 Copyright (c) 2000 - 2011 Intel Corporation packardbell-r1926.asl 3565: Return (0x00) Error4080 -Invalid object type for reserved name ^ (found INTEGER, requires Buffer) ASL Input: packardbell-r1936.asl - 3577 lines, 109288 bytes, 1236 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 572 Optimizations The ASL can be found here: http://dl.dropbox.com/u/7820484/packardbell-r1926.asl I had a look at the ASL code and it appears to cause problems in ALKD as mentioned in the dmesg: It's not trivial to fix this warning, but I also strongly doubt it will do anything to help your wifi card. If your wifi card works at all (gets interrupts, etc.), then worrying about ALKD is just a red herring. You might ask on mob...@freebsd.org about debugging your wifi issues. As far as suspend and resume, resume is not very easy to debug when it doesn't work. Does your screen come back at all if you resume or does it just stay black? -- John Baldwin -- John Baldwin ___ 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 for Asus Notebook N50Vc
On Wednesday, February 08, 2012 11:50:07 am simplicissimus wrote:
Hello everybody,
I have just installed FreeBSD 9 on my Asus Notebook.
When I load the acpi_asus module, I get the message
acpi_asus0: Unsupported Asus laptop: N50Vc
This is the output of
#acpidump -dt acpidump.aml
http://paste.pocoo.org/show/547876/
It says:
acpidump: RSDT entry 10 (sig ATKG) is corrupt
Is there any chance to get this model working by some simple patch to
acpi_asus.c ?
Try this. It may be possible to get some more things working on your
machine as well (e.g. dsp_get/set and lcd_get/set), but I'm not sure
which methods to use.
Index: acpi_asus.c
===
--- acpi_asus.c (revision 231586)
+++ acpi_asus.c (working copy)
@@ -379,6 +379,13 @@ static struct acpi_asus_model acpi_asus_models[] =
.disp_set = SDSP
},
{
+ .name = N50Vc,
+ .bled_set = BLED,
+ .wled_set = WLED,
+ .brn_get= GPLV,
+ .brn_set= SPLV,
+ },
+ {
.name = S1x,
.mled_set = MLED,
.wled_set = WLED,
--
John Baldwin
___
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 for Asus Notebook N50Vc
On Monday, February 13, 2012 6:38:26 pm simplicissimus wrote:
Hello John,
Thank you very much for your patch.
This is how my laptop’s behaviour changed:
% sysctl -a | grep -i asus
hw.acpi.asus.lcd_brightness: 4
dev.acpi.0.%desc: _ASUS_ Notebook
dev.acpi_asus.0.%desc: Asus N50Vc Laptop Extras
dev.acpi_asus.0.%driver: acpi_asus
dev.acpi_asus.0.%location: handle=\_SB_.ATKD
dev.acpi_asus.0.%pnpinfo: _HID=ATK0100 _UID=16843008
dev.acpi_asus.0.%parent: acpi0
hw.acpi.asus.lcd_brightness shows the correct brightness (with acpi_video
loaded).
My notebook has a combined switch for wifi/bluetooth.
Without (the modified) acpi_asus the Wifi LED would be always off, although
wifi worked.
By pressing the button, bluetooth was toggled on/off with the corresponding
LED going on/off.
Now the button cycles through these LED statuses:
both on both off wifi only bluetooth only
Wifi stays on all the time, bluetooth works as it is supposed to (like it
did before).
Is there a chance to get ATK0110 events working? I tried xev, but had no
output there.
Thanks in advance
Can you try this? BTW, someone should port the asus-laptop.c driver from
Linux over to replace acpi_asus.c.
Index: acpi_asus.c
===
--- acpi_asus.c (revision 231973)
+++ acpi_asus.c (working copy)
@@ -379,6 +379,18 @@ static struct acpi_asus_model acpi_asus_models[] =
.disp_set = SDSP
},
{
+ .name = N50Vc,
+ .bled_set = BLED,
+ .wled_set = WLED,
+ .brn_get= GPLV,
+ .brn_set= SPLV,
+#if 0
+ .lcd_set= \\_SB.PCI0.SBRG.EC0._Q10,
+#endif
+ .disp_get = \\_SB.PCI0.P0P1.VGA.GETD,
+ .disp_set = SDSP
+ },
+ {
.name = S1x,
.mled_set = MLED,
.wled_set = WLED,
@@ -509,6 +521,9 @@ static struct {
ACPI_SERIAL_DECL(asus, ACPI ASUS extras);
+static int acpi_asus_wapf = 1;
+TUNABLE_INT_FETCH(hw.acpi.asus.wapf acpi_asus_wapf);
+
/* Function prototypes */
static int acpi_asus_probe(device_t dev);
static int acpi_asus_attach(device_t dev);
@@ -724,6 +739,8 @@ acpi_asus_attach(device_t dev)
{
struct acpi_asus_softc *sc;
struct acpi_softc *acpi_sc;
+ ACPI_OBJECT Arg;
+ ACPI_OBJECT_LISTArgs;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
@@ -735,6 +752,9 @@ acpi_asus_attach(device_t dev)
sc-sysctl_tree = SYSCTL_ADD_NODE(sc-sysctl_ctx,
SYSCTL_CHILDREN(acpi_sc-acpi_sysctl_tree),
OID_AUTO, asus, CTLFLAG_RD, 0, );
+ SYSCTL_ADD_INT(sc-sysctl_ctx, SYSCTL_CHILDREN(sc-sysctl_tree),
+ OID_AUTO, wapf, CTLFLAG_RD, acpi_asus_wapf, 0,
+ Argument to pass WAPF method during initialization);
/* Hook up nodes */
for (int i = 0; acpi_asus_sysctls[i].name != NULL; i++) {
@@ -804,6 +824,9 @@ acpi_asus_attach(device_t dev)
/* Activate hotkeys */
AcpiEvaluateObject(sc-handle, BSTS, NULL, NULL);
+ /* Configure wlan key. */
+ acpi_SetInteger(sc-handle, WAPF, acpi_asus_wapf);
+
/* Handle notifies */
if (sc-model-n_func == NULL)
sc-model-n_func = acpi_asus_notify;
--
John Baldwin
___
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 for Asus Notebook N50Vc
On Tuesday, February 21, 2012 7:43:37 pm simplicissimus wrote:
Thanks again for your time and the patch; unfortunately it gives me an error
message:
http://paste.pocoo.org/show/554781/
This is my modified acpi_asus.c :
http://paste.pocoo.org/show/554783/
I hope I got the changes to the file right.
Regards
Simplicissimus
Oops, try this:
Index: acpi_asus.c
===
--- acpi_asus.c (revision 231983)
+++ acpi_asus.c (working copy)
@@ -379,6 +379,18 @@ static struct acpi_asus_model acpi_asus_models[] =
.disp_set = SDSP
},
{
+ .name = N50Vc,
+ .bled_set = BLED,
+ .wled_set = WLED,
+ .brn_get= GPLV,
+ .brn_set= SPLV,
+#if 0
+ .lcd_set= \\_SB.PCI0.SBRG.EC0._Q10,
+#endif
+ .disp_get = \\_SB.PCI0.P0P1.VGA.GETD,
+ .disp_set = SDSP
+ },
+ {
.name = S1x,
.mled_set = MLED,
.wled_set = WLED,
@@ -509,6 +521,9 @@ static struct {
ACPI_SERIAL_DECL(asus, ACPI ASUS extras);
+static int acpi_asus_wapf = 1;
+TUNABLE_INT(hw.acpi.asus.wapf, acpi_asus_wapf);
+
/* Function prototypes */
static int acpi_asus_probe(device_t dev);
static int acpi_asus_attach(device_t dev);
@@ -735,6 +750,9 @@ acpi_asus_attach(device_t dev)
sc-sysctl_tree = SYSCTL_ADD_NODE(sc-sysctl_ctx,
SYSCTL_CHILDREN(acpi_sc-acpi_sysctl_tree),
OID_AUTO, asus, CTLFLAG_RD, 0, );
+ SYSCTL_ADD_INT(sc-sysctl_ctx, SYSCTL_CHILDREN(sc-sysctl_tree),
+ OID_AUTO, wapf, CTLFLAG_RD, acpi_asus_wapf, 0,
+ Argument to pass WAPF method during initialization);
/* Hook up nodes */
for (int i = 0; acpi_asus_sysctls[i].name != NULL; i++) {
@@ -804,6 +822,9 @@ acpi_asus_attach(device_t dev)
/* Activate hotkeys */
AcpiEvaluateObject(sc-handle, BSTS, NULL, NULL);
+ /* Configure wlan key. */
+ acpi_SetInteger(sc-handle, WAPF, acpi_asus_wapf);
+
/* Handle notifies */
if (sc-model-n_func == NULL)
sc-model-n_func = acpi_asus_notify;
--
John Baldwin
___
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 'driver bug: Unable to set devclass'
On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: on 15/05/2012 17:34 John Baldwin said the following: On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: on 14/05/2012 01:43 Bruce Cran said the following: On 13/05/2012 21:06, Andriy Gapon wrote: Can you produce an equivalent snippet with verbose logging enabled? I have a suspicion that these messages are a byproduct from r231161. acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bbf0 (3) failed acpi_sysresource: acpi_sysresource0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) acpi_timer: acpi_timer0 already exists; skipping it driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) cpu0: ACPI CPU on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 (20120420/tbutils-293) ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) acpi_sysresource: acpi_sysresource2 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu2: ACPI CPU on acpi0 acpi_sysresource: acpi_sysresource1 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) cpu1: ACPI CPU on acpi0 acpi_sysresource: acpi_sysresource3 already exists; skipping it driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) I think that the following is what happens here in the acpi_timer case. Previously one acpi_timer device_t was added with an order of zero and a fixed unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t could be added when walking the ACPI device tree, that device would always have a later order and a wildcard unit number (-1). Now both the hardwired device and auto-probed device are added with the same order of 2 and it also so happens that the hardwired device is after the auto-probed in the device list. So first the auto-probed device just takes the unit number of zero because it is free and then the hardwired device fails to claim the same unit number. Eh. This should not be true. The unit 0 is reserved when device_add_child() is called in the acpi_timer identify routine. The wildcard device will not be assigned a unit number until device_probe_child time. Not sure what you disagree with... First, the wildcard device is added to the child list during the walk. Then, the unit 0 device is added to the list when acpi_timer identify is executed. Then, the wildcard device is probed and gets unit number of zero. Then, the fixed device is being probed and the unit number conflict arises. Am I misunderstanding something? Yes. The third step will see that unit 0 is already in use and shouldn't reuse unit 0. -- John Baldwin ___ 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 'driver bug: Unable to set devclass'
On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: on 17/05/2012 17:05 John Baldwin said the following: On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() (and/or, not make the unit number in cpuX mean anything at all, but use a separate ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think the last approach is really the right way to fix this. I haven't been able to try this yet, but I have a first cut at www.freebsd.org/~jhb/patches/acpi_cpu.patch The patch has not been compile-tested? :) Not yet. I'll try to test it later today unless someone beats me to it. :-P -- John Baldwin ___ 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 Wednesday, June 20, 2012 7:28:36 pm Sean Bruno wrote:
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.
No, every device in new-bus can be a bus (and acpi_cpuX is in fact a bus).
The issue here is that this driver is deferring attaching child devices until
later in the boot. This is a bit of a lame workaround that should be using
new-bus multipass instead.
--
John Baldwin
___
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: IPMI attachment fails: vendor bug, or just unusual choice?
On Friday, June 22, 2012 11:24:29 pm Garrett Wollman wrote:
On my Quanta QSSC-S99Q, the IPMI driver has trouble using the ACPI
attachment. It reports:
ipmi0: IPMI System Interface on acpi0
ipmi0: unknown resource type
device_attach: ipmi0 attach returned 6
It then goes on to find it the old-fashioned way as ipmi1, which
sometimes works and sometiems doesn't. (Not worrying about that part
yet -- I think it's a timing issue.)
Looking at the code, it looks like this can only happen if there are
neither I/O port nor memory resources defined for this device.
However, there clearly is one in the AML:
Device (MI0)
{
Name (_HID, EisaId (IPI0001))
Method (_STA, 0, NotSerialized)
{
If (LEqual (OSN, Zero))
{
Return (Zero)
}
Return (0x0F)
}
Name (_STR, Unicode (IPMI_KCS))
Name (_UID, Zero)
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0CA2, // Range Minimum
0x0CA3, // Range Maximum
0x00, // Alignment
0x02, // Length
)
})
Method (_IFT, 0, NotSerialized)
{
Return (One)
}
Method (_SRV, 0, NotSerialized)
{
Return (0x0200)
}
}
Did the vendor screw this up by writing this as a port range? Or is
this perfectly legitimate and just not implemented?
Yes, the vendor screwed this up. The range is a range of valid
starting addresses (not a range from which the entire resource must be
sub-allocated), so what they should have done was used 0xCA2 as
the range maximum. You can try patching your ASL to change that to
use 0xCA3. That said, I believe that a true range should only show
up in _PRS, not in _CRS, so we might be able to use your workaround for
parsing _CRS. (_CRS should only return assigned resources, so those should
always be fixed, not variable ranges.)
If you can convince Quanta to fix their BIOS that would be the best
result however.
--
John Baldwin
___
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 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. -- John Baldwin ___ 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: [ patch ] improper handling of ACPI TCPA table, acpidump abend imminent
On Sunday, July 08, 2012 7:54:40 am Dan Lukes wrote: Submitter-Id:current-users Originator: Dan Lukes Organization:Obludarium Confidential:no Synopsis:[ patch ] improper handling of ACPI TCPA table, acpidump abend imminent Severity:serious Priority:medium Category:bin Class: sw-bug Release: FreeBSD 9.0 i386 Environment: System: FreeBSD 9.0 src/usr.sbin/acpi/acpidump/acpi.c,v 1.42.2.1.2.1 but apply for all revisions past 1.38 (e.g. all RELENG_9 and HEAD) Description: TCG ACPI (TPCA) support added as SVN rev 211196 1. event-event_type and event-event_size are big-endian (see TPCA PC Specific Specification, paragraph 7.2.2.2). Current code use them directly. It cause misinterpretation of values and may cause abend. 2. 'if (vaddr + event-event_size = vend )' test is insufficient because: 2a) event-event_size is declared signed and may be negative (especialy when big-endian value used without proper conversion) 2b) vaddr+event-event_size may overflow / wrap around even in the case the event_size is positive in both cases, memory outside of vaddr,vend range may be referenced. Abend is imminent. How-To-Repeat: Dump non-empty TCPA table. It will print events incorrectly, may abend. Fix: 1. use ntohl() to convert event-event_size and event-event_type before use 2. test vaddr + eventdatasize for wraparound/underflow case also It might be best to use betoh() macros from sys/endian.h instead of nthol(). -- John Baldwin ___ 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 errors on ASUS M5A88-M m/b
On Wednesday, July 11, 2012 7:26:25 am Alexey Markov wrote: Hello! Two days ago I have installed FreeBSD 8.3-RELEASE-p3 amd6 on ASUS M5A88-M motherboard with AMD Phenom II X4 925 processor, and got some ACPI errors in the dmesg: Are you seeing any functional problems or just error messages? I realize aibs didn't work, though it seems it simply may not support your system. The acpi_hpet1 thing just seems to be a duplicate device (acpi_hpet0 attached fine), so I believe you can most likely ignore that. -- John Baldwin ___ 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: amd64/169779: [patch] powerd doesn't honor the -n flag
On Tuesday, July 10, 2012 10:48:51 pm Axel Gonzalez wrote:
Number: 169779
Category: amd64
Synopsis: [patch] powerd doesn't honor the -n flag
Confidential: no
Severity: serious
Priority: low
Responsible:freebsd-amd64
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Wed Jul 11 02:50:10 UTC 2012
Closed-Date:
Last-Modified:
Originator: Axel Gonzalez
Release:9.0-RELEASE-p2
Organization:
Environment:
FreeBSD moonlight 9.0-RELEASE-p2 FreeBSD 9.0-RELEASE-p2 #0: Tue Jun 12
02:12:57 CDT 2012 toor@moonlight:/usr/obj/usr/src/sys/LXCORE964 amd64
Description:
powerd never initializes the variable that keeps the status of the line
status. This variable defaults to 0 (with the compiler? with the arch?) and
results in powerd using the AC profile.
This is a problem, since at start it says it is in unkown status, but
doesn't respect the -n argument.
Note: since the variable is not initialized, it can lead to other unexpected
behaviour.
How-To-Repeat:
This should use the adaptive profile specified by -n, but uses hiadaptive
# /usr/sbin/powerd -i 50 -r 80 -M 1800 -v -p 1000 -n adaptive
powerd: unable to determine AC line status
CPU frequency is above user-defined maximum; changing frequency to 1795 MHz
load 15%, current freq 1795 MHz ( 0), wanted freq 2094 MHz
Fix:
Initialize the variable
--- powerd.c.orig 2012-07-10 21:21:07.882970887 -0500
+++ powerd.c2012-07-10 21:22:29.292974203 -0500
@@ -278,6 +278,7 @@
acline_init(void)
{
acline_mib_len = 4;
+acline_status = SRC_UNKNOWN;
if (sysctlnametomib(ACPIAC, acline_mib, acline_mib_len) == 0) {
acline_mode = ac_sysctl;
I suspect this is correct, but cc'ing acpi@ to see if anyone there has any
comments.
--
John Baldwin
___
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 Thursday, July 19, 2012 4:49:23 pm Sean Bruno wrote: 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: snip vga0: Generic ISA VGA 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: Enhanced SpeedStep Frequency Control 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: Intel at usbus0 uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 ugen1.1: Intel at usbus1 uhub1: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 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 /snip 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. I think it should be something like MAX(32, MAXCPU). -- John Baldwin ___ 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: Dell acpi_video patch
- (val DOD_DEVID_MASK_FULL) == adr) {
+ (val (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK_FULL)) ==
+ adr) {
argset-callback(handle, val, argset-context);
argset-count++;
}
--
John Baldwin
___
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: Dell acpi_video patch
On Friday, October 12, 2012 7:57:43 pm Alberto Villa wrote: On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin j...@freebsd.org wrote: I think this is correct, but in we need to do more to properly handle that flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the device ID unless that bit is set (except for the special case of DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b spec. I think this larger patch will do that while also fixing your case: I tested your patch and the only effect is that my three reported screens (I'm on a laptop) changed from crt to out (I understand why, from the code): hw.acpi.video.out0.active: 1 hw.acpi.video.out1.active: 1 hw.acpi.video.out1.brightness: 100 hw.acpi.video.out1.fullpower: 100 hw.acpi.video.out1.economy: 50 hw.acpi.video.out1.levels: 100 50 0 10 20 30 40 50 60 70 80 90 100 hw.acpi.video.out2.active: 1 Is there something I can do to help you make them recognised correctly, or is it fault of a buggy ACPI table? Interesting. Can you get an acpidump? -- John Baldwin ___ 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: Dell acpi_video patch
On Wednesday, October 17, 2012 9:08:34 pm Alberto Villa wrote:
On Mon, Oct 15, 2012 at 5:12 PM, John Baldwin j...@freebsd.org wrote:
Interesting. Can you get an acpidump?
Sure:
http://people.FreeBSD.org/~avilla/files/avilla.asl.gz
I'd be glad to solve my problems with ACPI!
Ah, looks like your BIOS excludes DOD_DEVID_SCHEME_STD from it's _ADR
methods (but does included it in on the list of displays returned by
_DOD).
Please test this updated version:
Index: acpi_video.c
===
--- acpi_video.c(revision 241683)
+++ acpi_video.c(working copy)
@@ -320,7 +320,8 @@ acpi_video_resume(device_t dev)
ACPI_SERIAL_BEGIN(video_output);
STAILQ_FOREACH_SAFE(vo, sc-vid_outputs, vo_next, vn) {
if ((vo-adr DOD_DEVID_MASK_FULL) != DOD_DEVID_LCD
- (vo-adr DOD_DEVID_MASK) != DOD_DEVID_INTDFP)
+ (vo-adr (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) !=
+ (DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP))
continue;
if ((vo_get_device_status(vo-handle) DCS_ACTIVE) == 0)
@@ -467,38 +468,40 @@ acpi_video_vo_init(UINT32 adr)
ACPI_SERIAL_ASSERT(video);
- switch (adr DOD_DEVID_MASK) {
+ /* Assume an unknown unit by default. */
+ desc = unknown output;
+ type = out;
+ voqh = other_units;
+
+ switch (adr (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) {
case DOD_DEVID_MONITOR:
if ((adr DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) {
/* DOD_DEVID_LCD is a common, backward compatible ID */
desc = Internal/Integrated Digital Flat Panel;
type = lcd;
voqh = lcd_units;
- } else {
- desc = VGA CRT or VESA Compatible Analog Monitor;
- type = crt;
- voqh = crt_units;
}
break;
- case DOD_DEVID_TV:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR:
+ desc = VGA CRT or VESA Compatible Analog Monitor;
+ type = crt;
+ voqh = crt_units;
+ break;
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV:
desc = TV/HDTV or Analog-Video Monitor;
type = tv;
voqh = tv_units;
break;
- case DOD_DEVID_EXT:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT:
desc = External Digital Monitor;
type = ext;
voqh = ext_units;
break;
- case DOD_DEVID_INTDFP:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP:
desc = Internal/Integrated Digital Flat Panel;
type = lcd;
voqh = lcd_units;
break;
- default:
- desc = unknown output;
- type = out;
- voqh = other_units;
}
n = 0;
@@ -633,21 +636,25 @@ acpi_video_vo_destroy(struct acpi_video_output *vo
AcpiOsFree(vo-vo_levels);
}
- switch (vo-adr DOD_DEVID_MASK) {
+ voqh = other_units;
+
+ switch (vo-adr (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) {
case DOD_DEVID_MONITOR:
+ if ((vo-adr DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD)
+ voqh = lcd_units;
+ break;
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR:
voqh = crt_units;
break;
- case DOD_DEVID_TV:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV:
voqh = tv_units;
break;
- case DOD_DEVID_EXT:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT:
voqh = ext_units;
break;
- case DOD_DEVID_INTDFP:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP:
voqh = lcd_units;
break;
- default:
- voqh = other_units;
}
STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next);
free(vo, M_ACPIVIDEO);
@@ -905,8 +912,14 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 l
return (AE_OK);
for (i = 0; i argset-dod_pkg-Package.Count; i++) {
+ /*
+* Some systems do not include DOD_DEVID_SCHEME_STD in
+* the _ADR of output devices and some do, so just
+* ignore DOD_DEVID_SCHEME_STD.
+*/
if (acpi_PkgInt32(argset-dod_pkg, i, val) == 0
- (val DOD_DEVID_MASK_FULL) == adr) {
+ (val DOD_DEVID_MASK_FULL) ==
+ (adr ~DOD_DEVID_SCHEME_STD)) {
argset-callback(handle, val, argset-context);
argset-count++;
}
--
John Baldwin
___
freebsd-acpi
Re: Dell acpi_video patch
On Friday, October 12, 2012 12:33:49 pm Juergen Lock wrote:
On Fri, Oct 12, 2012 at 10:06:17AM -0400, John Baldwin wrote:
On Friday, October 05, 2012 5:53:16 pm Juergen Lock wrote:
Hi!
I finally took a closer look why acpi_video found nothing on my
Dell laptop (Precision M4500), and came up with this patch:
--- sys/dev/acpica/acpi_video.c.orig
+++ sys/dev/acpica/acpi_video.c
@@ -906,7 +906,7 @@ vid_enum_outputs_subr(ACPI_HANDLE handle
for (i = 0; i argset-dod_pkg-Package.Count; i++) {
if (acpi_PkgInt32(argset-dod_pkg, i, val) == 0
- (val DOD_DEVID_MASK_FULL) == adr) {
+ (val (DOD_DEVID_MASK_FULL | 0x8000)) == adr) {
argset-callback(handle, val, argset-context);
argset-count++;
}
which gives me:
I think this is correct, but in we need to do more to properly handle that
flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in
the
device ID unless that bit is set (except for the special case of
DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b
spec. I think this larger patch will do that while also fixing your case:
Thank you, yes that still works for me the same as my original patch:
Can you please test this updated patch as well:
Index: acpi_video.c
===
--- acpi_video.c(revision 241683)
+++ acpi_video.c(working copy)
@@ -320,7 +320,8 @@ acpi_video_resume(device_t dev)
ACPI_SERIAL_BEGIN(video_output);
STAILQ_FOREACH_SAFE(vo, sc-vid_outputs, vo_next, vn) {
if ((vo-adr DOD_DEVID_MASK_FULL) != DOD_DEVID_LCD
- (vo-adr DOD_DEVID_MASK) != DOD_DEVID_INTDFP)
+ (vo-adr (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) !=
+ (DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP))
continue;
if ((vo_get_device_status(vo-handle) DCS_ACTIVE) == 0)
@@ -467,38 +468,40 @@ acpi_video_vo_init(UINT32 adr)
ACPI_SERIAL_ASSERT(video);
- switch (adr DOD_DEVID_MASK) {
+ /* Assume an unknown unit by default. */
+ desc = unknown output;
+ type = out;
+ voqh = other_units;
+
+ switch (adr (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) {
case DOD_DEVID_MONITOR:
if ((adr DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD) {
/* DOD_DEVID_LCD is a common, backward compatible ID */
desc = Internal/Integrated Digital Flat Panel;
type = lcd;
voqh = lcd_units;
- } else {
- desc = VGA CRT or VESA Compatible Analog Monitor;
- type = crt;
- voqh = crt_units;
}
break;
- case DOD_DEVID_TV:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR:
+ desc = VGA CRT or VESA Compatible Analog Monitor;
+ type = crt;
+ voqh = crt_units;
+ break;
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV:
desc = TV/HDTV or Analog-Video Monitor;
type = tv;
voqh = tv_units;
break;
- case DOD_DEVID_EXT:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT:
desc = External Digital Monitor;
type = ext;
voqh = ext_units;
break;
- case DOD_DEVID_INTDFP:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP:
desc = Internal/Integrated Digital Flat Panel;
type = lcd;
voqh = lcd_units;
break;
- default:
- desc = unknown output;
- type = out;
- voqh = other_units;
}
n = 0;
@@ -633,21 +636,25 @@ acpi_video_vo_destroy(struct acpi_video_output *vo
AcpiOsFree(vo-vo_levels);
}
- switch (vo-adr DOD_DEVID_MASK) {
+ voqh = other_units;
+
+ switch (vo-adr (DOD_DEVID_SCHEME_STD | DOD_DEVID_MASK)) {
case DOD_DEVID_MONITOR:
+ if ((vo-adr DOD_DEVID_MASK_FULL) == DOD_DEVID_LCD)
+ voqh = lcd_units;
+ break;
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_MONITOR:
voqh = crt_units;
break;
- case DOD_DEVID_TV:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_TV:
voqh = tv_units;
break;
- case DOD_DEVID_EXT:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_EXT:
voqh = ext_units;
break;
- case DOD_DEVID_INTDFP:
+ case DOD_DEVID_SCHEME_STD | DOD_DEVID_INTDFP:
voqh = lcd_units;
break;
- default:
- voqh = other_units;
}
STAILQ_REMOVE
Re: Dell acpi_video patch
On Thursday, October 18, 2012 4:58:42 pm Alberto Villa wrote: On Thu, Oct 18, 2012 at 2:58 PM, John Baldwin j...@freebsd.org wrote: Ah, looks like your BIOS excludes DOD_DEVID_SCHEME_STD from it's _ADR methods (but does included it in on the list of displays returned by _DOD). Please test this updated version: Still the same: hw.acpi.video.out0.active: 1 hw.acpi.video.out1.active: 1 hw.acpi.video.out1.brightness: 100 hw.acpi.video.out1.fullpower: 100 hw.acpi.video.out1.economy: 50 hw.acpi.video.out1.levels: 100 50 0 10 20 30 40 50 60 70 80 90 100 hw.acpi.video.out2.active: 1 Ok, can you possibly hack acpi_video to output the values returned _DOD (in hex) and the _ADR values (in hex) of your outputs? -- John Baldwin ___ 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: Dell acpi_video patch
On Friday, October 19, 2012 10:34:08 am Alberto Villa wrote:
On Thu, Oct 18, 2012 at 11:16 PM, John Baldwin j...@freebsd.org wrote:
Ok, can you possibly hack acpi_video to output the values returned _DOD (in
hex) and the _ADR values (in hex) of your outputs?
I've read the ACPI spec and checked my dump, now I see what you mean.
Nonetheless, I think you have confused the _STD bit with the _BIOS
one:
0x00010100,
0x00010118,
0x00010121
So acpi_video.c behaves just as expected. By the way, the GFX device
has a _DOD method too, which returns 0x0400 (an LCD device)...
I'm looking at section B.4.2 in the 3.0b spec, it has a sample _DOD of:
Method (_DOD, 0) {
Return (
Package() {
0x0110, // Primary LCD panel, not detectable by BIOS
0x8100, // CRT type display, not detectable by BIOS
0x8220, // TV type display, not detectable by the BIOS
0x8411, // Secondary LCD panel, not detectable by BIOS
}
)
}
The description of bit 31 is quite clear:
Device ID Scheme
31 1 – Uses the bit-field definitions above (bits 15:0)
0 – Other scheme, contact the Video Chip Vendor
Then there is table B-3:
Table B-3: Example Device Ids
Bits Definition
0x000x Bit 31 = 0. Other proprietary scheme - 0x110 Device ID is an
exception. (See Note 3)
0x0110 Integrated LCD Panel #1 using a common, backwards compatible ID
0x8100 Integrated VGA CRT or VESA compatible Monitor #1 on Port0
0x8240 Integrated TV #1 on Port4
0x8410 Integrated Internal LCD Panel #1 on Port1
0x8421 LVDS Panel #2 Dual-Link using Port2 3. (See Note 4)
0x8131 VGA CRT or VESA compatible Monitor #2 on Port3
0x8121 Dual-Link VGA CRT or VESA compatible Monitor #2 using Port2 3.
(See Note 4.)
0x8320 DVI Monitor #1 on Port2 (shares Port2 with a Dual-Function DVI/TV
Encoder). (See Note 5)
0x8331 DVI Monitor #2 on Port3
0x8330 Dual-Link DVI Monitor #1 using Port2 3
0x8231 TV #2 on Port2 (shares Port2 with a Dual-Function DVI/TV Encoder).
(See Note 5)
Notes:
3. When Bit 31 is 0, no assumptions can be made on which ID will be used
for any particular display type. Contact the Video Chip vendor for
details of the ID scheme employed.
Looking back at earlier ACPI specs (1.0b and 2.0c), they did not mention bit
31 at all (well, it was required to be zero). Their examples are different as
well, but they don't define any meaning to the low bits, so I think we are
correct in calling all of them plain outputs. Specifically, the
Display Type bitfield (Bits 8:11) are undefined in the earlier specs, and
3.0b only claims they are defined if bit 31 is set.
--
John Baldwin
___
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: Dell acpi_video patch
On Thursday, October 18, 2012 3:57:23 pm Juergen Lock wrote:
On Thu, Oct 18, 2012 at 08:59:14AM -0400, John Baldwin wrote:
On Friday, October 12, 2012 12:33:49 pm Juergen Lock wrote:
On Fri, Oct 12, 2012 at 10:06:17AM -0400, John Baldwin wrote:
On Friday, October 05, 2012 5:53:16 pm Juergen Lock wrote:
Hi!
I finally took a closer look why acpi_video found nothing on my
Dell laptop (Precision M4500), and came up with this patch:
--- sys/dev/acpica/acpi_video.c.orig
+++ sys/dev/acpica/acpi_video.c
@@ -906,7 +906,7 @@ vid_enum_outputs_subr(ACPI_HANDLE handle
for (i = 0; i argset-dod_pkg-Package.Count; i++) {
if (acpi_PkgInt32(argset-dod_pkg, i, val) == 0
- (val DOD_DEVID_MASK_FULL) == adr) {
+ (val (DOD_DEVID_MASK_FULL | 0x8000)) == adr) {
argset-callback(handle, val, argset-context);
argset-count++;
}
which gives me:
I think this is correct, but in we need to do more to properly handle
that
flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits
in the
device ID unless that bit is set (except for the special case of
DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI
3.0b
spec. I think this larger patch will do that while also fixing your
case:
Thank you, yes that still works for me the same as my original patch:
Can you please test this updated patch as well:
Sorry, one more request. I think I want to commit just your fix separately,
but I have a slightly different version of it. Can you just double check
this version:
Index: acpi_video.c
===
--- acpi_video.c(revision 241688)
+++ acpi_video.c(working copy)
@@ -906,7 +906,8 @@ vid_enum_outputs_subr(ACPI_HANDLE handle, UINT32 l
for (i = 0; i argset-dod_pkg-Package.Count; i++) {
if (acpi_PkgInt32(argset-dod_pkg, i, val) == 0
- (val DOD_DEVID_MASK_FULL) == adr) {
+ (val DOD_DEVID_MASK_FULL) ==
+ (adr DOD_DEVID_MASK_FULL)) {
argset-callback(handle, val, argset-context);
argset-count++;
}
--
John Baldwin
___
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: Dell acpi_video patch
On Friday, October 19, 2012 11:41:56 am Alberto Villa wrote: On Fri, Oct 19, 2012 at 4:53 PM, John Baldwin j...@freebsd.org wrote: I'm looking at section B.4.2 in the 3.0b spec, it has a sample _DOD of: I've read section B.3.2 of 5.0 spec, which looks the same as 3.0b, but my IDs don't have bit 31 set, they have bit 16 (which is the difference between _DOD and _ADR you were probably talking about). Or am I missing the point? Yes, unless bit 31 is set, we can't know anything about bits 0-15 except that they are unique. Specifically, we can't look at the Display Type bits to determine if an output device is a CRT vs LCD vs TV, etc. You can only do that if bit 31 is set. -- John Baldwin ___ 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: Dell acpi_video patch
On Friday, October 19, 2012 11:23:57 am Alberto Villa wrote: On Fri, Oct 12, 2012 at 4:06 PM, John Baldwin j...@freebsd.org wrote: I think this is correct, but in we need to do more to properly handle that flag (DOD_DEVID_SCHEME_STD). Specifically, we shouldn't trust any bits in the device ID unless that bit is set (except for the special case of DOD_DEVID_LCD) as per my reading of the _DOD description in the ACPI 3.0b spec. I think this larger patch will do that while also fixing your case: By the way, it looks like also 0x0100 and 0x0200 should be handled as legacy values: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=include/acpi/video.h;h=61109f2609fc3ee446ec43e242875b28ae719344;hb=HEAD http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/acpi/video.c;h=f94d4c818fc74dc9a076e8f67fe98d7bc6620a61;hb=HEAD I considered that, but 1) it wouldn't help your laptop, and 2) the ACPI 3.0b spec where bit 31 is added specifically states (in the Note 3 I included in my prior e-mail) that 0x110 is the only valid legacy ID. -- John Baldwin ___ 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: Dell acpi_video patch
On Friday, October 19, 2012 06:21:00 PM Alberto Villa wrote: On Fri, Oct 19, 2012 at 7:13 PM, John Baldwin j...@freebsd.org wrote: Yes, unless bit 31 is set, we can't know anything about bits 0-15 except that they are unique. Specifically, we can't look at the Display Type bits to determine if an output device is a CRT vs LCD vs TV, etc. You can only do that if bit 31 is set. I know, I was saying that you probably confused bit 31 with bit 16, so the patch you proposed (about bit 31 being set in _DOD but not in _ADR) was not correct. ;) Oh, no, I hadn't been able to tell from your ASL that bit 16 was set (it's not that easy to guess as it computes the ID's dynamically at runtime. I was merely guessing that since I had changed the matching logic to look at bit 31 that that was the cause, but it wasn't the matching logic that was different (comparing _ADR to _DOD), but the logic that parsed _DOD is what treated your laptop differently. -- John Baldwin ___ 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: Dell acpi_video patch
On Saturday, October 20, 2012 9:37:40 am Alberto Villa wrote: On Sat, Oct 20, 2012 at 2:40 PM, John Baldwin j...@freebsd.org wrote: Oh, no, I hadn't been able to tell from your ASL that bit 16 was set (it's not that easy to guess as it computes the ID's dynamically at runtime. I see. I was merely guessing that since I had changed the matching logic to look at bit 31 that that was the cause, Oh, no, it wasn't working before too, it just changed from crt to out because of your change (which makes sense). but it wasn't the matching logic that was different (comparing _ADR to _DOD), but the logic that parsed _DOD is what treated your laptop differently. So, just to be sure, you don't need any other information from me, right? I don't think, by the way, that a list of known non-standard configurations is worth being added to the code for this issue. Largely correct. However, we could add support for vendor-specific IDs if someone wanted to maintain it. -- John Baldwin ___ 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: Fixing X220 Video The Right Way
On Sunday, February 24, 2013 2:54:39 pm matt wrote: I am working on fixing acpi_video for X220. My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty. So I've set out to fix acpi_video to work naturally, as it does in linux land. Background: Lenovo laptops boot in a mode where the brightness keys automagically work, under BIOS/EC control. This gets blown away (for us) shortly after Kernel attach. At this point, the acpi method \NBCF will return 0, which means acpi cannot control video brightness. Once we touch the _BCL method on the video output (even inactive ones), \NBCF returns 1 and will allow acpi control. You may remember that acpi_video records some brightness value that changes with keypresses, but does not work on X220. Current status: If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works via sysctl but not keypress (\NBCF = 1) If I leave that alone, but just redirect the brightness set function to \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works That is obviously a hack, but it indicates something is going on here. I think that get_acpi_handle() on the X220 vgapci is returning the wrong ACPI_HANDLE. Perhaps this is why the screen stays off when resume used to work? Obviously it can be fixed by hard coding this path into acpi_video, but I feel like that is definitely the wrong way. A tunable for an acpi_video override might be useful, but it still leaves potentially the wrong path in vgapci's IVARs. Is there a better place to correct the ACPI_PATH that gets stored in vgapci's ivar? Is there already a tunable I can use to fix this? vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices? -- John Baldwin ___ 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: call suspend_cpus() under smp_ipi_mtx
On Saturday, March 23, 2013 5:48:50 am Andriy Gapon wrote: Looks like this issue needs more thinking and discussing. The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on SMP systems). This is for exactly the same reasons as to why we first take smp_ipi_mtx before calling stop_cpus() in the shutdown path. Essentially one CPU could be holding smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown), while another CPU could be with interrupts disabled (explicitly - like in the shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all regular (non-NMI) synchronous IPI-based communication between CPUs. Otherwise a deadlock is quite possible. Some obstacles for just going ahead and making the suggested change: - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we would have to make intr_table_lock and msi_lock the spin-locks as well; - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and currently it performs an action that requires memory allocation; again, with interrupts disabled via intr_disable() this fact is not visible to witness, etc, but with smp_ipi_mtx it needs to be somehow handled. I talked to ACPICA guys about the last issue and they told me that what is currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and _GTS support was removed. What do you think? Thank you. Hmm, I think intr_table_lock used to be a spin lock at some point. I don't remember why we changed it to a regular mutex. It may be that there was a lock order reason for that. :( -- John Baldwin ___ 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: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type)
-pl_crs_bad !link-l_isa_irq + link-l_crs_type == ACPI_RESOURCE_TYPE_IRQ) + req-sc-pl_crs_bad = TRUE; break; default: if (req-in_dpf == DPF_IGNORE) -- John Baldwin ___ 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: panic: acpi_pci_link_srs_from_crs: can't put non-ISA IRQ 20 in legacy IRQ resource type)
On Friday, April 19, 2013 06:21:10 PM Benjamin Lee wrote: On Fri, 19 Apr 2013 17:26:31 -0400, John Baldwin j...@freebsd.org wrote: On Friday, April 19, 2013 4:18:49 pm Benjamin Lee wrote: On Fri, 19 Apr 2013 11:31:49 -0400, John Baldwin j...@freebsd.org wrote: On Thursday, April 18, 2013 3:49:40 pm Benjamin Lee wrote: I have a system that panics on boot with 10-CURRENT and boots with many ACPI error messages and non-functional devices with 9.1-RELEASE. Motherboard is Foxconn C51XEM2AA (NVIDIA nForce 590) desktop board. [...] Even though 9.1-RELEASE boots successfully, devices such as the ehci USB controller and SATA controller do not work. Ugh, your BIOS does unexpected things. It uses a _CRS for these pci link devices that uses a short IRQ resource, but uses an extended IRQ resource in _PRS (and expects an extended one in _SRS). We use _CRS as a template for the resource to build. Try this patch. It's a bit hackish, but it forces us to not use _CRS as a template if _CRS uses a short IRQ resource, but the link supports non- ISA IRQs. [...] Thanks, that fixed the panic and the system boots. Now it is complaining about AE_AML_BAD_RESOURCE_LENGTH and still unable to route IRQs, but it definitely looks better than the ACPI parsing errors in 9: pcib0: allocated type 3 (0xd000-0xdfff) for rid 10 of pci0:0:10:0 pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) pci_link26: Picked IRQ 20 with weight 0 pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH Full boot -v output: http://www.b1c1l1.com/media/debug/20130419-10-patched- boot.txt.gz Can you add some printfs to the places that return the AE_AML_BAD_RESOURCE_LENGTH to see which one is being triggered? (Just look for that constant in sys/contrib/dev/acpica to find the possible places.) Is there a macro for dumping information about Resource or Resource-Data? Here's what I have for now at sys/contrib/dev/acpica/resources/rscalc.c line 237: pcib0: matched entry for 0.10.INTA (src \_SB_.PCI0.AUBA:0) pci_link26: Picked IRQ 20 with weight 0 rscalc.c:237 Resource-Type: 7 Resource-Length: 0 pci_link26: Unable to route IRQs: AE_AML_BAD_RESOURCE_LENGTH All of the errors are from there and look identical (Type 7, Length 0). Type 7 appears to be ACPI_RESOURCE_TYPE_END_TAG. Ah, this is easy to fix then. It seems in sys/dev/acpica/acpi.c in acpi_AppendBufferResource() we didn't create the end tag correctly. Can you try this in addition to the patch to acpi_pci_link.c: Index: sys/dev/acpica/acpi.c === --- acpi.c (revision 249195) +++ acpi.c (working copy) @@ -2384,7 +2384,7 @@ /* And add the terminator. */ rp = ACPI_NEXT_RESOURCE(rp); rp-Type = ACPI_RESOURCE_TYPE_END_TAG; -rp-Length = 0; +rp-Length = ACPI_RS_SIZE_MIN; return (AE_OK); } -- John Baldwin ___ 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: Fixing suspend/resume on Lenovo x220
On Thursday, June 13, 2013 10:00:21 am Ganael LAPLANCHE wrote: Hi, As you may know, suspend/resume has been broken on Lenovo x220 for a long time now, see : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 I have been able to do a suspend(S3)/resume operation in text mode (it works, but console stays dark at resume, I had to connect through ssh ; also, resume hangs if X is started with i915kms.ko loaded) and collect the following verbose logs : Interesting, I connected a serial console via AMT but wasn't able to get any output during resume. Is this with a stock kernel? -- John Baldwin ___ 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: Fixing X220 Video The Right Way
On Thursday, March 07, 2013 9:13:38 pm matt wrote:
On 02/28/13 09:09, John Baldwin wrote:
On Thursday, February 28, 2013 8:15:46 am matt wrote:
On 02/27/13 12:27, John Baldwin wrote:
On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
On 02/27/13 09:00, John Baldwin wrote:
If that is true, it's because your BIOS is lying. Do you have a URL to
your ASL lying around already?
Too big for pastebin :( +500k
https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
Here is where I find _DOD and _DOS methods:
Device (PCI0)
Device (VID)
Name (_ADR, 0x0002) // _ADR: Address
Method (_DOS, 1, NotSerialized) // _DOS: Disable
Output Switching
Method (_DOD, 0, NotSerialized) // _DOD: Display
Output Devices
Device (PEG)
Name (_ADR, 0x0001) // _ADR: Address
Device (VID)
Name (_ADR, 0x00) // _ADR: Address
Method (_DOS, 1, NotSerialized) // _DOS: Disable
Output Switching
Method (_DOD, 0, NotSerialized) // _DOD: Display
Output Devices
PCI0.VID is a PCI device at pci0:0:2:0.
PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
It would have a child device at 0:0 that would be PCI0.PEG.VID. Does
the X220
have a switchable GPU (e.g. it has built-in Intel graphics, but also has
an
Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel
graphics
and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful
to determine
that. If both PCI devices exist you shoudl have both acpi_video0 and
acpi_video1.
However, it may be that the acpi_video driver doesn't cope well with
having multiple
devices.
Only Intel graphics, there is no option for switchable graphics.
I initially thought that PEG was for Optimus usage, and left in the bios
by accident (i.e. Lenovo using a generic DSDT for many machines)
Here is pciconf -lcf, truncated
hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086
rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family DRAM Controller'
class = bridge
subclass = HOST-PCI
cap 09[e0] = vendor (length 12) Intel cap 0 version 1
vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086
rev=0x09 hdr=0x00
vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family Integrated
Graphics Controller'
class = display
subclass = VGA
cap 05[90] = MSI supports 1 message enabled with 1 message
cap 01[d0] = powerspec 2 supports D0 D3 current D0
cap 13[a4] = PCI Advanced Features: FLR TP
none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
As you can see there is no device at pci0:0:1:0. So no dev_t with for
acpi_video to probe or attach to.
Nonetheless, only PEGs ACPI methods work, which is quite broken. This is
true for a large number of Lenovo devices, back to x61 (non-attaching
AGP adr) and probably including some other x series and t series.
Unfortunately the ASL will not compile which makes fixing the DSDT an
exercise in fixing broken ACPI.
What I find interesting is that as far as I can tell, there's no special
case handling for this device in Linux, yet backlight controls work out
of the box since about 3.0. Installing Linux as the OSI via loader.conf
is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows
2009 (/WIN7). I get correct (for platform) behavior when I call PEGs
_BCM... :(
Is Linux getting this to work by doing it wrong, essentially?
Yes. I think the best way to fix this is to add a way to specify a
hint to override the ACPI path associated with a PCI device. Something
like:
hw.pci0.0.2.0.handle=\_SB_.PCI0.PEG.VID
I think this patch should do the trick:
Index: sys/dev/acpica/acpi_pci.c
===
--- acpi_pci.c (revision 247320)
+++ acpi_pci.c (working copy)
@@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
return_ACPI_STATUS (AE_OK);
}
+static void
+acpi_pci_override_handles(device_t dev)
+{
+ struct acpi_pci_devinfo *dinfo;
+ device_t *devlist;
+ int error, i, numdevs;
+ char tunable_name[64], *path;
+ ACPI_HANDLE handle;
+
+ error = device_get_children(dev, devlist, numdevs);
+ if (error)
+ return;
+ for (i = 0; i numdevs; i++) {
+ dinfo = device_get_ivars(devlist[i]);
+ snprintf(tunable_name, sizeof(tunable_name),
+ hw.pci%d.%d.%d.%d.handle, dinfo-ap_dinfo.cfg.domain,
+ dinfo-ap_dinfo.cfg.bus, dinfo
Re: kern/91594: [acpi] FreeBSD gt; 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression]
The following reply was made to PR kern/91594; it has been noted by GNATS.
From: John Baldwin j...@freebsd.org
To: bug-follo...@freebsd.org, b...@bsd.de
Cc:
Subject: Re: kern/91594: [acpi] FreeBSD gt; 5.4 w/ACPI fails to detect Intel
Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression]
Date: Tue, 02 Jul 2013 12:49:13 -0700
This is a multi-part message in MIME format.
--040100040502060400080805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Please try this change:
--
John Baldwin
--040100040502060400080805
Content-Type: text/plain; charset=UTF-8; x-mac-type=0; x-mac-creator=0;
name=pcib_acpi_present.patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=pcib_acpi_present.patch
--- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib.c
+++ //depot/projects/pci/sys/dev/acpica/acpi_pcib.c
@@ -135,15 +135,6 @@
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
/*
- * Don't attach if we're not really there.
- *
- * XXX: This isn't entirely correct since we may be a PCI bus
- * on a hot-plug docking station, etc.
- */
-if (!acpi_DeviceIsPresent(dev))
- return_VALUE(ENXIO);
-
-/*
* Get the PCI interrupt routing table for this bus. If we can't
* get it, this is not an error but may reduce functionality. There
* are several valid bridges in the field that do not have a _PRT, so
--- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib_acpi.c
+++ //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c
@@ -287,6 +292,12 @@
sc-ap_handle = acpi_get_handle(dev);
/*
+ * Don't attach if we're not really there.
+ */
+if (!acpi_DeviceIsPresent(dev))
+ return (ENXIO);
+
+/*
* Get our segment number by evaluating _SEG.
* It's OK for this to not exist.
*/
@@ -353,7 +364,7 @@
if (status != AE_NOT_FOUND) {
device_printf(dev, could not evaluate _BBN - %s\n,
AcpiFormatException(status));
- return_VALUE (ENXIO);
+ return (ENXIO);
} else {
/* If it's not found, assume 0. */
sc-ap_bus = 0;
--040100040502060400080805--
___
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: USB ports on Lenovo T400 do not work after a suspend/resume
On Sunday, June 30, 2013 10:22:09 am Ian Smith wrote: On Sat, 29 Jun 2013, Adrian Chadd wrote: On 27 June 2013 04:58, Ian Smith smi...@nimnet.asn.au wrote: We don't yet know if this is a bus, ACPI /or USB issue. Home yet? :) Yup: http://people.freebsd.org/~adrian/usb/ dmesg.boot = dmesg at startup 1 - after powerup, usb device in 2 - after acpiconf -s3 suspend/resume, w/ a USB device plugged in 3 - after acpiconf -s3 suspend/resume, with a USB device removed before suspend/resume After removing [numbers] (for WITNESS?), diff started making sense. The below is between the first and second suspend/resume cycles in dmesg-3.txt, encompassing the others. Nothing of note that I can see, if that usb hub-to-bus remapping is normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. Maybe someone who knows might comment on that? From sys/amd64/include/apicreg.h: /* fields in ESR */ #define APIC_ESR_SEND_CS_ERROR 0x0001 #define APIC_ESR_RECEIVE_CS_ERROR 0x0002 #define APIC_ESR_SEND_ACCEPT0x0004 #define APIC_ESR_RECEIVE_ACCEPT 0x0008 #define APIC_ESR_SEND_ILLEGAL_VECTOR0x0020 #define APIC_ESR_RECEIVE_ILLEGAL_VECTOR 0x0040 #define APIC_ESR_ILLEGAL_REGISTER 0x0080 Receive illegal vector (if look in Intel's SDM manuals) means it got an interrupt vector 32 (probably zero). Perhaps it asserted an interrupt in an I/O APIC before the I/O APIC was properly reset? Are you using MSI at all? -- John Baldwin ___ 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: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Friday, August 30, 2013 10:51:02 am Sergey A. Osokin wrote: On Fri, Aug 30, 2013 at 01:39:59AM -0700, Adrian Chadd wrote: On 29 August 2013 20:14, Sergey A. Osokin o...@freebsd.org wrote: On Wed, Aug 28, 2013 at 07:03:10PM +0400, Gleb Smirnoff wrote: Laura, Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. Agree with Gleb. Kind of a slowness exist after resume. Can y'all grab some basic, naive benchmarks (disk, CPU) and compare them before/after a suspend/resume cycle? Unfortunately, I'm not sure what I need to check... Maybe try x11perf before and after? I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). -- John Baldwin ___ 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: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote: (cc jkim) Hi! Would you mind taking a look at the -acpi list posts with this subject? It looks like a lot of the video suspend/resume issues on these thinkpads boil down to the VESA driver code. If it's disabled, (at least) x11 resume works. Would you be able to help us track down what's going on? Thanks! Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is calling vidd_save_state() and vidd_load_state() which in the VESA case map to the _save_state() and _load_state() methods in sys/dev/fb/vesa.c. These methods look fairly sane to me, so it's probably either a BIOS bug, or the fact that KMS is bypassing the BIOS, so when KMS is active we should perhaps disable the VESA BIOS. I'd argue that we should be it is a BIOS bug regardless. However, one thing that might help is that this is being called at a random time rather than when vgapci0 is being suspended and resumed. Actually, it looks like jkim fixed this via the vgapm driver, except I have no vgapm0 device on my laptop. I wonder if it's supposed to be device_get_unit() instead of device_get_flags() in the vgapm identify routine? -- John Baldwin ___ 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: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Wednesday, September 04, 2013 3:14:32 pm Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 09:29:35 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: On 2013-09-03 16:47:47 -0400, John Baldwin wrote: Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, ... What happens? Does it panic, hang, or just no backlight? Just no backlight. It resumes fine and if I do it in multiuser I can ssh in, etc. It's just the backlight that doesn't resume. I was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. I think i915drm has code to specifically turn on the backlight as I get some weird error message in the kernel console about a timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I have enabled on my older hardware (TP X40 running 8.3-REL and an old Xorg server) for it to work properly. (I however have some faint memory that reset_video might a no-op these days, or?) In this old mail regarding reset_video, there is a thought that it could be good with more reinitialisation: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html I however have one datapoint that I think contradicts John's thought. This is on a X201 with stable/9 and no options VESA. I first just booted up and stayed in text console, suspended and resumed. No backlight, of course, and also no content on the LCD, it is completely black. Then, I started Xorg with KMS. Still no backlight, but you can see that the LCD is driven with the desired content, which is one step forward. Finally, I suspended and resumed, but no difference, the backlight is still off. Xorg/KMS didn't manage to turn the backlight on, so the text console suspend/resume cycle managed to persistently turn the backlight off. Try starting X before you suspend the first time. For me resume works fine if I do that. One more thing, the kernel logs this at resume directly after the devices are powered on (transition to D0), but I have no idea whether it is relevant: Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off I see this even when resume works fine. -- John Baldwin ___ 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: panic after acpi suspend/resume 9.1, 9.2rc3
On Sunday, September 08, 2013 5:24:54 pm J.R. Oldroyd wrote:
This problem may have existed for some time in the 9.x kernel.
I've had similar panics for a while, but not had time to look into
it. I did not have this problem on 8.x kernels on this laptop.
It never happens when the system is cold-booted. It only happens
after a suspend/resume cycle or two which is why I am posting to
freebsd-apci to start with...
The repeat-by goes something like this:
- boot system
- suspend system
- resume system
- use as normal (mix of email/firefox/sh nvi/openvpn)
- perhaps suspend/resume again
- keep using as normal
- system panics, seems often to be when using firefox
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x80ceddcd
stack pointer = 0x28:0xff80dbfe25e0
frame pointer = 0x28:0xff80dbfe2660
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 52022 (firefox)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x80947986 at kdb_backtrace+0x66
#1 0x8090d9ae at panic+0x1ce
#2 0x80cf1db0 at trap_fatal+0x290
#3 0x80cf2111 at trap_pfault+0x211
#4 0x80cf26c4 at trap+0x344
#5 0x80cdb9f3 at calltrap+0x8
#6 0x80b797a7 at vm_fault_hold+0x1b87
This is where the NULL pointer is. Frame 9 (listed below) is above this.
(kgdb) list *0x80ceddcd
0x80ceddcd is in pmap_enter (../../../amd64/amd64/pmap.c:3577).
3572if ((m-oflags VPO_UNMANAGED) == 0) {
3573newpte |= PG_MANAGED;
3574pv = get_pv_entry(pmap, lock);
3575pv-pv_va = va;
3576CHANGE_PV_LIST_LOCK_TO_PHYS(lock, pa);
3577TAILQ_INSERT_TAIL(m-md.pv_list, pv, pv_list);
3578if ((newpte PG_RW) != 0)
3579vm_page_aflag_set(m, PGA_WRITEABLE);
3580}
3581
So it seems like pv_list of a page might be busted? Can you try looking at
the disassembly to see if you can find 'm' in one of the registers?
--
John Baldwin
___
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: panic after acpi suspend/resume 9.1, 9.2rc3
On Thursday, September 12, 2013 9:23:39 pm J.R. Oldroyd wrote:
On Mon, 9 Sep 2013 16:54:27 -0400 John Baldwin j...@freebsd.org wrote:
(kgdb) list *0x80ceddcd
0x80ceddcd is in pmap_enter
(../../../amd64/amd64/pmap.c:3577).
3572if ((m-oflags VPO_UNMANAGED) == 0) {
3573newpte |= PG_MANAGED;
3574pv = get_pv_entry(pmap, lock);
3575pv-pv_va = va;
3576CHANGE_PV_LIST_LOCK_TO_PHYS(lock, pa);
3577TAILQ_INSERT_TAIL(m-md.pv_list, pv,
pv_list);
3578if ((newpte PG_RW) != 0)
3579vm_page_aflag_set(m, PGA_WRITEABLE);
3580}
3581
So it seems like pv_list of a page might be busted? Can you try
looking at
the disassembly to see if you can find 'm' in one of the registers?
Sure, here you go...
(kgdb) print m
$1 = 0xfe00b260b430
(kgdb) print m-md.pv_list
$4 = {tqh_first = 0x0, tqh_last = 0x0}
Eh, tqh_last shouldn't bmd.pv_liste NULL here IIRC. I think it should
point at
tqh_first.
I had a quick look at the code for this list.
md.pv_list is initialized in pmap_page_init() and there's also a
similar piece of init in pmap_init(), both in sys/amd64/amd64/pmap.c
and also in the other arch's.
But I have little background on how the VM code is supposed to be
initialized or saved on suspend and re-inited on resume. It'd take
me ages to work out what should be going on here.
The hardware should preserve RAM contents which is all VM really needs.
What's the best course of action here...? Open a PR and hand-over to
someone with more background in these areas?
I think kib@ is the best person to ask. I suspect it is a bug in how a
driver is handling resume perhaps.
--
John Baldwin
___
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: Suspend/Resume on Dell E6410 Laptop
On Saturday, October 19, 2013 8:17:14 pm Andrew Klaus wrote: Mine uses the Intel 3000 graphics I believe. There's no Nvidia on this system. I did run the patch anyways, and it didn't seem to help on the modified kernel. Try suspending in X with VESA removed from your kernel. This has worked reliably for some Thinkpad laptops using i915. The LCD will only turn back on if you suspend/resume in X, but not at the console. -- John Baldwin ___ 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: Xeon E5 cpu work in low status
On Monday, November 04, 2013 12:52:53 pm Kevin Oberman wrote: On Mon, Nov 4, 2013 at 12:46 AM, 李森 lisen1...@gmail.com wrote: hi,all: the cpu of my machine is : Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz. after a reboot. The cpu freq is : sysctl dev.cpu.0.freq dev.cpu.0.freq: 1200 i didn't set any power savings config in rc.conf. How can i fix this? It's not clear what is broken. Is the server busy? Is there some reason to expect it to be running at full clock-rate? What is the content of dev.cpu.0.freq_levels? By default, FreeBSD runs powerd and that will, by default, throttle back the clock when the system is not busy. I think that this is a bad thing., but it is not a bug. It's by design. I really think, based on my own testing, research and a major NSF computer center (SDSC), and work done by mav@ which can be found on the FreeBSD wiki ( https://wiki.freebsd.org/TuningPowerConsumption), those power management tools are broken by design a they are actually there for thermal control, not power management and are, at best, break-even, and in most cases are actually a loser in both power savings and system performance. (There are a very few edge cases where they can be beneficial, but as a side effect for very specific loads under fairly unusual circumstances.) To turn off these (mis)features, add the following to /boot/loader.conf: # Disable CPU throttling hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 rant All real power management is through the use of EST and CPU sleep (CX) states. These can provide a big power win at minimal performance impact. Unfortunately CX states and throttling lay very badly together, probably because processor designers don't think that TCC and throttling are for power management, so are not an issue. For reasons that have always baffled me, rather than disable the inappropriate use of thermal management as power management, we disable the most effective power management tools by default. performance_cx_lowest=HIGH # Online CPU idle state economy_cx_lowest=HIGH # Offline CPU idle state Even the comments are confusing: what do Online and Offline mean? Offline means running on battery and online means AC power. In any case, it's not clear that there is any issue with your system other than that, by default, FreeBSD tries to really, really hard to manage power as badly as humanly possible. /rant The only thing is that powerd is not enabled by default, so it shouldn't be set to 1200 out of the box. I think there have been a few laptops historically that would startup at a lower clock speed (EST) when booted on battery, but I've never heard of that for servers. In terms of thermal throttling vs EST: ideally powerd would only ever use EST, and the throttling would be driven by acpi_thermal. Most systems don't have the _TC1/_TC2 methods acpi_thermal needs (I think I've only seen it on older laptops), so that would effectively disable TCC on modern systems. This requires tearing cpufreq apart a bit. It's also not clear what we should display to the user. The simplest approach would be to only export absolute frequencies in freq_levels and the current absolute frequency as freq. That would allow powerd to not need any changes. You could use a different sysctl node that is throttling percent or some such. If throttling kicked in on a system with TC1/TC2 then 'freq' wouldn't change when the CPU was throttled, only the throttling percent. -- John Baldwin ___ 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: P-state setting suddenly disappeared, what gives?
On Thursday, November 14, 2013 6:13:43 pm Jung-uk Kim wrote: On 2013-11-14 17:41:44 -0500, Adrian Chadd wrote: Hi all, I have this Lenovo T400 that I've been doing FreeBSD development on for a while. It has a P8700 in it: CPU: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz (2527.07-MHz 686-class CPU) Now, up until yesterday, ACPI exported the required twiddles to enter various different P-states. However, as of sometime yesterday, it stopped being able to do so. sysctl dev.cpu.0.freq returns nothing. Setting it to something retuns device not configured. The frequency list (ie, the P-state list) is still fine. I had to load cpufreq.ko to get the enhanced speedstep stuff to show up, but (a) it doesn't support this CPU (and it seems to have stopped growing EST bits after Pentium M CPUs..) and (b) setting the frequency using it versus P-state settings doesn't save as much power. I'd like to try and debug why the heck this is. The laptop still works fine, things are just not as nice as they once were. Any ideas? Any suggestions on where to start debugging this? SSDT tables for Intel processors are usually dynamic and often times additional tables are loaded per _OSC or _PDC. [1] Basically, we advertise our capabilities from sys/dev/acpica/acpi_cpu.c, depending on loaded device drivers. Unfortunately, some times it is too late and some SSDTs are not properly loaded. Also, warm booting from other OSes to FreeBSD may cause similar problems. To debug the problem, you need to dump DSDT and SSDTs and try to understand _OSC (or _PDC), _PCT and _PSS for your system. Also, the reason that est.c doesn't hardcode tables for modern CPUs is that on modern systems the tables are provided by ACPI via the acpi_perf(4) driver. -- John Baldwin ___ 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 issues with PC engines APU beta board
On Wednesday, January 22, 2014 11:32:15 am Larry Baird wrote:
I have a protoype board from PC Engines for their upcoming APU board.
The board runs fine under FreeBSD 8.4 release but fails to boot using either
FreeBSD 9.2 release or FreeBSD 10.0 release. Verbose boot seems to indicate
issue is with ACPI. I am working with PC Engines to get FreeBSD up and
running on their board. Hopefully attached information is enough to
determine issue with BIOS. I'll then feed this information back to PC
Engines so they can provide the information to their BIOS provider.
Attached is a verbose dmesg from 9.2. In case it gets stripped you
can also find dmesg at: ftp://ftp.gta.com/pub/apu/FreeBSD9.2/bootVerbose.txt
Dmesg from booting 8.4 is at: ftp://ftp.gta.com/pub/apu/FreeBSD8.4/dmesg.boot
Dump of sysctl.hw.acpi from FreeBSD 8.4 is:
hw.acpi.supported_sleep_state: S1 S2 S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 0
hw.acpi.disable_on_reboot: 0
hw.acpi.handle_reboot: 1
hw.acpi.reset_video: 0
hw.acpi.cpu.cx_lowest: C1
acpidump -dt from from FreeBSD 8.4 is at:
ftp://ftp.gta.com/pub/apu/FreeBSD8.4/lab-pcengines-apu1b.asl
The BIOS is busted. The resource ranges that the Host-PCI bridge decodes are
marked as regular resources when they should be ResourceProducer ranges
instead. They have this correct for I/O port resources, but not memory. You
can try this workaround:
Index: sys/dev/acpica/acpi.c
===
--- acpi.c (revision 261235)
+++ acpi.c (working copy)
@@ -1190,6 +1190,7 @@ acpi_set_resource(device_t dev, device_t child, in
struct acpi_softc *sc = device_get_softc(dev);
struct acpi_device *ad = device_get_ivars(child);
struct resource_list *rl = ad-ad_rl;
+ACPI_DEVICE_INFO *devinfo;
u_long end;
/* Ignore IRQ resources for PCI link devices. */
@@ -1196,6 +1197,21 @@ acpi_set_resource(device_t dev, device_t child, in
if (type == SYS_RES_IRQ ACPI_ID_PROBE(dev, child, pcilink_ids) != NULL)
return (0);
+/*
+ * Ignore memory resources for PCI root bridges. Some BIOSes
+ * incorrectly enumerate the memory ranges they decode as plain
+ * memory resources instead of as a ResourceProducer range.
+ */
+if (type == SYS_RES_MEMORY) {
+ if (ACPI_SUCCESS(AcpiGetObjectInfo(ad-ad_handle, devinfo))) {
+ if ((devinfo-Flags ACPI_PCI_ROOT_BRIDGE) != 0) {
+ AcpiOsFree(devinfo);
+ return (0);
+ }
+ AcpiOsFree(devinfo);
+ }
+}
+
/* If the resource is already allocated, fail. */
if (resource_list_busy(rl, type, rid))
return (EBUSY);
--
John Baldwin
___
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 Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. -- John Baldwin ___ 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 Monday, May 05, 2014 12:55:29 pm Adrian Chadd wrote: On 5 May 2014 08:09, John Baldwin j...@freebsd.org wrote: On Sunday, May 04, 2014 4:27:38 am Adrian Chadd wrote: Hi, I'd like to propose flipping a few things: * Flipping the default lid state to S3. I think ACPI suspend/resume seems to work well enough these days and I've not met anyone lately who expects the default from their laptop to be stay awake with the lid shut. * Save chip bugs that we should add workarounds for, we should be OK to enter lower sleep states when idling. Flipping this may expose some further crazy driver, platform or timer bugs, but they again likely should be fixed. what do people think? I think the lid switch thing is premature. Even on my X220 I use a devd hook to enable it only when i915drm is loaded as resume doesn't work until that is done. I think the Cmax thing OTOH is probably more appropriate. We have several things place that should mostly DTRT for picking the correct timers to use. The one case I know of recently were some somewhat older systems where the HPET wasn't reliable, but the system chose to use HPET instead of LAPIC becuase the LAPIC was known to stop during C1E, etc. In this case the user just stuck with plain old C1 and forced the LAPIC timer which worked fine. However, it is hard to identify those cases. On modern systems I would expect the LAPIC to work just fine, so this problem will become less and less important as time goes on. right. I'd rather we start finding more of these sooner rather than later. :-) The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) -- John Baldwin ___ 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: suspend issues with latest -HEAD, ahci failing to complete something?
On Monday, May 05, 2014 3:55:31 pm Adrian Chadd wrote: Hi, Would you mind testing the latest -HEAD out? It worked a couple weeks ago with my last rebuild on this particular laptop. My x220 resumes just fine with yesterday's HEAD from S3. Uses ahci: ahci0: Intel Cougar Point AHCI SATA controller port 0x50a8-0x50af,0x50bc-0x50bf,0x50a0-0x50a7,0x50b8-0x50bb,0x5060-0x507f mem 0xd2528000-0xd25287ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ahcich4: AHCI channel at channel 4 on ahci0 ahciem0: AHCI enclosure management bridge on ahci0 ... ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST320LT000-9VL142 0003LVM1 ATA-8 SATA 2.x device ada0: Serial Number W0Q06E4A ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 1H 63S/T 16383C) ada0: quirks=0x14K ada0: Previously was known as ad4 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: AHCI SGPIO Enclosure 1.00 0001 SEMB S-E-S 2.00 device ses0: SEMB SES Device -- John Baldwin ___ 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 Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: On 5 May 2014 13:57, John Baldwin j...@freebsd.org wrote: The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) Hm. Sounds uncomfortable. How does Windows run on systems like this? Do the windows drivers just disable HPET and use LAPIC or worse for timing, and just ignore anything lower than C1? I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems works if you use it sparingly. I believe OS X might have only used the HPET to provide the missing LAPIC wakeups when entering Cx for example. (Our current eventtimer system wants to always use whichever timer it picks, not switch off between them.) -- John Baldwin ___ 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 Tuesday, May 06, 2014 6:15:46 pm Ian Lepore wrote: On Tue, 2014-05-06 at 16:37 -0400, John Baldwin wrote: On Tuesday, May 06, 2014 2:08:35 pm Adrian Chadd wrote: On 5 May 2014 13:57, John Baldwin j...@freebsd.org wrote: The user in question found this on 9-stable with the existing defaults as the HPET was just plain broken on their system and that was unrelated to Cx states. (Rather, Cx states were only involved because worries about them are why the system chose to use HPET. Had Cx states been enabled by default, they would have had to disable those as well in addition to forcing LAPIC instead of HPET.) Hm. Sounds uncomfortable. How does Windows run on systems like this? Do the windows drivers just disable HPET and use LAPIC or worse for timing, and just ignore anything lower than C1? I have no idea. Maybe they use the RTC. :-/ Maybe the HPET on these systems works if you use it sparingly. I believe OS X might have only used the HPET to provide the missing LAPIC wakeups when entering Cx for example. (Our current eventtimer system wants to always use whichever timer it picks, not switch off between them.) The eventtimer code is happy to switch between timers on the fly, but iirc the only interface to that feature is sysctl. I found it fairly easy to add an in-kernel API for changing the frequency of the current timer on the fly. I think it would be just as easy to add a kernel call to change timers as well. Ah. Well, if it's only a small slice of time where machines need this, I'd be fine with those machines just having to disable C1E and forcing use of LAPIC rather than adding a lot of goop to do LAPIC + HPET and then hoping the HPET works well enough. -- John Baldwin ___ 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 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
real memory = 2147483648 (2048 MB)
avail memory = 2007138304 (1914 MB)
Event timer LAPIC quality 400
ACPI APIC Table: LENOVO TP-7L
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)
--
John Baldwin
___
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 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
real memory = 2147483648 (2048 MB)
avail memory = 2007138304 (1914 MB)
Event timer LAPIC quality 400
ACPI APIC Table: LENOVO TP-7L
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.)
--
John Baldwin
___
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 Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote:
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
real memory = 2147483648 (2048 MB)
avail memory = 2007138304 (1914 MB)
Event timer LAPIC quality 400
ACPI APIC Table: LENOVO TP-7L
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.
Humm. I wonder if we can get the Intel guys to accept the patch upstream?
--
John Baldwin
___
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 Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote:
On 2014-05-28 12:20:24 -0400, John Baldwin wrote:
On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote:
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM AMD
Features2=0x1LAHF TSC: P-state invariant,
performance statistics real memory = 2147483648
(2048 MB) avail memory = 2007138304 (1914 MB) Event
timer LAPIC quality 400 ACPI APIC Table: LENOVO
TP-7LFreeBSD/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.
Humm. I wonder if we can get the Intel guys to accept the patch
upstream?
Yes, ACPICA guys are very open to patches. Actually there are several
ways to report bugs and/or submit patches.
Bug reports:
https://bugs.acpica.org
Developer ML:
https://lists.acpica.org/mailman/listinfo/devel
Source repository:
https://github.com/acpica/acpica
However, I'm afraid the following commit may have nullified your patch.
https://github.com/acpica/acpica/commit/8149df49
It looks to only be adjusting the preference for the Address portion.
It still uses the length field from FADT and doesn't use the length
from the GAS.
--
John Baldwin
___
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 Wednesday, May 28, 2014 2:16:03 pm Jung-uk Kim wrote:
On 2014-05-28 13:44:46 -0400, John Baldwin wrote:
On Wednesday, May 28, 2014 12:44:44 pm Jung-uk Kim wrote:
On 2014-05-28 12:20:24 -0400, John Baldwin wrote:
On Wednesday, May 28, 2014 12:10:55 pm Sean Bruno wrote:
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM AMD
Features2=0x1LAHF TSC: P-state invariant,
performance statistics real memory = 2147483648
(2048 MB) avail memory = 2007138304 (1914 MB)
Event timer LAPIC quality 400 ACPI APIC Table:
LENOVO TP-7LFreeBSD/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.
Humm. I wonder if we can get the Intel guys to accept the
patch upstream?
Yes, ACPICA guys are very open to patches. Actually there are
several ways to report bugs and/or submit patches.
Bug reports: https://bugs.acpica.org
Developer ML: https://lists.acpica.org/mailman/listinfo/devel
Source repository: https://github.com/acpica/acpica
However, I'm afraid the following commit may have nullified your
patch.
https://github.com/acpica/acpica/commit/8149df49
It looks to only be adjusting the preference for the Address
portion. It still uses the length field from FADT and doesn't use
the length from the GAS.
Okay.
BTW, I just read your patch carefully but I failed to understand how
shutting up a warning can fix any problem at all. Did you mean to
patch internal table?
It shuts up the second warning. The first warning is still legit (there is a
length mismatch), but it handles the special case of the 32-bit length being
zero by using the 64-bit length. Once a valid length is set, the second
warning goes away (and GPE1 works which apparently fixes resume for Sean).
--
John Baldwin
Re: Investigating failed suspend/resume T61
On Wednesday, May 28, 2014 6:14:34 pm Jung-uk Kim wrote:
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)? Perhaps _PTS wants to frob
something that uses GPE1 that this fixes?
static void
AcpiTbValidateFadt (
void)
{
...
UINT8 Length;
...
for (i = 0; i ACPI_FADT_INFO_ENTRIES; i++)
{
...
Length = *ACPI_ADD_PTR (UINT8,
AcpiGbl_FADT, FadtInfoTable[i].Length);
...
Note the Length is read from the internal FADT and it is NOT a pointer.
...
if (Address64-Address
(ACPI_MUL_8 (Length) = ACPI_UINT8_MAX)
(Address64-BitWidth != ACPI_MUL_8 (Length)))
{
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);
+ }
}
...
}
}
AFAICT, it does change anything in AcpiGbl_FADT. If you really wanted
to patch it, you had to do something like this:
+ if (Length == 0)
+ {
+ Length = ACPI_DIV_8 (Address64-BitWidth);
+ *ACPI_ADD_PTR (UINT8,
+ AcpiGbl_FADT, FadtInfoTable[i].Length) = Length;
+ }
However, it had to be done from AcpiEvGpeInitialize() in
sys/contrib/dev/acpica/components/events/evgpeinit.c, IMHO.
ACPI_STATUS
AcpiEvGpeInitialize (
void)
{
...
if (AcpiGbl_FADT.Gpe1BlockLength
HERE!!!
AcpiGbl_FADT.XGpe1Block.Address)
{
...
What did I miss?
Nothing, I've no idea how this could possibly have affected suspend/resume on
Sean's laptop then. Maybe it was just a coincidence.
--
John Baldwin
___
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 messages on Lenovo W540
On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: Hello, I'm trying to set up on a lenovo W540 mobile workstation I recently purchased. Things work well for the most part (including suspend/resume), however there's some error messages that I suspect are at the root of why the nvidia Xorg driver doesn't work, and possibly also at the root of why USB 3.0 won't work either. At suspend/resume, the following error messages show up: pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: AE_BAD_PARAMETER I think these are harmless and you can ignore them. Probably these devices only support D0 (on) and D3 (off) and not D2 (low power). I suspect these might have something to do with the USB 3.0 system not working, though I don't have experience with either the ACPI or USB subsystems. Does it not work in general, or does it not work after resume? Also, the nvidia Xorg driver fails to work, and causes a similar error message: ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) (the same message gets repeated about 10 times) That is a very different error, but it might explain nvidia driver problems. The ACPI spec explains how _DSM works (there's an example method in section 9 of the 5.0 spec which you can get from acpi.info). In this case the warning is complaining that the return type is incorrect. Of course, the spec says that this function should return a Buffer, but ACPICA seems to think it should return a Package. It would be good to track down which specific arguments were passed to _DSM and then examine the acpidump to see which path that would take. -- John Baldwin ___ 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: powerd stopped working after update from 8.4 to 9.2
On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: John Baldwin wrote: On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: Hi, powerd doesn't work anymore after the update from 8.4 to 9.2. The system has an old (more than 10 years) mainboard with Via KT133 chipset. I made a verbose boot with both, 8.4 and 9.2: 8.4: http://pastebin.com/iiZXRXgK 9.2: http://pastebin.com/sHcd3MHv The relevant part of the diff seem to be these parts: viapropm0: SMBus I/O base at 0x5000 viapropm0: SMBus I/O base at 0x5000 viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 -viapropm0: SMBus revision code 0x40 -smbus0: System Management Bus on viapropm0 -smb0: SMBus generic I/O on smbus0 +viapropm0: could not allocate bus space +device_attach: viapropm0 attach returned 6 […] acpi_throttle0: ACPI CPU Throttling on cpu0 -acpi_throttle0: P_CNT from P_BLK 0x4010 +acpi_throttle0: failed to attach P_CNT +device_attach: acpi_throttle0 attach returned 6 Any ideas what I can do? acpi_timer0 also failed to probe due to a resource issue. Can you get the output of 'devinfo -rv' and 'devinfo -u' from the both kernels? Yes, no problem. devinfo -rv: 8.4: http://pastebin.com/6xm1tBrU 9.2: http://pastebin.com/whXk32Ab devinfo -u: 8.4: http://pastebin.com/47U7HZb3 9.2: http://pastebin.com/U85HTw0C thanks for your help, Hilko Can you provide your acpidump? This box seems confusing. -- John Baldwin ___ 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 messages on Lenovo W540
On Monday, June 23, 2014 6:42:28 pm Eric McCorkle wrote: On 06/23/2014 09:53, John Baldwin wrote: On Tuesday, June 17, 2014 9:54:57 am Eric McCorkle wrote: I suspect these might have something to do with the USB 3.0 system not working, though I don't have experience with either the ACPI or USB subsystems. Does it not work in general, or does it not work after resume? Actually, USB seems to be working quite well. It even detects an already plugged-in mouse during the ith resume. The sign of trouble are some messages that show up during resume: usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) ugen0.2: Unknown at usbus2 (disconnected) uhub_reattach_port: could not allocate new device There had been some timeout messages, which googling seemed to implicate was a USB 3.0 issue with lenovos, but those seem to have disappeared (I did do a kernel update). Maybe I should test USB 3.0-specific features to see if they are working. Unfortunately, I'm not that familiar with the gritty details of USB. Any ideas for how to do that? There was a recent fix to acpi_pwrres.c that fixed USB issues on resume for several ThinkPads because the kernel wasn't properly turning certain things back on during resume, so if your problems were only with resume, then there's a good chance they should now be fixed (and it sounds like they did after you updated). Also, the nvidia Xorg driver fails to work, and causes a similar error message: ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], APCI requires [Package] (20130823/nsarguments-97) (the same message gets repeated about 10 times) That is a very different error, but it might explain nvidia driver problems. The ACPI spec explains how _DSM works (there's an example method in section 9 of the 5.0 spec which you can get from acpi.info). In this case the warning is complaining that the return type is incorrect. Of course, the spec says that this function should return a Buffer, but ACPICA seems to think it should return a Package. It would be good to track down which specific arguments were passed to _DSM and then examine the acpidump to see which path that would take. I looked at acpidump, and I was able to find the definition of _DSM. Is there a way to get better ACPI debugging info out of the kernel (aside from adding debug messages directly)? Probably not in this case, though just looking at the source of the _DSM method might be a start. However, re-reading this warning (and checking the source), the problem is not in the _DSM method, but in some code calling the _DSM method. Are there any calls to _DSM in your acpidump? Ah, the nvidia driver calls _DSM and it has the bug. In its nvidia_acpi.c file it uses a Buffer instead of a Package for the fourth argument to _DSM. OTOH, the warning doesn't prevent the method from running, so the warning may be harmless. You can try contacting the nvidia folks to tell them about the warning and point out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say. -- John Baldwin ___ 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: powerd stopped working after update from 8.4 to 9.2
On Tuesday, June 24, 2014 1:36:41 pm Hilko Meyer wrote:
On Tue, 24 Jun 2014 10:26:52 -0400, you wrote:
On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote:
John Baldwin wrote:
On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote:
powerd doesn't work anymore after the update from 8.4 to 9.2. The system
has an old (more than 10 years) mainboard with Via KT133 chipset.
I made a verbose boot with both, 8.4 and 9.2:
8.4: http://pastebin.com/iiZXRXgK
9.2: http://pastebin.com/sHcd3MHv
The relevant part of the diff seem to be these parts:
viapropm0: SMBus I/O base at 0x5000
viapropm0: SMBus I/O base at 0x5000
viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at
device 7.4 on pci0
-viapropm0: SMBus revision code 0x40
-smbus0: System Management Bus on viapropm0
-smb0: SMBus generic I/O on smbus0
+viapropm0: could not allocate bus space
+device_attach: viapropm0 attach returned 6
[
]
acpi_throttle0: ACPI CPU Throttling on cpu0
-acpi_throttle0: P_CNT from P_BLK 0x4010
+acpi_throttle0: failed to attach P_CNT
+device_attach: acpi_throttle0 attach returned 6
Any ideas what I can do?
acpi_timer0 also failed to probe due to a resource issue. Can you get the
output of 'devinfo -rv' and 'devinfo -u' from the both kernels?
Yes, no problem.
devinfo -rv:
8.4: http://pastebin.com/6xm1tBrU
9.2: http://pastebin.com/whXk32Ab
devinfo -u:
8.4: http://pastebin.com/47U7HZb3
9.2: http://pastebin.com/U85HTw0C
thanks for your help,
Hilko
Can you provide your acpidump? This box seems confusing.
Well, its quite old. An Epox 8kta3 from around 2002. I was not sure which
output
you need so I attached acpidump -d and acpidump -dt.
Ok, try this:
Index: sys/dev/acpica/acpi.c
===
--- acpi.c (revision 267784)
+++ acpi.c (working copy)
@@ -1196,15 +1196,24 @@ acpi_set_resource(device_t dev, device_t child, in
return (0);
/*
- * Ignore memory resources for PCI root bridges. Some BIOSes
+ * Ignore most resources for PCI root bridges. Some BIOSes
* incorrectly enumerate the memory ranges they decode as plain
- * memory resources instead of as a ResourceProducer range.
+ * memory resources instead of as ResourceProducer ranges. Other
+ * BIOSes incorrectly list system resource entries for I/O ranges
+ * under the PCI bridge. Do allow the one known-correct case on
+ * x86 of a PCI bridge claiming the I/O ports used for PCI config
+ * access.
*/
-if (type == SYS_RES_MEMORY) {
+if (type == SYS_RES_MEMORY || type == SYS_RES_IOPORT) {
if (ACPI_SUCCESS(AcpiGetObjectInfo(ad-ad_handle, devinfo))) {
if ((devinfo-Flags ACPI_PCI_ROOT_BRIDGE) != 0) {
- AcpiOsFree(devinfo);
- return (0);
+#if defined(__i386__) || defined(__amd64__)
+ if (!(type == SYS_RES_IOPORT start == CONF1_ADDR_PORT))
+#endif
+ {
+ AcpiOsFree(devinfo);
+ return (0);
+ }
}
AcpiOsFree(devinfo);
}
--
John Baldwin
___
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: powerd stopped working after update from 8.4 to 9.2
On Wednesday, June 25, 2014 8:03:58 am Hilko Meyer wrote: John Baldwin schrieb: On Tuesday, June 24, 2014 1:36:41 pm Hilko Meyer wrote: On Tue, 24 Jun 2014 10:26:52 -0400, you wrote: On Monday, June 23, 2014 7:12:23 pm Hilko Meyer wrote: John Baldwin wrote: On Sunday, June 22, 2014 9:27:08 pm Hilko Meyer wrote: powerd doesn't work anymore after the update from 8.4 to 9.2. The system has an old (more than 10 years) mainboard with Via KT133 chipset. I made a verbose boot with both, 8.4 and 9.2: 8.4: http://pastebin.com/iiZXRXgK 9.2: http://pastebin.com/sHcd3MHv The relevant part of the diff seem to be these parts: viapropm0: SMBus I/O base at 0x5000 viapropm0: SMBus I/O base at 0x5000 viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 -viapropm0: SMBus revision code 0x40 -smbus0: System Management Bus on viapropm0 -smb0: SMBus generic I/O on smbus0 +viapropm0: could not allocate bus space +device_attach: viapropm0 attach returned 6 […] acpi_throttle0: ACPI CPU Throttling on cpu0 -acpi_throttle0: P_CNT from P_BLK 0x4010 +acpi_throttle0: failed to attach P_CNT +device_attach: acpi_throttle0 attach returned 6 Any ideas what I can do? acpi_timer0 also failed to probe due to a resource issue. Can you get the output of 'devinfo -rv' and 'devinfo -u' from the both kernels? Yes, no problem. devinfo -rv: 8.4: http://pastebin.com/6xm1tBrU 9.2: http://pastebin.com/whXk32Ab devinfo -u: 8.4: http://pastebin.com/47U7HZb3 9.2: http://pastebin.com/U85HTw0C thanks for your help, Hilko Can you provide your acpidump? This box seems confusing. Well, its quite old. An Epox 8kta3 from around 2002. I was not sure which output you need so I attached acpidump -d and acpidump -dt. Ok, try this: Index: sys/dev/acpica/acpi.c The patch doesn't apply. Was it for head or 9-stable and not for 9.2? It is for HEAD though it should apply to 9-stable. It might not apply to 9.2 as it patches a previous fix that went to 9.2. For 9.2, please merge the change to stable/9 from http://svnweb.freebsd.org/base?view=revisionrevision=263022 first and then apply this patch. -- John Baldwin ___ 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: powerd stopped working after update from 8.4 to 9.2
On Wednesday, June 25, 2014 3:48:07 pm Hilko Meyer wrote: On Wed, 25 Jun 2014 10:17:31 -0400, John Baldwin wrote: It is for HEAD though it should apply to 9-stable. It might not apply to 9.2 as it patches a previous fix that went to 9.2. For 9.2, please merge the change to stable/9 from http://svnweb.freebsd.org/base?view=revisionrevision=263022 first and then apply this patch. Thanks for the patch. Works now. Diff to the verbose dmesg without your patch: -acpi_timer0: couldn't allocate resource (port 0x4008) +ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 - 10 +Timecounter ACPI-fast frequency 3579545 Hz quality 900 +acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 [...] -pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 +pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 [...] viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 -viapropm0: could not allocate bus space -device_attach: viapropm0 attach returned 6 +viapropm0: SMBus revision code 0x40 +smbus0: System Management Bus on viapropm0 +smb0: SMBus generic I/O on smbus0 [...] acpi_throttle0: ACPI CPU Throttling on cpu0 -acpi_throttle0: failed to attach P_CNT -device_attach: acpi_throttle0 attach returned 6 +acpi_throttle0: P_CNT from P_BLK 0x4010 I could start powerd again. Thanks for your help, Hilko PS: Just for the record, output of dmesg and devinfo from the working system with your patch: devinfo -rv: http://pastebin.com/whga6mxc devinfo -u: http://pastebin.com/xQLdCWTz dmesg -v : http://pastebin.com/jtLmsJzs Committed to HEAD. It won't make 9.3 release, but it should be in 10.1. Thanks for the report and for testing! -- John Baldwin ___ 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 X61s suspend/resume status
On Thursday, September 18, 2014 05:30:17 PM Sevan / Venture37 wrote: Hi, Following the thread on getting resume working on the T61[1], I factory reset my BIOS once more but this time confirmed the modem was enabled. Resuming then worked fine on 11-CURRENT r270990 AMD64. hw.acpi.reset_video=1 needs to be set otherwise system resumes without switching the system back on. You only need reset_video with syscons, correct? With vt i915kms, when the system goes to sleep, it reports (trimmed): pci5: failed to set ACPI power state D2 on \134_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP0: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER acpi0: cleared fixed power button status and when it wakes, it reports uhci_interrupt: resume detect error: [drm:pid786:intel_lvds_enable] *ERROR* timed out waiting for panel to power off I get the panel error on resume everytime on my x220, but it still works fine. With sys cons, , when the system goes to sleep, it reports: pci5: failed to set ACPI power state D2 on \_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP0: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER acpi0: cleared fixed power button status I've not had a chance to test X or the USB ports. To be clear, is it resuming ok in all of your tests, just logging these messages? I think you can ignore the mesages about power states and the panel power off error. -- John Baldwin ___ 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 X61s suspend/resume status
On Friday, September 19, 2014 10:39:26 PM Sevan / Venture37 wrote: On 19 Sep 2014, at 16:25, John Baldwin j...@freebsd.org wrote: On Thursday, September 18, 2014 05:30:17 PM Sevan / Venture37 wrote: Hi, Following the thread on getting resume working on the T61[1], I factory reset my BIOS once more but this time confirmed the modem was enabled. Resuming then worked fine on 11-CURRENT r270990 AMD64. hw.acpi.reset_video=1 needs to be set otherwise system resumes without switching the system back on. You only need reset_video with syscons, correct? I get the panel error on resume everytime on my x220, but it still works fine. Ok To be clear, is it resuming ok in all of your tests, just logging these messages? I think you can ignore the mesages about power states and the panel power off error. Yes, system is working fine, when I get a chance to install X, I'll post a followup, hopefully before eurobsdcon. If things go as planned I should be able to test on a X60s next. If you have a wiki account, can you create a page for your laptops at https://wiki.freebsd.org/Laptops If not, let me know what works/doesn't so I can add a page for your models (or lets get you setup with a wiki account) -- John Baldwin ___ 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: intel NUC dn2820 hardware bios issue
On Monday, October 06, 2014 11:13:52 AM Mark Edwards wrote: please see my notes at freenas. https://bugs.freenas.org/issues/6265 kudos to you all This was not fixed by the PR you mentioned. This was fixed in this commit: https://svnweb.freebsd.org/base?view=revisionrevision=228110 Which has not been merged to 9. -- John Baldwin ___ 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 X61s suspend/resume status
On Monday, October 20, 2014 5:51:26 pm Sevan / Venture37 wrote: On 15/10/2014 02:12, Sevan / Venture37 wrote: X60s works as x61s though I haven't tried switching off the modem on the X60s, will update the wiki in the next week. So I reflashed the X60s with the coreboot/SeaBIOS, just tried booting FreeBSD-11.0-CURRENT-i386-20140918-r271779-mini-memstick.img on it. It sleeps wakes just fine. When it wakes all the USB ports are reprobed, the USB stick is found but a error message is listed vnode_pager_getpages: I/O read error then everything detaches re-attaches. It's not possible to execute new commands that aren't cached from previous attempt before sleep. If you try the console is filled with vnode_pager_getpages: I/O read error messages. Maybe this is only an issue as I'm booting from USB wouldn't be a problem from disk? I suspect that booting from disk would not have the same issue, yes. -- John Baldwin ___ 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: ENXIOing non-present battery
On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote: Hi ACPI people, On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First the battery which exists; and second, a Not Present battery with zeroed statistics. FreeBSD, not realizing that this second battery is a complete myth -- the E7440 only has one battery, and there is nowhere to add another -- faithfully reports the data from ACPI to userland. Unfortunately it causes some problems there; in particular, KDE interprets it as meaning that the system should have two batteries, and when it sees that the second battery has 0% power remaining it kicks off the battery is low, turn the laptop off code. If that code is disabled, it still displays the wrong battery-charge-remaining status icons. For dealing with such broken ACPIs, it seems like not attaching a non-present battery would be a good idea. This shouldn't be the default behaviour, since there are plenty of systems where a non-present battery might be inserted at a later time; but I see nothing wrong with adding an option. The attached patch adds a acpi.cmbat.hide_not_present loader tunable which, as the name suggests, hides non-present batteries; this is done in the probe code by returning ENXIO if the tunable is set to a nonzero value and acpi_BatteryIsPresent returns zero. With this patch and the tunable set my laptop behaves appropriately; and (aside from wasting a few bytes of memory) there should be no effect on systems where the tunable is not set. Any objections to me committing this? Does setting hint.battery.1.disabled=1 work for you? -- John Baldwin ___ 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: ENXIOing non-present battery
On Thursday, December 11, 2014 01:05:49 PM Colin Percival wrote: On 12/11/14 11:08, John Baldwin wrote: On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote: On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First the battery which exists; and second, a Not Present battery with zeroed statistics. FreeBSD, not realizing that this second battery is a complete myth -- the E7440 only has one battery, and there is nowhere to add another -- faithfully reports the data from ACPI to userland. Does setting hint.battery.1.disabled=1 work for you? That fixes the dev.battery sysctls and KDE's battery monitor. The hw.acpi.battery.units sysctl still reports 2, and `acpiconf -i 1` still reports the phantom battery; but I suppose those don't matter much... Ok. That is the generic thing we already have in place to disable devices, so I'd probably prefer to use that as the known workaround rather than adding another knob. That said, it looks like we report the userland state of not present correctly. I wonder if the bug is in KDE itself and its FreeBSD-specific power management bits (rather than hald)? -- John Baldwin ___ 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: Lenovo T520: Present (-STABLE) vs. Future (-CURRENT) ACPI Support
On Sunday, January 18, 2015 11:20:21 pm Adrian Chadd wrote: hm, someone just needs to do the MFC. I don't have stable/10 on any laptop, so I'd be doing it blind. I think most of these types of MFCs are blind as most of the folks testing it in HEAD are running HEAD. Would someone with stable/10 please MFC 270516 from HEAD? Pretty please? Eh, you can always use a VM to test the 10 build if you wish, but since you committed this head, you should just MFC it to 10. You've already gotten one confirmation by a user reporting that it works fine when merged, so I think that is ample. -- John Baldwin ___ 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: Fwd: Activating Suspend/Resume on FreeBSD 10.1
On Friday, January 30, 2015 12:37:10 pm Kevin Oberman wrote: My experience is the opposite. With KMS I could run with VESA and without it I needed to pull VESA from my kernel. As of today I am running fine with KMS, i915, and vt(4) with a standard GENERIC 10-STABLE kernel. I was running KMS and vt(4) well before they were MFCed, so I don't remember when I stopped adding nooptions VESA, but I definitely used to need it to make suspect/resume work and don't any longer. In any case, trying kernel without VESA is a good idea. FYI, VESA only applies to sc(4). It is ignored for vt(4). That is why it works with vt(4). -- John Baldwin ___ 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: How to know the system state if the system is going for halt or poweroff or reboot in FreeBSD
On Thursday, March 26, 2015 01:54:45 AM Sibananda Sahu wrote:
My requirement is to know the exact reason of shutdown, whether is it a
power-off or a reboot call.
And I can get the information from the “howto” variable that is passed to
the kern_reboot() function call, but this variable is local to
kern_reboot() only.
It is passed to the shutdown_* eventhandlers. So if you register an
eventhandler
you can get the howto argument that way. ACPI uses this to power off the
machine
for a power off request for example:
static void
acpi_shutdown_final(void *arg, int howto)
{
...
if ((howto RB_POWEROFF) != 0) {
status = AcpiEnterSleepStatePrep(ACPI_STATE_S5);
}
--
John Baldwin
___
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 problems op ASrock
On Saturday, September 26, 2015 10:17:20 AM Arthur van der Peijl wrote: > Thank you for assistance: powerd must clearly not be my focus: the CPU stays > high and thus cannot go into idle mode. Yes, I don't think tcc or throttling is related here. Your issue is that something is queueing tasks to the ACPI task queue threads (or a task is getting stuck in a busy loop). AFAIK there isn't really a great way currently to see which tasks are being queued to a taskqueue and how long they are running. It might be a nice thing to add some KTR traces for, to log how long tasks run on a given taskqueue thread (I added something a while back for callouts so they show up in schedgraph with the function pointer and you can then use a debugger to map that pointer to a symbol name). As an initial guess you might try identifying tasks that can be queued and adding some stat counters exported via sysctl for different functions. -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: boot process is freez on Intel S1200RP Board
On Saturday, August 29, 2015 07:55:49 PM Vladimir Laskov wrote: > Hello, All. > > I have a problem on Intel S1200RP Board. > > boot process is freez on boot stage > > how to repeat? > > 1. launch system reboot > 2. wait to start kernel initialization stage > 3. system freez on kernel initialization stage > > screenshot here > http://oi62.tinypic.com/33d8jz5.jpg > > please help me > > P.S. - if i reset system and boot linux, freebsd start without freez This might be fixed by this commit: https://svnweb.freebsd.org/base?view=revision=299977 -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI display brightness control not detected
On Sunday, June 18, 2017 01:41:56 PM Hans Petter Selasky wrote: > Hi, > > I've dumped the relevant ACPI tables below. Does anyone know why the > parsing of the ACPI DOD fails in acpi_video.c ? > > Any patch suggestions? First, do you know what error you get when it fails? (I.e. what is the status value from the ACPICA method) -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: [Bug 220096][PATCH] acpi_thermal: Fix a possible sleep-under-mutex bug in acpi_tz_thread
On Sunday, June 18, 2017 05:52:45 PM Jia-Ju Bai wrote: > The driver may sleep under a mutex, and the code path is: > acpi_tz_thread [line 992: acquire the mutex] > acpi_tz_thread [line 993] > acpi_tz_thread [line 1003] > acpi_tz_thread [line 1004] (msleep is excuted) > acpi_tz_thread [line 1008] > acpi_tz_thread [line 970] > acpi_tz_thread [line 971] > acpi_tz_thread [line 975] >malloc(M_WAITOK) [line 976] > > The possible fix of this bug is to replace "M_WAITOK" in malloc with > "M_NOWAIT". > > This bug is found by a static analysis tool written by myself, and it is > checked by my review of the FreeBSD code. > > Signed-off-by: Jia-Ju Bai <baijiaju1...@163.com> > --- > sys/dev/acpica/acpi_thermal.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c > index b2b2a13aa88..fb9f44b5711 100644 > --- a/sys/dev/acpica/acpi_thermal.c > +++ b/sys/dev/acpica/acpi_thermal.c > @@ -974,7 +974,7 @@ acpi_tz_thread(void *arg) > } > devclass_get_devices(acpi_tz_devclass, , ); > sc = malloc(sizeof(struct acpi_tz_softc *) * devcount, M_TEMP, > - M_WAITOK | M_ZERO); > + M_NOWAIT | M_ZERO); > for (i = 0; i < devcount; i++) > sc[i] = device_get_softc(devs[i]); > } As noted in the followup to the PR, the lock is never held when malloc is called because msleep() uses PDROP. The malloc is safe to stay as M_WAITOK. -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
