Dreamboard

noggie · 3. April 2006

Box type: 7025
GUI (enigma1/enigma2): e2
Firmware version: dreamville 03-24

I've been running my 7025 with the root file system on CF for a while, and since the latest revision of the kernel patches, I've had a problem that the machine just hangs after some time when recording to HDD. This week-end, I moved my root file system to HDD instead (using CF just for the boot partition), and the problem seems to have disappeared. By running the following script, the system hangs after a few minutes. Sometimes I see a kernel message saying "hdc: lost interrupt".

Code

#! /usr/bin/python


import os


if os.fork():
    file = "/dev/ide/host0/bus0/target0/lun0/disc"
else:
    file = "/dev/ide/host1/bus0/target0/lun0/disc"


while 1:
    print "Open %s" % file
    fd = open(file, "r")


    i = 0
    while fd.read(4*1024):
        i += 1
    fd.close()

Alles anzeigen

My problem could also be caused by a faulty HDD or a faulty CF, so could someone with both CF and HDD be so kind and run the test and see what happens? I tend to believe that the sharing of the interrupt between CF and HDD is to blame, but I can't be sure until someone else can repeat it.

tmbinc · 3. April 2006

It's well possible that there is some bug. the IDE interface is muxed between the HDD and the CF card, however i think i made sure (by experiments) that the sharing does work properly. Well, maybe it doesn't.

It could, of course, be as well your CF card.

Does anybody else has a problem?

noggie · 4. April 2006

I've now tested with a different CF card, and the problem persists. A little while after starting my test program, the machine hangs up, or to be more precise, as soon as a process needs access to the IDE bus, it hangs forever. It also complains a couple of times on the serial console that it's loosing interrupts from hdc. The two cards I have tested are:
1. SanDisk 256MB (an old one, with no DMA capabilities)
2. TwinMOS 256MB Ultra-X 70X (does have DMA capabilities)

One other thing I've noticed. When running the TwinMOS 70X, hdparm correctly reports that it is able to run UDMA. However, the IDE driver will by default use PIO mode to access it, and if I try to force it to use UDMA, the machine just hangs. Does anybody have a good explanation?

nul00000 · 13. Juni 2007

hi noggie,
i see, iam not the only one who discovered that messages in syslog.

hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }

i experienced every 2-3 days short freezes (3-30 sec) when playing videofiles, dmesg reported that lost interupt stuff and some more for the cf card (see thread) in that cases. often the machine hangs up then completely.

i tried different hard drives, and different cf cards. the problem returned sooner or later in any combination.

i gave up using a cf card until a solution is found.

tmbinc · 16. Juni 2007

Ok, i will look into this again.

tmbinc · 22. Juni 2007

Hm, i've tried my best, but i could not provoke the error. I'm using noggie's script (which is basically how i've initially developed the driver: "(while true; do cat /dev/discs/disc0 > /dev/null; done & while true; do cat /dev/discs/disc1 > /dev/null; done)

I've let it run for some 10 minutes now, and i've tried 3 different CF cards.

