You are not logged in.
Today, kmod replaced module-init-tools, and after upgrading my system, noticed this error after udev loaded:
Jan 6 07:44:41 localhost kernel: [ 4.528051] watchdog: INTCAMT: cannot register miscdev on minor=130 (err=-16).
Jan 6 07:44:41 localhost kernel: [ 4.528088] watchdog: error registering /dev/watchdog (err=-16).
Jan 6 07:44:41 localhost kernel: [ 4.528113] mei: unable to register watchdog device.
Thankfully, nothing else happened and my system didn't go kaput. But reading the manpage, watchdog does appear to be important. Since udev errors were expected with the kmod upgrade, and this error never occurred before today (checked my /var/log/everything.log), it appears kmod is the likely culprit.
Edit: Tried posting this to the ML, and discovered that the general public does not have write access to the ML. So if some developer thinks this is important, hopefully that person will see this post.
Last edited by Sara (2012-01-09 00:12:41)
Registed Linux User 483618
Offline
Same here:
[ 6.174878] mei: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.594932] mei 0000:00:16.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 7.594942] mei 0000:00:16.0: setting latency timer to 64
[ 7.595132] mei 0000:00:16.0: irq 44 for MSI/MSI-X
[ 7.663138] watchdog: INTCAMT: cannot register miscdev on minor=130 (err=-16).
[ 7.664367] watchdog: error registering /dev/watchdog (err=-16).
[ 7.665319] mei: unable to register watchdog device.
Offline
Same here. Fuijitsu Lifebook E751
Harvey
Linux is like a wigwam: No Gates, no Windows and an Apache inside
Offline
I'm sure this is not kmod. I got this already after upgrading to Linux 3.2-1 and before kmod was even installed. This was the upgrade:
[2012-01-05 20:13] upgraded linux (3.1.7-1 -> 3.2-1)
[2012-01-05 20:13] upgraded lirc-utils (1:0.9.0-8 -> 1:0.9.0-9)
So I'm guessing it's a thing with the linux package.
Offline
So I'm guessing it's a thing with the linux package.
Confirmed. No problem with kernel26-lts (but no mei module either).
Offline
btw, /dev/watchdog with minor 130 exists in my devtmpfs.
Edit: this seems to be a conflict between Intel TCO WatchDog Timer Driver (iTCO_wdt) and Software Watchdog Device (softdog) which both try to register their device node as /dev/watchdog with minor WATCHDOG_MINOR (130)
Edit 2: Confirmed by blacklisting the iTCO_wdt module.
Last edited by laloch (2012-01-06 17:45:28)
Offline
Same result here on Linux 3.2CK.
@laloch, would you recommend to permanently blacklist iTCO_wdt module?
Offline
Edit: Tried posting this to the ML, and discovered that the general public does not have write access to the ML. So if some developer thinks this is important, hopefully that person will see this post.
You can post to arch-general.
Offline
@laloch, would you recommend to permanently blacklist iTCO_wdt module?
No, I'd rather remove the IMEI driver from the kernel.
Offline
I finally found some time to dig in the kernel source a bit and found that I was wrong. Sorry for the confusion. There's nothing wrong with the Intel MEI watchdog driver and the softdog is not involved at all. The truth is that the watchdog core functions only support 1 watchdog device via /dev/watchdog [1]. If the iTCO_wdt driver would use the watchdog core [2], we'd get the correct "only one watchdog can use /dev/watchdog." message and the IMEI watchdog registration would not be attempted. But it doesn't. It registers in a different way [3] and so the core does not "know" about another watchdog being already registered, attempts to register the IMEI watchdog and fails with the confusing "cannot register miscdev..." message.
The bottom line is that the kernel supports only one watchdog and we (administrators) have to decide which device we want to use.
[1] http://lxr.linux.no/linux+v3.2/drivers/ … dev.c#L344
[2] http://lxr.linux.no/linux+v3.2/drivers/ … dog_core.c
[3] http://lxr.linux.no/linux+v3.2/drivers/ … wdt.c#L854
Last edited by laloch (2012-01-08 15:34:41)
Offline
The bottom line is that the kernel supports only one watchdog and we (administrators) have to decide which device we want to use.
Nice work. Two questions though.
1) It's a bug right? At least one of the two should be chosen as the default, so we don't get the error.
2) How do we decide which device to use? And how do we set up the system to use that one?
Offline
1) It's a bug right? At least one of the two should be chosen as the default, so we don't get the error.
I don't think so. The same applies to all modules in drivers/watchdog. There's no reasonable way to set their priorities.
2) How do we decide which device to use? And how do we set up the system to use that one?
If you don't need Intel AMT, you should probably blacklist the mei module and go with the TCO watchdog and watchdog daemon. You can even disable the Intel ME completely via its BIOS setup (which for me, besides of other strange problems, triggers a known bug in IPS driver).
Offline
Lars Stokholm wrote:1) It's a bug right? At least one of the two should be chosen as the default, so we don't get the error.
I don't think so. The same applies to all modules in drivers/watchdog. There's no reasonable way to set their priorities.
Shouldn't Arch boot in the default setup without errors?
Offline
laloch wrote:Lars Stokholm wrote:1) It's a bug right? At least one of the two should be chosen as the default, so we don't get the error.
I don't think so. The same applies to all modules in drivers/watchdog. There's no reasonable way to set their priorities.
Shouldn't Arch boot in the default setup without errors?
Well, I thing that the watchdog core should support multiple devices and such patch already exists [1]. I don't think it's a bug, but you can file a bug report if you feel so.
[1] http://lists.lm-sensors.org/pipermail/l … 33707.html
Last edited by laloch (2012-01-08 19:11:09)
Offline
I'm in way over my head on this at the moment. How do I blacklist mei? Putting !mei in rc.conf sort of works. I get this
Loading User-specified Modules [BUSY] [FAIL]
iTCO_wdt: cannot register miscdev on minor=130 (err=-16)
Reading 'man rc.conf' on blacklisting modules tells me to look in 'man modprobe.conf' which doesn't exist after the kmod update.
I'm not comfortable reporting this, but I still feel Arch should boot without errors by default.
Offline
How do I blacklist mei? ... Reading 'man rc.conf' on blacklisting modules tells me to look in 'man modprobe.conf' which doesn't exist after the kmod update.
Offline
Thanks laloch, I should have thought about the wiki. I guess a lot of recent problems have been stressing me out.
Do you by any chance know what changed from 3.1 to 3.2 since this error has started appearing?
PS: This thread should be renamed to say linux-3.2 instead of kmod-3-4.
Offline
Do you by any chance know what changed from 3.1 to 3.2 since this error has started appearing?
The MEI watchdog support was added on 2011-08-31 by Oren Weil [1] and merged into 3.2 on 2011-10-26 by Greg Kroah-Hartman [2]
[1] https://lkml.org/lkml/2011/8/31/136
[2] https://lkml.org/lkml/2011/10/26/104
Offline
did you guys let know upstream about this issue?
Give what you have. To someone, it may be better than you dare to think.
Offline
I would very much like to report it but I'm extremely unqualified to do so. If no one else does it though, I'll probably have a go at it in the weekend.
Offline
I don't think there's anything to report. We just happend to have two hardware watchdogs. Linux supports only one. That's all.
Offline
I must say that I completely disagree with you. I'm not ready to accept my boot process being clouded by one error after another.
Offline
Lars, I had the same problem on my Thinkpad x220i.
From the /var/log/errors.log
Jan 20 11:12:50 localhost kernel: [ 4.888313] watchdog: error registering /dev/watchdog (err=-16).
Jan 20 11:12:50 localhost kernel: [ 4.888377] mei: unable to register watchdog device.
Blacklisting mei:
echo blacklist mei > /etc/modprobe.d/mei.conf
No more errors during boot!
Offline
Same here, on a HP 2540p
Offline
Same here on a Gigabyte GA-H55M-UD2H (Quad core Intel i5). Blacklisted mei as above and boot error message gone.
Thanks,
Algenon.
Offline