On Sun, 2007-03-04 at 14:52 +, 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
>
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/earlyqui
Andrew wrote:
I have just discovered 2.6.21-rc1 boots with
pci=noacpi ...
Try setting the resolution and frame rate, video=XXX:[EMAIL PROTECTED] or
such. Worked for me. I like pci=noacpi, though ;-)
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompet
On Mon, 2007-02-26 at 18:48 +, 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
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=). Your machine
On Sun, 2007-02-25 at 11:07 +, 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 wou
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
On Sat, 2007-02-24 at 23:00 +, 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.
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
On Sat, February 24, 2007 11:09 am, Andrew Morton wrote:
>> On Fri, 23 Feb 2007 13:35:50 - (GMT) "Andrew" <[EMAIL PROTECTED]> 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.
> On Fri, 23 Feb 2007 13:35:50 - (GMT) "Andrew" <[EMAIL PROTECTED]> 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
I have just discovered 2.6.21-rc1 boots with
pci=noacpi ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 whi
13 matches
Mail list logo
