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
>
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
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
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
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
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
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
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
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 would this only
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).
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 config
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
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
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,
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
>>
> 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
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
2.6.21-rc1
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.
I've run a
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, 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.
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
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
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/
26 matches
Mail list logo