(I have one Microdrive which already fails while booting. But I don't think this issue is related to the others..)

Maybe it's HDD related? Or CF? Is there a definite type of CF card/HDD combination which doesn't work, and still available in stores?

noggie · 22. Juni 2007

I also think it's an issue with my CFs, or as you say a combination with my disk. Since my disk is quit enough to run the root file system, I haven't done anything more with it.

In case my disk model should be an issue, here's what the system reports:

Code

root@dm7025:~# cat /proc/ide/hda/model
SAMSUNG HM160JC

One more thought: I had one of those bad power supplies, and that caused all sorts of really weird problems. Could this be one of them?

nul00000 · 25. Juni 2007

Zitat

Original von tmbinc
Hm, i've tried my best, but i could not provoke the error. .......
Maybe it's HDD related? Or CF? Is there a definite type of CF card/HDD combination which doesn't work, and still available in stores?

as mentioned above (and in the thread i linked too) i noticed that problems with cf cards and discovered related kernel messages too.

since 3 weeks iam not using cf card anymore and i have 3 weeks uptime (before max uptime 2 days).

to help you i tried noggies script with my old configuration:
i started it once and the next 10 minutes nothing happened.
to get a bit more traffic on ide bus i started it a second time.
now 2x noggie.py were running - kabooOOOOM! freeze within 30 seconds.
one service after another stopped working (first: shell isnt responding anymore, after 10 secs you cannot switch channels anymore, after 5 more seconds the tv-programm and sound is freezing too) - the old known behaviour. (since the shell blocked first - i couldnt refresh dmesg to see kernel messages).

now my config:

Enigma v2.2-2007-02-14, CVS Image ~ 14.02.
----------------------------------------------------------------
HDD Samsung HD400LD - 400 GB
/dev/ide/host0/bus0/target0/lun0/disc:
Model=SAMSUNG HD400LD, FwRev=WQ100-14, SerialNo=S0AXJ1EL924***
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled

CF CARD
labeled as: RiDATA CF CARD, 512MB, Pro-2, 80X
/dev/ide/host1/bus0/target0/lun0/disc:

Model=KTC CF, FwRev=YUAN1026, SerialNo=KTC CF
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=1007/16/63, TrkSize=0, SectSize=512, ECCbytes=4
BuffType=1Sect, BuffSize=0kB, MaxMultSect=1, MultSect=off
CurCHS=1007/16/63, CurSects=1015056, LBA=yes, LBAsects=1015056
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:480,rec:480}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0
UDMA modes: udma0 udma1 udma2
AdvancedPM=no

I experienced same problems (not re-tested with noggie script atm) with Maxtor 6B200P0 200GB Harddrive and a CF Card labeled as A Data, MyFlash 512MB 120X in any combination.

Zitat

Original von noggie
One more thought: I had one of those bad power supplies, and that caused all sorts of really weird problems. Could this be one of them?

I also thought that - i bought a a new power supply (the new series), installed a 21cm fan just to be sure, the box is now far below room temp :P, but the freezers remain.

tmbinc: at least the RiDATA CF Card should be still availabled in Mediamarkt - where i bought it some months ago - if not - i would send you mine

tmbinc · 26. Juni 2007

Hm, I still couldn't reproduce the problem.

However, I've found that my microdrive didn't worked (irq problem while booting, so still not the same problem as you have), and fixed that.

I've attached the new kernel. maybe you can check if this makes any difference?
(just copy to /tmp via ftp, and then do "ipkg install /tmp/kernel_image*.ipk" via telnet, and reboot)

nul00000 · 27. Juni 2007

problem still there.
i tried three times:
a) hangup after 20 seconds with 2x noggie.py &
b) hangup after 15 minutes with 2x noggie.py &
c) hangup after 3 minutes with 1x noggie.py AND playing video fast forward 32x

does it make sense to connect a terminal@rs232 to capture a dbg message from the kernel? (as atm i dont have a rs232 connector at the laptop i would get some).

tmbinc · 27. Juni 2007

yes, that will definitely make sense.

Can any of you try to see if a different HDD makes a difference?

nul00000 · 28. Juni 2007

Ok provoked it 3 times with serial bootlog attached.
hdc related things in the log:

select 1
hdc: KTC CF, ATA DISK drive
hdc: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdc: set_drive_speed_status: error=0x04 { DriveStatusError }
ide1 at 0x2410-0x2417,0x2422 on irq 3
select 0
hda: SAMSUNG HD400LD, ATA DISK drive
ide0 at 0x2410-0x2417,0x2422 on irq 3 (shared with ide1)
hdc: max request size: 128KiB
hdc: 1015056 sectors (519 MB) w/0KiB Cache, CHS=1007/16/63
hdc: cache flushes not supported
/dev/ide/host1/bus0/target0/lun0:select 1
p1 p2 < p5 p6 > p3
hda: max request size: 1024KiB

.....box is booting until idle...

starting noggie.py, the frequency of
select 1
select 0
increases heavily.

10...20 seconds later:

hdc: lost interrupt
action -> InfobarShowHideActions toggleShow
hdc: lost interrupt
INIT: Id "1" respawning too fast: disabled for 5 minutes
hdc: lost interrupt
hdc: lost interrupt
[EPGC] start cleanloop
[EPGC] stop cleanloop
[EPGC] 2178145 bytes for cache used
hdc: lost interrupt

since the first "hdc: lost interupt" the box is starting to freeze - that means:
a) you can press enter on shell - still alive - if you issue a real command it never returns
b) i press ok (see action-> ...) the infobar appears incompletely and never disappears
c) the last thing that stops is the clock in the lcd display (and of course some time (often minutes) later the video/audio)

