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
[Bug 169862] [acpi] Prevent system sleep once shutdown has been initiated
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169862 Jung-uk Kim j...@freebsd.org changed: What|Removed |Added Assignee|j...@freebsd.org|freebsd-acpi@FreeBSD.org --- Comment #2 from Jung-uk Kim j...@freebsd.org --- Apparently, I don't have time for this. Sorry. -- You are receiving this mail because: You are the assignee for the bug. ___ 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 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. regards, Hilko acpidump-d.gz Description: Binary data acpidump-dt.gz Description: Binary data ___ 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
