Invalid context debug message from 2.6.14-git6 with powernow_k7

[Larry.Finger@att.net (Larry.Finger@lwfinger.net)]

The current kernel (2.6.14-git6) generates a debug message on an HP ze1115 notebook with a
mobile AMD  Duron(tm) stepping 01 processor.

Kernel command line: root=/dev/hda6 vga=0x314 selinux=0 resume=/dev/hda3  splash=silent psmouse.proto=bare. config.gz attached.

Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
in_atomic():1, irqs_disabled():0
 [<c0103d9e>] dump_stack+0x1e/0x20
 [<c0117231>] __might_sleep+0xa1/0xc0
 [<c028ef95>] cpufreq_notify_transition+0x45/0x220
 [<ddae1448>] change_speed+0x78/0xf0 [powernow_k7]
 [<ddae190b>] powernow_target+0x4b/0x60 [powernow_k7]
 [<c02902af>] __cpufreq_driver_target+0x5f/0x70
 [<ddb194e1>] dbs_check_cpu+0x151/0x1c0 [cpufreq_ondemand]
 [<ddb19582>] do_dbs_timer+0x32/0x70 [cpufreq_ondemand]
 [<c012b7c6>] worker_thread+0x1c6/0x2b0
 [<c012ff5c>] kthread+0xac/0xb0
 [<c010100d>] kernel_thread_helper+0x5/0x18

Using the git bisect method, I determined that
c32b6b8e524d2c337767d312814484d9289550cf is first bad commit

Author: Ashok Raj <ashok.raj@intel.com>
Date:   Sun Oct 30 14:59:54 2005 -0800

    [PATCH] create and destroy cpufreq sysfs entries based on cpu notifiers

    cpufreq entries in sysfs should only be populated when CPU is online state.
     When we either boot with maxcpus=x and then boot the other cpus by echoing
    to sysfs online file, these entries should be created and destroyed when
    CPU_DEAD is notified.  Same treatement as cache entries under sysfs.

    We place the processor in the lowest frequency, so hw managed P-State
    transitions can still work on the other threads to save power.

    Primary goal was to just make these directories appear/disapper dynamically.

    There is one in this patch i had to do, which i really dont like myself but
    probably best if someone handling the cpufreq infrastructure could give
    this code right treatment if this is not acceptable.  I guess its probably
    good for the first cut.

    - Converting lock_cpu_hotplug()/unlock_cpu_hotplug() to disable/enable preempt.
      The locking was smack in the middle of the notification path, when the
      hotplug is already holding the lock. I tried another solution to avoid this
      so avoid taking locks if we know we are from notification path. The solution
      was getting very ugly and i decided this was probably good for this iteration
      until someone who understands cpufreq could do a better job than me.

    (akpm: export cpucontrol to GPL modules: drivers/cpufreq/cpufreq_stats.c now
    does lock_cpu_hotplug())

    Signed-off-by: Ashok Raj <ashok.raj@intel.com>
    Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
    Cc: Dave Jones <davej@codemonkey.org.uk>
    Cc: Zwane Mwaikambo <zwane@holomorphy.com>
    Cc: Greg KH <greg@kroah.com>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

:040000 040000 0892a56c73b43a6984224f16ac60e742d4d22588 e87c14eb9bb5a06b0cf4ff668f794bfa4dc2968d M      drivers
:040000 040000 3cad3076f6bc2372704f09bed50e77f7a5f26192 b8a5721cc1a2730bc38c6c34dbd57493713db7bb M      kernel

Attachment: config.gz
Description: Binary data