the box is still pingable. even the enigma EPGC-thread is continuing its work. but all the important things are hung - the kernel is busy dealing around with the lost hdc interrupts.

i tried also setting udma2 mode on the cf card (unsure if it does make sense) - no difference.
-----------------------------------------------------------------------------------------------

Zitat

Original von tmbinc
Can any of you try to see if a different HDD makes a difference?

retried the whole procedure with a factory new and fresh initialized MAXTOR Diamond Plus 8 - 40GB drive. no difference.

-----------------------------------------------------------------------------------------------

ps: just to ensure that problem is really kernel-related i would like to reproduce it the way you did. i guess you used your own NFI2CF to get the image onto the cf card? any image(cvs)date recommendations?

tmbinc · 28. Juni 2007

I've booted either an image or via NFS. I haven't booted from CF.

nul00000 · 4. Juli 2007

tmbinc: heute mal dann ein versuch nach deiner methode, gebootet aus dem flash boxman cvs testimage 2007-06-01. CF card ist natürlich auch im system.
2x noggie.py & (startabstand ca. 30 sec)

dmesg zwischendurch dann (bisher noch nicht gesehen):
i2c0: irq with inactive waitqueue
xilleon_i2c: timeout waiting for IRQ!
und nach ein weiteren paar minuten
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt
hdc: lost interrupt

jetzt hängt sich natürlich der rest nicht auf da nun das rootfs ja nicht auf der cf liegt.
diese ist ab dem ersten lost interrupt nun natürlich unbenutzbar, sprich ein ls /media/cf (ls /media/hdd interessanterweise auch nicht) kehrt niemals zurück.

enigma2 läuft aber 1A weiter, mit dem flash ist immernoch alles in ordnung - ich nehme aber an würde ich jetzt eine aufnahme starten wäre dann damit auch schluss da der das warten auf die hdd kein ende hätte.

alle prozesse die nun sich mit einer der beiden ide medien anlegen landen im status "D uninterruptible sleep (usually IO)".

einen stapel cf karten habe ich schon liegen für meinen nächsten post ;P

Lost in Translation · 19. Juli 2007

short input in english:

have you tried using the mount -o async option if it improves the situation, because my assumption is that there is synchronous IO happening blocking the async one which might cause the hangings.

So simply forbidding synchronous IO for CF & Harddisk could be worth a try.

------------------------------------------------------

nachdem das problem scheinbar auch den Multibootern von CF karte das Leben schwer macht, darf ich vieleicht auch mal meine Gedanken einbringen ?

Ich habe mein Unix ja auf 'ordentlichen' Unix Servern gelernt (nichts gegen die Pinguine, aber vor 20 jahren lebten die halt nur in der Antarktis und in Südamerika)

Gefühlsmässig würde ich sagen das die Locks die man mit noggie's script so schön reproduzieren kann dadurch passieren, das irgend jemand synchronen IO macht wodurch dann asynchroner nicht drankommt und das geht dann halt böse aus.

Habt Ihr evt. schon mal probiert mit -o async zu mounten, weil normalerweise ist Unix schon ziemlich gut solche lock situations zu verhindern, aber man kann ja ein bischen 'helfen' indem man synchonen IO 'verbietet'

Für eine Systemdisk was die CF ja beim Multibooten und swappen de-facto darstellt macht das auch durchaus Sinn sie so zu mounten und der Harddisk sollte es auch nicht schaden. Und mit den writeback, journal und commit options sollte man eigentlich auch ein bischen spielen können ob sich dadurch was ändert.

Vieleicht sind meine Inputs/Ideen ja auch Blödsinn, aber wenn ich nicht immer auch den Blödsinn ausprobiert hätte dann hätte ich weniger dabei gelernt.

LG
gutemine

Cenic · 19. Juli 2007

Hi,

Zitat

Original von gutemine
Habt Ihr evt. schon mal probiert mit -o async zu mounten, weil normalerweise ist Unix schon ziemlich gut solche lock situations zu verhindern, aber man kann ja ein bischen 'helfen' indem man synchonen IO 'verbietet'

Laut Linus macht Linux eh immer async, weil es schneller ist (und manchmal eben auch nur schneller kaputt):

