- 27 Oct, 2004 15 commits
-
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest, and cleared some whitespace/tab confusion. The big comment regarding which frequency to pass as "old" value wasn't up to date any longer in two regards: the driver's behaviour had changed, and the core is know able to handle such things... anyways, the comment could be removed. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Modified existing dprintks and added a few which might be / have been of interest. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
cpufreq_debug_printk will print messages if a) debugging for the specified part is activated (add 1 for core, 2 for drivers, 4 for governors and pass value as cpufreq.debug=<value> on the kernel command line). b) and either b1) printk_ratelimit() allows it to be printed, b2) the user disables ratelimit'ing by passing cpufreq.debug_ratelimit=0 on the kernel command line, _or_ b3) during driver initialization [unless a different driver has been initialized successfully] and unloading, and whenever a new policy is set. The last point may cause for numerous messages if an userspace-based dynamic governor is used which mis-uses the policy interface to set specific frequencies. Oh, the ACPI processor.c interface to the file "performance" uses the same trick, but that interface is marked deprecated as well, so I don't care. And debugging isn't activated normally, you know... Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Clarify that cpufreq_set() and cpufreq_setmax() are parts of the 2.4. API to the userspace governor which will be removed soon after 2005-01-01. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
The "acpi" cpufreq driver uses the far too generic module name "acpi". Fix it by renaming it to "cpufreq-acpi". A MODULE_ALIAS("acpi"); will allow for backwards-compatible naming until 2005-06-30. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Thanks to Brian Miles for debugging this issue. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Some BIOSes export invalid _PSS entries where all bits are set to one. While this is totally contrary to the ACPI specification, BIOS vendors try to tell userspace that these entries should not be considered or used. In order to not fail on such entries, the speedstep-centrino already contains a method to ignore these things. However, due to a wrong ordering of checks the driver aborts nonetheless. So move some checks around. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
Dave Jones authored
Sometimes, a user or userspace daemon wants a specific frequency is set, but that frequency is (temporarily) unavailable or becomes unavailable due to e.g. thermal considerations. As soon as this situation changes, the user wish should be re-evaluated. The attached patch saves the user wish in "cpu_set_freq", and re-uses that whenever appropriate. Thanks to Thomas Renninger for testing. Signed-off-by: Dominik Brodowski <linux@brodo.de> Signed-off-by: Dave Jones <davej@redhat.com>
-
- 26 Oct, 2004 11 commits
-
-
bk://gkernel.bkbits.net/libata-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://gkernel.bkbits.net/net-drivers-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Andrew Morton authored
We decided to do this a different way. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Roland McGrath authored
In general it is not safe to do any non-ptrace wakeup of a thread in TASK_TRACED, because the waking thread could race with a ptrace call that could be doing things like mucking directly with its kernel stack. AFAIK noone has established that whatever clobberation ptrace can do to a running thread is safe even if it will never return to user mode, so we can't allow this even for SIGKILL. What we _can_ safely do is make a thread switching out of TASK_TRACED resume rather than sitting in TASK_STOPPED if it has a pending SIGKILL or SIGCONT. The following patch does this. This should be sufficient for the shutdown case. When killing all processes, if the tracer gets killed first, the tracee goes into TASK_STOPPED and will be woken and killed by the SIGKILL (same as before). If the tracee gets killed first, it gets a pending SIGKILL and doesn't wake up immediately--but, now, when the tracer gets killed, the tracee will then wake up to die. This will also fix the (same) situations that can arise now where you have used gdb (or whatever ptrace caller), killed -9 the gdb and the process being debugged, but still have to kill -CONT the process before it goes away (now it should just go away either the first time or when you kill gdb). Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This is a batch of sparse fixes for things in arch/ppc64/* and include/asm-ppc64/* More to come of course... Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
My latest 8250 patch prevented registration of "empty" ports (ports that have a 0 iobase in the static table). Unfortunately, some archs seem to rely on this, and so broke. This patch reverts that part of the patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This adds support for the Maple 970FX Eval Board. It adds the basic arch support. For the Maple to be fully functional, it needs a couple more patches to be applied for IDE and Ethernet that are currently pending with the respective maintainers of those subsystems. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
The iommu_free_table() patch broke g5 only build by adding back some incestuous relationship between generic code and pSeries code. This wraps this in #ifdef as a quick fix until the original author of the patch comes up with a better solution. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
On machines using the "ISU" mecanism for the MPIC, the new driver didn't properly calculate the new interrupt count when an ISU was added. That would cause later on failure to request interrupts in the offending range. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
The ppc64 PCI code, when parsing the OF tree, may end up getting empty regions in addition to the "normal" ones for the PHB (some pSeries OF device-tree contains weird "ranges" properties). These are harmless but do trigger some annoying warnings during boot, so let's ignore them. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 25 Oct, 2004 10 commits
-
-
Jeff Garzik authored
-
Arjan van de Ven authored
CONFIG_NET_HW_FLOWCONTROL is entirely unused now, and superceded by NAPI in practice, so remove the dead code Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Andrew Morton authored
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
-
Jeff Garzik authored
into pobox.com:/garz/repo/netdev-2.6/e1000-2
-
Andrew Morton authored
Fix for updated pci_{save,restore}_state() Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
-
Jeff Garzik authored
into pobox.com:/garz/repo/netdev-2.6/misc
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
bk://bk.skbuff.net:20610/linux-2.6-inet6-20041026/David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
- 26 Oct, 2004 4 commits
-
-
Hideaki Yoshifuji authored
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
-
Hideaki Yoshifuji authored
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
-
Hideaki Yoshifuji authored
Simplify ipv6_get_saddr(), ipv6_dev_get_saddr() and rt6_purge_dflt_routers(). Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
-
Hideaki Yoshifuji authored
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
-