Created attachment 27323 [details] .config for 2.6.35 (exactly the same as my working 2.6.34.1) I just compiled the brand new 2.6.35. I have a Vaio SR11M with an Intel processor Core 2 Duo Penryn P8400. When I booted my system, it took about half an hour to reach the console login (getty). At boot, the whole system is stuck (no cursor blinking anymore, although I can press CapsLocks and the led will light up). It takes about 5 minutes for udev scripts to run. After about 7 minutes, the kernel reports that it was unable to load the iwlwifi-5000-ucode firmware (this is probably another bug, but wifi worked perfectly with 2.6.34.1). Still, after this the boot process continues but very very slowly. Every line appears every 2 or 3 minutes, and it seems that the kernel is doing something. After waiting for almost half an hour, the system finally boots, I can see the display manager, but in console 0 (in text mode). Again (although this should be another topic) I can see ioctl errors about wlan0, my wireless device is not recognized. I use Debian Sid (up to date), kernel 2.6.35 vanilla with the same options as 2.6.34.1 (which works perfectly in the exact same environment). My system is 64-bits (Debian amd64). Any clues why 2.6.35 boots so extremely slowly? Please find enclosed my .config-2.6.35. --Claudio
Hi, I just performed some tests. I downloaded 2.6.35.2 and tried to boot. So here is some explanation now: When the system boots, the kernel loads perfectly, without any stop. Then, udev starts to initialize. The system freezes at the point where udev says: "Waiting for /dev to be populated..". But the system is not actually frozen, it seems to be the console. If I keep pressing any key on my keyboard, the system loads. That is, any time I press one key, the system does "something" and stops again. So, as long as I keep pressing keys, the console spits out boot messages (from rc scripts and so on). Once I reach the X display manager, the system works perfectly. In fact, I am writing right now from my browser on 2.6.35.2. To sum up, it seems that only the rc messages at boot are frozen and I have to press any key on the keyboard to make the system react and go on with the boot process. Otherwise (once the system gets to the login) everything is completely normal. Here is my hardware/software that could affect: - Intel GM45 (using KMS) - Intel ICH9 bus - udev 160-1 (from Debian Sid) - sysvinit 2.88dsf-11 (from Debian Sid) Until you have time to check this, I will have to boot by pressing down a key on my keyboard until I reach the X display manager. Thank you in advance, once again. --Claudio
(marked as a regression) (recategorised as x86_64) (cc Dmitry) I've seen numerous reports of this "kernel needs me to keep hitting the keyboard to be able to boot" problem but I don't recall ever having seen an explanation for why this happens. Is it familiar to any of you guys?
In general, "need to hit the keyboard" usually implies that some kind of interrupts aren't being received and so implies a problem with the interrupt controller or timer device. Hitting the keyboard provides a source of interrupts and therefore allows the boot to proceed. This is the first bug report I remember seeing with 2.6.35 for an Intel processor, though. Bug 16636 had similar behavior, but that one only affects AMD processors. Claudio, is there any way you can do a "git bisect" on this from the last known kernel?
Hi, Sorry for answering so late, but I was on holiday. This problem happens both in my Debian and in Ubuntu 10.10 (alpha), both with kernel 2.6.35.x. However, Ubuntu seems to have patched "somehow" the kernel, since it boots normally, it is only the shutdown that needs interrupts (e.g. from the keyboard). 2.6.36-rc1 seems to boot fine sometimes, but sometimes it needs from keyboard feedback too, not always though (as it happens in 2.6.35.x). I could try to bisect, but I have almost no free time. Should I start from 2.6.35.4 onwards? 2010/8/27 <bugzilla-daemon@bugzilla.kernel.org> > https://bugzilla.kernel.org/show_bug.cgi?id=16495 > > > H. Peter Anvin <hpa@zytor.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |hpa@zytor.com > > > > > --- Comment #3 from H. Peter Anvin <hpa@zytor.com> 2010-08-26 21:58:08 > --- > In general, "need to hit the keyboard" usually implies that some kind of > interrupts aren't being received and so implies a problem with the > interrupt > controller or timer device. Hitting the keyboard provides a source of > interrupts and therefore allows the boot to proceed. > > This is the first bug report I remember seeing with 2.6.35 for an Intel > processor, though. Bug 16636 had similar behavior, but that one only > affects > AMD processors. > > Claudio, is there any way you can do a "git bisect" on this from the last > known > kernel? > > -- > Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
Hello, I don't have time to test nor bisect. Yet I discovered that this bug is half-fixed in 2.6.36-rc3. I mean that it sometimes boots normally (most of the times) without having to give interrupts to the bus. Yet sometimes (maybe 30% of the times) I have to press some keyboard key all the time until I get to the display manager. I assume that the X work fine because I am interacting with the mouse and the keyboard which provide a source of interrupts. I just thought it would be good to let you know. Kind regards, --Claudio
The first thing to try is adding "nohz=off highres=off" to the boot options. You could also try "hpet=0".
Hello Chuck, Thank you for the tip! It is "nohz=off" that makes it work properly! I am at work, so I just tested 2.6.36-rc4. But I assume it is the same thing as in 2.6.35.x. I tried all the combinations and the system works normally only if I have the option "nohz=off". The highres and hpet are not relevant to this bug, at least on my laptop. If you need further details, please let me know. Hopefully there is a fix and can be included in 2.6.36 still, or then in 2.6.37. Looking forward to hear from you. Kind regards, --Claudio
Hello again, Alright, I just tested "nohz=off" with 2.6.35.4 and it also makes it work! Hence, to sum up: Using "nohz=off" with 2.6.35.x and 2.6.36-rc4 makes the system work again. If I remove that option, I have to press the keyboard (I guess to generate interrupts). Now, what could be the fix for this bug? I assume "nohz=off" disables the "tickless" option. I am looking forward to hear from you. Kind regards, --Claudio
Claudio, this looks like the HPET bug we fixed a couple of days ago. Can you test the following patch ? http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=patch;h=995bd3bb5c78f3ff71339803c0b8337ed36d64fb Thanks, tglx
Hi, Against which kernel version exactly should I apply this patch? Thanks in advance, --Claudio
It is already in mainline, so you could just try 2.6.36-rc5 which just Linus just released.
Hi, It is fixed with 2.6.36-rc5. You can close this. Thank you very much for your effort! --Claudio
Confused. AFACIT 995bd3bb5c78f3ff71339803c0b8337ed36d64fb is not present in 2.6.36-rc5. Nor is it present in linux-next. And the bug report is against 2.6.35.2 but the commit to which tglx linked has no Cc:stable in the changelog.
Indeed. I'm confused too now. 995bd3bb5c78f3ff71339803c0b8337ed36d64fb is actually in some of the x86 git trees and not mainline. Sorry for that. There were actually some other reports about similar issues, so it could be fixed nonetheless in mainline. I will close this as fixed. Claudio, if it happens again to you, shout loud and clear. Thx, Flo
(In reply to comment #14) > > I will close this as fixed. > I'll reopen it because the report is against 2.6.35.x and it isn't fixed there. If it's really fixed in 2.6.36-rc5 then we want to find out what fixed it and backport that.
Created attachment 30892 [details] Patch to test on top of 2.6.35.4 for the hpet issue Right. Claudio, could you test if the attached patch from Thomas on top of 2.6.35.4 fixes the issue for you? (Patch taken out of 2.6.35.5)
Hi, Tested and working! So 2.6.35.4 with that patch is working for my Vaio SR11M. Thank you! 2010/9/21 <bugzilla-daemon@bugzilla.kernel.org> > https://bugzilla.kernel.org/show_bug.cgi?id=16495 > > > > > > --- Comment #16 from Florian Mickler <florian@mickler.org> 2010-09-21 > 07:48:57 --- > Created an attachment (id=30892) > --> (https://bugzilla.kernel.org/attachment.cgi?id=30892) > Patch to test on top of 2.6.35.4 for the hpet issue > > Right. Claudio, could you test if the attached patch from Thomas on top of > 2.6.35.4 fixes the issue for you? > > (Patch taken out of 2.6.35.5) > > -- > Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
B1;2401;0c> --- Comment #15 from Andrew Morton <akpm@linux-foundation.org> 2010-09-21 06:48:11 --- > I'll reopen it because the report is against 2.6.35.x and it isn't fixed > there. > > If it's really fixed in 2.6.36-rc5 then we want to find out what fixed it and > backport that. It's commit 54ff7e59 in Linus tree, which has a cc:stable tag. And it's in 2.6.35.5 commit 8ba36a90f. So we can close that thing. Thanks, tglx