Amahi Forums

I installed Amahi on my machine that has been running WHS for the past year. I am pretty confident that the hardware of this machine is fine and that I don't have memory problems, heat problems, etc.

On two occasions when I had my KVM switched over to a different PC and then switched to the server I had a blank screen and the machine seemed unresponsive. I could not SSH in either, IIRC. I had to hard-reset. It has just happened again while I was on the server desktop. The desktop froze up but the mouse cursor still moved around. I could not kill X, could not switch to a different VT, and again had to power-cycle to get the server back up.

There is nothing in the logs it seems; here is the last section:

Aug 2 23:37:52 server dhcpd: DHCPREQUEST for 192.168.1.207 from 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPACK on 192.168.1.207 to 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPREQUEST for 192.168.1.207 from 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPACK on 192.168.1.207 to 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPREQUEST for 192.168.1.207 from 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPACK on 192.168.1.207 to 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPREQUEST for 192.168.1.207 from 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPACK on 192.168.1.207 to 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPDISCOVER from 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:52 server dhcpd: DHCPOFFER on 192.168.1.207 to 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:53 server dhcpd: DHCPREQUEST for 192.168.1.207 (192.168.1.3) from 00:26:b0:65:d5:af (iPhone) via eth0
Aug 2 23:37:53 server dhcpd: DHCPACK on 192.168.1.207 to 00:26:b0:65:d5:af (iPhone) via eth0

I realize this is likely a Fedora issue and may have nothing to do with Amahi but thought I would start here just in case. Has anyone experienced this?

The only odd thing with my system is that I am using the IGP but I do have an ATI Radeon 3950 PCI-e card installed; I found that it didn't work out of the box with Fedora and had to use the IGP.

Mobo is a Gigabyte GA-G41M-ES2L; on board LAN is a RTL8111.

can you post the last 40 or so lines of your hardware log?

dmesg output is below. I did notice quite a number of similar complaints about Fedora 12 in the Fedora forums, with people reverting back to F11 or later finding F13 to be better. Is it possible to do an in-place update to F13 with an Amahi install?

r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
r8169 0000:03:00.0: setting latency timer to 64
r8169 0000:03:00.0: irq 29 for MSI/MSI-X
eth0: RTL8168c/8111c at 0xf7e7a000, 6c:f0:49:46:a1:11, XID 1c4000c0 IRQ 29
intel_rng: FWH not detected
ppdev: user-space parallel port driver
i801_smbus 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05
iTCO_wdt: Found a ICH7 or ICH7R TCO device (Version=2, TCOBASE=0x0460)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
HDA Intel 0000:00:1b.0: setting latency timer to 64
hdaps: supported laptop not found!
hdaps: driver init failed (ret=-19)!
input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input5
HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
HDA Intel 0000:01:00.1: setting latency timer to 64
device-mapper: multipath: version 1.1.0 loaded
EXT4-fs (sda1): mounted filesystem with ordered data mode
EXT4-fs (sdb1): mounted filesystem with ordered data mode
EXT4-fs (sdd1): mounted filesystem with ordered data mode
EXT4-fs (sdc1): mounted filesystem with ordered data mode
EXT4-fs (sde1): mounted filesystem with ordered data mode
Adding 4063224k swap on /dev/mapper/vg_server-lv_swap. Priority:-1 extents:1 across:4063224k
microcode: CPU0 sig=0xf64, pf=0x4, revision=0x4
platform microcode: firmware: requesting intel-ucode/0f-06-04
microcode: CPU1 sig=0xf64, pf=0x4, revision=0x4
platform microcode: firmware: requesting intel-ucode/0f-06-04
Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
Microcode Update Driver: v2.00 removed.
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ip6_tables: (C) 2000-2006 Netfilter Core Team
r8169: eth0: link up
r8169: eth0: link up
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
tun0: Disabled Privacy Extensions
eth0: no IPv6 routers present
Slow work thread pool: Starting up
Slow work thread pool: Ready
vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=none
vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
CPU0 attaching NULL sched-domain.
CPU1 attaching NULL sched-domain.
CPU0 attaching sched-domain:
domain 0: span 0-1 level CPU
groups: 0 1
CPU1 attaching sched-domain:
domain 0: span 0-1 level CPU
groups: 1 0
hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
fuse init (API version 7.13)

Linux does seem to complain about the intel chipset/graphics. You might need to install the Intel Linux drivers separately. For the graphics driver you can go to http://intellinuxgraphics.org/

HTH

Thanks. I did do a yum update about two days ago and the problem has not occurred since then so I'm hoping it is gone.