[linux-dvb] Re: Driver crash (ARM Crash)

[Michael Hunold <hunold-ml@web.de>]

Hello Tim,

although I'm only the saa7146 author and not the av7110 guru,
here are my thoughts:

> in my box (K6-2 300 on Apollo VP3) i always had a few problems with the
> driver and my Hauppage card. Now i've been able to track it down a bit
> and send some traces. 
Your box is quite slow -- I noticed that the cards are very sensitive 
against interrupt or system delays of any kind.

> I am using the current version of dvb-kernel and a 2.5.54 kernel.
> Everything is installed as described in the README. And i am using the
> driver with vdr.
I recently fixed the i2c-transfer in the saa7146 driver. It tried to use 
interrupts for the transfers to lower the system load -- but 
unfortunately this resulted in "oops" messages and sometimes TS lockup.

> when i am using my harddrive with DMA (udma, mdma) i see ARM crashes
> with kernel OOPS. If the drive is using PIO everything runs stable. the
> rest of the systems runs stable now for years with udma !
> <4>blk: queue c0398e1c, I/O limit 4095Mb (mask 0xffffffff)
> <6>hda: tagged command queueing enabled, command queue depth 32

Are you sure you want to run tcq on an ide drive? It's only fully 
supported on some ibm(?) harddisks afaik. Does your drive support tcq at 
all?

> With PIO i get a blocky picture when i hear the driver write data onto
> the disk.With DMA i get a perfect picture till the hole machine goes
> oops.
One problem is the via pci<->ide arbitration, in conjunction with pci 
devices that create high pci bus loads. (Remember the via bug?) I have 
had severe problems with saa7146 based cards and via chipsets (for me: 
the kt133a on a ecs k7zva mainboard) -- I came to the conclusion to drop
all via based systems and did not buy via again.

PIO creates a high cpu load (and probably pci bus, too), so it's likely 
that the saa7146 cannot write to the gfx card's framebuffer as fast as 
it should.

> If i am using timeshifting the driver oopses after a few seconds, if i
> am just recording it runs a few minutes.
Again: the problem is the pci load that the saa7146 creates when writing 
to the framebuffer. If you only record, then the load is much lower.

> On 2.4.20 with the cvs-driver i had the same problems except that i
> didnt saw a kernel oops and after rmmod/insmod everything ran o.k.
> again.
Please try again with the latest cvs driver. At least some of the oops 
messages should go away.

> I attached the "cat /proc/kmsg" traces i did remote. i didnt attached
> the kernel oops yet (i will send it if someone is interested) because
> the oops (unable to handle kernel paging request at virtual adress
> xxxx)occurs endlessly on the screen and i'll have note it down by hand
> and type it in again.
If you decide to do so, please run it through "ksymoops" first, because 
otherwise it's unusable for the developers.

> <4>buffer empty
> <4>buffer empty
> <4>buffer empty
> <4>gpioirq unknown type=49792 len=9217
> <4>av71100: ARM crashed!
I cannot comment on the actual av7110 errors here, sorry. I don't know 
how graceful the whole frontend<=>av7110<=>saa7146 connection is, and 
what happens in case of buffer overflows/underflows.

> thanks
> Tim Schröder

CU
Michael.



--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.