lkml.org 
[lkml]   [2008]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6.26-rc1] WARNING: at drivers/base/sys.c:183
On Sun, May 11, 2008 at 08:18:08PM +0200, Tilman Schmidt wrote:
> This warning, first reported for 2.6.25-rc5-mm1
> (see http://lkml.org/lkml/2008/3/12/444)
> has now made it into mainline:

Probably the sysdev check got merged.

> May 11 19:32:44 xenon kernel: [ 29.017148] powernow: This module only works with AMD K7 CPUs

So we call into powernow-k7 and get -ENODEV. From looking at the code,
we're not leaking anything (because we don't even allocate anything at this point).

> May 11 19:32:44 xenon kernel: [ 29.607563] sysdev: class cpu: driver (c0439804) has already been registered to a class, something is wrong, but will forge on!
> May 11 19:32:44 xenon kernel: [ 29.611835] ------------[ cut here ]------------
> May 11 19:32:44 xenon kernel: [ 29.616182] WARNING: at drivers/base/sys.c:183 sysdev_driver_register+0x59/0xf2()
> May 11 19:32:44 xenon kernel: [ 29.622037] Modules linked in: acpi_cpufreq(+) speedstep_lib microcode firmware_class loop osst st sr_mod cdrom pata_acpi bas_gigaset snd_hda_intel gigaset isdn snd_pcm rtc_cmos ata_generic aic7xxx snd_timer rtc_core usblp snd slhc ohci1394 pata_marvell thermal ieee1394 rtc_lib i2c_i801 parport_pc intel_agp processor soundcore crc_ccitt iTCO_wdt button scsi_transport_spi iTCO_vendor_support parport snd_page_alloc agpgart i2c_core sg ext3 jbd mbcache linear usbhid hid sd_mod ahci libata uhci_hcd ehci_hcd scsi_mod dock usbcore dm_snapshot dm_mod
> May 11 19:32:44 xenon kernel: [ 29.648305] Pid: 2860, comm: modprobe Not tainted 2.6.26-rc1-testing #1
> May 11 19:32:44 xenon kernel: [ 29.653156] [<c0129d09>] warn_on_slowpath+0x41/0x6d
> May 11 19:32:44 xenon kernel: [ 29.658026] [<c0120032>] ? push_rt_task+0xb1/0x1ab
> May 11 19:32:44 xenon kernel: [ 29.664013] [<c012a75a>] ? vprintk+0x3a5/0x3c5
> May 11 19:32:44 xenon kernel: [ 29.670995] [<c010b7a4>] ? native_sched_clock+0xe0/0xff
> May 11 19:32:44 xenon kernel: [ 29.675849] [<c010b7a4>] ? native_sched_clock+0xe0/0xff
> May 11 19:32:44 xenon kernel: [ 29.680678] [<c0143881>] ? put_lock_stats+0xd/0x21
> May 11 19:32:44 xenon kernel: [ 29.685465] [<c012a78f>] ? printk+0x15/0x17
> May 11 19:32:44 xenon kernel: [ 29.690406] [<c026a57a>] sysdev_driver_register+0x59/0xf2
> May 11 19:32:44 xenon kernel: [ 29.696845] [<c02a8fe3>] cpufreq_register_driver+0x80/0xfc
> May 11 19:32:44 xenon kernel: [ 29.701892] [<faafe034>] acpi_cpufreq_init+0x34/0x3a [acpi_cpufreq]
> May 11 19:32:44 xenon kernel: [ 29.708279] [<c014d441>] sys_init_module+0x1883/0x1a34
> May 11 19:32:44 xenon kernel: [ 29.713176] [<c0106b63>] sysenter_past_esp+0x78/0xd1
> May 11 19:32:44 xenon kernel: [ 29.718586] =======================
> May 11 19:32:44 xenon kernel: [ 29.723414] ---[ end trace da2515dc0122d0b1 ]---

And then we freak out when we init the next cpufreq module, acpi-cpufreq, which gets further
and tries to actually get registered.

I don't really understand what's happening that makes sysfs so unhappy.
I guess if we had a clue what driver 'c0439804' was me might have some clues.
What symbols are near that address in /proc/kallsyms ?

Dave

--
http://www.codemonkey.org.uk


\
 
 \ /
  Last update: 2008-05-11 20:49    [W:0.043 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site