Am 10.11.2012 11:35, schrieb Arnaud Patard "(Rtp): > David Pottage <da...@chrestomanci.org> writes: > > Hi, > >> On 07/11/12 22:03, Hoshpak wrote: >> >>> I'm currently trying to install Debian GNU/Linux on a Qnap TS-219 PII which >>> is based on the Marvell Sheeva platform. I followed the instructions which >>> can be found at http://www.cyrius.com/debian/kirkwood/qnap/ts-219/ so far, >>> backed up the original firmware, downloaded the installer files and flashed >>> them. >>> >>> After rebooting the device, I am now able to log into the device using ssh >>> and start the installer. The only problem is, after a few minutes the >>> device resets itself thus aborting the installation process. This happens >>> no matter if the installer is actually doing something or just waiting for >>> input. Since the ssh-session is killed instantly when it happens, I >>> couldn't find out what caused the device to reset itself. >>> >>> This only happens when the Debian installer is loaded (I tried stable and >>> testing so far) and not with the original firmware so I believe the device >>> itself is just fine. Did anyone else experience this strange behaviour with >>> this Qnap system or could think of possible reason or an alternative way to >>> get the installation done? >> >> It sounds to me like the hardware has a watchdog device, which >> automatically reboots it if it does not receive a magic signal from >> the OS at regular intervals. >> >> These things are quite common on consumer embedded devices such as >> cable modems, as they help hide bugs in system software. A bug that >> would normally cause a hard lock-up will instead cause the device to >> reset, which the user might not notice if they where not using it at >> that moment. >> >> Can you do some experiments to see how long after power on the reset >> happens? My guess is that it will be after a fixed interval. >> >> You could also try taking the motherboard out an photographing it to >> see if anyone in the community can identify the offending component. > > Orion and kirkwoods SoCs have a watchdog so if this watchdog is used, > you won't notice it with a photo. If you can log into the vendor os, > looking at the sysfs (for instance, /sys/class/misc/watchdog) may help.
Thanks, the watchdog indeed seems to be the problem here. I stopped the time and the device resets itself exactly five minutes after it has booted the installer. So at least the device is not broken. After flashing back the kernel from the Qnap firmware and logging into it I found the watchdog information where they were supposed to be: [/proc/708] # ls -la /sys/class/misc/watchdog/ drwxr-xr-x 2 admin administ 0 Nov 10 13:55 ./ drwxr-xr-x 14 admin administ 0 Nov 10 13:54 ../ -r--r--r-- 1 admin administ 4096 Nov 10 13:56 dev lrwxrwxrwx 1 admin administ 0 Nov 10 13:56 subsystem -> ../../misc/ -rw-r--r-- 1 admin administ 4096 Nov 10 13:56 uevent [/proc/708] # cat /sys/class/misc/watchdog/dev 10:130 [/proc/708] # cat /sys/class/misc/watchdog/uevent MAJOR=10 MINOR=130 DEVNAME=watchdog Also present on the system is a daemon called "qwatchdogd" which seems to ping the watchdog device every second. I couldn't find a way to disable it (qwatchdogd has a "-d" switch but after the next reboot the watchdog is active again). I couldn't find a kernel module responsible for the watchdog functionality so it might be compiled into the stock firmware kernel. Does this information help to identify the watchdog device? So it seems to perform a successful installation, I would need a Debian installer with both a kernel that supports the watchdog device and a running daemon pinging the watchdog device, right? Helmut -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509e72f0.50...@pozimski.eu
