[vdr] Re: system hangs after deleting records in vdr

[Usenet-372112@zocki.toppoint.de (Rainer Zocholl)]

mobil.mail@freenet.de 15.10.01 00:06

Once upon a time shaped the electrons to say...

>>>>>My system is a 1GHZ Thunderbird, NMC 8TAX+ MB, 256MB Ram,
>>>>>>>Hauppauge Rev 1.3 Sat card, 80 Maxtor disk, Suse 7.2.
>>>Suse 7.2 comes with kernel 2.4.4 an that one I use

[assuming: no hardware error]

>But the strange thing: I formated the disk with reiserfs, did all the
>tests, like daylong kernelcompiling, filling the disk with data and so
>on nothing happens, and then the same thing happens again (as shown in
>my first posting):

>Oct 12 23:36:20 video vdr[745]: removing
>/video/jag/2001-09-16.14.58.99.99.del/marks.vdr
>Oct 12 23:36:20 video
>vdr[745]: removing /video/jag/2001-09-16.14.58.99.99.del/index.vdr
>Oct 12 23:36:20 video vdr[745]: removing
>/video/jag/2001-09-16.14.58.99.99.del/001.vdr
>Oct 12 23:36:23 video vdr[745]: removing /video/jag/2001-09-16.14.58.99.99.del/resume.vdr
>Oct 12 23:36:23 video vdr[745]: removing /video/jag/2001-09-16.14.58.99.99.del
>Oct 12 23:36:23 video vdr[745]: removing /video/jag
>Oct 12 23:36:23 video vdr[745]: max. latency time 3 seconds 
>### here unprintable characters, something dies! ###

All "\@" ?

>Oct 12 23:58:23 video sshd[376]: Server listening on :: port 22. and at 23:58:23 the machine was up again.


>To find something about these strange things, I created anonther
>script, that writes every second the current time to a logfile. 


>If the machine was restarted, the last logfile (and so the last time, the
>system was alive) was kept. And in this case, the last logfile entry
>was at 23:47:45!?? So some minutes, parts of the system work.

Try a "sync" so the data is actually written to disc and not
hold in the memory.

A better way would be to write it to the serial port or
directly to the VGA memory.


>I saw, Axel knows this problem. I don't think too, it's a hardware
>problem, but where can it come from?

Does Axel have too a 80GB disk?
Maybe a Maxtor too?


>I think one possible problem is that deleting such huge files (about
>2GB) takes some time and the deleting of the directory comes to fast
>(in my case, the deleting of the vdr-file needs 3 seconds, then the
>directory was deleted).

Hm...that would be a problem of the filesystem, not vdr.
(It is possible that VDR brings that bug up...but i don't
understand while this crash do not occure at more other users.
All have to delete files.
But this seems to be independend of the FS in use.
Maybe something in the 2.4.4 kernel is wrong?
But there are others with that kerenel who do not have the problem, or?


>One hint is that in the vat-case a checkdisk restores the deleted
>directory again. I run reiserfsck on my now reiserfs formated disk an
>found errors after the crash like

>"block 142213xx is not marked as used in the disk bitmap" 
>for many blocks or
>"bad_indirect_item: block 20383: item 150 153 0x51e07001 IND, len
>4048, entry count 0, fsck need 0, format old has a pointer 44 to the
>block 14221330 which is in tree already"

>and the were definitely caused by that crash, because come old records
>show some seconds of a new one (cross linked blocks)!

Did you turn "write cache" in the disc off?
(hdparm) 
That's strongly recommended on journaling FS.


"crosslinks" happens in FAT if a sector is written into
the wrong disk position, because the did not place the head right.
(Yes, shit happens ;-)
This would fit to the garbage reisefs found.

Most often the RAM-contens is bad (maybe caused by a 
pointer error or DMA!),  and -in the time of "non-UDMA"-
it was possible to corrupt the data on the way to the disk.
(That's why i asked these things. The reason why i ask
for hardware is that such an error in a software  should 
have give more complaints.
BTW: Which RAM test did you use?)