We where trying to get pm-qos to work with a wireless driver and found that the idiom of passing the *dev in the callback (notification) parameters was not supported. This makes having drivers as clients of PM-QOS sort of a challenge. The driver writer would have to mimic code in md.c where it keeps a list of all its instances and iterates over each upon notifier callback. Not that difficult but as the driver writers are so accustomed to having there instance data passed to them by the callers it...

This patch fixes the issue described at Thanks, Rafael --

Hi friends, when I read sysrq-t call trace, I find the collected call trace for some cases is not a still snapshot, but a moving one. After checking show_state src, I realize other cpus are not frozen when one cpu is doing show_state; thus some task switching can occur among those cpus, even the cpu doing sysrq for some kind of kernels. This moving call traces make debugging much more difficult, or even impossible for some cases, since some tasks have been switched in/out which make us lose the ...

I really don't want to do this, and I was actually hoping to release 2.6.25 last weekend (which is why -rc9 is a few days late - just me hoping to not do another -rc at all), but I've done an -rc9. The changes in -rc9 are pretty small (shortlog appended), and 60% of them are m68k updates - mostly defconfigs. And some doc updates. But there's some network driver updates (tg3 and wireless hostap stand out), some late XFS patches and a mvsas driver update (the mvsas driver is new in 2.6.25, s...

Is it 100% reproducable? I mean sometimes I also have complete lockup right after one of eth interfaces shutdown during shutdown sequence. And it's also recent. But it triggers ~1 time in 10 subjectively.. --

After about 4 restarts and 4 reboots, 2.6.25-rc9 seems to work fine with and without the revert. I'll do some more testing. The assembly output files for kernel/printk.c don't seem that different between rc9 and rc7. I'll see what else I can test. Thanx --

This patch series (based on v2.6.25-rc8-mm2) has several improvements to the rfkill class that I need for thinkpad-acpi, plus two fluff and documentation fixes. I'd appreciate comments, and if the patches are acceptable, that they are sent to mainline early during the 2.6.26 merge window. That way, I could try for a thinkpad-acpi rfkill submission for 2.6.26 as well. The thinkpad-acpi work that needs these patches is ready, and can be looked at on the thinkpad-acpi git tree (devel branch): ht...

I know it is easier to complain than to submit code, but at this point, shouldn't we make this dynamic? [so that the interested technology that provides an rfkill switch registers it?]. Something that given a technology name registers a dynamic key and type number that can be use throughout? -- Inaky --

Currently, radios are always enabled when their rfkill interface is registered. This is not optimal, the safest state for a radio is to be offline unless the user turns it on. Add a module parameter that causes all radios to be disabled when their rfkill interface is registered. Add override parameters for each rfkill switch type as well, just in case the user wants the defaults to be different for a given radio type. We don't change the module default, but I'd really recommed doing so in a fu...

Add a RFKILL_TYPE_ANY switch. This switch can control more than one type of radio, and it is always subject to toggling by any type of rfkill-input event. It is suitable to implement kill-all-radios functionality when coupled with input event EV_SW SW_RADIO. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Dmitry Torokhov <dtor@mail.ru> --- include/linux/rfkill.h | 2...

Fix a minor typo in an exported function documentation Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: Dmitry Torokhov <dtor@mail.ru> --- net/rfkill/rfkill.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c index 140a0a8..1601e50 100644 --- a/net/rfkill/rfkill.c +++ b/net/rfkill/rfkill.c @@ -412,7 +412,7...

rfkill really should have been named rfswitch. As it is, one can get confused whether RFKILL_STATE_ON means the KILL switch is on (and therefore, the radio is being *blocked* from operating), or whether it means the RADIO rf output is on. Clearly state that RFKILL_STATE_ON means the radio is *unblocked* from operating (i.e. there is no rf killing going on). Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: John W. Linville <linv...

Is this indicative of a kernel or hardware problem? [ 0.279606] ACPI: Using IOAPIC for interrupt routing [ 0.279789] initcall acpi_init+0x0/0x216() returned with preemption imbalance [ 0.330789] ACPI: PCI Root Bridge [PCI0] (0000:00) Thanks, Miles --

