I actually get this also. My machine is a Mini-ITX the EPIA-800. My
machine will also lockup with the ondemand governor set. I tried using
cpufreqd and the userspace governor it worked fine with no lockups but
my recording clarity not good. I moved back to the performance governor.
It should be noted that before this thread I did not have the CPU
scaling drivers built into my kernel but still saw these interupt errors.
This is not something that really bothers me I am just posting to
hopefully provide some additional information. One thing I notice is
that after this my power button quits responding to acpid. So I push the
powerbutton expecting it to gracefully shut down and it just cuts the
power. I noticed these errors some where in the 0.3.x when I moved from
the 2.4.x kernel series to the 2.6.x kernel series.
See below for all relevant debug information.
Jonathan
ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.4.1 (development svn snapshot revision 2789) loading
ivtv: Linux version: 2.6.12.5 preempt CYRIXIII gcc-3.3
ivtv: In case of problems please include the debug info
ivtv: between the START INIT IVTV and END INIT IVTV lines when
ivtv: mailing the ivtv-devel mailinglist.
ivtv0: Autodetected WinTV PVR 350 card (iTVC15 based)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:14.0[A] -> Link [LNKB] -> GSI 10 (level,
low) -> IRQ 10
ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
tveeprom: Hauppauge: model = 48132, rev = K268, serial# = 7853014
tveeprom: tuner = LG TAPE H001F MK3 (idx = 68, type = 47)
tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
tveeprom: audio_processor = MSP3440 (type = 11)
ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
saa7115 1-0021: saa7115 found @ 0x42 (ivtv i2c driver #0)
ivtv0: i2c attach to card #0 ok [client=saa7115, addr=21]
saa7127 1-0044: saa7129 found @ 0x88 (ivtv i2c driver #0)
ivtv0: i2c attach to card #0 ok [client=saa7127, addr=44]
msp34xx: init: chip=MSP3448W-A2 +nicam +simple +simpler +radio mode=simpler
msp34xxg: daemon started
ivtv0: i2c attach to card #0 ok [client=MSP3448W-A2, addr=40]
tda9885/6/7: chip found @ 0x86
ivtv0: i2c attach to card #0 ok [client=tda9887, addr=43]
ivtv0: loading /lib/modules/ivtv-fw-enc.bin
ivtv0: loading /lib/modules/ivtv-fw-dec.bin
ivtv0: Encoder revision: 0x02040011
ivtv0: Decoder revision: 0x02020023
ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB
total)
ivtv0: Create encoder radio stream
ivtv0: Allocate DMA decoder MPEG stream: 16 x 65536 buffers (1024KB total)
ivtv0: Allocate DMA decoder VBI stream: 512 x 2048 buffers (1024KB total)
ivtv0: Create decoder VOUT stream
ivtv0: Allocate DMA decoder YUV stream: 24 x 43200 buffers (1024KB total)
ivtv0: loading /lib/modules/ivtv_init_mpeg.bin
tuner 1-0061: type set to 47 (LG NTSC (TAPE series))
ivtv0: Initialized WinTV PVR 350, card #0
ivtv: ==================== END INIT IVTV ====================
#cat /proc/interupts
CPU0
0: 234909627 XT-PIC timer
2: 0 XT-PIC cascade
7: 331308 XT-PIC acpi
8: 2 XT-PIC rtc
10: 88002009 XT-PIC ivtv0
11: 37242 XT-PIC eth0
12: 0 XT-PIC VIA686A
14: 606315 XT-PIC ide0
NMI: 0
ERR: 236109
# dmesg
irq 7: nobody cared!
[<c0135642>] __report_bad_irq+0x22/0x90
[<c0135738>] note_interrupt+0x58/0x90
[<c0135198>] __do_IRQ+0x128/0x140
[<c0104bcf>] do_IRQ+0x2f/0x60
[<c010335a>] common_interrupt+0x1a/0x20
[<c0260660>] acpi_processor_idle+0x120/0x260
[<c01010fc>] cpu_idle+0x4c/0x60
[<c042e766>] start_kernel+0x186/0x1c0
handlers:
[<c0244020>] (acpi_irq+0x0/0x20)
Disabling IRQ #7
spurious 8259A interrupt: IRQ7.
Jonathan
Hans Verkuil wrote:
> On Wednesday 26 October 2005 01:32, John-Marc Chandonia wrote:
>
>>I've encountered a strange bug in that ivtv 0.4.0 doesn't seem to get
>>along with the "ondemand" frequency scaling governor on my system
>>(2.6.13.2 kernel). After less than 24 hours of running, the system
>>disables the IRQ used by my PVR350. This always seems to happen at
>>night, and I'm guessing it's caused by the system switching from slow
>>to fast CPU speed while parsing new program listings. It may be a bug
>>in the governor rather than the ivtv driver, but I'm posting results
>>here just in case anybody is experiencing similar problems:
>>
>>Oct 23 02:38:19 gypsy kernel: irq 9: nobody cared (try booting with the
>>"irqpoll" option) Oct 23 02:38:19 gypsy kernel: [__report_bad_irq+42/160]
>>__report_bad_irq+0x2a/0xa0 Oct 23 02:38:19 gypsy kernel:
>>[note_interrupt+128/240] note_interrupt+0x80/0xf0Oct 23 02:38:19 gypsy
>>kernel: [__do_IRQ+308/320] __do_IRQ+0x134/0x140 Oct 23 02:38:19 gypsy
>>kernel: [do_IRQ+35/64] do_IRQ+0x23/0x40
>>Oct 23 02:38:19 gypsy kernel: [common_interrupt+26/32]
>>common_interrupt+0x1a/0x20 Oct 23 02:38:19 gypsy kernel: handlers:
>>Oct 23 02:38:19 gypsy kernel: [acpi_irq+0/22] (acpi_irq+0x0/0x16)
>>Oct 23 02:38:19 gypsy kernel: [pg0+507679328/1068168192]
>>(ivtv_irq_handler+0x0/0x730 [ivtv]) Oct 23 02:38:19 gypsy kernel: Disabling
>>IRQ #9
>>
>>After this, the PVR350 doesn't work again until the system is rebooted.
>>
>>ivtv shares the interrupt with ACPI:
>>
>>>cat /proc/interrupts
>>
>> CPU0
>> 0: 48513481 XT-PIC timer
>> 1: 10 XT-PIC i8042
>> 2: 0 XT-PIC cascade
>> 5: 0 XT-PIC ehci_hcd:usb1
>> 8: 1 XT-PIC rtc
>> 9: 16830118 XT-PIC acpi, ivtv0
>> 11: 629701 XT-PIC eth0, SiS SI7012
>> 12: 110 XT-PIC i8042
>> 14: 636422 XT-PIC ide0
>>NMI: 0
>>ERR: 49590
>>
>>I don't know when the bug was introduced, since this is the first
>>kernel I've tried since 2.6.8.1 that supported both "ondemand"
>>frequency scaling and a recent ivtv driver.
>>
>>Booting with the "irqpoll" option doesn't have any effect, but
>>switching to the "userspace" governor and using the cyudynd program
>>works fine and gives me a stable system.
>
>
> Can you move the card to another slot (and so to another IRQ number)? If the
> same problem occurs, then it does seem as if something might be wrong in the
> driver, but it could very well be caused by something else.
>
> Hans
>
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
