Summary: | sys-kernel/gentoo-sources-2.6.17-r1: reading from /proc/cpuinfo (e.g. by uname -p) hangs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Boot messages of my 2.6.17-r1 kernel
Boot messages of my 2.6.17-r1 kernel dmesg on 2.6.17-gentoo-r2 dmesg on 2.6.17-gentoo-r2 untainted |
Description
Martin von Gagern
2006-07-06 03:49:26 UTC
It just happened again. I configured some package several times, and suddenly it got stuck in reading cpuinfo. So this problem was not there from the start but rather occurred somtime while the system was up. Connecting to cpufreqd fails as well: $ cpufreqd-get socket I'll try to connect: /tmp/cpufreqd-6BRIMP/cpufreqd And killing it is no betther, be it SIGTERM or SIGKILL, the process stays there. Attaching strace to it hangs as well, as with that uname above. Because I've been asked about my preemtion setings in IRC today: # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y I will disable CONFIG_PREEMPT_BKL for the time being and see if that helps. Please attach dmesg output from when after the hang occurrs (In reply to comment #2) > Please attach dmesg output from when after the hang occurrs I did not save the dmesg, but the last event was hours before the hang, there was nothing related. And what was the last event? (In reply to comment #4) > And what was the last event? Some message about an unknown PS/2 mouse after I last used my KVM switch. But accessing /proc/cpuinfo definitely worked several times after that. Oh, I have that line in my logs: Jul 9 04:24:22 server kernel: [4358097.856000] logips2pp: Detected unknown logitech mouse model 94 I rebooted my system at 12:36, which in my estimation was less than an hour after the bug occurred. So there were about 7 hours without any kernel messages. Ok, in that case just post a dmesg from a clean boot please. Created attachment 91316 [details] Boot messages of my 2.6.17-r1 kernel (In reply to comment #6) > Ok, in that case just post a dmesg from a clean boot please. I grabbed the messages from my kern.log. It is my understanding that they contain all dmesg contents as well. This log was from the latest boot process before comment #1, so a boot after which the error occurred. In the meantime I've switched to 2.6.17-r2 and disabled CONFIG_PREEMPT_BKL, so if I reboot now and grab the dmesg contents, things would be slightly different. Created attachment 91317 [details] Boot messages of my 2.6.17-r1 kernel (In reply to comment #7) > I grabbed the messages from my kern.log. Lost a few lines in the process, sorry about that. Please post dmesg output even if it is from a slightly different kernel. syslog often misses stuff... Also you need to reproduce this on a clean kernel (i.e. no fritz stuff, not even loaded then unloaded: must be completely untainted) (In reply to comment #9) > Please post dmesg output even if it is from a slightly different kernel. > syslog often misses stuff... Currently the dmesg contents is incomplete, too many messages since the last boot. And I don't want to reboot my system just now, I'm remote accessing it and if anything goes wrong I'd probably have to drive there just to fix it. I'll create this log as soon as I manage to, probably around the end of the week. (In reply to comment #10) > Also you need to reproduce this on a clean kernel (i.e. no fritz stuff, not > even loaded then unloaded: must be completely untainted) I'll try if I can get capisuite working with misdn as well. If so, then I'll switch and have a clean kernel. Otherwise this will have to wait even longer, until I find some time when I can do without my capisuite answering machine. (In reply to comment #11) > Currently the dmesg contents is incomplete, too many messages since the last > boot. The dmesg from when you last booted the machine is stored in /var/log/dmesg - you can attach that :) In that case I'll close this for now, please reopen once you have reproduced on a clean kernel and provided the extra info. At that point you'd need to test the latest development kernel too, which is currently 2.6.18-rc1. Created attachment 92068 [details] dmesg on 2.6.17-gentoo-r2 (In reply to comment #12) > The dmesg from when you last booted the machine is stored in /var/log/dmesg - > you can attach that :) Thanks! It just happened again. I got that and combined it with the current dmesg, they had enough overlap. This is the kernel from my comment #7, 2.6.17-r2 with CONFIG_PREEMPT_BKL disabled. I'm now installing vanilla sources and will boot them without fritzcapi. (In reply to comment #13) > At that point you'd need to test the latest development kernel too 2.6.18-rc2 does not work for me. I just filed bug 141015 about this. (In reply to comment #10) > Also you need to reproduce this on a clean kernel (i.e. no fritz stuff, not > even loaded then unloaded: must be completely untainted) At least I have capisuite working with mISDN instead of fritzcapi, so my kernel should be untainted, although it still uses modules not from the main kernel source tree. Created attachment 92636 [details] dmesg on 2.6.17-gentoo-r2 untainted (In reply to comment #10) > Also you need to reproduce this on a clean kernel (i.e. no fritz stuff, not > even loaded then unloaded: must be completely untainted) OK, it just happened again, with mISDN instead of fritzcapi this time. (In reply to comment #13) > In that case I'll close this for now, please reopen once you have reproduced > on a clean kernel and provided the extra info. Reproduced with an clean i.e. untainted kernel. Merged /var/log/dmesg and current dmesg to build attached file. > At that point What point? Before or after reopening? Because reopening is done in an instant, trying to reproduce it may take months, and actually reproducing it certainly won't coincide with me reopening this bug. > you'd need to test the latest development kernel too. As 2.6.18-rc2 still does not work for me, that is out of the question for now. I could try the 2.6.17.6 vanilla sources, if that is any help. As this is about an ancient kernel, using ancient drivers, and I seem to be the only one who had been affected by this, and don't encounter it any more, I'm changing the resolution from NEEDINFO to OBSOLETE. |