Hi,
I booted up 2.6.24-rc1 this morning [Real early over a brew ;-)] and was
having a problems with multiple ~5 second hangs on SATA/drive init
(Something to do with "EH" something-or-other and resets but I'll email
in separately about it later unless its fixed by the time I get the chance).
Hi,
I booted up 2.6.24-rc1 this morning [Real early over a brew ;-)] and was
having a problems with multiple ~5 second hangs on SATA/drive init
(Something to do with EH something-or-other and resets but I'll email
in separately about it later unless its fixed by the time I get the chance).
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 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 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 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, 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 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
12 matches
Mail list logo