Linux ext2fs vs. ufs vs. presto

Lost in Translation · 19. Juli 2007

Na ja dann wird das auch nicht viel helfen wenn man es noch extra beim mounten angibt

Wie schon gesagt ich komme aus einer Zeit als logbasiereden Filesystem noch den teuren kommerziellen Unix Systemen vorbehalten waren, IO langsam war und die Platten kaum cache hatten. Um es mit Olove zu sagen - ein altes Mädchen halt

Ich spiel mich halt mal ein bischen mit den anderen mount Parametern und werde berichten ob es was ändert.

Die meisten kontrollieren aber nur das Schreibverhalten, aber mal sehen, im prinzip geht es ja darum das man aufnehmen kann ohne Hänger zu produzieren.

LG
gutemine2

HeiRos · 19. Juli 2007

Zitat

Original von gutemine
Die meisten kontrollieren aber nur das Schreibverhalten, aber mal sehen, im prinzip geht es ja darum das man aufnehmen kann ohne Hänger zu produzieren.

Das Ganze passiert nicht nur beim Aufnehmen. Es hat bei mir schon gereicht, daß ich die Picons auf der CF hatte und die Box daraufhin manchmal hdc-Fehler ins Syslog geschrieben und einige Zeit nicht mehr auf die Fenrbedienung reagiert hat. Beim Booten von CF ging es soweit, daß beim Anschauen einer Aufnahme plötzlich die Wiedergabe stand, keine Reaktion auf die Fernbedienung erfolgte und auch kein Konsolen-Login mehr möglich war. Das einzige Lebenszeichen der Box war über mehrere Minuten ein regelmäßiges "hdc: lost interrupt" im Syslog. In dem Fall half nur noch Ausschalten per Netzschalter.

HeiRos

Lost in Translation · 20. Juli 2007

na ja so schlimm hatte ich es noch nie - wobei ich picons nicht verwende.

Ich kann mehrere Aufnahmen von einem Transponder starten damit der Disk so richtig warm wird und trotzdem normal im enigma2 herumzappen und TV gucken.

Und so Sachen wie dabei noch einen Film von Harddisk anschauen und den noch Vorspulen sollte man sich auch im Flash 2x überlegen.

Nachdem noggie's script ja den IO direkt aufs IDE device produziert bin ich auch nicht sicher ob man durch mount oder diverse Kernel Options damit was beieinflussen kann, aber wer nicht sucht der nicht findet.

LG
gutemine

nul00000 · 20. Juli 2007

Zitat

Original von gutemine
na ja so schlimm hatte ich es noch nie - wobei ich picons nicht verwende.

ich schon. manchmal 2-3 tage keinen hänger (bei stetig sehr intensiver nutzung (aufnahmen im hintergrund, film von platte schauen)) - und dann innerhalb 30 minuten 5 hänger.

Zitat

Original von gutemine
Ich kann mehrere Aufnahmen von einem Transponder starten damit der Disk so richtig warm wird und trotzdem normal im enigma2 herumzappen und TV gucken.

konnte ich auch. provozieren konnte ich das im grunde überhaupt nicht. vollkommmen sporadisch (allerdings im rahmen von max 2 tagen up). seit noggies script kann ichs innerhalb sekunden bis minuten.

Zitat

Original von gutemine
Und so Sachen wie dabei noch einen Film von Harddisk anschauen und den noch Vorspulen sollte man sich auch im Flash 2x überlegen.

kann ich nicht bestätigen, seit ich der cf abgeschworen habe (bis ein fix da ist) habe ich eine uptime von 3 wochen erreicht - und dann habe ich auch nur selbst neu gestartet um weitere provokationstests auf der cf durchzuführen. bzw. jetzt starte ich nur alle 5-8 tage neu weil mir enigma vor allem in der videoliste einfach zu träge wird (der pythonfix hat da nichts gebracht).

kurzum: seit also fast 2 monaten benutze ich ein boxman cvs (1.6.) im flash und habe nicht einen einzigen crash oder hänger gehabt. davor alle 2 tage.
gaaaaanz langsam hab ich die box auch wieder lieb.

dennoch hätte ich natürlich gern meine cf wieder die platz für compiler usw. bot - aber im moment leider nicht praktikabel