Rafał,
Thanks very much for the patch - much appreciated.
On 27 Aug 2007, at 14:13, Rafał Krypa wrote:
> Could you try the small patch I've attached (apply it to your kernel
> sources and recompile, and then load cx88xx module with
> 'ir_disable=1')?
Was a lot better to start with, then MythTV started using the EIT
scanner, which uses the cards (just realised this, should have
thought about this before). I waited until it seemed like MythTV
stopped using the scanner, but it doesn't seem to be any different:
Cn Avg residency P-states (frequencies)
C0 (cpu running) (19.7%)
C1 0.0ms ( 0.0%)
C2 3.4ms (80.3%)
Wakeups-from-idle per second : 273.4 interval: 5.0s
no ACPI power usage estimate available
Top causes for wakeups:
31.2% ( 94.0) <interrupt> : cx88[1], cx88[1]
31.2% ( 94.0) <interrupt> : cx88[0], cx88[0], eth1
13.6% ( 41.0) mythbackend : do_nanosleep (hrtimer_wakeup)
13.4% ( 40.4) mythbackend : schedule_timeout (process_timeout)
6.0% ( 18.0) mythbackend : futex_wait (hrtimer_wakeup)
1.3% ( 3.8) <interrupt> : ide0
0.7% ( 2.0) <kernel core> : clocksource_register
(clocksource_watchdog)
0.5% ( 1.6) xfsbufd : schedule_timeout (process_timeout)
0.3% ( 1.0) apache2 : schedule_timeout (process_timeout)
0.3% ( 0.8) <kernel core> : ide_do_rw_disk
(ledtrig_ide_timerfunc)
0.2% ( 0.6) ifconfig : __netdev_watchdog_up (dev_watchdog)
0.2% ( 0.6) kdvb-fe-1 : schedule_timeout (process_timeout)
0.2% ( 0.6) kdvb-fe-0 : schedule_timeout (process_timeout)
0.2% ( 0.6) <kernel core> : neigh_table_init_no_netlink
(neigh_periodic_timer)
0.1% ( 0.4) <kernel module> : neigh_table_init_no_netlink
(neigh_periodic_timer)
0.1% ( 0.4) <kernel core> : queue_delayed_work_on
(delayed_work_timer_fn)
0.1% ( 0.2) <kernel core> : sk_reset_timer (tcp_delack_timer)
0.1% ( 0.2) sshd : sk_reset_timer (tcp_write_timer)
0.1% ( 0.2) mysqld : start_this_handle (commit_timeout)
0.1% ( 0.2) init : schedule_timeout (process_timeout)
0.1% ( 0.2) <kernel core> : page_writeback_init (wb_timer_fn)
0.1% ( 0.2) rpc.idmapd : schedule_timeout (process_timeout)
0.1% ( 0.2) <kernel core> : neigh_update (neigh_timer_handler)
I don't know why the cards are causing a lot of interrupts if the
backend isn't scanning for EIT data... or is it some continuous
thing? Am surprised the scanner would use both cards, not just one.
Your thoughts? Or is the cards still polling for IR stuff?
I'll have another look tomorrow morning to see if it's any better.
Thanks very much for your time again though. I think you should
submit the kernel patch - would be useful for some people I'd guess?
Regards - Piers
_______________________________________________
Power mailing list
[email protected]
http://www.bughost.org/mailman/listinfo/power
