[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: System freeze with kernels after 2.6.12



On Thu September 28 2006 17:08, Harry Mofo wrote:
> I've been running Sarge, then Etch on this system for a couple years.
> It has been happily running 2.6.12-1 for a while but any attempt to use
> newer kernels has resulted in the system freezing - requiring a hardware
> reset.  Keyboard is nonfunctional except numlock will turn off (but not
> back on).  System becomes inaccessible via the network.  Sometimes the
> hard drive light is on solid.
>
> I've tried 2.6.15-1, 2.6.16-2 and 2.6.17-2.  All cause the system to
> freeze at some point - usually within 5 minutes of X starting but
> sometimes before it even reaches that point.  I normally use the K7
> kernel but have tried 486 as well with no change in symptoms.
>
> I tried a fresh install, thinking the original install just had some bad
> combination somewhere but that's a no-go as well.  Etch beta 3 installer
> freezes during "Installing core packages..." at 32-34% completion (it
> varies).
>
> There is no useful (to me) info in messages, syslog, nor dmesg.
>
> System details:
> Abit KT7 motherboard (Via KT133 chipset)
> Athlon 1GHz (Model 4 Stepping 2)
> 512 MB RAM
> Audio=SoundBlaster Live MP3+ (driver=emu10K1_audigy)
> Video=GeForce4 Ti4200-8x (NV28) (driver=nv)
> eth0=Netgear FA310Tx 10/100 (driver=tulip)
> hda=Samsung SP1614N 160GB ATA100
> hdc=Plextor PX-320A CDRW
> misc =Syba SD-V2-5U 	USB 2 adapter
>
> Does anyone have a clue what could be happening or any advice how to
> diagnose this further?



I've been running 2.6.17 for 2 days now so I think I can claim victory.

I compared boot messages between 2.6.12 and 2.6.15.  2.6.12 shows "ACPI: 
Interpreter disabled." while 2.6.15 shows "ACPI: Interpreter enabled" and 
many more ACPI-related messages.  If I use a "acpi=off" boot parameter with a 
newer kernel, no more freezes.

The newer kernels apparently decided to try using ACPI with this chipset but 
there is apparently a bug in the kernel or the chipset (or somewhere else?).  
I can live with this workaround.



Reply to: