[PlanetCCRMA] Can't use rt-kernel from planetccrma-core

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Sat Sep 4 16:06:20 PDT 2010


On Sat, 2010-09-04 at 22:48 +0200, Filip Hoško wrote:
> Hi,
> daemon faileddaemon failed
> thanks for all your answers, my system specs are -
> 
> OS: Fedora 13 Gnome, kernel 2.6.34.6-47.fc13.x86_64 (stock, non-rt
> that works well - but with lots of xruns, so it's unacceptable)
> laptop: ASUS A6KM Q072 with buggy DSDT table (I have a fixed DSDT, but
> can't find a way to implement it into kernel)
> graphic card: Nvidia Geforce Go 7300, nouveau driver + mesa dri
> drivers and dri drivers experimental installed to make 3D work
> wireless: Broadcom BCM4318 with b43 driver
> on-board sound card: SiS AC'97
> firewire adapter and ext. sound card: Ricoh Co Ltd R5C552 with M-Audio
> ProFire 610 (firewire adapter actually works only partially and didn't
> work at all in Ubuntu.. It seem I'll have to buy a cardbus adapter
> with Texas Instruments chip in order to use my ProFire under Linux..)
> 
> ----
> 
> This is the output from /var/log/messages after the "hang" - 
> 
> Sep  4 15:10:35 Nemo kernel: imklog 4.4.2, log source = /proc/kmsg
> started.
> Sep  4 15:10:35 Nemo rsyslogd: [origin software="rsyslogd"
> swVersion="4.4.2" x-pid="1165" x-info="http://www.rsyslog.com"]
> (re)start
> Sep  4 15:10:35 Nemo kernel: Initializing cgroup subsys cpuset
> Sep  4 15:10:35 Nemo kernel: Initializing cgroup subsys cpu
> Sep  4 15:10:35 Nemo kernel: Linux version
> 2.6.33.6-147.2.4.rt28.1.fc13.ccrma.x86_64.rt
> (mockbuild at planetforge.stanford.edu) (gcc version 4.4.4 20100630 (Red
> Hat 4.4.4-10) (GCC) ) #1 SMP PREEMPT RT Mon Aug 2 15:24:36 EDT 2010
> Sep  4 15:10:35 Nemo kernel: Command line: ro
> root=/dev/mapper/vg_nemo-lv_root rd_LVM_LV=vg_nemo/lv_root
> rd_LVM_LV=vg_nemo/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM
> LANG=sk_SK.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> KEYTABLE=sk-qwerty rhgb quiet
> Sep  4 15:10:35 Nemo kernel: BIOS-provided physical RAM map:
> Sep  4 15:10:35 Nemo kernel: BIOS-e820: 0000000000000000 -
> 000000000009fc00 (usable)
> Sep  4 15:10:35 Nemo kernel: BIOS-e820: 000000000009fc00 -
> 00000000000a0000 (reserved)
> Sep  4 15:10:35 Nemo kernel: BIOS-e820: 00000000000e0000 -
> 0000000000100000 (reserved)
> Sep  4 15:10:35 Nemo kernel: BIOS-e820: 0000000000100000 -
> 000000003ffd0000 (usable)
> Sep  4 15:10:35 Nemo kernel: BIOS-e820: 000000003ffd0000 -
> 000000003ffde000 (ACPI data)
> Sep  4 15:10:35 Nemo kernel: BIOS-e820: 000000003ffde000 -
> 0000000040000000 (ACPI NVS)
> Sep  4 15:10:35 Nemo kernel: BIOS-e820: 00000000ff780000 -
> 0000000100000000 (reserved)
> Sep  4 15:10:35 Nemo kernel: NX (Execute Disable) protection: active
> Sep  4 15:10:35 Nemo kernel: DMI 2.3 present.
> Sep  4 15:10:35 Nemo kernel: AMI BIOS detected: BIOS may corrupt low
> RAM, working around it.
> Sep  4 15:10:35 Nemo kernel: No AGP bridge found
> Sep  4 15:10:35 Nemo kernel: last_pfn = 0x3ffd0 max_arch_pfn =
> 0x400000000
> Sep  4 15:10:35 Nemo kernel: x86 PAT enabled: cpu 0, old
> 0x7040600070406, new 0x7010600070106
> Sep  4 15:10:35 Nemo kernel: init_memory_mapping:
> 0000000000000000-000000003ffd0000
> Sep  4 15:10:35 Nemo kernel: RAMDISK: 37470000 - 37fef806
> Sep  4 15:10:35 Nemo kernel: ACPI: RSDP 00000000000f7870 00014 (v00
> ACPIAM)
> Sep  4 15:10:35 Nemo kernel: ACPI:Sep  4 15:13:20 Nemo kernel: imklog
> 4.4.2, log source = /proc/kmsg started.
> 
> ----
> 
> Then I rebooted again, deleted those parameters "quiet" and "rhgb" and
> did a boot with that rt-kernel (while in runlevel 3). Everything went
> fine until it stopped at Running Avahi Daemon ..... Failed (translated
> from slovak) and system froze. Maybe that Avahi daemon causes the
> hang?

Yes, most probably something is going wrong with avahi and the whole
system hangs. 

I don't see anything in the logs above that would indicate trouble. You
need to boot into the rt kernel - it fails, then restart the machine
into the Fedora kernel and look at /var/log/messages. The last part of
the logs will belong to the just performed successful reboot. So you
have to go back (maybe writing the time at which you boot the rt kernel
could help find it) and find the start of the successful boot - anything
_before_ that could help find what is going wrong. 

You could also try disabling avahi service but then part of the
functionality of the computer would not work (I don't know exactly
what). 

-- Fernando




More information about the PlanetCCRMA mailing list