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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
