[arch-general] kernel26-2.6.34.1 - won't boot - stuck at "Setting up UTF-8 mode" or craters with kernel NULL pointer

[David C. Rankin]

On 07/13/2010 09:26 AM, David C. Rankin wrote:
>      Can anyone think of the possible mechanism that would cause a kernel to
> boot once after rebuilding the initramfs, but then be corrupt for every boot
> thereafter?? As mentioned in the title on the 2nd boot attempt (and all
> subsequent attempts), the boot process either hard-locks when the "Setting up
> UTF-8 mode" message is displayed --or-- a kernel NULL Pointer message is
> displayed and then I get 3 screens of garbage before the box either locks or a
> ctrl+c kills that part of the boot process and booting proceeds until it craters
> 4-10 steps later.

Could the Null Pointer blow up be due to incorrect gpu handling by the Arch 
kernel causing the blow-up when the modules are loaded (about the same time the 
KMS magic is taking place?

I say this because I have one of ATI's less common gpu's in this Toshiba laptop. 
The video card is:

Radeon X1250 Graphics(690G Chipset), RS690M, RV410 Graphics Core. This uses the 
onboard PCIe bus interface and has API support for DirectX 9.0b and OpenGL 2.0. 
For some reason the kernel crashes 'smell' like a mishandling of the gpu 
subsystem in the 2.6.34 kernels (Note: this is just a 'gut feel', and I can't 
point to anything in particular). Of all things that could have changed for the 
past 2 kernels, the KMS magic and a possible bug slipping in for this card seems 
like one of the likely areas to start looking.

The lspci -vv data for the card are as follows (I have opensuse running at the 
moment - thus the fglrx driver is shown):

01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 
Series] (prog-if 00 [VGA controller])
         Subsystem: Toshiba America Info Systems Device ff00
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
         Latency: 64, Cache Line Size: 32 bytes
         Interrupt: pin A routed to IRQ 18
         Region 0: Memory at f0000000 (64-bit, prefetchable) [size=128M]
         Region 2: Memory at f8100000 (64-bit, non-prefetchable) [size=64K]
         Region 4: I/O ports at 9000 [size=256]
         Region 5: Memory at f8000000 (32-bit, non-prefetchable) [size=1M]
         Capabilities: [50] Power Management version 2
                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
         Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 
Enable-
                 Address: 0000000000000000  Data: 0000
         Kernel driver in use: fglrx_pci
         Kernel modules: fglrx

I don't know why the card is reporting as an X1200 in lspci. The Core Clock for 
this gpu is 400 MHz and according to AMD, that means this is the 1250 and not 
the 1200 because the Core Clock on the 1200 is 350 MHz.

I don't know what, if any, changes took place in KMS or in gpu initialization 
for the 2.6.34 kernel, but this card always sucked when using the ATI driver 
which prevented me from moving to Arch sooner on this box. Then with the 2.6.32 
& 2.6.33 kernels, it was like somebody turned on a light-switch in the kernel 
and I was getting Blazing fast performance out of the xf86-video-ati driver on 
Arch, compiz was working great, and the gpu subsystem was working better than 
ever before in Arch with just the 'radeon' driver.

When I updated to 2.6.34-2 I ran into the problem with compiz "whitescreening" 
and video performance 'tanked' when I had the system running on 'first boot' 
which would boot.

Then on every attempt to boot thereafter - the boot would fail and either hang 
of blow-up with the kernel NULL Pointer error.

That has me thinking that this problem has to be related to some module 
rearrangement/updating that takes place after you boot the box for the first 
time -- thus preventing the next boot from working.

I don't know how to verify or check this out, but this is what my gut tells me 
is going on.

Arch gurus -- any way to test this hypothesis??

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com