All action stops. Unless something is happening. {?}
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
All action stops. Unless something is happening. {?}
Yeah, I know that's a pretty bad thread title, but that's the only way I can think of to describe my current problem succinctly.
In full, I recently (Yesterday) installed Slackware 12.0 on my new Acer Aspire 5100 Laptop. the machine has an AMD Turion64x2 processor, 1GiB of RAM and an ATi chipset though I can't find many details in my documents (Other than the Radeon Xpress 1100 Graphics) lsmod and lspci will follow.
Almost everything works pretty much as expected (I know I have some un- or poorly-supported hardware like the built in microphone and webcam) unfortunately at boot time (Using the "vmlinuz-huge-smp-2.6.21.5-smp" kernel) almost immediately after, and sometimes just before:
Code:
INIT: version 2.86 booting
... well, here's a snippet of the log:
Code:
Sep 6 18:13:42 aydindril kernel: raid6: using algorithm sse2x2 (2985 MB/s)
Sep 6 18:13:42 aydindril kernel: pIII_sse : 4904.000 MB/sec
Sep 6 18:13:42 aydindril kernel: raid5: using function: pIII_sse (4904.000 MB/sec)
Sep 6 18:13:42 aydindril kernel: Using IPI Shortcut mode
Sep 6 18:13:42 aydindril kernel: VFS: Mounted root (ext3 filesystem) readonly.
Sep 6 18:13:42 aydindril kernel: Clocksource tsc unstable (delta = 9373545226 ns)
Sep 6 18:13:42 aydindril kernel: i2c_core: exports duplicate symbol i2c_smbus_write_i2c_block_data (owned by kernel)
Sep 6 18:13:42 aydindril kernel: kobject_add failed for ehci_hcd with EEXIST, don't try to register things with the same name in the same directory.
Sep 6 18:13:42 aydindril kernel: [<c03e86f7>] kobject_shadow_add+0x117/0x1a0
The problem begins apparently right at the Clocksource line.
The problem is that, unless I am actively providing input (Anything from typing or holding a key to moving my finger around on the laptops touchpad mouse) the entire machine seems to stop. not freeze. not crash. just stop. Initial responses on IRC and from searching the internets led me to believe that I was having an ACPI issue, so I tried to append acpi=off to my boot paramaters... for some reason that was good for providing me with a pleasant
Quote:
VFS: unable to mount root filesystem, kernel panic
It was then suggested that I disable ACPI in my BIOS. unfortunately, I have no such option. I also tried issuing
Code:
# /ect/rc.d/rc.acpid stop
but as I expected that didn't work (the problem starts before rc.M starts rc.acpid).
I can't really think of anything else I can add without first knowing where I should look further
I wish I knew more, unfortunately (ha ha) I rarely have problems with Slackware, so I don't get many chances to fix it!
So, for excessive informations sake, here's my lsmod and lspci:
<snip>
Sep 6 18:13:42 aydindril kernel: Clocksource tsc unstable (delta = 9373545226 ns)
Sep 6 18:13:42 aydindril kernel: i2c_core: exports duplicate symbol i2c_smbus_write_i2c_block_data (owned by kernel)
Sep 6 18:13:42 aydindril kernel: kobject_add failed for ehci_hcd with EEXIST, don't try to register things with the same name in the same directory.
Sep 6 18:13:42 aydindril kernel: [<c03e86f7>] kobject_shadow_add+0x117/0x1a0
You should read the txt that 'PV' provides for you!
excerpt from Slackware 12 'CHANGES_AND_HINTS.TXT'
As stated earlier, it is recommended that you use one of the generic kernels
rather than the huge kernels; the huge kernel is primarily intended as
an "installer" and "emergency" kernel in case you forget to make an initrd.
However, if you do use one of the huge kernels, you will likely encounter
errors like this:
kobject_add failed for uhci_hcd with -EEXIST, don't try to register
These occur because the respective drivers are compiled statically into the
huge kernels but udev tries to load them anyway. These errors should be safe
to ignore, but if you really don't want them to appear, you can blacklist the
modules that try to load in /etc/modprobe.d/blacklist. However, make sure you
remove them from the blacklist if you ever decide to use the (recommended)
generic kernels.
Okay, with the generic smp kernel and the initrd I can now boot with acpi=off. but my problem remains.
Istill get the clocksource tsc unstable error, the machine still stops when not getting direct manual stimulation (Poor phrasing... I should say, direct outside input, or something to that effect.)
My lilo.conf (Most comments removed for brevity)
Code:
# Start LILO global section
boot = /dev/sda
message = /boot/boot_message.txt
prompt
timeout = 1200
# Override dangerous defaults that rewrite the partition table:
change-rules
reset
# VESA framebuffer console @ 1024x768x256
vga = 773
# Linux bootable partition config begins
image = /boot/vmlinuz-generic-smp-2.6.21.5-smp
initrd = /boot/initrd.gz
root = /dev/sda1
label = Linux
read-only
image = /boot/vmlinuz-generic-smp-2.6.21.5-smp
initrd = /boot/initrd.gz
root = /dev/sda1
append = "acpi=off"
label = TEST
read-only
## this is the default "Huge-smp" kernel installed by slackware
image = /boot/vmlinuz
root = /dev/sda1
label = Huge
read-only
# Linux bootable partition config ends
All three of those configurations will boot, they all behave exactly the same.
my approach on this would be to go for a kernel compiled for your machine. you have an advanced processor and architecture, your right on the bleeding edge. at the very least you should have the latest kernel updates from slackware.com (typically ending in '-2').
check out my thread on installing slackware, getting the latest kernel updates and more importantly on how to compile a kernel for your system... (click on my signature)
and let us know how it turns out.
chances are there are particularities related to your processors related to the kernel and only a properly compiled kernel for your machine will be a best match. which says nothing to the fact that you need cpu cooling, not on by default with the generic/huge kernels...
I wonder if someone will reply while I'm typing again
Thanks perry, I'll be reading your thread later on. I do know how to compile a custom kernel, and I'll definitely try that once any other options have been attempted... It's a big job, especially since I can't just leave the computer while it's compiling (otherwise It will stop). I'd much rather explore different options in configuration first.
Thanks for the advice though, because this is certainly a good time for me to begin collecting information about which kernel modules I'm going to need.
I wonder if someone will reply while I'm typing again
Thanks perry, I'll be reading your thread later on. I do know how to compile a custom kernel, and I'll definitely try that once any other options have been attempted... It's a big job, especially since I can't just leave the computer while it's compiling (otherwise It will stop). I'd much rather explore different options in configuration first.
Thanks for the advice though, because this is certainly a good time for me to begin collecting information about which kernel modules I'm going to need.
Hi,
You don't have too build your new kernel on the resident machine. If you have another machine to use for the build then all you need to do is make certain the'.config' file is correct for the compile session. Then move the kernel image and the '`/lib/modules' together. If you have LAN then the move is just a matter of using the 'scp'. Otherwise you will need another medium since the kernel plus modules will be rather big, a flash will work fine.
As for the configuration, I tend to lean towards what perry suggested. You should create a new custom kernel with modules for your machine.
I wonder if someone will reply while I'm typing again
Thanks perry, I'll be reading your thread later on. I do know how to compile a custom kernel, and I'll definitely try that once any other options have been attempted... It's a big job, especially since I can't just leave the computer while it's compiling (otherwise It will stop). I'd much rather explore different options in configuration first.
Thanks for the advice though, because this is certainly a good time for me to begin collecting information about which kernel modules I'm going to need.
Code:
init 3
cd /usr/src/linux
{setup your kernel as indicated by the link below}
make all
make modules_install
make install
There is a chance that X is the one doing the locking up. init 3 will put you back into terminal mode. go init 4 to start x again
There is no "Lock up" perry just a stop. X isn't a problem.
In fact, since doing a few re-boots, the problem seems more sporadic. I'm not experiencing it right now, so I have no reason not to build myself a kernel -- as well as do some package updating, and standard configuring
@ rworkman, I've tried the notsc option. Unfortunately, I get no significant improvement.
It's frustrating. I'm pretty sure it's a kernel thing at this point. We'll see once I get my new kernel up and tweaked.
@ rworkman, I've tried the notsc option. Unfortunately, I get no significant improvement.
It's frustrating. I'm pretty sure it's a kernel thing at this point. We'll see once I get my new kernel up and tweaked.
Okay, I talked again with PiterPunk - it seems that one of the power-saving options in the kernel (for Intel chipsets) caused some breakage on some AMD chipsets. Try passing "idle=poll" to the kernel and see if that makes a difference.
I wish I could say that worked.
I've also tried a new kernel with these differences:
where "old.configfile" belongs to the standard generic-smp kernel
Code:
root@aydindril:/usr/src/linux# diff old.configfile .config
4c4
< # Tue Jun 19 14:44:11 2007
---
> # Mon Sep 10 03:12:09 2007
35c35
< CONFIG_LOCALVERSION="-smp"
---
> CONFIG_LOCALVERSION="-nrm"
165,166c165
< CONFIG_HPET_TIMER=y
< CONFIG_HPET_EMULATE_RTC=y
---
> # CONFIG_HPET_TIMER is not set
168c167
< CONFIG_SCHED_SMT=y
---
> # CONFIG_SCHED_SMT is not set
170,171c169,170
< CONFIG_PREEMPT_NONE=y
< # CONFIG_PREEMPT_VOLUNTARY is not set
---
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
220,221c219,220
< CONFIG_HZ_250=y
< # CONFIG_HZ_300 is not set
---
> # CONFIG_HZ_250 is not set
> CONFIG_HZ_300=y
223c222
< CONFIG_HZ=250
---
> CONFIG_HZ=300
I wasn't sure what differences there would be, but they didn't make the difference I wanted.
I'm starting to feel at a loss but I sincerely thank you all for the help so far!
Last edited by truthfatal; 09-10-2007 at 11:03 PM.
Reason: clarification
I wish I could say that worked.
I've also tried a new kernel with these differences:
where "old.configfile" belongs to the standard generic-smp kernel
Code:
root@aydindril:/usr/src/linux# diff old.configfile .config
4c4
< # Tue Jun 19 14:44:11 2007
---
> # Mon Sep 10 03:12:09 2007
35c35
< CONFIG_LOCALVERSION="-smp"
---
> CONFIG_LOCALVERSION="-nrm"
165,166c165
< CONFIG_HPET_TIMER=y
< CONFIG_HPET_EMULATE_RTC=y
---
> # CONFIG_HPET_TIMER is not set
168c167
< CONFIG_SCHED_SMT=y
---
> # CONFIG_SCHED_SMT is not set
170,171c169,170
< CONFIG_PREEMPT_NONE=y
< # CONFIG_PREEMPT_VOLUNTARY is not set
---
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
220,221c219,220
< CONFIG_HZ_250=y
< # CONFIG_HZ_300 is not set
---
> # CONFIG_HZ_250 is not set
> CONFIG_HZ_300=y
223c222
< CONFIG_HZ=250
---
> CONFIG_HZ=300
I wasn't sure what differences there would be, but they didn't make the difference I wanted.
I'm starting to feel at a loss but I sincerely thank you all for the help so far!
*Sporatic*
I know what that is like... it has nothing to do with Linux. It wouldn't matter if you had Windows installed either.
It's your Bios! You got your system setup for high performance or something similar. Go back and change your Bios to either default settings or something much more reserved.
Ran into the same problem two weeks ago when a failed Lilo re-write took out my Cmos settings. Spent a week trying to get it figured out only to find out that just the default/basic settings in the Bios stopped the *eratic* behaviour that my formerly working Linux install was exhibiting.
Bet you any money you've got your Bios setup for high performance! Check out the web for other owners of your machine possibily having similiar problems!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