I've never programmed in C++ ... I just expect to find API documentation I see that as being "move the complexity around" and "get the interfaces Fine, I've done it the other way round. Please review this doc-patch. Without comments, I'll commit it to the semaphore git tree tomorrow. diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h index a7125da..9cae64b 100644 --- a/include/linux/semaphore.h +++ b/include/linux/semaphore.h @@ -4,8 +4,7 @@ * * Distributed under th...

This patch implements various helpers to support OF bindings for the i2c API. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- drivers/of/Kconfig | 6 +++ drivers/of/Makefile | 1 + drivers/of/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/of_i2c.h | 24 ++++++++++ 4 files changed, 146 insertions(+), 0 deletions(-) create mode 100644 drivers/of/i2c.c create mode 100644 include/linux/of_i2c.h diff --git a/drivers/of/Kconfig b/dri...

In commit 08f1c192c3c32797068bfe97738babb3295bbf42 (x86-64: introduce struct pci_sysdata to facilitate sharing of ->sysdata), a change was made from using pcibios_scan_root to pci_scan_bus_parented. pcibios_scan_root applies some quirks to various systems via pciprobe_dmi_table, including a number of Dell PowerEdge servers. The similarly named acpi_pciprobe_dmi_table, however, does not apply the same set_bf_sort quirk, so between .22 and .23, the onboard Broadcom nics reversed their probe order. ...

When reporting clock problems, please post dmesg. This has all the interesting timekeeping-related log messages from the kernel. Please also describe the drift quantitatively. -- Chris --

With the older chips, each core had its own TSC, which caused synchronization problems. The Barcelona generation chips (including your Phenom) have a constant frequency TSC on the northbridge, so they should be immune to these problems. If it's steadily losing a few seconds every hour, it's probably just slightly mis-calibrated hardware. ntp should fix this right up. If the drift is more extreme than ntp can correct for, or the drift keeps changing, or time is jumping around, that is def...

No - it's not wild like it was back in the early X2 days and I think you're right about the drift being normal. Interesting thing though I am running ntpd and it's not working. I am fairly sure the ntp.conf file is exactly as it was installed by fedora. I'm now looking into that. Thanks for your help. Sorry for the false alarm. But if thee was an issue I thought you would want to know it. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com _________________________...

I have found that ntp tends to fail to work on any machine with spread spectrum clocking enabled. On those machines disabling spread specturm in the BIOS seems to fix it. I had to update the BIOS on one machine to even get the option to disable it though. -- Len Sorensen --

While compiling linux-2.6.25-rc8-git7 with CONFIG_DEBUG_SECTION_MISMATCH=y, I noticed the following "section mismatch" warnings. Please CC me as I'm not subscribed to this list. WARNING: vmlinux.o(.text+0x10d58): Section mismatch in reference from the function cpu_exit_clear() to the function .cpuinit.text:cpu_uninit() The function cpu_exit_clear() references the function __cpuinit cpu_uninit(). This is often because cpu_exit_clear lacks a __cpuinit annotation or the annotation of cpu_uninit is ...

From: Kay Sievers <kay.sievers@vrfy.org> Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable platform LED drivers, to re-enable auto loading. [ dbrownell@users.sourceforge.net: more drivers, registration fixes ] Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> --- drivers/leds/leds-ams-delta.c | 2 ++ drivers/leds/leds-at...

On Fri, 11 Apr 2008 20:28:27 +0300 Acked-by: Alan Cox <alan@redhat.com> --

/* * Load-balancing iterator. Note: while the runqueue stays locked * during the whole iteration, the current task might be * dequeued so the iterator has to be dequeue-safe. Here we * achieve that by always pre-iterating before returning * the current task: */ I don't think this comment is correct, but if it were, it would only apply to rq->curr, not for any enqueue/dequeue. --

This patch adds three tests that test whether the PR_GET_TSC and PR_SET_TSC commands have the desirable effect. The tests check whether the control register is updated correctly at context switches and try to discover bugs while enabling/disabling the timestamp counter. Signed-off-by: Erik Bosman <ejbosman@cs.vu.nl> --- .../prctl/disable-tsc-ctxt-sw-stress-test.c | 96 ++++++++++++++++++++ .../prctl/disable-tsc-on-off-stress-test.c | 95 ++++++++++...