Re: [PATCH] Abort powerd when no cpufreq(4) support is found
The message is fine, but I think an error code of 0 is wrong. Powerd didn't start, whereas 0 means the daemon launched successfully. On Apr 9, 2012, at 2:11 AM, Robert Millan wrote: Hi, I'd like to check-in this patch so that powerd aborts gracefully when there's no cpufreq(4) support for the CPU in which it is running. Does this look alright? -- Robert Millan no_cpufreq.diff ___ 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: paper on reverse-engineering drivers
On 5/26/2011 1:19 PM, Andriy Gapon wrote: on 26/05/2011 22:25 Nate Lawson said the following: This might be a useful source for making ACPI compatible with Windows. http://dslab.epfl.ch/pubs/revnic I had thought of a project like this before. My idea was to take QEMU and map PCI config space and allow direct access to the bare hardware for only one device. The developer would install Windows in this QEMU image on a system with the target device, identify it by its PCI id, and then run Windows normally. The VM would log the driver's accesses to config space as well as use CoW semantics for DMA accesses to memory and IO ports. Something like this? http://www.serialice.com/News/News.html Now that Intel/AMD support hardware virtualization and DMA isolation, it would be better to do this with a modified Xen hypervisor. Yes, that is a nice project but requires flashing firmware. With hardware virtualization you can trap all IO accesses and do this in software. -- Nate ___ 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/6/2011 1:00 PM, John Baldwin wrote: On Monday, March 28, 2011 2:06:27 pm John Baldwin wrote: 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. Ok, so I have a patch to rework how PCI-PCI bridges manage resources for devices. This patch applies to HEAD, no idea if it applies to older branches (likely not). You will need to add the option 'NEW_PCIB' to your kernel config after applying this patch. http://www.FreeBSD.org/~jhb/patches/pcib_new.patch For my local testing I used a hack to wipe out the PCI-PCI bridges in my test machine similar to what the BIOS does on these machines. The bridges all grew windows to match their original BIOS-assigned windows based on the BIOS-assigned resources in the BARs of the child devices. These patches should also let us allocate new resources from scratch for devices behind PCI-PCI bridges once we have better support for determining what are valid PCI address ranges in the Host-PCI bridge drivers. 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? -- Nate ___ 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
Don't thank me, thank John Baldwin. Glad it works! On 4/6/2011 3:43 PM, Sergio de Almeida Lenzi wrote: Great work Nate now I know I will have a chance for my notebook acer5050... I tested the patch in the 8.2 version 4bits and it worked (patch done) all exept for the ftd device (that does not have in the 8.2).. Thanks ___ 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: pci buses missing from suspend/resume powerstate
On 4/2/2011 2:34 PM, J.R. Oldroyd wrote: On Sat, 2 Apr 2011 11:29:58 -0400, J.R. Oldroyd f...@opal.com wrote: [suspend/resume of network cards] pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 scpm0 acpi_video0 drm0 hdac1 pcm2 pcib2 pci2 ath0 pcib3 pci3 re0 miibus0 rgephy0 ... I had been working from this: on suspend: kernel: pci0:1:5:0: Transition from D0 to D3 # vgapci kernel: pci0:1:5:1: Transition from D0 to D3 # hdac1 kernel: pci0:2:0:0: Transition from D0 to D3 # ath0 kernel: pci0:3:0:0: Transition from D0 to D3 # re0 kernel: pci0:0:18:2: Transition from D0 to D3 # ohci0 kernel: pci0:0:19:2: Transition from D0 to D3 # ohci1 kernel: pci0:0:20:2: Transition from D0 to D3 # hdac0 but on resume, only: kernel: pci0:0:18:2: Transition from D3 to D0 kernel: pci0:0:19:2: Transition from D3 to D0 which had led me to think the buses were not being resumed. Looking further at this, two things come to light: - they ARE being suspended using set_powerstate to D3, but after the resume, their powerstate still shows as D0, so set_powerstate is not being re-invoked to actually set D0 again - the PCI-PCI bridges pcib1, pcib2, pcib3 have hdrtype==1 and so are also excluded from the set_powerstate (don't know if that's OK or not) But, overriding those checks and forcing set_powerstate D0 to be invoked for all devices still doesn't get ath0 or re0 working after the resume. I have an older but similar laptop model with the same configuration of ath0 and re0 also on secondary PCI buses pci2 and pci3 and that one does suspend/resume properly. But on the newer laptop: kernel: ath0: unable to reset hardware; hal status 3 kernel: re0: reset never completed! kernel: re0: PHY write failed last message repeated 4 times So this problem is specific to this newer hardware. Perhaps related to the PCI-PCI bridges? pcib2 and pcib3 are both devid=96xx1022... perhaps some odd quirk handling is needed here? I suspect something in the ASL is different. -- Nate ___ 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: ideas for _PSD/_CSD/_TSD
On 11/18/2010 11:09 AM, Andriy Gapon wrote: I am trying to solicit some architectural/design ideas for implementing logic that would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains. Well, I am primarily interested in _PSD, but I think that some general principles could be shared. In simple terms. Currently we do only the global P-state management. cpufreq advertises a common set of frequencies/P-states and a single P-state/frequency is set on all (logical) processors by e.g. powerd based on global system load. The downsides are obvious, I think. Modern systems can provide _PSD method which describes grouping of logical processors into P-state domains and nature of dependency between the processors in the domain. E.g. on some systems putting a single processor from the domain into a Px state results in all the processors being put into that state. On other systems, all processors have to be put into the same state for it to become effective. On yet other systems there could be no coordination required between the processors (even when they are all cores in the same package), so each would be placed in its own domain. I think that this issue may get more prominence because of the new technologies that combine power saving with turbo boosting. E.g. there could be a technology where some processor's performance would only be boosted if other processors are at or above some state Pt. With current cpufreq design we would not be able to take an advantage of that, because we always put all the processors into the same state. As you can see from the codebase, cpufreq was designed with this model in mind. I spent a lot of work adding the cpu devices to newbus in order to have cpufreq attach per-cpu. Each instance has its own dev.cpu.X.freq setting. Of course, there weren't any asymmetrical CPU Px states back then so calculation of levels is shared as you point out. But since it's done in cpufreq attach(), it is easy to make that independent while still merging states with global settings (e.g., p4tcc relative levels that apply system-wide, not per-cpu). What you want is to have a flag that indicates if Px states are global or not. If global, you can still attach a cpufreq device to each cpu but make changing any of their settings loop through changing all cpu settings equally. This is how it currently works. If the flag is false, then only apply a setting to the device it was received on. -- Nate ___ 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 10/28/2010 9: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. Fine with me. Users will still be able to disable ACPI if they want. And systems that don't have ACPI (pre-2001) can still compile it out with nodevice to save a few 100 KB of RAM. There's no reason to keep it as a kernel module. -- Nate ___ 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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Andriy Gapon wrote: on 13/09/2010 20:07 Andriy Gapon said the following: I am also going to take a look how Linux and OpenSolaris name the C-states. Well, Linux does what you suggested, it uses index of a C-state as its name. There is one difference from our current code - if a C-state is skipped for some reason, then its index is not re-used, but the entry is marked as non-valid. So, if we skip C2 for some reason, then C3 will become C2. Not so on Linux. Also, they print a type/class of a C state using C1, C2, C3 and -- for higher/unknown types. Additionally, it seems that we do not currently have any support for Functional Fixed Hardware (FFH) way of providing C states. In this case _CST returns GAS of a register used to enter a C state with address space ID set to ACPI_ADR_SPACE_FIXED_HARDWARE (0x7f/127). Such addresses should be handled in a special way: ftp://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf Currently we simply (and silently) ignore such _CST entries. I think that this should be useful (if not necessary) with mwait. I added some FFHW support for ACPI P-states. You can see that in the cpufreq code or in the speedstep driver. -- Nate ___ 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
