lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Feb 2007 07:09:19 +0800
From:	"Antonino A. Daplas" <adaplas@...il.com>
To:	Andrew Nelless <andrew@...less.net>
Cc:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: 2.6.21-rc1: framebuffer/console boot failure

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@...gy ~ $ 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