* 2.6.21-rc1: framebuffer/console boot failure @ 2007-02-23 13:35 Andrew 2007-02-23 16:05 ` Andrew 2007-02-24 11:09 ` Andrew Morton 0 siblings, 2 replies; 13+ messages in thread From: Andrew @ 2007-02-23 13:35 UTC (permalink / raw) To: linux-kernel Hi, 2.6.21-rc1 fails to boot on my machine. As soon as I switch from grub the screen turns and remains black with no sign of Tux or any output. I've run a git-bisect between 2.6.20 (which works fine) and 2.6.21-rc1 and found the first bad commit to be #59b8175c771040afcd4ad67022b0cc80c216b866 which seems bizarre to me since this is a mostly an ARM commit. I haven't tried to revert this commit because frankly I don't know where to go from there with a multi-parent commit. I'm running on on a Asus A8N-VM CSM motherboard with a single core AMD64 processor, with a nVidia GPU in the PCI-ex slot using the standard VESA frame buffer driver. Relevant config's can be found here: http://homepage.ntlworld.com/anelless/linux/2.6.21-rc1/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-23 13:35 2.6.21-rc1: framebuffer/console boot failure Andrew @ 2007-02-23 16:05 ` Andrew 2007-02-28 1:35 ` Bill Davidsen 2007-02-24 11:09 ` Andrew Morton 1 sibling, 1 reply; 13+ messages in thread From: Andrew @ 2007-02-23 16:05 UTC (permalink / raw) To: linux-kernel I have just discovered 2.6.21-rc1 boots with pci=noacpi ... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-23 16:05 ` Andrew @ 2007-02-28 1:35 ` Bill Davidsen 0 siblings, 0 replies; 13+ messages in thread From: Bill Davidsen @ 2007-02-28 1:35 UTC (permalink / raw) To: Andrew; +Cc: linux-kernel Andrew wrote: > I have just discovered 2.6.21-rc1 boots with > pci=noacpi ... > Try setting the resolution and frame rate, video=XXX:1280x1024@70 or such. Worked for me. I like pci=noacpi, though ;-) -- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-23 13:35 2.6.21-rc1: framebuffer/console boot failure Andrew 2007-02-23 16:05 ` Andrew @ 2007-02-24 11:09 ` Andrew Morton 2007-02-24 22:57 ` Andrew Nelless 2007-02-24 23:00 ` Andrew Nelless 1 sibling, 2 replies; 13+ messages in thread From: Andrew Morton @ 2007-02-24 11:09 UTC (permalink / raw) To: Andrew; +Cc: linux-kernel, linux-acpi > On Fri, 23 Feb 2007 13:35:50 -0000 (GMT) "Andrew" <andrew@nelless.net> wrote: > Hi, > > 2.6.21-rc1 fails to boot on my machine. As soon as I switch > from grub the screen turns and remains black with no sign > of Tux or any output. > > I've run a git-bisect between 2.6.20 (which works fine) and > 2.6.21-rc1 and found the first bad commit to be > #59b8175c771040afcd4ad67022b0cc80c216b866 which seems bizarre > to me since this is a mostly an ARM commit. > > I haven't tried to revert this commit because frankly I don't > know where to go from there with a multi-parent commit. > > I'm running on on a Asus A8N-VM CSM motherboard with a single > core AMD64 processor, with a nVidia GPU in the PCI-ex slot > using the standard VESA frame buffer driver. > > Relevant config's can be found here: > http://homepage.ntlworld.com/anelless/linux/2.6.21-rc1/ > and, later, > I have just discovered 2.6.21-rc1 boots with > pci=noacpi ... Presumably this regression was caused by the ACPI merge. Are you able to capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be useful here, thanks. (You get added to the post-2.6.20 regression list, so you'll be hearing from us quite a lot for the next month. Sorry ;)) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-24 11:09 ` Andrew Morton @ 2007-02-24 22:57 ` Andrew Nelless 2007-02-24 23:00 ` Andrew Nelless 1 sibling, 0 replies; 13+ messages in thread From: Andrew Nelless @ 2007-02-24 22:57 UTC (permalink / raw) To: linux-kernel, linux-acpi On Sat, February 24, 2007 11:09 am, Andrew Morton wrote: >> On Fri, 23 Feb 2007 13:35:50 -0000 (GMT) "Andrew" <andrew@nelless.net> wrote: >> Hi, >> >> >> 2.6.21-rc1 fails to boot on my machine. As soon as I switch >> from grub the screen turns and remains black with no sign of Tux or any output. >> >> I've run a git-bisect between 2.6.20 (which works fine) and >> 2.6.21-rc1 and found the first bad commit to be >> #59b8175c771040afcd4ad67022b0cc80c216b866 which seems bizarre >> to me since this is a mostly an ARM commit. >> >> I haven't tried to revert this commit because frankly I don't >> know where to go from there with a multi-parent commit. >> >> I'm running on on a Asus A8N-VM CSM motherboard with a single >> core AMD64 processor, with a nVidia GPU in the PCI-ex slot using the standard VESA frame >> buffer driver. >> >> Relevant config's can be found here: >> http://homepage.ntlworld.com/anelless/linux/2.6.21-rc1/ >> >> > > and, later, > >> I have just discovered 2.6.21-rc1 boots with >> pci=noacpi ... > > Presumably this regression was caused by the ACPI merge. Are you able to > capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be useful here, thanks. > > (You get added to the post-2.6.20 regression list, so you'll be hearing > from us quite a lot for the next month. Sorry ;)) > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-24 11:09 ` Andrew Morton 2007-02-24 22:57 ` Andrew Nelless @ 2007-02-24 23:00 ` Andrew Nelless 2007-02-24 23:30 ` Antonino A. Daplas 1 sibling, 1 reply; 13+ messages in thread From: Andrew Nelless @ 2007-02-24 23:00 UTC (permalink / raw) To: linux-kernel, linux-acpi On Sat, February 24, 2007 11:09 am, Andrew Morton wrote: > > Presumably this regression was caused by the ACPI merge. Are you able to > capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be useful here, thanks. > I've confirmed a few things: 1) 2.6.21-rc1 actually will boot intermittently. 2) pci=noacpi always allows 2.6.21-rc1 to boot. 2) 2.6.20 always boots. 3) There doesn't seem to be a pattern (that I can tell) between booting and not booting, although it'll now boot more often than not (It seemed very much t'other way around yesterday) 4) When 2.6.21-rc1 doesn't boot ('Boot'? Am i using the right term here? hmm...) nothing is sent across netconsole at all. 5) Netconsole is useful. I've uploaded all the dmesg output i've managed to capture here: http://homepage.ntlworld.com/anelless/linux/2.6.21-rc1/ > (You get added to the post-2.6.20 regression list, so you'll be hearing > from us quite a lot for the next month. Sorry ;)) > Lucky me :) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-24 23:00 ` Andrew Nelless @ 2007-02-24 23:30 ` Antonino A. Daplas 2007-02-25 11:07 ` Andrew Nelless 0 siblings, 1 reply; 13+ messages in thread From: Antonino A. Daplas @ 2007-02-24 23:30 UTC (permalink / raw) To: Andrew Nelless; +Cc: linux-kernel, linux-acpi On Sat, 2007-02-24 at 23:00 +0000, Andrew Nelless wrote: > On Sat, February 24, 2007 11:09 am, Andrew Morton wrote: > > > > Presumably this regression was caused by the ACPI merge. Are you able to > > capture the dmesg output from the 2.6.20-rc1 boot? netconsole might be useful here, thanks. > > > > I've confirmed a few things: > > 1) 2.6.21-rc1 actually will boot intermittently. > 2) pci=noacpi always allows 2.6.21-rc1 to boot. > 2) 2.6.20 always boots. > 3) There doesn't seem to be a pattern (that I can tell) between booting and not booting, > although it'll now boot more often than not (It seemed very much t'other way around yesterday) > 4) When 2.6.21-rc1 doesn't boot ('Boot'? Am i using the right term here? hmm...) nothing is > sent across netconsole at all. > 5) Netconsole is useful. > > I've uploaded all the dmesg output i've managed to capture here: > http://homepage.ntlworld.com/anelless/linux/2.6.21-rc1/ > > > (You get added to the post-2.6.20 regression list, so you'll be hearing > > from us quite a lot for the next month. Sorry ;)) > > > > Lucky me :) How about booting with just vga=normal? Tony ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-24 23:30 ` Antonino A. Daplas @ 2007-02-25 11:07 ` Andrew Nelless 2007-02-26 12:41 ` Antonino A. Daplas 0 siblings, 1 reply; 13+ messages in thread From: Andrew Nelless @ 2007-02-25 11:07 UTC (permalink / raw) To: linux-kernel, linux-acpi; +Cc: Antonino A. Daplas On Sat, February 24, 2007 11:30 pm, Antonino A. Daplas wrote: > > How about booting with just vga=normal? > > > Tony > That seems to work too. I've rebooted about 20 times in a row and it hasn't done it again yet. Why would this only occur at higher modes? In the 2.6.20 dmesg log it reads "Nvidia board detected. Ignoring ACPI timer override." whereas in 2.6.21-rc1 it doesn't. Could this be the culprit? Andrew ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-25 11:07 ` Andrew Nelless @ 2007-02-26 12:41 ` Antonino A. Daplas 2007-02-26 18:48 ` Andrew Nelless 0 siblings, 1 reply; 13+ messages in thread From: Antonino A. Daplas @ 2007-02-26 12:41 UTC (permalink / raw) To: Andrew Nelless; +Cc: linux-kernel, linux-acpi On Sun, 2007-02-25 at 11:07 +0000, Andrew Nelless wrote: > On Sat, February 24, 2007 11:30 pm, Antonino A. Daplas wrote: > > > > How about booting with just vga=normal? > > > > > > Tony > > > > That seems to work too. I've rebooted about 20 times in a row > and it hasn't done it again yet. Why would this only occur > at higher modes? > > In the 2.6.20 dmesg log it reads "Nvidia board detected. > Ignoring ACPI timer override." whereas in 2.6.21-rc1 it doesn't. > Could this be the culprit? > I don't know, probably the ACPI code can now probably detect the presence or absence of the HPET timer. Can you remove CONFIG_FB_VESA support from your kernel config but boot as if you have vesafb (ie with vga=<VESA mode number>). Your machine may boot to completion but you will have a blank screen. But you should be able to have an output in netconsole and you can start X. I wanted to know if the lockup is related to the framebuffer. Tony ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-26 12:41 ` Antonino A. Daplas @ 2007-02-26 18:48 ` Andrew Nelless 2007-02-26 23:09 ` Antonino A. Daplas 0 siblings, 1 reply; 13+ messages in thread From: Andrew Nelless @ 2007-02-26 18:48 UTC (permalink / raw) To: linux-kernel, linux-acpi; +Cc: Antonino A. Daplas On Mon, February 26, 2007 12:41 pm, Antonino A. Daplas wrote: > > I don't know, probably the ACPI code can now probably detect the > presence or absence of the HPET timer. > > Can you remove CONFIG_FB_VESA support from your kernel config but boot > as if you have vesafb (ie with vga=<VESA mode number>). Your machine may boot to completion but > you will have a blank screen. But you should be able to have an output in netconsole and you > can start X. I wanted to know if the lockup is related to the framebuffer. > > Tony > > I disabled CONFIG_FB_VESA but it is still happening because intermittent boots don't pump out anything over NetConsole. It's tempting to think this is a hardware issue but I've been booting 2.6.20 daily since -rc3 and this hasn't happened before and still doesn't. I've even installed Asus's latest "beta bios" (which convenient doesn't come with a changelog) but it had no effect. The only thing I can think to do now is another git bisect. Now I know this occurs on average about every third boot I could do half a dozen reboots between bisections and hopefully find out what caused the problem.. Unfortunately I won't have the time for such a time consuming adventure much the weekend.. Any further ideas? -- Andrew P.S. You mentioned HPET, is this HPET config normal? andrew@ziggy ~ $ fgrep -i hpet /usr/src/linux-2.6.21-rc1/.config CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET is not set ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-26 18:48 ` Andrew Nelless @ 2007-02-26 23:09 ` Antonino A. Daplas 2007-03-04 14:52 ` Andrew Nelless 0 siblings, 1 reply; 13+ messages in thread From: Antonino A. Daplas @ 2007-02-26 23:09 UTC (permalink / raw) To: Andrew Nelless; +Cc: linux-kernel, linux-acpi On Mon, 2007-02-26 at 18:48 +0000, Andrew Nelless wrote: > On Mon, February 26, 2007 12:41 pm, Antonino A. Daplas wrote: > > > > I don't know, probably the ACPI code can now probably detect the > > presence or absence of the HPET timer. > > > > Can you remove CONFIG_FB_VESA support from your kernel config but boot > > as if you have vesafb (ie with vga=<VESA mode number>). Your machine may boot to completion but > > you will have a blank screen. But you should be able to have an output in netconsole and you > > can start X. I wanted to know if the lockup is related to the framebuffer. > > > > Tony > > > > > > I disabled CONFIG_FB_VESA but it is still happening because > intermittent boots don't pump out anything over NetConsole. > Okay, which rules out console code. The vga= parameter is processed at the very start, specifically in arch/x86_64/boot/video.S. This is probably not mixing very well with the rest of the code. > It's tempting to think this is a hardware issue but I've been > booting 2.6.20 daily since -rc3 and this hasn't happened before > and still doesn't. I've even installed Asus's latest "beta bios" > (which convenient doesn't come with a changelog) but it had > no effect. If your machine was broken right from the beginning, I would say that this is also a hardware issue, but, no, it's a regression. > > The only thing I can think to do now is another git bisect. > Now I know this occurs on average about every third boot I > could do half a dozen reboots between bisections and hopefully > find out what caused the problem.. > > Unfortunately I won't have the time for such a time consuming > adventure much the weekend.. > > Any further ideas? > > -- Andrew > > P.S. You mentioned HPET, is this HPET config normal? > andrew@ziggy ~ $ fgrep -i hpet /usr/src/linux-2.6.21-rc1/.config > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > # CONFIG_HPET is not set Not sure if the timer override workaround for nvidia chipsets is the culprit, but if you want, you can choose to revert that to the previous behavior (which is ignoring ACPI timer override). Open arch/x86_64/kernel/earlyquirk.c:nvidia_bugs() and change this line: if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) return; into this: acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check); /* return; */ Tony ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-02-26 23:09 ` Antonino A. Daplas @ 2007-03-04 14:52 ` Andrew Nelless 2007-03-05 6:12 ` Antonino A. Daplas 0 siblings, 1 reply; 13+ messages in thread From: Andrew Nelless @ 2007-03-04 14:52 UTC (permalink / raw) To: Antonino A. Daplas; +Cc: linux-kernel, linux-acpi On Mon, February 26, 2007 11:09 pm, Antonino A. Daplas wrote: > > Not sure if the timer override workaround for nvidia chipsets is the > culprit, but if you want, you can choose to revert that to the previous behavior (which is > ignoring ACPI timer override). Open arch/x86_64/kernel/earlyquirk.c:nvidia_bugs() and change > this line: > > if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) return; into this: > > acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check); /* return; */ > > > Tony > This fixes the problem. After a lot of rebooting and testing the problem is definitely gone when this check is patched out and the ACPI timer override is ignored. It looks like there should be a cleaner patch than just obliterating the condition and return though. Perhaps the code should remain as is and "acpi_use_timer_override" could be complimented by exposing the "acpi_skip_timer_override" option to the kernel command line? This seems to have been exposed in the past: https://www.x86-64.org/pipermail/discuss/2005-April/005948.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.21-rc1: framebuffer/console boot failure 2007-03-04 14:52 ` Andrew Nelless @ 2007-03-05 6:12 ` Antonino A. Daplas 0 siblings, 0 replies; 13+ messages in thread From: Antonino A. Daplas @ 2007-03-05 6:12 UTC (permalink / raw) To: Andrew Nelless; +Cc: linux-kernel, linux-acpi On Sun, 2007-03-04 at 14:52 +0000, Andrew Nelless wrote: > On Mon, February 26, 2007 11:09 pm, Antonino A. Daplas wrote: > > > > Not sure if the timer override workaround for nvidia chipsets is the > > culprit, but if you want, you can choose to revert that to the previous behavior (which is > > ignoring ACPI timer override). Open arch/x86_64/kernel/earlyquirk.c:nvidia_bugs() and change > > this line: > > > > if (acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check)) return; into this: > > > > acpi_table_parse(ACPI_SIG_HPET, nvidia_hpet_check); /* return; */ > > > > > > Tony > > > > This fixes the problem. After a lot of rebooting > and testing the problem is definitely gone when this > check is patched out and the ACPI timer override is > ignored. It looks like there should be a cleaner > patch than just obliterating the condition and return > though. > > Perhaps the code should remain as is and > "acpi_use_timer_override" could be complimented > by exposing the "acpi_skip_timer_override" option to > the kernel command line? acpi_skip_timer_override is still documented in Documentation/kernel-parameters.txt. Tony ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-03-05 6:10 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-23 13:35 2.6.21-rc1: framebuffer/console boot failure Andrew 2007-02-23 16:05 ` Andrew 2007-02-28 1:35 ` Bill Davidsen 2007-02-24 11:09 ` Andrew Morton 2007-02-24 22:57 ` Andrew Nelless 2007-02-24 23:00 ` Andrew Nelless 2007-02-24 23:30 ` Antonino A. Daplas 2007-02-25 11:07 ` Andrew Nelless 2007-02-26 12:41 ` Antonino A. Daplas 2007-02-26 18:48 ` Andrew Nelless 2007-02-26 23:09 ` Antonino A. Daplas 2007-03-04 14:52 ` Andrew Nelless 2007-03-05 6:12 ` Antonino A. Daplas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.