* cx18: Unable to find blank work order form to schedule incoming mailbox ...
@ 2010-03-01 16:07 Mark Lord
2010-03-02 1:34 ` Andy Walls
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-03-01 16:07 UTC (permalink / raw)
To: Hans Verkuil, Andy Walls, linux-media, ivtv-devel
I'm using MythTV-0.21-fixes (from svn) on top of Linux-2.6.33 (from kernel.org),
with an HVR-1600 tuner card. This card usually works okay (with workarounds for
the known analog recording bugs) in both analog and digital modes.
Last night, for the first time ever, MythTV chose to record from both the analog
and digital sides of the HVR-1600 card at exactly the same times..
The kernel driver failed, and neither recording was successful.
The only message in /var/log/messages was:
Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing
I strongly suspect some kind of conflict/race between the analog and digital sides,
as in this case both were trying to start a new recording at the same time.
Any ideas?
Log files follow..
The MythTV backend log file is a bit tricky to follow, because there are many other
tuners also present in the same system:
2010-02-28 19:58:59.604 TVRec(42): ASK_RECORDING 42 29 0 0
2010-02-28 19:58:59.923 TVRec(29): ASK_RECORDING 29 29 0 0
2010-02-28 19:59:00.365 TVRec(41): ASK_RECORDING 41 29 0 0
2010-02-28 19:59:29.463 TVRec(30): ASK_RECORDING 30 29 0 0
2010-02-28 19:59:31.483 TVRec(41): Changing from None to RecordingOnly
2010-02-28 19:59:31.486 TVRec(41): HW Tuner: 41->41
2010-02-28 19:59:31.779 DVBSM(0), Warning: Can not measure Signal Strength
eno: Invalid argument (22)
2010-02-28 19:59:31.781 DVBSM(0), Warning: Can not measure S/N
eno: Invalid argument (22)
2010-02-28 19:59:31.801 AutoExpire: CalcParams(): Max required Free Space: 6.0 GB w/freq: 10 min
2010-02-28 19:59:31.805 Started recording: XXI Winter Olympics "Closing Ceremony": channel 4271 on cardid 41, sourceid 4
2010-02-28 19:59:31.827 TVRec(29): Changing from None to RecordingOnly
2010-02-28 19:59:31.828 TVRec(29): HW Tuner: 29->29
/usr/local/bin/diseqc_switcher[21502]: Selecting '2D'
/usr/local/bin/diseqc_switcher[21502]: writing 0x0e [- - - - 1 1 1 -]
/dev/video1: 211.250 MHz (Signal Detected)
2010-02-28 19:59:32.836 ret_pid(21499) child(21499) status(0x0)
2010-02-28 19:59:32.838 External Tuning program exited with no error
2010-02-28 19:59:32.885
Not ivtv driver??
2010-02-28 19:59:32.888 AutoExpire: CalcParams(): Max required Free Space: 6.0 GB w/freq: 8 min
2010-02-28 19:59:32.891 Started recording: XXI Winter Olympics "Closing Ceremony": channel 1013 on cardid 29, sourceid 1
2010-02-28 19:59:36.606 JobQueue: Commercial Flagging Starting for XXI Winter Olympics "Closing Ceremony" recorded from channel 1013 at Sun Feb 28 20:00:00 2010
2010-02-28 19:59:36.749 Using runtime prefix = /usr
2010-02-28 19:59:36.753 Empty LocalHostName.
2010-02-28 19:59:36.755 Using localhost value of duke
2010-02-28 19:59:36.766 New DB connection, total: 1
2010-02-28 19:59:36.771 Connected to database 'mythconverg' at host: localhost
2010-02-28 19:59:36.775 Closing DB connection named 'DBManager0'
2010-02-28 19:59:36.777 Connected to database 'mythconverg' at host: localhost
2010-02-28 19:59:36.782 New DB connection, total: 2
2010-02-28 19:59:36.784 Connected to database 'mythconverg' at host: localhost
2010-02-28 19:59:36.810 Connecting to backend server: 10.0.0.18:6543 (try 1 of 5)
2010-02-28 19:59:36.814 Using protocol version 40
2010-02-28 19:59:36.820 MainServer::HandleAnnounce Monitor
2010-02-28 19:59:36.822 adding: duke as a client (events: 0)
2010-02-28 19:59:36.826 MainServer::HandleAnnounce Monitor
2010-02-28 19:59:36.828 adding: duke as a client (events: 1)
2010-02-28 19:59:41.609 JobQueue: Commercial Flagging Starting for XXI Winter Olympics "Closing Ceremony" recorded from channel 4271 at Sun Feb 28 20:00:00 2010
2010-02-28 19:59:41.695 Using runtime prefix = /usr
2010-02-28 19:59:41.698 Empty LocalHostName.
2010-02-28 19:59:41.704 Using localhost value of duke
2010-02-28 19:59:41.712 New DB connection, total: 1
2010-02-28 19:59:41.718 Connected to database 'mythconverg' at host: localhost
2010-02-28 19:59:41.721 Closing DB connection named 'DBManager0'
2010-02-28 19:59:41.724 Connected to database 'mythconverg' at host: localhost
2010-02-28 19:59:41.730 New DB connection, total: 2
2010-02-28 19:59:41.734 Connected to database 'mythconverg' at host: localhost
2010-02-28 19:59:41.749 Connecting to backend server: 10.0.0.18:6543 (try 1 of 5)
2010-02-28 19:59:41.751 Using protocol version 40
2010-02-28 19:59:41.753 MainServer::HandleAnnounce Monitor
2010-02-28 19:59:41.757 adding: duke as a client (events: 0)
2010-02-28 19:59:41.760 MainServer::HandleAnnounce Monitor
2010-02-28 19:59:41.762 adding: duke as a client (events: 1)
2010-02-28 19:59:50.538 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 19:59:56.741 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:02.547 TVRec(30): Changing from RecordingOnly to None
2010-02-28 20:00:02.552 Finished recording The Monarchy "King and Emperor": channel 1024
2010-02-28 20:00:02.883 Finished recording The Monarchy "King and Emperor": channel 1024
2010-02-28 20:00:02.908 TVRec(30): Changing from None to RecordingOnly
2010-02-28 20:00:02.911 TVRec(30): HW Tuner: 30->30
2010-02-28 20:00:02.943 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:02.963 Using runtime prefix = /usr
2010-02-28 20:00:02.965 Empty LocalHostName.
2010-02-28 20:00:02.967 Using localhost value of duke
2010-02-28 20:00:02.977 New DB connection, total: 1
2010-02-28 20:00:02.982 Connected to database 'mythconverg' at host: localhost
2010-02-28 20:00:02.985 Closing DB connection named 'DBManager0'
2010-02-28 20:00:02.987 Connected to database 'mythconverg' at host: localhost
2010-02-28 20:00:02.992 New DB connection, total: 2
2010-02-28 20:00:02.995 Connected to database 'mythconverg' at host: localhost
2010-02-28 20:00:02.998 Current Schema Version: 1214
/usr/local/bin/diseqc_switcher[21597]: Selecting '1B'
/usr/local/bin/diseqc_switcher[21597]: writing 0x0d [- - - - 1 1 - 1]
/dev/video0: 645.250 MHz (Signal Detected)
2010-02-28 20:00:03.925 ret_pid(21594) child(21594) status(0x0)
2010-02-28 20:00:03.928 External Tuning program exited with no error
2010-02-28 20:00:03.957 AutoExpire: CalcParams(): Max required Free Space: 6.0 GB w/freq: 8 min
2010-02-28 20:00:03.960 Started recording: The Amazing Race 16 "Run Like Scalded Dogs!": channel 1043 on cardid 30, sourceid 1
*********************** WARNING ***********************
ivtv drivers prior to 0.10.0 can cause lockups when
reading VBI. Drivers between 0.10.5 and 1.0.3+ do not
properly capture VBI data on PVR-250 and PVR-350 cards.
2010-02-28 20:00:05.005 Reschedule requested for id 0.
2010-02-28 20:00:05.177 Scheduled 120 items in 0.2 = 0.00 match + 0.16 place
2010-02-28 20:00:05.489 AFD: Opened codec 0x204a5d0, id(MPEG2VIDEO) type(Video)
2010-02-28 20:00:05.492 AFD: codec MP2 has 2 channels
2010-02-28 20:00:05.495 AFD: Opened codec 0x2053b20, id(MP2) type(Audio)
2010-02-28 20:00:05.635 Preview: Grabbed preview '/var/lib/mythtv/recordings/1024_20100228190000.mpg' 720x480@180s
2010-02-28 20:00:09.146 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:15.349 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:21.551 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:27.755 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:32.850 RingBuf(/var/lib/mythtv/recordings/4271_20100228200000.mpg): Waited 1.0 seconds for data to become available...
2010-02-28 20:00:33.650 RingBuf(/var/lib/mythtv/recordings/1013_20100228200000.mpg): Waited 2.0 seconds for data to become available...
2010-02-28 20:00:33.859 RingBuf(/var/lib/mythtv/recordings/4271_20100228200000.mpg): Waited 2.0 seconds for data to become available...
2010-02-28 20:00:33.959 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:33.993 AFD: Opened codec 0xddbb70, id(MPEG2VIDEO) type(Video)
2010-02-28 20:00:33.996 AFD: codec MP2 has 2 channels
2010-02-28 20:00:33.998 AFD: Opened codec 0xde4850, id(MP2) type(Audio)
2010-02-28 20:00:34.254 AFD: Opened codec 0x7fe7bc009230, id(MPEG2VIDEO) type(Video)
2010-02-28 20:00:34.257 AFD: codec AC3 has 6 channels
2010-02-28 20:00:34.260 AFD: Opened codec 0x7fe7bc0098b0, id(AC3) type(Audio)
2010-02-28 20:00:34.264 AFD: codec AC3 has 1 channels
2010-02-28 20:00:34.268 AFD: Opened codec 0x7fe7bc024520, id(AC3) type(Audio)
2010-02-28 20:00:40.162 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:46.365 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:52.567 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:00:58.769 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:01:04.971 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:01:11.175 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:01:17.378 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:01:23.581 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:01:29.784 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:01:35.987 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
2010-02-28 20:01:42.190 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
And here's /var/log/messages from boot up to/after the failure:
Feb 28 12:55:56 duke syslogd 1.5.0#2ubuntu6: restart.
Feb 28 12:55:58 duke ntpdate[3184]: step time server 10.0.0.2 offset 2.330536 sec
Feb 28 12:55:58 duke ntpd[3556]: ntpd 4.2.4p4@1.1520-o Fri Dec 4 19:14:37 UTC 2009 (1)
Feb 28 12:55:58 duke ntpd[3564]: precision = 1.000 usec
Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #2 eth0, 10.0.0.18#123 Enabled
Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #3 eth1, 169.254.4.100#123 Enabled
Feb 28 12:55:58 duke ntpd[3564]: kernel time sync status 0040
Feb 28 12:55:58 duke ntpd[3564]: frequency initialized 8.502 PPM from /var/lib/ntp/ntp.drift
Feb 28 12:55:58 duke kernel: Inspecting /boot/System.map-2.6.33
Feb 28 12:55:58 duke kernel: Inspecting /boot/System.map
Feb 28 12:55:58 duke kernel: Inspecting /usr/src/linux/System.map
Feb 28 12:55:59 duke kernel: Cannot find map file.
Feb 28 12:55:59 duke kernel: Loaded 43513 symbols from 75 modules.
Feb 28 12:55:59 duke kernel: orted from D0 D3hot D3cold
Feb 28 12:55:59 duke kernel: pci 0000:00:1b.0: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:00:1d.0: reg 20: [io 0xf400-0xf41f]
Feb 28 12:55:59 duke kernel: pci 0000:00:1d.1: reg 20: [io 0xf000-0xf01f]
Feb 28 12:55:59 duke kernel: pci 0000:00:1d.2: reg 20: [io 0xec00-0xec1f]
Feb 28 12:55:59 duke kernel: pci 0000:00:1d.7: reg 10: [mem 0xfdffe000-0xfdffe3ff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
Feb 28 12:55:59 duke kernel: pci 0000:00:1d.7: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: quirk: [io 0x0400-0x047f] claimed by ICH6 ACPI/GPIO/TCO
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: quirk: [io 0x0480-0x04bf] claimed by ICH6 GPIO
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800 (mask 003f)
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 003f)
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 10: [io 0xe800-0xe807]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 14: [io 0xe400-0xe403]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 18: [io 0xe000-0xe007]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 1c: [io 0xdc00-0xdc03]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 20: [io 0xd800-0xd81f]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 24: [mem 0xfdffd000-0xfdffd7ff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: PME# supported from D3hot
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.3: reg 10: [mem 0xfdffc000-0xfdffc0ff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.3: reg 20: [io 0x0500-0x051f]
Feb 28 12:55:59 duke kernel: pci 0000:00:1f.6: reg 10: [mem 0xfdffb000-0xfdffbfff 64bit]
Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 10: [mem 0xfb000000-0xfbffffff]
Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 14: [mem 0xb0000000-0xbfffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 1c: [mem 0xce000000-0xcfffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 24: [io 0x5c00-0x5c7f]
Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0007ffff pref]
Feb 28 12:55:59 duke kernel: pci 0000:01:00.1: reg 10: [mem 0xfcffc000-0xfcffffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [io 0x5000-0x5fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xfb000000-0xfcffffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xb0000000-0xcfffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PCI bridge to [bus 02-02]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [io 0xa000-0xafff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdc00000-0xfdcfffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdb00000-0xfdbfffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: reg 24: [mem 0xfdafe000-0xfdafffff]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: reg 30: [mem 0x00000000-0x0000ffff pref]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: PME# supported from D3hot
Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 10: [io 0x9c00-0x9c07]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 14: [io 0x9800-0x9803]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 18: [io 0x9400-0x9407]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 1c: [io 0x9000-0x9003]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 20: [io 0x8c00-0x8c0f]
Feb 28 12:55:59 duke syslogd: /dev/console: Resource temporarily unavailable
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PCI bridge to [bus 03-03]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [io 0x8000-0x9fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfda00000-0xfdafffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfd900000-0xfd9fffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: reg 10: [mem 0xfdefc000-0xfdefffff 64bit]
Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: reg 18: [io 0x6c00-0x6cff]
Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: supports D1 D2
Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PCI bridge to [bus 04-04]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [io 0x6000-0x6fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfde00000-0xfdefffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: reg 10: [mem 0xdbfff000-0xdbfff7ff]
Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: reg 14: [io 0x7c00-0x7c7f]
Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: supports D2
Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: PME# supported from D2 D3hot D3cold
Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: PME# disabled
Feb 28 12:55:59 duke kernel: pci 0000:05:02.0: reg 10: [mem 0xf4000000-0xf7ffffff pref]
Feb 28 12:55:59 duke kernel: pci 0000:05:03.0: reg 10: [mem 0xd4000000-0xd7ffffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [io 0x7000-0x7fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xd4000000-0xdbffffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xf4000000-0xf7ffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci_bus 0000:00: on NUMA node 0
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 9 10 11 12 *14 15)
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 9 10 11 12 14 *15)
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 9 10 *11 12 14 15)
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 9 *10 11 12 14 15)
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 9 10 11 12 14 15) *0, disabled.
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *9 10 11 12 14 15)
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNK0] (IRQs *5 9 10 11 12 14 15)
Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs 5 9 10 11 12 14 *15)
Feb 28 12:55:59 duke kernel: vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
Feb 28 12:55:59 duke kernel: vgaarb: loaded
Feb 28 12:55:59 duke kernel: SCSI subsystem initialized
Feb 28 12:55:59 duke kernel: libata version 3.00 loaded.
Feb 28 12:55:59 duke kernel: PCI: Using ACPI for IRQ routing
Feb 28 12:55:59 duke kernel: PCI: pci_cache_line_size set to 64 bytes
Feb 28 12:55:59 duke kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
Feb 28 12:55:59 duke kernel: hpet0: 3 comparators, 64-bit 14.318180 MHz counter
Feb 28 12:55:59 duke kernel: Switching to clocksource tsc
Feb 28 12:55:59 duke kernel: pnp: PnP ACPI init
Feb 28 12:55:59 duke kernel: ACPI: bus type pnp registered
Feb 28 12:55:59 duke kernel: pnp: PnP ACPI: found 14 devices
Feb 28 12:55:59 duke kernel: ACPI: ACPI bus type pnp unregistered
Feb 28 12:55:59 duke kernel: system 00:01: [io 0x04d0-0x04d1] has been reserved
Feb 28 12:55:59 duke kernel: system 00:01: [io 0x0290-0x029f] has been reserved
Feb 28 12:55:59 duke kernel: system 00:01: [io 0x0800-0x087f] has been reserved
Feb 28 12:55:59 duke kernel: system 00:01: [io 0x0880-0x088f] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0a: [io 0x0400-0x04bf] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000d6000-0x000d7fff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000f0000-0x000f7fff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000f8000-0x000fbfff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000fc000-0x000fffff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x7ff00000-0x7fffffff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfed00000-0xfed000ff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x7fee0000-0x7fefffff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x00000000-0x0009ffff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x00100000-0x7fedffff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfec00000-0xfec00fff] could not be reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfed13000-0xfed1ffff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfed20000-0xfed9ffff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfee00000-0xfee00fff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xffb00000-0xffb7ffff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfff00000-0xffffffff] has been reserved
Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000e0000-0x000effff] has been reserved
Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: BAR 6: assigned [mem 0xc0000000-0xc007ffff pref]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [io 0x5000-0x5fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xfb000000-0xfcffffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xb0000000-0xcfffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PCI bridge to [bus 02-02]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [io 0xa000-0xafff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdc00000-0xfdcfffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdb00000-0xfdbfffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: BAR 6: assigned [mem 0xfd900000-0xfd90ffff pref]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PCI bridge to [bus 03-03]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [io 0x8000-0x9fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfda00000-0xfdafffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfd900000-0xfd9fffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: BAR 6: assigned [mem 0xfdd00000-0xfdd1ffff pref]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PCI bridge to [bus 04-04]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [io 0x6000-0x6fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfde00000-0xfdefffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: PCI bridge to [bus 05-05]
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [io 0x7000-0x7fff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xd4000000-0xdbffffff]
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xf4000000-0xf7ffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffffffffffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:01: resource 0 [io 0x5000-0x5fff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:01: resource 1 [mem 0xfb000000-0xfcffffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:01: resource 2 [mem 0xb0000000-0xcfffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci_bus 0000:02: resource 0 [io 0xa000-0xafff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:02: resource 1 [mem 0xfdc00000-0xfdcfffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:02: resource 2 [mem 0xfdb00000-0xfdbfffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci_bus 0000:03: resource 0 [io 0x8000-0x9fff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:03: resource 1 [mem 0xfda00000-0xfdafffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:03: resource 2 [mem 0xfd900000-0xfd9fffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci_bus 0000:04: resource 0 [io 0x6000-0x6fff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:04: resource 1 [mem 0xfde00000-0xfdefffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:04: resource 2 [mem 0xfdd00000-0xfddfffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 0 [io 0x7000-0x7fff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 1 [mem 0xd4000000-0xdbffffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 2 [mem 0xf4000000-0xf7ffffff 64bit pref]
Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 3 [io 0x0000-0xffff]
Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 4 [mem 0x00000000-0xffffffffffffffff]
Feb 28 12:55:59 duke kernel: NET: Registered protocol family 2
Feb 28 12:55:59 duke kernel: IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
Feb 28 12:55:59 duke kernel: TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
Feb 28 12:55:59 duke kernel: TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
Feb 28 12:55:59 duke kernel: TCP: Hash tables configured (established 262144 bind 65536)
Feb 28 12:55:59 duke kernel: TCP reno registered
Feb 28 12:55:59 duke kernel: UDP hash table entries: 1024 (order: 3, 32768 bytes)
Feb 28 12:55:59 duke kernel: UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
Feb 28 12:55:59 duke kernel: NET: Registered protocol family 1
Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: Boot video device
Feb 28 12:55:59 duke kernel: PCI: CLS 64 bytes, default 64
Feb 28 12:55:59 duke kernel: Scanning for low memory corruption every 60 seconds
Feb 28 12:55:59 duke kernel: HugeTLB registered 2 MB page size, pre-allocated 0 pages
Feb 28 12:55:59 duke kernel: SGI XFS with security attributes, realtime, large block/inode numbers, no debug enabled
Feb 28 12:55:59 duke kernel: msgmni has been set to 4019
Feb 28 12:55:59 duke kernel: alg: No test for stdrng (krng)
Feb 28 12:55:59 duke kernel: Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
Feb 28 12:55:59 duke kernel: io scheduler noop registered
Feb 28 12:55:59 duke kernel: io scheduler cfq registered (default)
Feb 28 12:55:59 duke kernel: pcieport 0000:00:01.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pcieport 0000:00:1c.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pcieport 0000:00:1c.2: setting latency timer to 64
Feb 28 12:55:59 duke kernel: pcieport 0000:00:1c.3: setting latency timer to 64
Feb 28 12:55:59 duke kernel: lp: driver loaded but no devices found
Feb 28 12:55:59 duke kernel: Generic RTC Driver v1.07
Feb 28 12:55:59 duke kernel: Non-volatile memory driver v1.3
Feb 28 12:55:59 duke kernel: Linux agpgart interface v0.103
Feb 28 12:55:59 duke kernel: [drm] Initialized drm 1.1.0 20060810
Feb 28 12:55:59 duke kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Feb 28 12:55:59 duke kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Feb 28 12:55:59 duke kernel: 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Feb 28 12:55:59 duke kernel: parport_pc 00:08: reported by Plug and Play ACPI
Feb 28 12:55:59 duke kernel: parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Feb 28 12:55:59 duke kernel: lp0: using parport0 (interrupt-driven).
Feb 28 12:55:59 duke kernel: loop: module loaded
Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: version 3.0
Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x33 impl SATA mode
Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio slum part ccc ems
Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: setting latency timer to 64
Feb 28 12:55:59 duke kernel: scsi0 : ahci
Feb 28 12:55:59 duke kernel: scsi1 : ahci
Feb 28 12:55:59 duke kernel: scsi2 : ahci
Feb 28 12:55:59 duke kernel: scsi3 : ahci
Feb 28 12:55:59 duke kernel: scsi4 : ahci
Feb 28 12:55:59 duke kernel: scsi5 : ahci
Feb 28 12:55:59 duke kernel: ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
Feb 28 12:55:59 duke kernel: ata2: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
Feb 28 12:55:59 duke kernel: ata3: DUMMY
Feb 28 12:55:59 duke kernel: ata4: DUMMY
Feb 28 12:55:59 duke kernel: ata5: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
Feb 28 12:55:59 duke kernel: ata6: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd380 irq 17
Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: JMB361 has only one port, port_map 0x3 -> 0x1
Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x1 impl SATA mode
Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: scsi6 : ahci
Feb 28 12:55:59 duke kernel: scsi7 : ahci
Feb 28 12:55:59 duke kernel: ata7: SATA max UDMA/133 abar m8192@0xfdafe000 port 0xfdafe100 irq 18
Feb 28 12:55:59 duke kernel: ata8: DUMMY
Feb 28 12:55:59 duke kernel: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
Feb 28 12:55:59 duke kernel: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
Feb 28 12:55:59 duke kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Feb 28 12:55:59 duke kernel: mice: PS/2 mouse device common for all mice
Feb 28 12:55:59 duke kernel: md: raid0 personality registered for level 0
Feb 28 12:55:59 duke kernel: cpuidle: using governor ladder
Feb 28 12:55:59 duke kernel: ioatdma: Intel(R) QuickData Technology Driver 4.00
Feb 28 12:55:59 duke kernel: TCP cubic registered
Feb 28 12:55:59 duke kernel: NET: Registered protocol family 17
Feb 28 12:55:59 duke kernel: ata7: SATA link down (SStatus 0 SControl 300)
Feb 28 12:55:59 duke kernel: ata6: SATA link down (SStatus 0 SControl 300)
Feb 28 12:55:59 duke kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 28 12:55:59 duke kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 28 12:55:59 duke kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 28 12:55:59 duke kernel: ata1.00: ATA-8: OCZ-VERTEX, 1.5, max UDMA/133
Feb 28 12:55:59 duke kernel: ata1.00: 125045424 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
Feb 28 12:55:59 duke kernel: ata1.00: configured for UDMA/133
Feb 28 12:55:59 duke kernel: scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX 1.5 PQ: 0 ANSI: 5
Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Write Protect is off
Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 28 12:55:59 duke kernel: sda: sda1 sda2
Feb 28 12:55:59 duke kernel: ata2.00: ATA-7: ST3750640NS, 3.BAF, max UDMA/133
Feb 28 12:55:59 duke kernel: ata2.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Feb 28 12:55:59 duke kernel: ata2.00: configured for UDMA/133
Feb 28 12:55:59 duke kernel: ata5.00: ATA-7: ST3750640NS, 3.BAF, max UDMA/133
Feb 28 12:55:59 duke kernel: scsi 1:0:0:0: Direct-Access ATA ST3750640NS 3.BA PQ: 0 ANSI: 5
Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Write Protect is off
Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Feb 28 12:55:59 duke kernel: sdb: sdb1 sdb2
Feb 28 12:55:59 duke kernel: ata5.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Feb 28 12:55:59 duke kernel: ata5.00: configured for UDMA/133
Feb 28 12:55:59 duke kernel: scsi 4:0:0:0: Direct-Access ATA ST3750640NS 3.BA PQ: 0 ANSI: 5
Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Write Protect is off
Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Mode Sense: 00 3a 00 00
Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Feb 28 12:55:59 duke kernel: sdc: sdc1 sdc2
Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Attached SCSI disk
Feb 28 12:55:59 duke kernel: md: Waiting for all devices to be available before autodetect
Feb 28 12:55:59 duke kernel: md: If you don't use raid, use raid=noautodetect
Feb 28 12:55:59 duke kernel: md: Autodetecting RAID arrays.
Feb 28 12:55:59 duke kernel: md: Scanned 2 and added 2 devices.
Feb 28 12:55:59 duke kernel: md: autorun ...
Feb 28 12:55:59 duke kernel: md: considering sdc2 ...
Feb 28 12:55:59 duke kernel: md: adding sdc2 ...
Feb 28 12:55:59 duke kernel: md: adding sdb2 ...
Feb 28 12:55:59 duke kernel: md: created md0
Feb 28 12:55:59 duke kernel: md: bind<sdb2>
Feb 28 12:55:59 duke kernel: md: bind<sdc2>
Feb 28 12:55:59 duke kernel: md: running: <sdc2><sdb2>
Feb 28 12:55:59 duke kernel: raid0: looking at sdc2
Feb 28 12:55:59 duke kernel: raid0: comparing sdc2(1433013760)
Feb 28 12:55:59 duke kernel: with sdc2(1433013760)
Feb 28 12:55:59 duke kernel: raid0: END
Feb 28 12:55:59 duke kernel: raid0: ==> UNIQUE
Feb 28 12:55:59 duke kernel: raid0: 1 zones
Feb 28 12:55:59 duke kernel: raid0: looking at sdb2
Feb 28 12:55:59 duke kernel: raid0: comparing sdb2(1433013760)
Feb 28 12:55:59 duke kernel: with sdc2(1433013760)
Feb 28 12:55:59 duke kernel: raid0: EQUAL
Feb 28 12:55:59 duke kernel: raid0: FINAL 1 zones
Feb 28 12:55:59 duke kernel: raid0: done.
Feb 28 12:55:59 duke kernel: raid0 : md_size is 2866027520 sectors.
Feb 28 12:55:59 duke kernel: ******* md0 configuration *********
Feb 28 12:55:59 duke kernel: zone0=[sdb2/sdc2/]
Feb 28 12:55:59 duke kernel: zone offset=0kb device offset=0kb size=1433013760kb
Feb 28 12:55:59 duke kernel: **********************************
Feb 28 12:55:59 duke kernel:
Feb 28 12:55:59 duke kernel: md0: detected capacity change from 0 to 1467406090240
Feb 28 12:55:59 duke kernel: md: ... autorun DONE.
Feb 28 12:55:59 duke kernel: EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240)
Feb 28 12:55:59 duke kernel: EXT4-fs (sda2): mounted filesystem with ordered data mode
Feb 28 12:55:59 duke kernel: VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
Feb 28 12:55:59 duke kernel: Freeing unused kernel memory: 408k freed
Feb 28 12:55:59 duke kernel: fuse init (API version 7.13)
Feb 28 12:55:59 duke kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Feb 28 12:55:59 duke kernel: HDA Intel 0000:00:1b.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: hda_codec: ALC883: BIOS auto-probing.
Feb 28 12:55:59 duke kernel: HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Feb 28 12:55:59 duke kernel: HDA Intel 0000:01:00.1: setting latency timer to 64
Feb 28 12:55:59 duke kernel: Linux video capture interface: v2.00
Feb 28 12:55:59 duke kernel: ivtv: Start initialization, version 1.4.1
Feb 28 12:55:59 duke kernel: ivtv0: Initializing card 0
Feb 28 12:55:59 duke kernel: ivtv0: Autodetected Hauppauge card (cx23416 based)
Feb 28 12:55:59 duke kernel: ivtv 0000:05:02.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Feb 28 12:55:59 duke kernel: tveeprom 0-0050: Hauppauge model 32062, rev B185, serial# 2842715
Feb 28 12:55:59 duke kernel: tveeprom 0-0050: tuner model is TCL 2002N 6A (idx 85, type 50)
Feb 28 12:55:59 duke kernel: tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
Feb 28 12:55:59 duke kernel: tveeprom 0-0050: audio processor is MSP3445 (idx 12)
Feb 28 12:55:59 duke kernel: tveeprom 0-0050: decoder processor is SAA7115 (idx 19)
Feb 28 12:55:59 duke kernel: tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter
Feb 28 12:55:59 duke kernel: ivtv0: Autodetected Hauppauge WinTV PVR-250
Feb 28 12:55:59 duke kernel: saa7115 0-0021: saa7115 found (1f7115d0e100000) @ 0x42 (ivtv i2c driver #0)
Feb 28 12:55:59 duke kernel: msp3400 0-0040: MSP3445G-B8 found @ 0x80 (ivtv i2c driver #0)
Feb 28 12:55:59 duke kernel: msp3400 0-0040: msp3400 supports radio, mode is autodetect and autoselect
Feb 28 12:55:59 duke kernel: tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
Feb 28 12:55:59 duke kernel: tuner-simple 0-0061: creating new instance
Feb 28 12:55:59 duke kernel: tuner-simple 0-0061: type set to 50 (TCL 2002N)
Feb 28 12:55:59 duke kernel: IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
Feb 28 12:55:59 duke kernel: ivtv0: Registered device video0 for encoder MPG (4096 kB)
Feb 28 12:55:59 duke kernel: ivtv0: Registered device video32 for encoder YUV (2048 kB)
Feb 28 12:55:59 duke kernel: ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
Feb 28 12:55:59 duke kernel: ivtv0: Registered device video24 for encoder PCM (320 kB)
Feb 28 12:55:59 duke kernel: ivtv0: Initialized card: Hauppauge WinTV PVR-250
Feb 28 12:55:59 duke kernel: ivtv: End initialization
Feb 28 12:55:59 duke kernel: md0: unknown partition table
Feb 28 12:55:59 duke kernel: thermal LNXTHERM:01: registered as thermal_zone0
Feb 28 12:55:59 duke kernel: ACPI: Invalid PBLK length [0]
Feb 28 12:55:59 duke kernel: input: Power Button as /class/input/input0
Feb 28 12:55:59 duke kernel: ACPI: Power Button [PWRB]
Feb 28 12:55:59 duke kernel: ACPI Error (psparse-0537):
Feb 28 12:55:59 duke kernel: ACPI: Thermal Zone [THRM] (30 C)
Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver usbfs
Feb 28 12:55:59 duke kernel: Method parse/execution failed
Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver hub
Feb 28 12:55:59 duke kernel: [\_PR_.CPU0._PDC] (Node ffff88007f858490), AE_ALREADY_EXISTS
Feb 28 12:55:59 duke kernel: ACPI:
Feb 28 12:55:59 duke kernel: usbcore: registered new device driver usb
Feb 28 12:55:59 duke kernel: Marking method _PDC as Serialized because of AE_ALREADY_EXISTS error
Feb 28 12:55:59 duke kernel: input: Power Button as /class/input/input1
Feb 28 12:55:59 duke kernel: ACPI: Power Button [PWRF]
Feb 28 12:55:59 duke kernel: ACPI: Invalid PBLK length [0]
Feb 28 12:55:59 duke kernel: ACPI: SSDT 000000007fee8750 000CE (v01 PmRef Cpu1Ist 00003000 INTL 20041203)
Feb 28 12:55:59 duke kernel: nvidia: module license 'NVIDIA' taints kernel.
Feb 28 12:55:59 duke kernel:
Feb 28 12:55:59 duke kernel: firewire_ohci 0000:05:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
Feb 28 12:55:59 duke kernel: firewire_ohci 0000:05:00.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: cx18: Start initialization, version 1.3.0
Feb 28 12:55:59 duke kernel: sky2 driver version 1.26
Feb 28 12:55:59 duke kernel: sky2 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
Feb 28 12:55:59 duke kernel: pata_jmicron 0000:03:00.1: enabling device (0000 -> 0001)
Feb 28 12:55:59 duke kernel: pata_jmicron 0000:03:00.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
Feb 28 12:55:59 duke kernel: pata_jmicron 0000:03:00.1: setting latency timer to 64
Feb 28 12:55:59 duke kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Feb 28 12:55:59 duke kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
Feb 28 12:55:59 duke kernel: sd 4:0:0:0: Attached scsi generic sg2 type 0
Feb 28 12:55:59 duke kernel: scsi8 : pata_jmicron
Feb 28 12:55:59 duke kernel: scsi9 : pata_jmicron
Feb 28 12:55:59 duke kernel: ata9: PATA max UDMA/100 cmd 0x9c00 ctl 0x9800 bmdma 0x8c00 irq 19
Feb 28 12:55:59 duke kernel: ata10: PATA max UDMA/100 cmd 0x9400 ctl 0x9000 bmdma 0x8c08 irq 19
Feb 28 12:55:59 duke kernel: ACPI: Fan [FAN] (on)
Feb 28 12:55:59 duke kernel: uhci_hcd: USB Universal Host Controller Interface driver
Feb 28 12:55:59 duke kernel: firewire_ohci: Added fw-ohci device 0000:05:00.0, OHCI version 1.10
Feb 28 12:55:59 duke kernel: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: setting latency timer to 64
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: EHCI Host Controller
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfdfff000
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
Feb 28 12:55:59 duke kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
Feb 28 12:55:59 duke kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 28 12:55:59 duke kernel: cx18-0: Initializing card 0
Feb 28 12:55:59 duke kernel: cx18-0: Autodetected Hauppauge card
Feb 28 12:55:59 duke kernel: sky2 0000:04:00.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: sky2 0000:04:00.0: Yukon-2 EC Ultra chip revision 2
Feb 28 12:55:59 duke kernel: sky2 eth0: addr 00:15:58:8a:ae:e5
Feb 28 12:55:59 duke kernel: usb usb1: Product: EHCI Host Controller
Feb 28 12:55:59 duke kernel: usb usb1: Manufacturer: Linux 2.6.33 ehci_hcd
Feb 28 12:55:59 duke kernel: usb usb1: SerialNumber: 0000:00:1a.7
Feb 28 12:55:59 duke kernel: hub 1-0:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 1-0:1.0: 4 ports detected
Feb 28 12:55:59 duke kernel: cx18 0000:05:03.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: UHCI Host Controller
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 2
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000fc00
Feb 28 12:55:59 duke kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
Feb 28 12:55:59 duke kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 28 12:55:59 duke kernel: usb usb2: Product: UHCI Host Controller
Feb 28 12:55:59 duke kernel: usb usb2: Manufacturer: Linux 2.6.33 uhci_hcd
Feb 28 12:55:59 duke kernel: usb usb2: SerialNumber: 0000:00:1a.0
Feb 28 12:55:59 duke kernel: hub 2-0:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 2-0:1.0: 2 ports detected
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: setting latency timer to 64
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: UHCI Host Controller
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 3
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000f800
Feb 28 12:55:59 duke kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
Feb 28 12:55:59 duke kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 28 12:55:59 duke kernel: usb usb3: Product: UHCI Host Controller
Feb 28 12:55:59 duke kernel: usb usb3: Manufacturer: Linux 2.6.33 uhci_hcd
Feb 28 12:55:59 duke kernel: usb usb3: SerialNumber: 0000:00:1a.1
Feb 28 12:55:59 duke kernel: hub 3-0:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 3-0:1.0: 2 ports detected
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: UHCI Host Controller
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 4
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000f400
Feb 28 12:55:59 duke kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
Feb 28 12:55:59 duke kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 28 12:55:59 duke kernel: usb usb4: Product: UHCI Host Controller
Feb 28 12:55:59 duke kernel: usb usb4: Manufacturer: Linux 2.6.33 uhci_hcd
Feb 28 12:55:59 duke kernel: usb usb4: SerialNumber: 0000:00:1d.0
Feb 28 12:55:59 duke kernel: hub 4-0:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 4-0:1.0: 2 ports detected
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: setting latency timer to 64
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: UHCI Host Controller
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 5
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000f000
Feb 28 12:55:59 duke kernel: usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
Feb 28 12:55:59 duke kernel: usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 28 12:55:59 duke kernel: usb usb5: Product: UHCI Host Controller
Feb 28 12:55:59 duke kernel: usb usb5: Manufacturer: Linux 2.6.33 uhci_hcd
Feb 28 12:55:59 duke kernel: usb usb5: SerialNumber: 0000:00:1d.1
Feb 28 12:55:59 duke kernel: hub 5-0:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 5-0:1.0: 2 ports detected
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: setting latency timer to 64
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: UHCI Host Controller
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 6
Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000ec00
Feb 28 12:55:59 duke kernel: usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
Feb 28 12:55:59 duke kernel: usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 28 12:55:59 duke kernel: usb usb6: Product: UHCI Host Controller
Feb 28 12:55:59 duke kernel: usb usb6: Manufacturer: Linux 2.6.33 uhci_hcd
Feb 28 12:55:59 duke kernel: usb usb6: SerialNumber: 0000:00:1d.2
Feb 28 12:55:59 duke kernel: hub 6-0:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 6-0:1.0: 2 ports detected
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: setting latency timer to 64
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: EHCI Host Controller
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 7
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfdffe000
Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
Feb 28 12:55:59 duke kernel: usb usb7: New USB device found, idVendor=1d6b, idProduct=0002
Feb 28 12:55:59 duke kernel: usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 28 12:55:59 duke kernel: usb usb7: Product: EHCI Host Controller
Feb 28 12:55:59 duke kernel: usb usb7: Manufacturer: Linux 2.6.33 ehci_hcd
Feb 28 12:55:59 duke kernel: usb usb7: SerialNumber: 0000:00:1d.7
Feb 28 12:55:59 duke kernel: hub 7-0:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 7-0:1.0: 6 ports detected
Feb 28 12:55:59 duke kernel: ata9.00: ATAPI: PIONEER DVD-RW DVR-118L, 1.00, max UDMA/100
Feb 28 12:55:59 duke kernel: ata9.00: configured for UDMA/100
Feb 28 12:55:59 duke kernel: scsi 8:0:0:0: CD-ROM PIONEER DVD-RW DVR-118L 1.00 PQ: 0 ANSI: 5
Feb 28 12:55:59 duke kernel: sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
Feb 28 12:55:59 duke kernel: Uniform CD-ROM driver Revision: 3.20
Feb 28 12:55:59 duke kernel: sr 8:0:0:0: Attached scsi CD-ROM sr0
Feb 28 12:55:59 duke kernel: sr 8:0:0:0: Attached scsi generic sg3 type 5
Feb 28 12:55:59 duke kernel: nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Feb 28 12:55:59 duke kernel: nvidia 0000:01:00.0: setting latency timer to 64
Feb 28 12:55:59 duke kernel: vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
Feb 28 12:55:59 duke kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 195.36.03 Mon Feb 1 18:33:51 PST 2010
Feb 28 12:55:59 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2)
Feb 28 12:55:59 duke kernel: cx18-0: cx23418 revision 01010000 (B)
Feb 28 12:55:59 duke kernel: firewire_core: created device fw0: GUID 00016c200022ce9e, S400
Feb 28 12:55:59 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Feb 28 12:55:59 duke kernel: tveeprom 1-0050: MAC address is 00-0D-FE-1A-BE-03
Feb 28 12:55:59 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Feb 28 12:55:59 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Feb 28 12:55:59 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Feb 28 12:55:59 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Feb 28 12:55:59 duke kernel: tveeprom 1-0050: has radio
Feb 28 12:55:59 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600
Feb 28 12:55:59 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported
Feb 28 12:55:59 duke kernel: usb 7-6: new high speed USB device using ehci_hcd and address 4
Feb 28 12:55:59 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
Feb 28 12:55:59 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
Feb 28 12:55:59 duke kernel: tda9887 2-0043: creating new instance
Feb 28 12:55:59 duke kernel: tda9887 2-0043: tda988[5/6/7] found
Feb 28 12:55:59 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
Feb 28 12:55:59 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
Feb 28 12:55:59 duke kernel: tuner-simple 2-0061: creating new instance
Feb 28 12:55:59 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
Feb 28 12:55:59 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB)
Feb 28 12:55:59 duke kernel: DVB: registering new adapter (cx18)
Feb 28 12:55:59 duke kernel: usb 7-6: New USB device found, idVendor=0b95, idProduct=7720
Feb 28 12:55:59 duke kernel: usb 7-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 28 12:55:59 duke kernel: usb 7-6: Product: AX88772
Feb 28 12:55:59 duke kernel: usb 7-6: Manufacturer: ASIX Elec. Corp.
Feb 28 12:55:59 duke kernel: usb 7-6: SerialNumber: 000001
Feb 28 12:55:59 duke kernel: MXL5005S: Attached at address 0x63
Feb 28 12:55:59 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
Feb 28 12:55:59 duke kernel: cx18-0: DVB Frontend registered
Feb 28 12:55:59 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
Feb 28 12:55:59 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB)
Feb 28 12:55:59 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes)
Feb 28 12:55:59 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB)
Feb 28 12:55:59 duke kernel: cx18-0: Registered device radio1 for encoder radio
Feb 28 12:55:59 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600
Feb 28 12:55:59 duke kernel: cx18: End initialization
Feb 28 12:55:59 duke kernel: usb 3-2: new low speed USB device using uhci_hcd and address 2
Feb 28 12:55:59 duke kernel: usb 3-2: New USB device found, idVendor=15c2, idProduct=ffdc
Feb 28 12:55:59 duke kernel: usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Feb 28 12:55:59 duke kernel: usb 4-2: new low speed USB device using uhci_hcd and address 2
Feb 28 12:55:59 duke kernel: usb 4-2: New USB device found, idVendor=046d, idProduct=c51e
Feb 28 12:55:59 duke kernel: usb 4-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver hiddev
Feb 28 12:55:59 duke kernel: input: HID 046d:c51e as /class/input/input2
Feb 28 12:55:59 duke kernel: generic-usb 0003:046D:C51E.0001: input: USB HID v1.11 Keyboard [HID 046d:c51e] on usb-0000:00:1d.0-2/input0
Feb 28 12:55:59 duke kernel: eth1: register 'asix' at usb-0000:00:1d.7-6, ASIX AX88772 USB 2.0 Ethernet, 00:50:5b:04:a2:4b
Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver asix
Feb 28 12:55:59 duke kernel: input: HID 046d:c51e as /class/input/input3
Feb 28 12:55:59 duke kernel: generic-usb 0003:046D:C51E.0002: input,hiddev0: USB HID v1.11 Mouse [HID 046d:c51e] on usb-0000:00:1d.0-2/input1
Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver usbhid
Feb 28 12:55:59 duke kernel: usbhid: USB HID core driver
Feb 28 12:55:59 duke kernel: usb 5-2: new full speed USB device using uhci_hcd and address 2
Feb 28 12:55:59 duke kernel: usb 5-2: New USB device found, idVendor=0403, idProduct=6001
Feb 28 12:55:59 duke kernel: usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 28 12:55:59 duke kernel: usb 5-2: Product: Triple Relay Controller
Feb 28 12:55:59 duke kernel: usb 5-2: Manufacturer: RTR
Feb 28 12:55:59 duke kernel: usb 5-2: SerialNumber: A4SI153I
Feb 28 12:55:59 duke kernel: Adding 16064960k swap on /dev/sdc1. Priority:-1 extents:1 across:16064960k
Feb 28 12:55:59 duke kernel: usb 1-3: new high speed USB device using ehci_hcd and address 3
Feb 28 12:55:59 duke kernel: usb 1-3: New USB device found, idVendor=05e3, idProduct=0608
Feb 28 12:55:59 duke kernel: usb 1-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Feb 28 12:55:59 duke kernel: usb 1-3: Product: USB2.0 Hub
Feb 28 12:55:59 duke kernel: hub 1-3:1.0: USB hub found
Feb 28 12:55:59 duke kernel: hub 1-3:1.0: 4 ports detected
Feb 28 12:55:59 duke kernel: usb 1-3.1: new full speed USB device using ehci_hcd and address 4
Feb 28 12:55:59 duke kernel: usb 1-3.1: New USB device found, idVendor=0c76, idProduct=1607
Feb 28 12:55:59 duke kernel: usb 1-3.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Feb 28 12:55:59 duke kernel: usb 1-3.1: Product: USB Headphone Set
Feb 28 12:55:59 duke kernel: input: USB Headphone Set as /class/input/input4
Feb 28 12:55:59 duke kernel: generic-usb 0003:0C76:1607.0003: input: USB HID v1.00 Device [USB Headphone Set] on usb-0000:00:1a.7-3.1/input3
Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver snd-usb-audio
Feb 28 12:55:59 duke kernel: usb 1-3.2: new high speed USB device using ehci_hcd and address 5
Feb 28 12:55:59 duke kernel: usb 1-3.2: New USB device found, idVendor=2040, idProduct=7200
Feb 28 12:55:59 duke kernel: usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=10
Feb 28 12:55:59 duke kernel: usb 1-3.2: Product: WinTV HVR-950
Feb 28 12:55:59 duke kernel: usb 1-3.2: Manufacturer: Hauppauge
Feb 28 12:55:59 duke kernel: usb 1-3.2: SerialNumber: 4031688744
Feb 28 12:55:59 duke kernel: au0828 driver loaded
Feb 28 12:55:59 duke kernel: usb 1-3.3: new full speed USB device using ehci_hcd and address 6
Feb 28 12:55:59 duke kernel: usb 1-3.3: New USB device found, idVendor=0403, idProduct=6001
Feb 28 12:55:59 duke kernel: usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 28 12:55:59 duke kernel: usb 1-3.3: Product: Frankenswitch v3 4x4:1 matrix
Feb 28 12:55:59 duke kernel: usb 1-3.3: Manufacturer: RTR
Feb 28 12:55:59 duke kernel: usb 1-3.3: SerialNumber: A8S59W9K
Feb 28 12:55:59 duke kernel: usb 1-3.4: new low speed USB device using ehci_hcd and address 7
Feb 28 12:55:59 duke kernel: au0828: i2c bus registered
Feb 28 12:55:59 duke kernel: usb 1-3.4: New USB device found, idVendor=051d, idProduct=0002
Feb 28 12:55:59 duke kernel: usb 1-3.4: New USB device strings: Mfr=3, Product=1, SerialNumber=2
Feb 28 12:55:59 duke kernel: usb 1-3.4: Product: Back-UPS XS 1300 LCD FW:836.H8 .D USB FW:H8
Feb 28 12:55:59 duke kernel: usb 1-3.4: Manufacturer: American Power Conversion
Feb 28 12:55:59 duke kernel: usb 1-3.4: SerialNumber: BB0820009163
Feb 28 12:55:59 duke kernel: tveeprom 3-0050: Hauppauge model 72001, rev B3F0, serial# 5156904
Feb 28 12:55:59 duke kernel: tveeprom 3-0050: MAC address is 00-0D-FE-4E-B0-28
Feb 28 12:55:59 duke kernel: tveeprom 3-0050: tuner model is Xceive XC5000 (idx 150, type 76)
Feb 28 12:55:59 duke kernel: tveeprom 3-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
Feb 28 12:55:59 duke kernel: tveeprom 3-0050: audio processor is AU8522 (idx 44)
Feb 28 12:55:59 duke kernel: tveeprom 3-0050: decoder processor is AU8522 (idx 42)
Feb 28 12:55:59 duke kernel: tveeprom 3-0050: has no radio, has IR receiver, has no IR transmitter
Feb 28 12:55:59 duke kernel: hauppauge_eeprom: hauppauge eeprom: model=72001
Feb 28 12:55:59 duke kernel: au8522 3-0047: creating new instance
Feb 28 12:55:59 duke kernel: au8522_decoder creating new instance...
Feb 28 12:55:59 duke kernel: tuner 3-0061: chip found @ 0xc2 (au0828)
Feb 28 12:55:59 duke kernel: xc5000 3-0061: creating new instance
Feb 28 12:55:59 duke kernel: xc5000: Successfully identified at address 0x61
Feb 28 12:55:59 duke kernel: xc5000: Firmware has not been loaded previously
Feb 28 12:55:59 duke kernel: au8522 3-0047: attaching existing instance
Feb 28 12:55:59 duke kernel: xc5000 3-0061: attaching existing instance
Feb 28 12:55:59 duke kernel: xc5000: Successfully identified at address 0x61
Feb 28 12:55:59 duke kernel: xc5000: Firmware has not been loaded previously
Feb 28 12:55:59 duke kernel: DVB: registering new adapter (au0828)
Feb 28 12:55:59 duke kernel: DVB: registering adapter 1 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)...
Feb 28 12:55:59 duke kernel: Registered device AU0828 [Hauppauge HVR950Q]
Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver au0828
Feb 28 12:55:59 duke kernel: generic-usb 0003:051D:0002.0004: hiddev1: USB HID v1.10 Device [American Power Conversion Back-UPS XS 1300 LCD FW:836.H8 .D USB FW:H8 ] on usb-0000:00:1a.7-3.4/input0
Feb 28 12:55:59 duke kernel: kjournald starting. Commit interval 5 seconds
Feb 28 12:55:59 duke kernel: EXT3-fs (sda1): using internal journal
Feb 28 12:55:59 duke kernel: EXT3-fs (sda1): mounted filesystem with writeback data mode
Feb 28 12:55:59 duke kernel: XFS mounting filesystem md0
Feb 28 12:55:59 duke kernel: Ending clean XFS mount for filesystem: md0
Feb 28 12:55:59 duke kernel: sky2 eth0: enabling interface
Feb 28 12:55:59 duke kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
Feb 28 12:55:59 duke kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
Feb 28 12:55:59 duke kernel: sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
Feb 28 12:55:59 duke kernel: warning: `ntpd' uses 32-bit capabilities (legacy support in use)
Feb 28 12:55:59 duke logger: /etc/rc2.d/S13local start
Feb 28 12:55:59 duke kernel: ata1.00: configured for UDMA/133
Feb 28 12:55:59 duke kernel: ata1: EH complete
Feb 28 12:55:59 duke kernel: ata2.00: configured for UDMA/133
Feb 28 12:55:59 duke kernel: ata2: EH complete
Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 28 12:55:59 duke sshd[3674]: Server listening on 0.0.0.0 port 22.
Feb 28 12:55:59 duke /usr/sbin/gpm[3694]: *** info [daemon/startup.c(131)]:
Feb 28 12:55:59 duke /usr/sbin/gpm[3694]: Started gpm successfully. Entered daemon mode.
Feb 28 12:55:59 duke mysqld_safe[3773]: started
Feb 28 12:55:59 duke mysqld[3776]: 100228 12:55:59 [Warning] option 'net_buffer_length': unsigned value 8388608 adjusted to 1048576
Feb 28 12:55:59 duke mysqld[3776]: 100228 12:55:59 InnoDB: Started; log sequence number 0 2439644
Feb 28 12:55:59 duke mysqld[3776]: 100228 12:55:59 [Note] /usr/sbin/mysqld: ready for connections.
Feb 28 12:55:59 duke mysqld[3776]: Version: '5.0.67-0ubuntu6.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
Feb 28 12:56:00 duke /etc/mysql/debian-start[3815]: Upgrading MySQL tables if necessary.
Feb 28 12:56:00 duke /etc/mysql/debian-start[3819]: Looking for 'mysql' in: /usr/bin/mysql
Feb 28 12:56:00 duke /etc/mysql/debian-start[3819]: Looking for 'mysqlcheck' in: /usr/bin/mysqlcheck
Feb 28 12:56:00 duke /etc/mysql/debian-start[3819]: This installation of MySQL is already upgraded to 5.0.67, use --force if you still need to run mysql_upgrade
Feb 28 12:56:00 duke /etc/mysql/debian-start[3831]: Checking for insecure root accounts.
Feb 28 12:56:00 duke /etc/mysql/debian-start[3835]: WARNING: mysql.user contains 3 root accounts without password!
Feb 28 12:56:00 duke /etc/mysql/debian-start[3836]: Triggering myisam-recover for all MyISAM tables
Feb 28 12:56:01 duke ntpd[3564]: ntpd exiting on signal 15
Feb 28 12:56:01 duke ntpdate[3943]: step time server 10.0.0.2 offset 0.647632 sec
Feb 28 12:56:02 duke ntpd[4089]: ntpd 4.2.4p4@1.1520-o Fri Dec 4 19:14:37 UTC 2009 (1)
Feb 28 12:56:02 duke ntpd[4090]: precision = 1.000 usec
Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #2 eth0, 10.0.0.18#123 Enabled
Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #3 eth1, 169.254.4.100#123 Enabled
Feb 28 12:56:02 duke ntpd[4090]: kernel time sync status 0040
Feb 28 12:56:02 duke ntpd[4090]: frequency initialized 8.502 PPM from /var/lib/ntp/ntp.drift
Feb 28 12:56:02 duke acpid: client connected from 4129[113:122]
Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Feb 28 12:56:02 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Feb 28 12:56:02 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
Feb 28 12:56:02 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Feb 28 12:56:03 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-dig.fw
Feb 28 12:56:03 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
Feb 28 12:56:03 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
Feb 28 12:56:04 duke kernel: ivtv 0000:05:02.0: firmware: requesting v4l-cx2341x-enc.fw
Feb 28 12:56:04 duke kernel: ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
Feb 28 12:56:04 duke kernel: ivtv0: Encoder revision: 0x02060039
Feb 28 12:56:04 duke logger: /etc/rc2.d/S25mythtv-backend: creating symlink for /dev/cdrom
Feb 28 12:56:04 duke logger: /etc/rc2.d/S25mythtv-backend: creating symlink for /dev/dvd
Feb 28 12:56:04 duke kernel: ata1.00: configured for UDMA/133
Feb 28 12:56:04 duke kernel: ata1: EH complete
Feb 28 12:56:04 duke logger: Pre-initializing /dev/video1
Feb 28 12:56:05 duke kernel: ata5.00: configured for UDMA/133
Feb 28 12:56:05 duke kernel: ata2.00: configured for UDMA/133
Feb 28 12:56:05 duke kernel: ata2: EH complete
Feb 28 12:56:05 duke kernel: ata5: EH complete
Feb 28 12:56:05 duke kernel: sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 28 12:56:07 duke nanny.mythbackend[4274]: mythbackend[4277] started
Feb 28 12:56:07 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: reconfiguring driver
Feb 28 12:56:07 duke kernel: input: i2c IR (Hauppauge) as /class/input/input5
Feb 28 12:56:07 duke kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0]
Feb 28 12:56:07 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: waiting for device(s)
Feb 28 12:56:07 duke gdm[4335]: WARNING: Didn't understand `' (expected true or false)
Feb 28 12:56:07 duke acpid: client connected from 4351[0:0]
Feb 28 12:56:08 duke /usr/sbin/cron[4404]: (CRON) INFO (pidfile fd = 3)
Feb 28 12:56:08 duke /usr/sbin/cron[4405]: (CRON) STARTUP (fork ok)
Feb 28 12:56:08 duke /usr/sbin/cron[4405]: (CRON) INFO (Running @reboot jobs)
Feb 28 12:56:08 duke logger[4415]: /usr/bin/input-kbd -f /usr/local/bin/hauppauge_remote.conf 5
Feb 28 12:56:08 duke rpc.statd[4454]: Version 1.1.2 Starting
Feb 28 12:56:08 duke kernel: RPC: Registered udp transport module.
Feb 28 12:56:08 duke kernel: RPC: Registered tcp transport module.
Feb 28 12:56:08 duke kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Feb 28 12:56:08 duke acpid: client connected from 4351[0:0]
Feb 28 12:56:08 duke kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Feb 28 12:56:08 duke kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Feb 28 12:56:08 duke kernel: NFSD: starting 90-second grace period
Feb 28 12:56:09 duke logger: /etc/rc2.d/S98local start
Feb 28 12:56:09 duke kernel: ata1.00: configured for UDMA/133
Feb 28 12:56:09 duke kernel: ata1: EH complete
Feb 28 12:56:09 duke kernel: ata2.00: configured for UDMA/133
Feb 28 12:56:09 duke kernel: ata2: EH complete
Feb 28 12:56:09 duke gdm[4342]: pam_unix(gdm-autologin:session): session opened for user mlord by (uid=0)
Feb 28 12:56:09 duke gdm[4342]: pam_ck_connector(gdm-autologin:session): nox11 mode, ignoring PAM_TTY :0
Feb 28 12:56:09 duke apcupsd[4379]: NIS server startup succeeded
Feb 28 12:56:09 duke apcupsd[4379]: apcupsd 3.14.4 (18 May 2008) debian startup succeeded
Feb 28 12:56:10 duke nanny.vfd_updater[4825]: vfd_updater[4826] started
Feb 28 12:56:10 duke vfd_updater[4826]: connect(): Connection refused
Feb 28 12:56:15 duke kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
Feb 28 12:56:15 duke kernel: usb 1-3.2: firmware: requesting dvb-fe-xc5000-1.6.114.fw
Feb 28 12:56:15 duke kernel: xc5000: firmware read 12401 bytes.
Feb 28 12:56:15 duke kernel: xc5000: firmware uploading...
Feb 28 12:56:22 duke kernel: xc5000: firmware upload complete...
Feb 28 12:56:23 duke /usr/local/bin/diseqc_switcher[4876]: Selecting '2B'
Feb 28 12:56:23 duke /usr/local/bin/diseqc_switcher[4876]: writing 0x04 [- - - - - 1 - -]
Feb 28 12:56:24 duke /usr/local/bin/diseqc_switcher[4882]: Selecting '1D'
Feb 28 12:56:24 duke /usr/local/bin/diseqc_switcher[4882]: writing 0x07 [- - - - - 1 1 1]
Feb 28 12:56:29 duke logger: /usr/local/bin/set_wakeup_alarm.sh: mythbackend started by 'auto'
Feb 28 12:56:29 duke vfd_updater[4826]: mythbackend: ACCEPT, MYTH_PROTOCOL_VERSION 40
Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: setting wakeup alarm the old fashioned way
Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: setting wakeup alarm to (1267444589) UTC '2010-03-01 11:56:29' (local '2010-03-01 06:56:29')
Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: echo 2010-03-01 11:56:29 > /proc/acpi/alarm
Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: RTC alarm readback: 2010-03-01 11:56:29
Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: UTC time now: 2010-02-28 17:56:30
Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: next wakeup: 2010-03-01 06:56:29
Feb 28 12:58:31 duke /usr/local/bin/diseqc_switcher[5469]: Selecting '1D'
Feb 28 12:58:31 duke /usr/local/bin/diseqc_switcher[5469]: writing 0x07 [- - - - - 1 1 1]
Feb 28 13:00:23 duke ntpd[4090]: synchronized to 10.0.0.2, stratum 3
Feb 28 13:00:24 duke ntpd[4090]: time reset +0.338051 s
Feb 28 13:00:24 duke ntpd[4090]: kernel time sync status change 0001
Feb 28 13:05:41 duke ntpd[4090]: synchronized to 10.0.0.2, stratum 3
Feb 28 13:15:58 duke -- MARK --
Feb 28 13:17:01 duke CRON[7427]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 13:17:01 duke /USR/SBIN/CRON[7433]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 13:17:01 duke CRON[7427]: pam_unix(cron:session): session closed for user root
Feb 28 13:35:58 duke -- MARK --
Feb 28 13:55:58 duke -- MARK --
Feb 28 14:15:58 duke -- MARK --
Feb 28 14:17:01 duke CRON[13871]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 14:17:01 duke /USR/SBIN/CRON[13878]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 14:17:01 duke CRON[13871]: pam_unix(cron:session): session closed for user root
Feb 28 14:35:58 duke -- MARK --
Feb 28 14:55:58 duke -- MARK --
Feb 28 15:15:58 duke -- MARK --
Feb 28 15:17:01 duke CRON[20310]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 15:17:01 duke /USR/SBIN/CRON[20317]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 15:17:01 duke CRON[20310]: pam_unix(cron:session): session closed for user root
Feb 28 15:34:32 duke /usr/local/bin/diseqc_switcher[22382]: Selecting '2D'
Feb 28 15:34:32 duke /usr/local/bin/diseqc_switcher[22382]: writing 0x0f [- - - - 1 1 1 1]
Feb 28 15:50:22 duke kernel: hrtimer: interrupt took 5076 ns
Feb 28 15:50:31 duke /usr/local/bin/diseqc_switcher[24128]: Selecting '2D'
Feb 28 15:50:31 duke /usr/local/bin/diseqc_switcher[24128]: writing 0x0f [- - - - 1 1 1 1]
Feb 28 15:57:35 duke diseqc_switcher[24931]: open(diseqc_switcher): No such file or directory
Feb 28 15:57:45 duke /ulb/diseqc_switcher[24951]: Selecting '1b'
Feb 28 15:57:45 duke /ulb/diseqc_switcher[24951]: writing 0x0d [- - - - 1 1 - 1]
Feb 28 15:57:53 duke /ulb/diseqc_switcher[24968]: Selecting '1d'
Feb 28 15:57:53 duke /ulb/diseqc_switcher[24968]: writing 0x0f [- - - - 1 1 1 1]
Feb 28 15:58:03 duke /ulb/diseqc_switcher[24985]: Selecting '1c'
Feb 28 15:58:03 duke /ulb/diseqc_switcher[24985]: writing 0x0e [- - - - 1 1 1 -]
Feb 28 15:58:11 duke /ulb/diseqc_switcher[24997]: Selecting '1a'
Feb 28 15:58:11 duke /ulb/diseqc_switcher[24997]: writing 0x0c [- - - - 1 1 - -]
Feb 28 15:58:17 duke /ulb/diseqc_switcher[25016]: Selecting '1d'
Feb 28 15:58:17 duke /ulb/diseqc_switcher[25016]: writing 0x0f [- - - - 1 1 1 1]
Feb 28 16:15:58 duke -- MARK --
Feb 28 16:17:01 duke CRON[27448]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 16:17:01 duke /USR/SBIN/CRON[27455]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 16:17:01 duke CRON[27448]: pam_unix(cron:session): session closed for user root
Feb 28 16:21:31 duke /usr/local/bin/diseqc_switcher[28112]: Selecting '2C'
Feb 28 16:21:31 duke /usr/local/bin/diseqc_switcher[28112]: writing 0x0b [- - - - 1 - 1 1]
Feb 28 16:35:58 duke -- MARK --
Feb 28 16:55:58 duke -- MARK --
Feb 28 17:15:58 duke -- MARK --
Feb 28 17:17:01 duke CRON[1744]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 17:17:01 duke /USR/SBIN/CRON[1750]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 17:17:01 duke CRON[1744]: pam_unix(cron:session): session closed for user root
Feb 28 17:35:58 duke -- MARK --
Feb 28 17:55:58 duke -- MARK --
Feb 28 18:15:58 duke -- MARK --
Feb 28 18:17:01 duke CRON[8585]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 18:17:01 duke /USR/SBIN/CRON[8591]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 18:17:01 duke CRON[8585]: pam_unix(cron:session): session closed for user root
Feb 28 18:35:58 duke -- MARK --
Feb 28 18:55:58 duke -- MARK --
Feb 28 18:59:31 duke /usr/local/bin/diseqc_switcher[14920]: Selecting '1C'
Feb 28 18:59:31 duke /usr/local/bin/diseqc_switcher[14920]: writing 0x0a [- - - - 1 - 1 -]
Feb 28 19:15:58 duke -- MARK --
Feb 28 19:17:01 duke CRON[16800]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 28 19:17:01 duke /USR/SBIN/CRON[16807]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 19:17:01 duke CRON[16800]: pam_unix(cron:session): session closed for user root
Feb 28 19:35:58 duke -- MARK --
Feb 28 19:55:58 duke -- MARK --
Feb 28 19:59:31 duke /usr/local/bin/diseqc_switcher[21502]: Selecting '2D'
Feb 28 19:59:31 duke /usr/local/bin/diseqc_switcher[21502]: writing 0x0e [- - - - 1 1 1 -]
Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing
Feb 28 20:00:03 duke /usr/local/bin/diseqc_switcher[21597]: Selecting '1B'
Feb 28 20:00:03 duke /usr/local/bin/diseqc_switcher[21597]: writing 0x0d [- - - - 1 1 - 1]
Feb 28 20:15:58 duke -- MARK --
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...
2010-03-01 16:07 cx18: Unable to find blank work order form to schedule incoming mailbox Mark Lord
@ 2010-03-02 1:34 ` Andy Walls
2010-03-02 5:57 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-03-02 1:34 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel
On Mon, 2010-03-01 at 11:07 -0500, Mark Lord wrote:
> I'm using MythTV-0.21-fixes (from svn) on top of Linux-2.6.33 (from kernel.org),
> with an HVR-1600 tuner card. This card usually works okay (with workarounds for
> the known analog recording bugs) in both analog and digital modes.
>
> Last night, for the first time ever, MythTV chose to record from both the analog
> and digital sides of the HVR-1600 card at exactly the same times..
>
> The kernel driver failed, and neither recording was successful.
> The only message in /var/log/messages was:
>
> Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing
This is really odd. It means:
1. Your machine had a very busy burst of cx18 driver buffer handling
activity. Stopping a number of different streams, MPEG, VBI, and (DTV)
TS at nearly the same time could do it
2. The firmware locked up.
3. The work handler kernel thread, cx18-0-in, got killed, if that's
possible, or the processor it was running on got really bogged down.
> I strongly suspect some kind of conflict/race between the analog and digital sides,
> as in this case both were trying to start a new recording at the same time.
Maybe stopping several streams at once is the real problem (and then
immediately trying to restart at the same time). You can turn on high
volume dma and mailbox debugging in the cx18 driver if you know how to
reliably reporduce the problem. You'll see lots of EPU_DMA_DONE
notifications when you stop a stream.
If you want to make the problem "just go away" then up this parameter in
cx18-driver.h:
#define CX18_MAX_IN_WORK_ORDERS (CX18_MAX_FW_MDLS_PER_STREAM + 7)
to something like
#define CX18_MAX_IN_WORK_ORDERS (2*CX18_MAX_FW_MDLS_PER_STREAM + 7)
or 3* or 4* or whatever. It's only memory, which is cheap nowadays.
The really odd part is that the streams failed to restart. That should
not happen, even if "work orders" are temporarily not available. The
fact that you got only one message means the condition was really
transient or the firmware just stopped working at that point. Normally
the firmware *does not wait* long for the driver to respond and
continues on. For the firmware to just stop and wait indefinitely for
the driver is not what it typically does.
> Any ideas?
You may also want to update to the latest version of the cx18 driver.
It is up to v1.4.0 now.
Regards,
Andy
> Log files follow..
>
> The MythTV backend log file is a bit tricky to follow, because there are many other
> tuners also present in the same system:
>
> 2010-02-28 19:58:59.604 TVRec(42): ASK_RECORDING 42 29 0 0
> 2010-02-28 19:58:59.923 TVRec(29): ASK_RECORDING 29 29 0 0
> 2010-02-28 19:59:00.365 TVRec(41): ASK_RECORDING 41 29 0 0
> 2010-02-28 19:59:29.463 TVRec(30): ASK_RECORDING 30 29 0 0
> 2010-02-28 19:59:31.483 TVRec(41): Changing from None to RecordingOnly
> 2010-02-28 19:59:31.486 TVRec(41): HW Tuner: 41->41
> 2010-02-28 19:59:31.779 DVBSM(0), Warning: Can not measure Signal Strength
> eno: Invalid argument (22)
> 2010-02-28 19:59:31.781 DVBSM(0), Warning: Can not measure S/N
> eno: Invalid argument (22)
> 2010-02-28 19:59:31.801 AutoExpire: CalcParams(): Max required Free Space: 6.0 GB w/freq: 10 min
> 2010-02-28 19:59:31.805 Started recording: XXI Winter Olympics "Closing Ceremony": channel 4271 on cardid 41, sourceid 4
> 2010-02-28 19:59:31.827 TVRec(29): Changing from None to RecordingOnly
> 2010-02-28 19:59:31.828 TVRec(29): HW Tuner: 29->29
> /usr/local/bin/diseqc_switcher[21502]: Selecting '2D'
> /usr/local/bin/diseqc_switcher[21502]: writing 0x0e [- - - - 1 1 1 -]
> /dev/video1: 211.250 MHz (Signal Detected)
> 2010-02-28 19:59:32.836 ret_pid(21499) child(21499) status(0x0)
> 2010-02-28 19:59:32.838 External Tuning program exited with no error
> 2010-02-28 19:59:32.885
>
> Not ivtv driver??
>
>
> 2010-02-28 19:59:32.888 AutoExpire: CalcParams(): Max required Free Space: 6.0 GB w/freq: 8 min
> 2010-02-28 19:59:32.891 Started recording: XXI Winter Olympics "Closing Ceremony": channel 1013 on cardid 29, sourceid 1
> 2010-02-28 19:59:36.606 JobQueue: Commercial Flagging Starting for XXI Winter Olympics "Closing Ceremony" recorded from channel 1013 at Sun Feb 28 20:00:00 2010
> 2010-02-28 19:59:36.749 Using runtime prefix = /usr
> 2010-02-28 19:59:36.753 Empty LocalHostName.
> 2010-02-28 19:59:36.755 Using localhost value of duke
> 2010-02-28 19:59:36.766 New DB connection, total: 1
> 2010-02-28 19:59:36.771 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 19:59:36.775 Closing DB connection named 'DBManager0'
> 2010-02-28 19:59:36.777 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 19:59:36.782 New DB connection, total: 2
> 2010-02-28 19:59:36.784 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 19:59:36.810 Connecting to backend server: 10.0.0.18:6543 (try 1 of 5)
> 2010-02-28 19:59:36.814 Using protocol version 40
> 2010-02-28 19:59:36.820 MainServer::HandleAnnounce Monitor
> 2010-02-28 19:59:36.822 adding: duke as a client (events: 0)
> 2010-02-28 19:59:36.826 MainServer::HandleAnnounce Monitor
> 2010-02-28 19:59:36.828 adding: duke as a client (events: 1)
> 2010-02-28 19:59:41.609 JobQueue: Commercial Flagging Starting for XXI Winter Olympics "Closing Ceremony" recorded from channel 4271 at Sun Feb 28 20:00:00 2010
> 2010-02-28 19:59:41.695 Using runtime prefix = /usr
> 2010-02-28 19:59:41.698 Empty LocalHostName.
> 2010-02-28 19:59:41.704 Using localhost value of duke
> 2010-02-28 19:59:41.712 New DB connection, total: 1
> 2010-02-28 19:59:41.718 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 19:59:41.721 Closing DB connection named 'DBManager0'
> 2010-02-28 19:59:41.724 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 19:59:41.730 New DB connection, total: 2
> 2010-02-28 19:59:41.734 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 19:59:41.749 Connecting to backend server: 10.0.0.18:6543 (try 1 of 5)
> 2010-02-28 19:59:41.751 Using protocol version 40
> 2010-02-28 19:59:41.753 MainServer::HandleAnnounce Monitor
> 2010-02-28 19:59:41.757 adding: duke as a client (events: 0)
> 2010-02-28 19:59:41.760 MainServer::HandleAnnounce Monitor
> 2010-02-28 19:59:41.762 adding: duke as a client (events: 1)
> 2010-02-28 19:59:50.538 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 19:59:56.741 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:02.547 TVRec(30): Changing from RecordingOnly to None
> 2010-02-28 20:00:02.552 Finished recording The Monarchy "King and Emperor": channel 1024
> 2010-02-28 20:00:02.883 Finished recording The Monarchy "King and Emperor": channel 1024
> 2010-02-28 20:00:02.908 TVRec(30): Changing from None to RecordingOnly
> 2010-02-28 20:00:02.911 TVRec(30): HW Tuner: 30->30
> 2010-02-28 20:00:02.943 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:02.963 Using runtime prefix = /usr
> 2010-02-28 20:00:02.965 Empty LocalHostName.
> 2010-02-28 20:00:02.967 Using localhost value of duke
> 2010-02-28 20:00:02.977 New DB connection, total: 1
> 2010-02-28 20:00:02.982 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 20:00:02.985 Closing DB connection named 'DBManager0'
> 2010-02-28 20:00:02.987 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 20:00:02.992 New DB connection, total: 2
> 2010-02-28 20:00:02.995 Connected to database 'mythconverg' at host: localhost
> 2010-02-28 20:00:02.998 Current Schema Version: 1214
> /usr/local/bin/diseqc_switcher[21597]: Selecting '1B'
> /usr/local/bin/diseqc_switcher[21597]: writing 0x0d [- - - - 1 1 - 1]
> /dev/video0: 645.250 MHz (Signal Detected)
> 2010-02-28 20:00:03.925 ret_pid(21594) child(21594) status(0x0)
> 2010-02-28 20:00:03.928 External Tuning program exited with no error
> 2010-02-28 20:00:03.957 AutoExpire: CalcParams(): Max required Free Space: 6.0 GB w/freq: 8 min
> 2010-02-28 20:00:03.960 Started recording: The Amazing Race 16 "Run Like Scalded Dogs!": channel 1043 on cardid 30, sourceid 1
> *********************** WARNING ***********************
> ivtv drivers prior to 0.10.0 can cause lockups when
> reading VBI. Drivers between 0.10.5 and 1.0.3+ do not
> properly capture VBI data on PVR-250 and PVR-350 cards.
>
> 2010-02-28 20:00:05.005 Reschedule requested for id 0.
> 2010-02-28 20:00:05.177 Scheduled 120 items in 0.2 = 0.00 match + 0.16 place
> 2010-02-28 20:00:05.489 AFD: Opened codec 0x204a5d0, id(MPEG2VIDEO) type(Video)
> 2010-02-28 20:00:05.492 AFD: codec MP2 has 2 channels
> 2010-02-28 20:00:05.495 AFD: Opened codec 0x2053b20, id(MP2) type(Audio)
> 2010-02-28 20:00:05.635 Preview: Grabbed preview '/var/lib/mythtv/recordings/1024_20100228190000.mpg' 720x480@180s
> 2010-02-28 20:00:09.146 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:15.349 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:21.551 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:27.755 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:32.850 RingBuf(/var/lib/mythtv/recordings/4271_20100228200000.mpg): Waited 1.0 seconds for data to become available...
> 2010-02-28 20:00:33.650 RingBuf(/var/lib/mythtv/recordings/1013_20100228200000.mpg): Waited 2.0 seconds for data to become available...
> 2010-02-28 20:00:33.859 RingBuf(/var/lib/mythtv/recordings/4271_20100228200000.mpg): Waited 2.0 seconds for data to become available...
> 2010-02-28 20:00:33.959 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:33.993 AFD: Opened codec 0xddbb70, id(MPEG2VIDEO) type(Video)
> 2010-02-28 20:00:33.996 AFD: codec MP2 has 2 channels
> 2010-02-28 20:00:33.998 AFD: Opened codec 0xde4850, id(MP2) type(Audio)
> 2010-02-28 20:00:34.254 AFD: Opened codec 0x7fe7bc009230, id(MPEG2VIDEO) type(Video)
> 2010-02-28 20:00:34.257 AFD: codec AC3 has 6 channels
> 2010-02-28 20:00:34.260 AFD: Opened codec 0x7fe7bc0098b0, id(AC3) type(Audio)
> 2010-02-28 20:00:34.264 AFD: codec AC3 has 1 channels
> 2010-02-28 20:00:34.268 AFD: Opened codec 0x7fe7bc024520, id(AC3) type(Audio)
> 2010-02-28 20:00:40.162 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:46.365 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:52.567 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:00:58.769 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:01:04.971 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:01:11.175 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:01:17.378 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:01:23.581 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:01:29.784 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:01:35.987 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
> 2010-02-28 20:01:42.190 MPEGRec(/dev/video1) Error: select timeout - ivtv driver has stopped responding
>
> And here's /var/log/messages from boot up to/after the failure:
>
> Feb 28 12:55:56 duke syslogd 1.5.0#2ubuntu6: restart.
> Feb 28 12:55:58 duke ntpdate[3184]: step time server 10.0.0.2 offset 2.330536 sec
> Feb 28 12:55:58 duke ntpd[3556]: ntpd 4.2.4p4@1.1520-o Fri Dec 4 19:14:37 UTC 2009 (1)
> Feb 28 12:55:58 duke ntpd[3564]: precision = 1.000 usec
> Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
> Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
> Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #2 eth0, 10.0.0.18#123 Enabled
> Feb 28 12:55:58 duke ntpd[3564]: Listening on interface #3 eth1, 169.254.4.100#123 Enabled
> Feb 28 12:55:58 duke ntpd[3564]: kernel time sync status 0040
> Feb 28 12:55:58 duke ntpd[3564]: frequency initialized 8.502 PPM from /var/lib/ntp/ntp.drift
> Feb 28 12:55:58 duke kernel: Inspecting /boot/System.map-2.6.33
> Feb 28 12:55:58 duke kernel: Inspecting /boot/System.map
> Feb 28 12:55:58 duke kernel: Inspecting /usr/src/linux/System.map
> Feb 28 12:55:59 duke kernel: Cannot find map file.
> Feb 28 12:55:59 duke kernel: Loaded 43513 symbols from 75 modules.
> Feb 28 12:55:59 duke kernel: orted from D0 D3hot D3cold
> Feb 28 12:55:59 duke kernel: pci 0000:00:1b.0: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:00:1d.0: reg 20: [io 0xf400-0xf41f]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1d.1: reg 20: [io 0xf000-0xf01f]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1d.2: reg 20: [io 0xec00-0xec1f]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1d.7: reg 10: [mem 0xfdffe000-0xfdffe3ff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
> Feb 28 12:55:59 duke kernel: pci 0000:00:1d.7: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: quirk: [io 0x0400-0x047f] claimed by ICH6 ACPI/GPIO/TCO
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: quirk: [io 0x0480-0x04bf] claimed by ICH6 GPIO
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800 (mask 003f)
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 003f)
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 10: [io 0xe800-0xe807]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 14: [io 0xe400-0xe403]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 18: [io 0xe000-0xe007]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 1c: [io 0xdc00-0xdc03]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 20: [io 0xd800-0xd81f]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: reg 24: [mem 0xfdffd000-0xfdffd7ff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: PME# supported from D3hot
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.2: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.3: reg 10: [mem 0xfdffc000-0xfdffc0ff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.3: reg 20: [io 0x0500-0x051f]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1f.6: reg 10: [mem 0xfdffb000-0xfdffbfff 64bit]
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 10: [mem 0xfb000000-0xfbffffff]
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 14: [mem 0xb0000000-0xbfffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 1c: [mem 0xce000000-0xcfffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 24: [io 0x5c00-0x5c7f]
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0007ffff pref]
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.1: reg 10: [mem 0xfcffc000-0xfcffffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [io 0x5000-0x5fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xfb000000-0xfcffffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xb0000000-0xcfffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PCI bridge to [bus 02-02]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [io 0xa000-0xafff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdc00000-0xfdcfffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdb00000-0xfdbfffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: reg 24: [mem 0xfdafe000-0xfdafffff]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: reg 30: [mem 0x00000000-0x0000ffff pref]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: PME# supported from D3hot
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 10: [io 0x9c00-0x9c07]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 14: [io 0x9800-0x9803]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 18: [io 0x9400-0x9407]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 1c: [io 0x9000-0x9003]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.1: reg 20: [io 0x8c00-0x8c0f]
> Feb 28 12:55:59 duke syslogd: /dev/console: Resource temporarily unavailable
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PCI bridge to [bus 03-03]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [io 0x8000-0x9fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfda00000-0xfdafffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfd900000-0xfd9fffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: reg 10: [mem 0xfdefc000-0xfdefffff 64bit]
> Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: reg 18: [io 0x6c00-0x6cff]
> Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
> Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: supports D1 D2
> Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PCI bridge to [bus 04-04]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [io 0x6000-0x6fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfde00000-0xfdefffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: reg 10: [mem 0xdbfff000-0xdbfff7ff]
> Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: reg 14: [io 0x7c00-0x7c7f]
> Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: supports D2
> Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: PME# supported from D2 D3hot D3cold
> Feb 28 12:55:59 duke kernel: pci 0000:05:00.0: PME# disabled
> Feb 28 12:55:59 duke kernel: pci 0000:05:02.0: reg 10: [mem 0xf4000000-0xf7ffffff pref]
> Feb 28 12:55:59 duke kernel: pci 0000:05:03.0: reg 10: [mem 0xd4000000-0xd7ffffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [io 0x7000-0x7fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xd4000000-0xdbffffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xf4000000-0xf7ffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:00: on NUMA node 0
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 9 10 11 12 *14 15)
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 9 10 11 12 14 *15)
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 9 10 *11 12 14 15)
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 9 *10 11 12 14 15)
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 9 10 11 12 14 15) *0, disabled.
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *9 10 11 12 14 15)
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNK0] (IRQs *5 9 10 11 12 14 15)
> Feb 28 12:55:59 duke kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs 5 9 10 11 12 14 *15)
> Feb 28 12:55:59 duke kernel: vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
> Feb 28 12:55:59 duke kernel: vgaarb: loaded
> Feb 28 12:55:59 duke kernel: SCSI subsystem initialized
> Feb 28 12:55:59 duke kernel: libata version 3.00 loaded.
> Feb 28 12:55:59 duke kernel: PCI: Using ACPI for IRQ routing
> Feb 28 12:55:59 duke kernel: PCI: pci_cache_line_size set to 64 bytes
> Feb 28 12:55:59 duke kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> Feb 28 12:55:59 duke kernel: hpet0: 3 comparators, 64-bit 14.318180 MHz counter
> Feb 28 12:55:59 duke kernel: Switching to clocksource tsc
> Feb 28 12:55:59 duke kernel: pnp: PnP ACPI init
> Feb 28 12:55:59 duke kernel: ACPI: bus type pnp registered
> Feb 28 12:55:59 duke kernel: pnp: PnP ACPI: found 14 devices
> Feb 28 12:55:59 duke kernel: ACPI: ACPI bus type pnp unregistered
> Feb 28 12:55:59 duke kernel: system 00:01: [io 0x04d0-0x04d1] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:01: [io 0x0290-0x029f] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:01: [io 0x0800-0x087f] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:01: [io 0x0880-0x088f] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0a: [io 0x0400-0x04bf] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000d6000-0x000d7fff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000f0000-0x000f7fff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000f8000-0x000fbfff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000fc000-0x000fffff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x7ff00000-0x7fffffff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfed00000-0xfed000ff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x7fee0000-0x7fefffff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x00000000-0x0009ffff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x00100000-0x7fedffff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfec00000-0xfec00fff] could not be reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfed13000-0xfed1ffff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfed20000-0xfed9ffff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfee00000-0xfee00fff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xffb00000-0xffb7ffff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0xfff00000-0xffffffff] has been reserved
> Feb 28 12:55:59 duke kernel: system 00:0d: [mem 0x000e0000-0x000effff] has been reserved
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: BAR 6: assigned [mem 0xc0000000-0xc007ffff pref]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [io 0x5000-0x5fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xfb000000-0xfcffffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: bridge window [mem 0xb0000000-0xcfffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PCI bridge to [bus 02-02]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [io 0xa000-0xafff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdc00000-0xfdcfffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdb00000-0xfdbfffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:03:00.0: BAR 6: assigned [mem 0xfd900000-0xfd90ffff pref]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PCI bridge to [bus 03-03]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [io 0x8000-0x9fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfda00000-0xfdafffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfd900000-0xfd9fffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:04:00.0: BAR 6: assigned [mem 0xfdd00000-0xfdd1ffff pref]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PCI bridge to [bus 04-04]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [io 0x6000-0x6fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfde00000-0xfdefffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: PCI bridge to [bus 05-05]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [io 0x7000-0x7fff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xd4000000-0xdbffffff]
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xf4000000-0xf7ffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> Feb 28 12:55:59 duke kernel: pci 0000:00:01.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.2: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
> Feb 28 12:55:59 duke kernel: pci 0000:00:1c.3: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pci 0000:00:1e.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffffffffffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:01: resource 0 [io 0x5000-0x5fff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:01: resource 1 [mem 0xfb000000-0xfcffffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:01: resource 2 [mem 0xb0000000-0xcfffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:02: resource 0 [io 0xa000-0xafff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:02: resource 1 [mem 0xfdc00000-0xfdcfffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:02: resource 2 [mem 0xfdb00000-0xfdbfffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:03: resource 0 [io 0x8000-0x9fff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:03: resource 1 [mem 0xfda00000-0xfdafffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:03: resource 2 [mem 0xfd900000-0xfd9fffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:04: resource 0 [io 0x6000-0x6fff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:04: resource 1 [mem 0xfde00000-0xfdefffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:04: resource 2 [mem 0xfdd00000-0xfddfffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 0 [io 0x7000-0x7fff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 1 [mem 0xd4000000-0xdbffffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 2 [mem 0xf4000000-0xf7ffffff 64bit pref]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 3 [io 0x0000-0xffff]
> Feb 28 12:55:59 duke kernel: pci_bus 0000:05: resource 4 [mem 0x00000000-0xffffffffffffffff]
> Feb 28 12:55:59 duke kernel: NET: Registered protocol family 2
> Feb 28 12:55:59 duke kernel: IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
> Feb 28 12:55:59 duke kernel: TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
> Feb 28 12:55:59 duke kernel: TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> Feb 28 12:55:59 duke kernel: TCP: Hash tables configured (established 262144 bind 65536)
> Feb 28 12:55:59 duke kernel: TCP reno registered
> Feb 28 12:55:59 duke kernel: UDP hash table entries: 1024 (order: 3, 32768 bytes)
> Feb 28 12:55:59 duke kernel: UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
> Feb 28 12:55:59 duke kernel: NET: Registered protocol family 1
> Feb 28 12:55:59 duke kernel: pci 0000:01:00.0: Boot video device
> Feb 28 12:55:59 duke kernel: PCI: CLS 64 bytes, default 64
> Feb 28 12:55:59 duke kernel: Scanning for low memory corruption every 60 seconds
> Feb 28 12:55:59 duke kernel: HugeTLB registered 2 MB page size, pre-allocated 0 pages
> Feb 28 12:55:59 duke kernel: SGI XFS with security attributes, realtime, large block/inode numbers, no debug enabled
> Feb 28 12:55:59 duke kernel: msgmni has been set to 4019
> Feb 28 12:55:59 duke kernel: alg: No test for stdrng (krng)
> Feb 28 12:55:59 duke kernel: Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> Feb 28 12:55:59 duke kernel: io scheduler noop registered
> Feb 28 12:55:59 duke kernel: io scheduler cfq registered (default)
> Feb 28 12:55:59 duke kernel: pcieport 0000:00:01.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pcieport 0000:00:1c.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pcieport 0000:00:1c.2: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: pcieport 0000:00:1c.3: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: lp: driver loaded but no devices found
> Feb 28 12:55:59 duke kernel: Generic RTC Driver v1.07
> Feb 28 12:55:59 duke kernel: Non-volatile memory driver v1.3
> Feb 28 12:55:59 duke kernel: Linux agpgart interface v0.103
> Feb 28 12:55:59 duke kernel: [drm] Initialized drm 1.1.0 20060810
> Feb 28 12:55:59 duke kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> Feb 28 12:55:59 duke kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> Feb 28 12:55:59 duke kernel: 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> Feb 28 12:55:59 duke kernel: parport_pc 00:08: reported by Plug and Play ACPI
> Feb 28 12:55:59 duke kernel: parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
> Feb 28 12:55:59 duke kernel: lp0: using parport0 (interrupt-driven).
> Feb 28 12:55:59 duke kernel: loop: module loaded
> Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: version 3.0
> Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x33 impl SATA mode
> Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio slum part ccc ems
> Feb 28 12:55:59 duke kernel: ahci 0000:00:1f.2: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: scsi0 : ahci
> Feb 28 12:55:59 duke kernel: scsi1 : ahci
> Feb 28 12:55:59 duke kernel: scsi2 : ahci
> Feb 28 12:55:59 duke kernel: scsi3 : ahci
> Feb 28 12:55:59 duke kernel: scsi4 : ahci
> Feb 28 12:55:59 duke kernel: scsi5 : ahci
> Feb 28 12:55:59 duke kernel: ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
> Feb 28 12:55:59 duke kernel: ata2: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
> Feb 28 12:55:59 duke kernel: ata3: DUMMY
> Feb 28 12:55:59 duke kernel: ata4: DUMMY
> Feb 28 12:55:59 duke kernel: ata5: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
> Feb 28 12:55:59 duke kernel: ata6: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd380 irq 17
> Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: JMB361 has only one port, port_map 0x3 -> 0x1
> Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x1 impl SATA mode
> Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
> Feb 28 12:55:59 duke kernel: ahci 0000:03:00.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: scsi6 : ahci
> Feb 28 12:55:59 duke kernel: scsi7 : ahci
> Feb 28 12:55:59 duke kernel: ata7: SATA max UDMA/133 abar m8192@0xfdafe000 port 0xfdafe100 irq 18
> Feb 28 12:55:59 duke kernel: ata8: DUMMY
> Feb 28 12:55:59 duke kernel: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
> Feb 28 12:55:59 duke kernel: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
> Feb 28 12:55:59 duke kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
> Feb 28 12:55:59 duke kernel: mice: PS/2 mouse device common for all mice
> Feb 28 12:55:59 duke kernel: md: raid0 personality registered for level 0
> Feb 28 12:55:59 duke kernel: cpuidle: using governor ladder
> Feb 28 12:55:59 duke kernel: ioatdma: Intel(R) QuickData Technology Driver 4.00
> Feb 28 12:55:59 duke kernel: TCP cubic registered
> Feb 28 12:55:59 duke kernel: NET: Registered protocol family 17
> Feb 28 12:55:59 duke kernel: ata7: SATA link down (SStatus 0 SControl 300)
> Feb 28 12:55:59 duke kernel: ata6: SATA link down (SStatus 0 SControl 300)
> Feb 28 12:55:59 duke kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> Feb 28 12:55:59 duke kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> Feb 28 12:55:59 duke kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> Feb 28 12:55:59 duke kernel: ata1.00: ATA-8: OCZ-VERTEX, 1.5, max UDMA/133
> Feb 28 12:55:59 duke kernel: ata1.00: 125045424 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
> Feb 28 12:55:59 duke kernel: ata1.00: configured for UDMA/133
> Feb 28 12:55:59 duke kernel: scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX 1.5 PQ: 0 ANSI: 5
> Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
> Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Write Protect is off
> Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Feb 28 12:55:59 duke kernel: sda: sda1 sda2
> Feb 28 12:55:59 duke kernel: ata2.00: ATA-7: ST3750640NS, 3.BAF, max UDMA/133
> Feb 28 12:55:59 duke kernel: ata2.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> Feb 28 12:55:59 duke kernel: sd 0:0:0:0: [sda] Attached SCSI disk
> Feb 28 12:55:59 duke kernel: ata2.00: configured for UDMA/133
> Feb 28 12:55:59 duke kernel: ata5.00: ATA-7: ST3750640NS, 3.BAF, max UDMA/133
> Feb 28 12:55:59 duke kernel: scsi 1:0:0:0: Direct-Access ATA ST3750640NS 3.BA PQ: 0 ANSI: 5
> Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
> Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Write Protect is off
> Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> Feb 28 12:55:59 duke kernel: sdb: sdb1 sdb2
> Feb 28 12:55:59 duke kernel: ata5.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
> Feb 28 12:55:59 duke kernel: ata5.00: configured for UDMA/133
> Feb 28 12:55:59 duke kernel: scsi 4:0:0:0: Direct-Access ATA ST3750640NS 3.BA PQ: 0 ANSI: 5
> Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] 1465149168 512-byte logical blocks: (750 GB/698 GiB)
> Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Write Protect is off
> Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Mode Sense: 00 3a 00 00
> Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
> Feb 28 12:55:59 duke kernel: sdc: sdc1 sdc2
> Feb 28 12:55:59 duke kernel: sd 4:0:0:0: [sdc] Attached SCSI disk
> Feb 28 12:55:59 duke kernel: md: Waiting for all devices to be available before autodetect
> Feb 28 12:55:59 duke kernel: md: If you don't use raid, use raid=noautodetect
> Feb 28 12:55:59 duke kernel: md: Autodetecting RAID arrays.
> Feb 28 12:55:59 duke kernel: md: Scanned 2 and added 2 devices.
> Feb 28 12:55:59 duke kernel: md: autorun ...
> Feb 28 12:55:59 duke kernel: md: considering sdc2 ...
> Feb 28 12:55:59 duke kernel: md: adding sdc2 ...
> Feb 28 12:55:59 duke kernel: md: adding sdb2 ...
> Feb 28 12:55:59 duke kernel: md: created md0
> Feb 28 12:55:59 duke kernel: md: bind<sdb2>
> Feb 28 12:55:59 duke kernel: md: bind<sdc2>
> Feb 28 12:55:59 duke kernel: md: running: <sdc2><sdb2>
> Feb 28 12:55:59 duke kernel: raid0: looking at sdc2
> Feb 28 12:55:59 duke kernel: raid0: comparing sdc2(1433013760)
> Feb 28 12:55:59 duke kernel: with sdc2(1433013760)
> Feb 28 12:55:59 duke kernel: raid0: END
> Feb 28 12:55:59 duke kernel: raid0: ==> UNIQUE
> Feb 28 12:55:59 duke kernel: raid0: 1 zones
> Feb 28 12:55:59 duke kernel: raid0: looking at sdb2
> Feb 28 12:55:59 duke kernel: raid0: comparing sdb2(1433013760)
> Feb 28 12:55:59 duke kernel: with sdc2(1433013760)
> Feb 28 12:55:59 duke kernel: raid0: EQUAL
> Feb 28 12:55:59 duke kernel: raid0: FINAL 1 zones
> Feb 28 12:55:59 duke kernel: raid0: done.
> Feb 28 12:55:59 duke kernel: raid0 : md_size is 2866027520 sectors.
> Feb 28 12:55:59 duke kernel: ******* md0 configuration *********
> Feb 28 12:55:59 duke kernel: zone0=[sdb2/sdc2/]
> Feb 28 12:55:59 duke kernel: zone offset=0kb device offset=0kb size=1433013760kb
> Feb 28 12:55:59 duke kernel: **********************************
> Feb 28 12:55:59 duke kernel:
> Feb 28 12:55:59 duke kernel: md0: detected capacity change from 0 to 1467406090240
> Feb 28 12:55:59 duke kernel: md: ... autorun DONE.
> Feb 28 12:55:59 duke kernel: EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240)
> Feb 28 12:55:59 duke kernel: EXT4-fs (sda2): mounted filesystem with ordered data mode
> Feb 28 12:55:59 duke kernel: VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
> Feb 28 12:55:59 duke kernel: Freeing unused kernel memory: 408k freed
> Feb 28 12:55:59 duke kernel: fuse init (API version 7.13)
> Feb 28 12:55:59 duke kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> Feb 28 12:55:59 duke kernel: HDA Intel 0000:00:1b.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: hda_codec: ALC883: BIOS auto-probing.
> Feb 28 12:55:59 duke kernel: HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> Feb 28 12:55:59 duke kernel: HDA Intel 0000:01:00.1: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: Linux video capture interface: v2.00
> Feb 28 12:55:59 duke kernel: ivtv: Start initialization, version 1.4.1
> Feb 28 12:55:59 duke kernel: ivtv0: Initializing card 0
> Feb 28 12:55:59 duke kernel: ivtv0: Autodetected Hauppauge card (cx23416 based)
> Feb 28 12:55:59 duke kernel: ivtv 0000:05:02.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> Feb 28 12:55:59 duke kernel: tveeprom 0-0050: Hauppauge model 32062, rev B185, serial# 2842715
> Feb 28 12:55:59 duke kernel: tveeprom 0-0050: tuner model is TCL 2002N 6A (idx 85, type 50)
> Feb 28 12:55:59 duke kernel: tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
> Feb 28 12:55:59 duke kernel: tveeprom 0-0050: audio processor is MSP3445 (idx 12)
> Feb 28 12:55:59 duke kernel: tveeprom 0-0050: decoder processor is SAA7115 (idx 19)
> Feb 28 12:55:59 duke kernel: tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter
> Feb 28 12:55:59 duke kernel: ivtv0: Autodetected Hauppauge WinTV PVR-250
> Feb 28 12:55:59 duke kernel: saa7115 0-0021: saa7115 found (1f7115d0e100000) @ 0x42 (ivtv i2c driver #0)
> Feb 28 12:55:59 duke kernel: msp3400 0-0040: MSP3445G-B8 found @ 0x80 (ivtv i2c driver #0)
> Feb 28 12:55:59 duke kernel: msp3400 0-0040: msp3400 supports radio, mode is autodetect and autoselect
> Feb 28 12:55:59 duke kernel: tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> Feb 28 12:55:59 duke kernel: tuner-simple 0-0061: creating new instance
> Feb 28 12:55:59 duke kernel: tuner-simple 0-0061: type set to 50 (TCL 2002N)
> Feb 28 12:55:59 duke kernel: IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
> Feb 28 12:55:59 duke kernel: ivtv0: Registered device video0 for encoder MPG (4096 kB)
> Feb 28 12:55:59 duke kernel: ivtv0: Registered device video32 for encoder YUV (2048 kB)
> Feb 28 12:55:59 duke kernel: ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
> Feb 28 12:55:59 duke kernel: ivtv0: Registered device video24 for encoder PCM (320 kB)
> Feb 28 12:55:59 duke kernel: ivtv0: Initialized card: Hauppauge WinTV PVR-250
> Feb 28 12:55:59 duke kernel: ivtv: End initialization
> Feb 28 12:55:59 duke kernel: md0: unknown partition table
> Feb 28 12:55:59 duke kernel: thermal LNXTHERM:01: registered as thermal_zone0
> Feb 28 12:55:59 duke kernel: ACPI: Invalid PBLK length [0]
> Feb 28 12:55:59 duke kernel: input: Power Button as /class/input/input0
> Feb 28 12:55:59 duke kernel: ACPI: Power Button [PWRB]
> Feb 28 12:55:59 duke kernel: ACPI Error (psparse-0537):
> Feb 28 12:55:59 duke kernel: ACPI: Thermal Zone [THRM] (30 C)
> Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver usbfs
> Feb 28 12:55:59 duke kernel: Method parse/execution failed
> Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver hub
> Feb 28 12:55:59 duke kernel: [\_PR_.CPU0._PDC] (Node ffff88007f858490), AE_ALREADY_EXISTS
> Feb 28 12:55:59 duke kernel: ACPI:
> Feb 28 12:55:59 duke kernel: usbcore: registered new device driver usb
> Feb 28 12:55:59 duke kernel: Marking method _PDC as Serialized because of AE_ALREADY_EXISTS error
> Feb 28 12:55:59 duke kernel: input: Power Button as /class/input/input1
> Feb 28 12:55:59 duke kernel: ACPI: Power Button [PWRF]
> Feb 28 12:55:59 duke kernel: ACPI: Invalid PBLK length [0]
> Feb 28 12:55:59 duke kernel: ACPI: SSDT 000000007fee8750 000CE (v01 PmRef Cpu1Ist 00003000 INTL 20041203)
> Feb 28 12:55:59 duke kernel: nvidia: module license 'NVIDIA' taints kernel.
> Feb 28 12:55:59 duke kernel:
> Feb 28 12:55:59 duke kernel: firewire_ohci 0000:05:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
> Feb 28 12:55:59 duke kernel: firewire_ohci 0000:05:00.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: cx18: Start initialization, version 1.3.0
> Feb 28 12:55:59 duke kernel: sky2 driver version 1.26
> Feb 28 12:55:59 duke kernel: sky2 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
> Feb 28 12:55:59 duke kernel: pata_jmicron 0000:03:00.1: enabling device (0000 -> 0001)
> Feb 28 12:55:59 duke kernel: pata_jmicron 0000:03:00.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> Feb 28 12:55:59 duke kernel: pata_jmicron 0000:03:00.1: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
> Feb 28 12:55:59 duke kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
> Feb 28 12:55:59 duke kernel: sd 4:0:0:0: Attached scsi generic sg2 type 0
> Feb 28 12:55:59 duke kernel: scsi8 : pata_jmicron
> Feb 28 12:55:59 duke kernel: scsi9 : pata_jmicron
> Feb 28 12:55:59 duke kernel: ata9: PATA max UDMA/100 cmd 0x9c00 ctl 0x9800 bmdma 0x8c00 irq 19
> Feb 28 12:55:59 duke kernel: ata10: PATA max UDMA/100 cmd 0x9400 ctl 0x9000 bmdma 0x8c08 irq 19
> Feb 28 12:55:59 duke kernel: ACPI: Fan [FAN] (on)
> Feb 28 12:55:59 duke kernel: uhci_hcd: USB Universal Host Controller Interface driver
> Feb 28 12:55:59 duke kernel: firewire_ohci: Added fw-ohci device 0000:05:00.0, OHCI version 1.10
> Feb 28 12:55:59 duke kernel: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: EHCI Host Controller
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfdfff000
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
> Feb 28 12:55:59 duke kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> Feb 28 12:55:59 duke kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> Feb 28 12:55:59 duke kernel: cx18-0: Initializing card 0
> Feb 28 12:55:59 duke kernel: cx18-0: Autodetected Hauppauge card
> Feb 28 12:55:59 duke kernel: sky2 0000:04:00.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: sky2 0000:04:00.0: Yukon-2 EC Ultra chip revision 2
> Feb 28 12:55:59 duke kernel: sky2 eth0: addr 00:15:58:8a:ae:e5
> Feb 28 12:55:59 duke kernel: usb usb1: Product: EHCI Host Controller
> Feb 28 12:55:59 duke kernel: usb usb1: Manufacturer: Linux 2.6.33 ehci_hcd
> Feb 28 12:55:59 duke kernel: usb usb1: SerialNumber: 0000:00:1a.7
> Feb 28 12:55:59 duke kernel: hub 1-0:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 1-0:1.0: 4 ports detected
> Feb 28 12:55:59 duke kernel: cx18 0000:05:03.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 2
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000fc00
> Feb 28 12:55:59 duke kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
> Feb 28 12:55:59 duke kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> Feb 28 12:55:59 duke kernel: usb usb2: Product: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: usb usb2: Manufacturer: Linux 2.6.33 uhci_hcd
> Feb 28 12:55:59 duke kernel: usb usb2: SerialNumber: 0000:00:1a.0
> Feb 28 12:55:59 duke kernel: hub 2-0:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 2-0:1.0: 2 ports detected
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 3
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000f800
> Feb 28 12:55:59 duke kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
> Feb 28 12:55:59 duke kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> Feb 28 12:55:59 duke kernel: usb usb3: Product: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: usb usb3: Manufacturer: Linux 2.6.33 uhci_hcd
> Feb 28 12:55:59 duke kernel: usb usb3: SerialNumber: 0000:00:1a.1
> Feb 28 12:55:59 duke kernel: hub 3-0:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 3-0:1.0: 2 ports detected
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 4
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000f400
> Feb 28 12:55:59 duke kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
> Feb 28 12:55:59 duke kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> Feb 28 12:55:59 duke kernel: usb usb4: Product: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: usb usb4: Manufacturer: Linux 2.6.33 uhci_hcd
> Feb 28 12:55:59 duke kernel: usb usb4: SerialNumber: 0000:00:1d.0
> Feb 28 12:55:59 duke kernel: hub 4-0:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 4-0:1.0: 2 ports detected
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 5
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000f000
> Feb 28 12:55:59 duke kernel: usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
> Feb 28 12:55:59 duke kernel: usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> Feb 28 12:55:59 duke kernel: usb usb5: Product: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: usb usb5: Manufacturer: Linux 2.6.33 uhci_hcd
> Feb 28 12:55:59 duke kernel: usb usb5: SerialNumber: 0000:00:1d.1
> Feb 28 12:55:59 duke kernel: hub 5-0:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 5-0:1.0: 2 ports detected
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 6
> Feb 28 12:55:59 duke kernel: uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000ec00
> Feb 28 12:55:59 duke kernel: usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
> Feb 28 12:55:59 duke kernel: usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> Feb 28 12:55:59 duke kernel: usb usb6: Product: UHCI Host Controller
> Feb 28 12:55:59 duke kernel: usb usb6: Manufacturer: Linux 2.6.33 uhci_hcd
> Feb 28 12:55:59 duke kernel: usb usb6: SerialNumber: 0000:00:1d.2
> Feb 28 12:55:59 duke kernel: hub 6-0:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 6-0:1.0: 2 ports detected
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: EHCI Host Controller
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 7
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfdffe000
> Feb 28 12:55:59 duke kernel: ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
> Feb 28 12:55:59 duke kernel: usb usb7: New USB device found, idVendor=1d6b, idProduct=0002
> Feb 28 12:55:59 duke kernel: usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> Feb 28 12:55:59 duke kernel: usb usb7: Product: EHCI Host Controller
> Feb 28 12:55:59 duke kernel: usb usb7: Manufacturer: Linux 2.6.33 ehci_hcd
> Feb 28 12:55:59 duke kernel: usb usb7: SerialNumber: 0000:00:1d.7
> Feb 28 12:55:59 duke kernel: hub 7-0:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 7-0:1.0: 6 ports detected
> Feb 28 12:55:59 duke kernel: ata9.00: ATAPI: PIONEER DVD-RW DVR-118L, 1.00, max UDMA/100
> Feb 28 12:55:59 duke kernel: ata9.00: configured for UDMA/100
> Feb 28 12:55:59 duke kernel: scsi 8:0:0:0: CD-ROM PIONEER DVD-RW DVR-118L 1.00 PQ: 0 ANSI: 5
> Feb 28 12:55:59 duke kernel: sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
> Feb 28 12:55:59 duke kernel: Uniform CD-ROM driver Revision: 3.20
> Feb 28 12:55:59 duke kernel: sr 8:0:0:0: Attached scsi CD-ROM sr0
> Feb 28 12:55:59 duke kernel: sr 8:0:0:0: Attached scsi generic sg3 type 5
> Feb 28 12:55:59 duke kernel: nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> Feb 28 12:55:59 duke kernel: nvidia 0000:01:00.0: setting latency timer to 64
> Feb 28 12:55:59 duke kernel: vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
> Feb 28 12:55:59 duke kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 195.36.03 Mon Feb 1 18:33:51 PST 2010
> Feb 28 12:55:59 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2)
> Feb 28 12:55:59 duke kernel: cx18-0: cx23418 revision 01010000 (B)
> Feb 28 12:55:59 duke kernel: firewire_core: created device fw0: GUID 00016c200022ce9e, S400
> Feb 28 12:55:59 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
> Feb 28 12:55:59 duke kernel: tveeprom 1-0050: MAC address is 00-0D-FE-1A-BE-03
> Feb 28 12:55:59 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
> Feb 28 12:55:59 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
> Feb 28 12:55:59 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
> Feb 28 12:55:59 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
> Feb 28 12:55:59 duke kernel: tveeprom 1-0050: has radio
> Feb 28 12:55:59 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600
> Feb 28 12:55:59 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported
> Feb 28 12:55:59 duke kernel: usb 7-6: new high speed USB device using ehci_hcd and address 4
> Feb 28 12:55:59 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
> Feb 28 12:55:59 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
> Feb 28 12:55:59 duke kernel: tda9887 2-0043: creating new instance
> Feb 28 12:55:59 duke kernel: tda9887 2-0043: tda988[5/6/7] found
> Feb 28 12:55:59 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
> Feb 28 12:55:59 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> Feb 28 12:55:59 duke kernel: tuner-simple 2-0061: creating new instance
> Feb 28 12:55:59 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
> Feb 28 12:55:59 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB)
> Feb 28 12:55:59 duke kernel: DVB: registering new adapter (cx18)
> Feb 28 12:55:59 duke kernel: usb 7-6: New USB device found, idVendor=0b95, idProduct=7720
> Feb 28 12:55:59 duke kernel: usb 7-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Feb 28 12:55:59 duke kernel: usb 7-6: Product: AX88772
> Feb 28 12:55:59 duke kernel: usb 7-6: Manufacturer: ASIX Elec. Corp.
> Feb 28 12:55:59 duke kernel: usb 7-6: SerialNumber: 000001
> Feb 28 12:55:59 duke kernel: MXL5005S: Attached at address 0x63
> Feb 28 12:55:59 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
> Feb 28 12:55:59 duke kernel: cx18-0: DVB Frontend registered
> Feb 28 12:55:59 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
> Feb 28 12:55:59 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB)
> Feb 28 12:55:59 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes)
> Feb 28 12:55:59 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB)
> Feb 28 12:55:59 duke kernel: cx18-0: Registered device radio1 for encoder radio
> Feb 28 12:55:59 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600
> Feb 28 12:55:59 duke kernel: cx18: End initialization
> Feb 28 12:55:59 duke kernel: usb 3-2: new low speed USB device using uhci_hcd and address 2
> Feb 28 12:55:59 duke kernel: usb 3-2: New USB device found, idVendor=15c2, idProduct=ffdc
> Feb 28 12:55:59 duke kernel: usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> Feb 28 12:55:59 duke kernel: usb 4-2: new low speed USB device using uhci_hcd and address 2
> Feb 28 12:55:59 duke kernel: usb 4-2: New USB device found, idVendor=046d, idProduct=c51e
> Feb 28 12:55:59 duke kernel: usb 4-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver hiddev
> Feb 28 12:55:59 duke kernel: input: HID 046d:c51e as /class/input/input2
> Feb 28 12:55:59 duke kernel: generic-usb 0003:046D:C51E.0001: input: USB HID v1.11 Keyboard [HID 046d:c51e] on usb-0000:00:1d.0-2/input0
> Feb 28 12:55:59 duke kernel: eth1: register 'asix' at usb-0000:00:1d.7-6, ASIX AX88772 USB 2.0 Ethernet, 00:50:5b:04:a2:4b
> Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver asix
> Feb 28 12:55:59 duke kernel: input: HID 046d:c51e as /class/input/input3
> Feb 28 12:55:59 duke kernel: generic-usb 0003:046D:C51E.0002: input,hiddev0: USB HID v1.11 Mouse [HID 046d:c51e] on usb-0000:00:1d.0-2/input1
> Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver usbhid
> Feb 28 12:55:59 duke kernel: usbhid: USB HID core driver
> Feb 28 12:55:59 duke kernel: usb 5-2: new full speed USB device using uhci_hcd and address 2
> Feb 28 12:55:59 duke kernel: usb 5-2: New USB device found, idVendor=0403, idProduct=6001
> Feb 28 12:55:59 duke kernel: usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Feb 28 12:55:59 duke kernel: usb 5-2: Product: Triple Relay Controller
> Feb 28 12:55:59 duke kernel: usb 5-2: Manufacturer: RTR
> Feb 28 12:55:59 duke kernel: usb 5-2: SerialNumber: A4SI153I
> Feb 28 12:55:59 duke kernel: Adding 16064960k swap on /dev/sdc1. Priority:-1 extents:1 across:16064960k
> Feb 28 12:55:59 duke kernel: usb 1-3: new high speed USB device using ehci_hcd and address 3
> Feb 28 12:55:59 duke kernel: usb 1-3: New USB device found, idVendor=05e3, idProduct=0608
> Feb 28 12:55:59 duke kernel: usb 1-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> Feb 28 12:55:59 duke kernel: usb 1-3: Product: USB2.0 Hub
> Feb 28 12:55:59 duke kernel: hub 1-3:1.0: USB hub found
> Feb 28 12:55:59 duke kernel: hub 1-3:1.0: 4 ports detected
> Feb 28 12:55:59 duke kernel: usb 1-3.1: new full speed USB device using ehci_hcd and address 4
> Feb 28 12:55:59 duke kernel: usb 1-3.1: New USB device found, idVendor=0c76, idProduct=1607
> Feb 28 12:55:59 duke kernel: usb 1-3.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> Feb 28 12:55:59 duke kernel: usb 1-3.1: Product: USB Headphone Set
> Feb 28 12:55:59 duke kernel: input: USB Headphone Set as /class/input/input4
> Feb 28 12:55:59 duke kernel: generic-usb 0003:0C76:1607.0003: input: USB HID v1.00 Device [USB Headphone Set] on usb-0000:00:1a.7-3.1/input3
> Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver snd-usb-audio
> Feb 28 12:55:59 duke kernel: usb 1-3.2: new high speed USB device using ehci_hcd and address 5
> Feb 28 12:55:59 duke kernel: usb 1-3.2: New USB device found, idVendor=2040, idProduct=7200
> Feb 28 12:55:59 duke kernel: usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=10
> Feb 28 12:55:59 duke kernel: usb 1-3.2: Product: WinTV HVR-950
> Feb 28 12:55:59 duke kernel: usb 1-3.2: Manufacturer: Hauppauge
> Feb 28 12:55:59 duke kernel: usb 1-3.2: SerialNumber: 4031688744
> Feb 28 12:55:59 duke kernel: au0828 driver loaded
> Feb 28 12:55:59 duke kernel: usb 1-3.3: new full speed USB device using ehci_hcd and address 6
> Feb 28 12:55:59 duke kernel: usb 1-3.3: New USB device found, idVendor=0403, idProduct=6001
> Feb 28 12:55:59 duke kernel: usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Feb 28 12:55:59 duke kernel: usb 1-3.3: Product: Frankenswitch v3 4x4:1 matrix
> Feb 28 12:55:59 duke kernel: usb 1-3.3: Manufacturer: RTR
> Feb 28 12:55:59 duke kernel: usb 1-3.3: SerialNumber: A8S59W9K
> Feb 28 12:55:59 duke kernel: usb 1-3.4: new low speed USB device using ehci_hcd and address 7
> Feb 28 12:55:59 duke kernel: au0828: i2c bus registered
> Feb 28 12:55:59 duke kernel: usb 1-3.4: New USB device found, idVendor=051d, idProduct=0002
> Feb 28 12:55:59 duke kernel: usb 1-3.4: New USB device strings: Mfr=3, Product=1, SerialNumber=2
> Feb 28 12:55:59 duke kernel: usb 1-3.4: Product: Back-UPS XS 1300 LCD FW:836.H8 .D USB FW:H8
> Feb 28 12:55:59 duke kernel: usb 1-3.4: Manufacturer: American Power Conversion
> Feb 28 12:55:59 duke kernel: usb 1-3.4: SerialNumber: BB0820009163
> Feb 28 12:55:59 duke kernel: tveeprom 3-0050: Hauppauge model 72001, rev B3F0, serial# 5156904
> Feb 28 12:55:59 duke kernel: tveeprom 3-0050: MAC address is 00-0D-FE-4E-B0-28
> Feb 28 12:55:59 duke kernel: tveeprom 3-0050: tuner model is Xceive XC5000 (idx 150, type 76)
> Feb 28 12:55:59 duke kernel: tveeprom 3-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
> Feb 28 12:55:59 duke kernel: tveeprom 3-0050: audio processor is AU8522 (idx 44)
> Feb 28 12:55:59 duke kernel: tveeprom 3-0050: decoder processor is AU8522 (idx 42)
> Feb 28 12:55:59 duke kernel: tveeprom 3-0050: has no radio, has IR receiver, has no IR transmitter
> Feb 28 12:55:59 duke kernel: hauppauge_eeprom: hauppauge eeprom: model=72001
> Feb 28 12:55:59 duke kernel: au8522 3-0047: creating new instance
> Feb 28 12:55:59 duke kernel: au8522_decoder creating new instance...
> Feb 28 12:55:59 duke kernel: tuner 3-0061: chip found @ 0xc2 (au0828)
> Feb 28 12:55:59 duke kernel: xc5000 3-0061: creating new instance
> Feb 28 12:55:59 duke kernel: xc5000: Successfully identified at address 0x61
> Feb 28 12:55:59 duke kernel: xc5000: Firmware has not been loaded previously
> Feb 28 12:55:59 duke kernel: au8522 3-0047: attaching existing instance
> Feb 28 12:55:59 duke kernel: xc5000 3-0061: attaching existing instance
> Feb 28 12:55:59 duke kernel: xc5000: Successfully identified at address 0x61
> Feb 28 12:55:59 duke kernel: xc5000: Firmware has not been loaded previously
> Feb 28 12:55:59 duke kernel: DVB: registering new adapter (au0828)
> Feb 28 12:55:59 duke kernel: DVB: registering adapter 1 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)...
> Feb 28 12:55:59 duke kernel: Registered device AU0828 [Hauppauge HVR950Q]
> Feb 28 12:55:59 duke kernel: usbcore: registered new interface driver au0828
> Feb 28 12:55:59 duke kernel: generic-usb 0003:051D:0002.0004: hiddev1: USB HID v1.10 Device [American Power Conversion Back-UPS XS 1300 LCD FW:836.H8 .D USB FW:H8 ] on usb-0000:00:1a.7-3.4/input0
> Feb 28 12:55:59 duke kernel: kjournald starting. Commit interval 5 seconds
> Feb 28 12:55:59 duke kernel: EXT3-fs (sda1): using internal journal
> Feb 28 12:55:59 duke kernel: EXT3-fs (sda1): mounted filesystem with writeback data mode
> Feb 28 12:55:59 duke kernel: XFS mounting filesystem md0
> Feb 28 12:55:59 duke kernel: Ending clean XFS mount for filesystem: md0
> Feb 28 12:55:59 duke kernel: sky2 eth0: enabling interface
> Feb 28 12:55:59 duke kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
> Feb 28 12:55:59 duke kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
> Feb 28 12:55:59 duke kernel: sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
> Feb 28 12:55:59 duke kernel: warning: `ntpd' uses 32-bit capabilities (legacy support in use)
> Feb 28 12:55:59 duke logger: /etc/rc2.d/S13local start
> Feb 28 12:55:59 duke kernel: ata1.00: configured for UDMA/133
> Feb 28 12:55:59 duke kernel: ata1: EH complete
> Feb 28 12:55:59 duke kernel: ata2.00: configured for UDMA/133
> Feb 28 12:55:59 duke kernel: ata2: EH complete
> Feb 28 12:55:59 duke kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Feb 28 12:55:59 duke sshd[3674]: Server listening on 0.0.0.0 port 22.
> Feb 28 12:55:59 duke /usr/sbin/gpm[3694]: *** info [daemon/startup.c(131)]:
> Feb 28 12:55:59 duke /usr/sbin/gpm[3694]: Started gpm successfully. Entered daemon mode.
> Feb 28 12:55:59 duke mysqld_safe[3773]: started
> Feb 28 12:55:59 duke mysqld[3776]: 100228 12:55:59 [Warning] option 'net_buffer_length': unsigned value 8388608 adjusted to 1048576
> Feb 28 12:55:59 duke mysqld[3776]: 100228 12:55:59 InnoDB: Started; log sequence number 0 2439644
> Feb 28 12:55:59 duke mysqld[3776]: 100228 12:55:59 [Note] /usr/sbin/mysqld: ready for connections.
> Feb 28 12:55:59 duke mysqld[3776]: Version: '5.0.67-0ubuntu6.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
> Feb 28 12:56:00 duke /etc/mysql/debian-start[3815]: Upgrading MySQL tables if necessary.
> Feb 28 12:56:00 duke /etc/mysql/debian-start[3819]: Looking for 'mysql' in: /usr/bin/mysql
> Feb 28 12:56:00 duke /etc/mysql/debian-start[3819]: Looking for 'mysqlcheck' in: /usr/bin/mysqlcheck
> Feb 28 12:56:00 duke /etc/mysql/debian-start[3819]: This installation of MySQL is already upgraded to 5.0.67, use --force if you still need to run mysql_upgrade
> Feb 28 12:56:00 duke /etc/mysql/debian-start[3831]: Checking for insecure root accounts.
> Feb 28 12:56:00 duke /etc/mysql/debian-start[3835]: WARNING: mysql.user contains 3 root accounts without password!
> Feb 28 12:56:00 duke /etc/mysql/debian-start[3836]: Triggering myisam-recover for all MyISAM tables
> Feb 28 12:56:01 duke ntpd[3564]: ntpd exiting on signal 15
> Feb 28 12:56:01 duke ntpdate[3943]: step time server 10.0.0.2 offset 0.647632 sec
> Feb 28 12:56:02 duke ntpd[4089]: ntpd 4.2.4p4@1.1520-o Fri Dec 4 19:14:37 UTC 2009 (1)
> Feb 28 12:56:02 duke ntpd[4090]: precision = 1.000 usec
> Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
> Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
> Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #2 eth0, 10.0.0.18#123 Enabled
> Feb 28 12:56:02 duke ntpd[4090]: Listening on interface #3 eth1, 169.254.4.100#123 Enabled
> Feb 28 12:56:02 duke ntpd[4090]: kernel time sync status 0040
> Feb 28 12:56:02 duke ntpd[4090]: frequency initialized 8.502 PPM from /var/lib/ntp/ntp.drift
> Feb 28 12:56:02 duke acpid: client connected from 4129[113:122]
> Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
> Feb 28 12:56:02 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
> Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
> Feb 28 12:56:02 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
> Feb 28 12:56:02 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
> Feb 28 12:56:02 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
> Feb 28 12:56:03 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-dig.fw
> Feb 28 12:56:03 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> Feb 28 12:56:03 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
> Feb 28 12:56:04 duke kernel: ivtv 0000:05:02.0: firmware: requesting v4l-cx2341x-enc.fw
> Feb 28 12:56:04 duke kernel: ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> Feb 28 12:56:04 duke kernel: ivtv0: Encoder revision: 0x02060039
> Feb 28 12:56:04 duke logger: /etc/rc2.d/S25mythtv-backend: creating symlink for /dev/cdrom
> Feb 28 12:56:04 duke logger: /etc/rc2.d/S25mythtv-backend: creating symlink for /dev/dvd
> Feb 28 12:56:04 duke kernel: ata1.00: configured for UDMA/133
> Feb 28 12:56:04 duke kernel: ata1: EH complete
> Feb 28 12:56:04 duke logger: Pre-initializing /dev/video1
> Feb 28 12:56:05 duke kernel: ata5.00: configured for UDMA/133
> Feb 28 12:56:05 duke kernel: ata2.00: configured for UDMA/133
> Feb 28 12:56:05 duke kernel: ata2: EH complete
> Feb 28 12:56:05 duke kernel: ata5: EH complete
> Feb 28 12:56:05 duke kernel: sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Feb 28 12:56:07 duke nanny.mythbackend[4274]: mythbackend[4277] started
> Feb 28 12:56:07 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: reconfiguring driver
> Feb 28 12:56:07 duke kernel: input: i2c IR (Hauppauge) as /class/input/input5
> Feb 28 12:56:07 duke kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0]
> Feb 28 12:56:07 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: waiting for device(s)
> Feb 28 12:56:07 duke gdm[4335]: WARNING: Didn't understand `' (expected true or false)
> Feb 28 12:56:07 duke acpid: client connected from 4351[0:0]
> Feb 28 12:56:08 duke /usr/sbin/cron[4404]: (CRON) INFO (pidfile fd = 3)
> Feb 28 12:56:08 duke /usr/sbin/cron[4405]: (CRON) STARTUP (fork ok)
> Feb 28 12:56:08 duke /usr/sbin/cron[4405]: (CRON) INFO (Running @reboot jobs)
> Feb 28 12:56:08 duke logger[4415]: /usr/bin/input-kbd -f /usr/local/bin/hauppauge_remote.conf 5
> Feb 28 12:56:08 duke rpc.statd[4454]: Version 1.1.2 Starting
> Feb 28 12:56:08 duke kernel: RPC: Registered udp transport module.
> Feb 28 12:56:08 duke kernel: RPC: Registered tcp transport module.
> Feb 28 12:56:08 duke kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
> Feb 28 12:56:08 duke acpid: client connected from 4351[0:0]
> Feb 28 12:56:08 duke kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> Feb 28 12:56:08 duke kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
> Feb 28 12:56:08 duke kernel: NFSD: starting 90-second grace period
> Feb 28 12:56:09 duke logger: /etc/rc2.d/S98local start
> Feb 28 12:56:09 duke kernel: ata1.00: configured for UDMA/133
> Feb 28 12:56:09 duke kernel: ata1: EH complete
> Feb 28 12:56:09 duke kernel: ata2.00: configured for UDMA/133
> Feb 28 12:56:09 duke kernel: ata2: EH complete
> Feb 28 12:56:09 duke gdm[4342]: pam_unix(gdm-autologin:session): session opened for user mlord by (uid=0)
> Feb 28 12:56:09 duke gdm[4342]: pam_ck_connector(gdm-autologin:session): nox11 mode, ignoring PAM_TTY :0
> Feb 28 12:56:09 duke apcupsd[4379]: NIS server startup succeeded
> Feb 28 12:56:09 duke apcupsd[4379]: apcupsd 3.14.4 (18 May 2008) debian startup succeeded
> Feb 28 12:56:10 duke nanny.vfd_updater[4825]: vfd_updater[4826] started
> Feb 28 12:56:10 duke vfd_updater[4826]: connect(): Connection refused
> Feb 28 12:56:15 duke kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
> Feb 28 12:56:15 duke kernel: usb 1-3.2: firmware: requesting dvb-fe-xc5000-1.6.114.fw
> Feb 28 12:56:15 duke kernel: xc5000: firmware read 12401 bytes.
> Feb 28 12:56:15 duke kernel: xc5000: firmware uploading...
> Feb 28 12:56:22 duke kernel: xc5000: firmware upload complete...
> Feb 28 12:56:23 duke /usr/local/bin/diseqc_switcher[4876]: Selecting '2B'
> Feb 28 12:56:23 duke /usr/local/bin/diseqc_switcher[4876]: writing 0x04 [- - - - - 1 - -]
> Feb 28 12:56:24 duke /usr/local/bin/diseqc_switcher[4882]: Selecting '1D'
> Feb 28 12:56:24 duke /usr/local/bin/diseqc_switcher[4882]: writing 0x07 [- - - - - 1 1 1]
> Feb 28 12:56:29 duke logger: /usr/local/bin/set_wakeup_alarm.sh: mythbackend started by 'auto'
> Feb 28 12:56:29 duke vfd_updater[4826]: mythbackend: ACCEPT, MYTH_PROTOCOL_VERSION 40
> Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: setting wakeup alarm the old fashioned way
> Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: setting wakeup alarm to (1267444589) UTC '2010-03-01 11:56:29' (local '2010-03-01 06:56:29')
> Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: echo 2010-03-01 11:56:29 > /proc/acpi/alarm
> Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: RTC alarm readback: 2010-03-01 11:56:29
> Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: UTC time now: 2010-02-28 17:56:30
> Feb 28 12:56:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: next wakeup: 2010-03-01 06:56:29
> Feb 28 12:58:31 duke /usr/local/bin/diseqc_switcher[5469]: Selecting '1D'
> Feb 28 12:58:31 duke /usr/local/bin/diseqc_switcher[5469]: writing 0x07 [- - - - - 1 1 1]
> Feb 28 13:00:23 duke ntpd[4090]: synchronized to 10.0.0.2, stratum 3
> Feb 28 13:00:24 duke ntpd[4090]: time reset +0.338051 s
> Feb 28 13:00:24 duke ntpd[4090]: kernel time sync status change 0001
> Feb 28 13:05:41 duke ntpd[4090]: synchronized to 10.0.0.2, stratum 3
> Feb 28 13:15:58 duke -- MARK --
> Feb 28 13:17:01 duke CRON[7427]: pam_unix(cron:session): session opened for user root by (uid=0)
> Feb 28 13:17:01 duke /USR/SBIN/CRON[7433]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
> Feb 28 13:17:01 duke CRON[7427]: pam_unix(cron:session): session closed for user root
> Feb 28 13:35:58 duke -- MARK --
> Feb 28 13:55:58 duke -- MARK --
> Feb 28 14:15:58 duke -- MARK --
> Feb 28 14:17:01 duke CRON[13871]: pam_unix(cron:session): session opened for user root by (uid=0)
> Feb 28 14:17:01 duke /USR/SBIN/CRON[13878]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
> Feb 28 14:17:01 duke CRON[13871]: pam_unix(cron:session): session closed for user root
> Feb 28 14:35:58 duke -- MARK --
> Feb 28 14:55:58 duke -- MARK --
> Feb 28 15:15:58 duke -- MARK --
> Feb 28 15:17:01 duke CRON[20310]: pam_unix(cron:session): session opened for user root by (uid=0)
> Feb 28 15:17:01 duke /USR/SBIN/CRON[20317]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
> Feb 28 15:17:01 duke CRON[20310]: pam_unix(cron:session): session closed for user root
> Feb 28 15:34:32 duke /usr/local/bin/diseqc_switcher[22382]: Selecting '2D'
> Feb 28 15:34:32 duke /usr/local/bin/diseqc_switcher[22382]: writing 0x0f [- - - - 1 1 1 1]
> Feb 28 15:50:22 duke kernel: hrtimer: interrupt took 5076 ns
> Feb 28 15:50:31 duke /usr/local/bin/diseqc_switcher[24128]: Selecting '2D'
> Feb 28 15:50:31 duke /usr/local/bin/diseqc_switcher[24128]: writing 0x0f [- - - - 1 1 1 1]
> Feb 28 15:57:35 duke diseqc_switcher[24931]: open(diseqc_switcher): No such file or directory
> Feb 28 15:57:45 duke /ulb/diseqc_switcher[24951]: Selecting '1b'
> Feb 28 15:57:45 duke /ulb/diseqc_switcher[24951]: writing 0x0d [- - - - 1 1 - 1]
> Feb 28 15:57:53 duke /ulb/diseqc_switcher[24968]: Selecting '1d'
> Feb 28 15:57:53 duke /ulb/diseqc_switcher[24968]: writing 0x0f [- - - - 1 1 1 1]
> Feb 28 15:58:03 duke /ulb/diseqc_switcher[24985]: Selecting '1c'
> Feb 28 15:58:03 duke /ulb/diseqc_switcher[24985]: writing 0x0e [- - - - 1 1 1 -]
> Feb 28 15:58:11 duke /ulb/diseqc_switcher[24997]: Selecting '1a'
> Feb 28 15:58:11 duke /ulb/diseqc_switcher[24997]: writing 0x0c [- - - - 1 1 - -]
> Feb 28 15:58:17 duke /ulb/diseqc_switcher[25016]: Selecting '1d'
> Feb 28 15:58:17 duke /ulb/diseqc_switcher[25016]: writing 0x0f [- - - - 1 1 1 1]
> Feb 28 16:15:58 duke -- MARK --
> Feb 28 16:17:01 duke CRON[27448]: pam_unix(cron:session): session opened for user root by (uid=0)
> Feb 28 16:17:01 duke /USR/SBIN/CRON[27455]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
> Feb 28 16:17:01 duke CRON[27448]: pam_unix(cron:session): session closed for user root
> Feb 28 16:21:31 duke /usr/local/bin/diseqc_switcher[28112]: Selecting '2C'
> Feb 28 16:21:31 duke /usr/local/bin/diseqc_switcher[28112]: writing 0x0b [- - - - 1 - 1 1]
> Feb 28 16:35:58 duke -- MARK --
> Feb 28 16:55:58 duke -- MARK --
> Feb 28 17:15:58 duke -- MARK --
> Feb 28 17:17:01 duke CRON[1744]: pam_unix(cron:session): session opened for user root by (uid=0)
> Feb 28 17:17:01 duke /USR/SBIN/CRON[1750]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
> Feb 28 17:17:01 duke CRON[1744]: pam_unix(cron:session): session closed for user root
> Feb 28 17:35:58 duke -- MARK --
> Feb 28 17:55:58 duke -- MARK --
> Feb 28 18:15:58 duke -- MARK --
> Feb 28 18:17:01 duke CRON[8585]: pam_unix(cron:session): session opened for user root by (uid=0)
> Feb 28 18:17:01 duke /USR/SBIN/CRON[8591]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
> Feb 28 18:17:01 duke CRON[8585]: pam_unix(cron:session): session closed for user root
> Feb 28 18:35:58 duke -- MARK --
> Feb 28 18:55:58 duke -- MARK --
> Feb 28 18:59:31 duke /usr/local/bin/diseqc_switcher[14920]: Selecting '1C'
> Feb 28 18:59:31 duke /usr/local/bin/diseqc_switcher[14920]: writing 0x0a [- - - - 1 - 1 -]
> Feb 28 19:15:58 duke -- MARK --
> Feb 28 19:17:01 duke CRON[16800]: pam_unix(cron:session): session opened for user root by (uid=0)
> Feb 28 19:17:01 duke /USR/SBIN/CRON[16807]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
> Feb 28 19:17:01 duke CRON[16800]: pam_unix(cron:session): session closed for user root
> Feb 28 19:35:58 duke -- MARK --
> Feb 28 19:55:58 duke -- MARK --
> Feb 28 19:59:31 duke /usr/local/bin/diseqc_switcher[21502]: Selecting '2D'
> Feb 28 19:59:31 duke /usr/local/bin/diseqc_switcher[21502]: writing 0x0e [- - - - 1 1 1 -]
> Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing
> Feb 28 20:00:03 duke /usr/local/bin/diseqc_switcher[21597]: Selecting '1B'
> Feb 28 20:00:03 duke /usr/local/bin/diseqc_switcher[21597]: writing 0x0d [- - - - 1 1 - 1]
> Feb 28 20:15:58 duke -- MARK --
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...
2010-03-02 1:34 ` Andy Walls
@ 2010-03-02 5:57 ` Mark Lord
2010-03-02 12:40 ` Andy Walls
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-03-02 5:57 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel
On 03/01/10 20:34, Andy Walls wrote:
> On Mon, 2010-03-01 at 11:07 -0500, Mark Lord wrote:
>> I'm using MythTV-0.21-fixes (from svn) on top of Linux-2.6.33 (from kernel.org),
>> with an HVR-1600 tuner card. This card usually works okay (with workarounds for
>> the known analog recording bugs) in both analog and digital modes.
>>
>> Last night, for the first time ever, MythTV chose to record from both the analog
>> and digital sides of the HVR-1600 card at exactly the same times..
>>
>> The kernel driver failed, and neither recording was successful.
>> The only message in /var/log/messages was:
>>
>> Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing
>
>
> This is really odd. It means:
>
> 1. Your machine had a very busy burst of cx18 driver buffer handling
> activity. Stopping a number of different streams, MPEG, VBI, and (DTV)
> TS at nearly the same time could do it
>
> 2. The firmware locked up.
>
> 3. The work handler kernel thread, cx18-0-in, got killed, if that's
> possible, or the processor it was running on got really bogged down.
..
Yeah, it was pretty strange.
I wonder.. the system also has a Hauppauge 950Q USB tuner,
which is also partially controlled by the cx18 driver (I think).
I wonder if perhaps that had anything to do with it?
> If you want to make the problem "just go away" then up this parameter in
> cx18-driver.h:
>
> #define CX18_MAX_IN_WORK_ORDERS (CX18_MAX_FW_MDLS_PER_STREAM + 7)
> to something like
> #define CX18_MAX_IN_WORK_ORDERS (2*CX18_MAX_FW_MDLS_PER_STREAM + 7)
..
Heh.. Yup, that's the first thing I did after looking at the code. :)
Dunno if it'll help or not, but easy enough to do.
And if the cx18 is indeed being used by two cards (HVR-1600 and HVR-950Q),
then perhaps that number does need to be bigger or dynamic (?).
I've since tried to reproduce the failure on purpose, with no luck to date.
Thanks guys!
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...
2010-03-02 5:57 ` Mark Lord
@ 2010-03-02 12:40 ` Andy Walls
2010-03-02 15:00 ` Mark Lord
2010-03-15 2:48 ` cx18: "missing audio" for analog recordings Mark Lord
0 siblings, 2 replies; 45+ messages in thread
From: Andy Walls @ 2010-03-02 12:40 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel
On Tue, 2010-03-02 at 00:57 -0500, Mark Lord wrote:
> On 03/01/10 20:34, Andy Walls wrote:
> > On Mon, 2010-03-01 at 11:07 -0500, Mark Lord wrote:
> >> I'm using MythTV-0.21-fixes (from svn) on top of Linux-2.6.33 (from kernel.org),
> >> with an HVR-1600 tuner card. This card usually works okay (with workarounds for
> >> the known analog recording bugs) in both analog and digital modes.
> >>
> >> Last night, for the first time ever, MythTV chose to record from both the analog
> >> and digital sides of the HVR-1600 card at exactly the same times..
> >>
> >> The kernel driver failed, and neither recording was successful.
> >> The only message in /var/log/messages was:
> >>
> >> Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing
> >
> >
> > This is really odd. It means:
> >
> > 1. Your machine had a very busy burst of cx18 driver buffer handling
> > activity. Stopping a number of different streams, MPEG, VBI, and (DTV)
> > TS at nearly the same time could do it
> >
> > 2. The firmware locked up.
> >
> > 3. The work handler kernel thread, cx18-0-in, got killed, if that's
> > possible, or the processor it was running on got really bogged down.
> ..
>
> Yeah, it was pretty strange.
> I wonder.. the system also has a Hauppauge 950Q USB tuner,
> which is also partially controlled by the cx18 driver (I think).
Nope. Different driver. The processing for the 950Q USB may have put
some extra load on the system, but likely not enough load to stall 70
MDL handover requests from the firmware.
> I wonder if perhaps that had anything to do with it?
>
> > If you want to make the problem "just go away" then up this parameter in
> > cx18-driver.h:
> >
> > #define CX18_MAX_IN_WORK_ORDERS (CX18_MAX_FW_MDLS_PER_STREAM + 7)
> > to something like
> > #define CX18_MAX_IN_WORK_ORDERS (2*CX18_MAX_FW_MDLS_PER_STREAM + 7)
> ..
>
> Heh.. Yup, that's the first thing I did after looking at the code. :)
> Dunno if it'll help or not, but easy enough to do.
If it doesn't, then there's a problem somewhere else. ;)
> And if the cx18 is indeed being used by two cards (HVR-1600 and HVR-950Q),
> then perhaps that number does need to be bigger or dynamic (?).
Dynamic would be better.
For each CX23418 based card in your system, a pool of these work
requests is allocated dynamically at card setup, and drawn from when
needed during operation.
Since the CX23418 can have up to 63 MDL done notifications (and 2 MDL
Ack notifications, IIRC) for the following 6 types of streams: MPEG,
VBI, IDX, PCM, YUV and TS. The most work orders that should ever need
is 6 * 65.
One would only need that maximum when effectively stopping all 6 streams
on a card at once, while not processing the work requests in a timely
manner. That is so pathological, its not worth considering. That's why
the cx18 driver only has 70 in the pool: 63 for one stream stopping and
5 others for running streams (and 2 for a couple of MDL Acks, IIRC).
Again, maybe dynamically allocating these work order objects from the
kernel as needed, would be better from a small dynamically allocated
pool for each card. I was concerned that the interrupt handler was
taking to long at the time I implemented the things the way they are
now.
> I've since tried to reproduce the failure on purpose, with no luck to date.
>
> Thanks guys!
You're welcome.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...
2010-03-02 12:40 ` Andy Walls
@ 2010-03-02 15:00 ` Mark Lord
2010-03-03 1:05 ` Andy Walls
2010-03-15 2:48 ` cx18: "missing audio" for analog recordings Mark Lord
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-03-02 15:00 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel
On 03/02/10 07:40, Andy Walls wrote:
..
>>> 3. The work handler kernel thread, cx18-0-in, got killed, if that's
>>> possible, or the processor it was running on got really bogged down.
>> ..
..
One thing from the /var/log/messages output:
12:55:59 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
Which is a result of the code doing this:
retval = request_irq(cx->pci_dev->irq, cx18_irq_handler,
IRQF_SHARED | IRQF_DISABLED,
cx->v4l2_dev.name, (void *)cx);
I'm not at the MythTV box right now, but it is likely that this IRQ
really is shared with other devices.
Does the driver *really* rely upon IRQF_DISABLED (to avoid races in the handler)?
If so, then this could be a good clue.
If not, then that IRQF_DISABLED should get nuked.
Cheers
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...
2010-03-02 15:00 ` Mark Lord
@ 2010-03-03 1:05 ` Andy Walls
0 siblings, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-03-03 1:05 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel
On Tue, 2010-03-02 at 10:00 -0500, Mark Lord wrote:
> On 03/02/10 07:40, Andy Walls wrote:
> ..
> >>> 3. The work handler kernel thread, cx18-0-in, got killed, if that's
> >>> possible, or the processor it was running on got really bogged down.
> >> ..
> ..
>
> One thing from the /var/log/messages output:
>
> 12:55:59 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
>
> Which is a result of the code doing this:
>
> retval = request_irq(cx->pci_dev->irq, cx18_irq_handler,
> IRQF_SHARED | IRQF_DISABLED,
> cx->v4l2_dev.name, (void *)cx);
Please read this thread and the LKML threads to which it points:
http://ivtvdriver.org/pipermail/ivtv-devel/2010-January/006416.html
> I'm not at the MythTV box right now, but it is likely that this IRQ
> really is shared with other devices.
That's very common for PCI. Make sure the linux kernel module's hard
IRQ handler for the other device doesn't do something stupid - like wait
for a really long time, perform linear searches on large data
structures,.etc.
> Does the driver *really* rely upon IRQF_DISABLED (to avoid races in the handler)?
Races aren't the issue here.
And no, the cx18 driver does not *rely* on IRQF_DISABLED. However, it
makes no sense to yield the processor in the cx18 hard IRQ handling,
during the small time window between the hardware IRQ from the CX23418
and the time CX23418 firmware decides to overwrite the buffer
notification with a new one and we lose the original notification data.
The cx18 driver would end up dropping video buffers for the sake of an
interrupt from a mouse, serial port, disk controller, USB host
controller, etc. that could have likely waited. If one's disk
controller or network card's interrupt is more important than one's
CX23418 interrupt, then one can nuke the IRQF_DISABLED flag. But that's
generally not what most people want.
The only place it would make sense for the cx18 IRQ handler to run with
interrupts enabled is on an interrupt bound, uniprocessor system, when
you conciously decide you have device interrupts more improtant than the
video capture card. That's usually not the setup of people performing
video capture with a CX23418 based card.
> If so, then this could be a good clue.
> If not, then that IRQF_DISABLED should get nuked.
Nope - the cx18 hard IRQ handler is as fast as I could make it. With
multiple streams running, the CX23418 firmware gives us only a very
short time to pick up buffer notifications. If we don't have
IRQF_DISABLED set, some other interrupt handler, for some other
interrupt line, will cut into the cx18 hard IRQ handler timeline.
A real problem is some other poorly written linux interrupt handler
taking too long for interuupt service of a device sharing the same IRQ
line with the CX23418. Such an other "slow" interrupt handler can cut
into the short time window in which the cx18 driver must pick up a
buffer notiifcation from the CX23418.
My understanmding is the whole IRQF_SHARED | IRQF_DISABLED problem not
being handled properly by the kernel IRQ handling is labeld as "do not
fix". So instead we're left with the arguments for particular
situations with no compromise solution:
1. "always run hard IRQ handlers with local interrupts disabled;
handlers shouldn't be slow"
and
2. "I have limited hardware that requires immediate care and feeding or
I'll drop characters or miss packets. Driver's with lots of hard IRQ
handling delay or low priority should run with interrupts enabled"
and
3. "I have a brain dead piece of hardware that existed before SMP or
multithreaded processing. It has to run its handler with local
interrupts (dis-?)enabled."
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* cx18: "missing audio" for analog recordings
2010-03-02 12:40 ` Andy Walls
2010-03-02 15:00 ` Mark Lord
@ 2010-03-15 2:48 ` Mark Lord
2010-03-15 11:51 ` Andy Walls
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-03-15 2:48 UTC (permalink / raw)
To: Andy Walls; +Cc: Mark Lord, Hans Verkuil, linux-media, ivtv-devel
On 03/02/10 07:40, Andy Walls wrote:
> Again, maybe dynamically allocating these work order objects from the
> kernel as needed, would be better from a small dynamically allocated
> pool for each card. I was concerned that the interrupt handler was
> taking to long at the time I implemented the things the way they are
> now.
..
I haven't seen that particular issue again, with or without increasing
the work orders, so hopefully it won't recur.
But after updating to the tip of the v4l2-dvb git tree last week,
I've been hitting the "no audio" on analog recordings bug much more often.
Digging through google, it appears this problem has been around as long
as the cx18 driver has existed, with no clear resolution. Lots of people
have reported it to you before, and nobody has found a silver bullet fix.
The problem is still there.
I have now spent a good many hours trying to isolate *when* it happens,
and have narrowed it down to module initialization.
Basically, if the audio is working after modprobe cx18, it then continues
to work from recording to recording until the next reboot.
If the audio is not working after modprobe, then simply doing rmmod/modprobe
in a loop (until working audio is achieved) is enough to cure it.
So for my Mythtv box here, I now have a script to check for missing audio
and do the rmmod/modprobe. This is a good, effective workaround.
http://rtr.ca/hvr1600/fix_hvr1600_audio.sh
That's a link to my script.
As for the actual underlying cause/bug, it's still not clear what is happening.
But the problem is a LOT more prevalent (for me, and for two other people I know)
with versions of the cx18 driver since spring 2009.
My suspicion is that the firmware download for the APU is somehow being corrupted,
and now that the driver downloads the firmware *twice* during init, it doubles the
odds of said corruption. Just a theory, but it's the best fit so far.
I think we have some nasty i2c issues somewhere in the kernel.
Cheers
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-03-15 2:48 ` cx18: "missing audio" for analog recordings Mark Lord
@ 2010-03-15 11:51 ` Andy Walls
2010-03-16 4:49 ` Mark Lord
2010-04-10 22:28 ` Mark Lord
0 siblings, 2 replies; 45+ messages in thread
From: Andy Walls @ 2010-03-15 11:51 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> On 03/02/10 07:40, Andy Walls wrote:
> > Again, maybe dynamically allocating these work order objects from the
> > kernel as needed, would be better from a small dynamically allocated
> > pool for each card. I was concerned that the interrupt handler was
> > taking to long at the time I implemented the things the way they are
> > now.
> ..
>
> I haven't seen that particular issue again, with or without increasing
> the work orders, so hopefully it won't recur.
OK.
> But after updating to the tip of the v4l2-dvb git tree last week,
> I've been hitting the "no audio" on analog recordings bug much more often.
Is that tuner audio or baseband (line-in) audio?
> Digging through google, it appears this problem has been around as long
> as the cx18 driver has existed, with no clear resolution. Lots of people
> have reported it to you before, and nobody has found a silver bullet fix.
Correct. I thought it was completely gone, but apparently, there just
isn't a lot of reporting of this intermittent problem.
> The problem is still there.
>
> I have now spent a good many hours trying to isolate *when* it happens,
> and have narrowed it down to module initialization.
>
> Basically, if the audio is working after modprobe cx18, it then continues
> to work from recording to recording until the next reboot.
>
> If the audio is not working after modprobe, then simply doing rmmod/modprobe
> in a loop (until working audio is achieved) is enough to cure it.
Good to know.
> So for my Mythtv box here, I now have a script to check for missing audio
> and do the rmmod/modprobe. This is a good, effective workaround.
>
> http://rtr.ca/hvr1600/fix_hvr1600_audio.sh
>
> That's a link to my script.
>
> As for the actual underlying cause/bug, it's still not clear what is happening.
> But the problem is a LOT more prevalent (for me, and for two other people I know)
> with versions of the cx18 driver since spring 2009.
>
> My suspicion is that the firmware download for the APU is somehow being corrupted,
> and now that the driver downloads the firmware *twice* during init, it doubles the
> odds of said corruption. Just a theory, but it's the best fit so far.
Please isolate an APU load and initialization problem, by seeing if
audio fails for both tuner audio and baseband audio.
Here are all the potential problem areas I can think of:
1. A/V digitizer/decoder audio detection firmware load and init. (I've
added firmware readback verification to try and head this off.)
2. A/V digitizer decoder audio microcontroller hard reset and "soft"
reset sequencing. (I think the cx18 driver has this wrong ATM.)
3. APU load and init. (The double load is to fix a DTV TS stream bug on
every other APU & CPU firmware load sequence. The APU_AI_RESET is to
fix the audio bitrate problem on first capture after a double firmware
load.)
4. AI1 Mux setting failing when switching between the internal A/V
decoder's I2S output and the external I2S inputs. (I thought I had this
fixed, but I don't have detailed register specs for that register - so
maybe not.)
5. A/V decoder audio clock PLL stops operating due to being programmed
out of range. (This was a problem for 32 ksps audio a while ago, but
I'm pretty confident I have it fixed.)
6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
to a problen Helen Buus reported with cable TV.)
I think #2 is the real problem. I just started to disassmble the
digitizer firmware 2 nights ago to see if I could get some insight as to
how to properly reset it.
I've got a first WAG at fixing the resets of the audio microcontroller's
resets at:
http://linuxtv.org/hg/~awalls/cx18-audio
If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
from 0x810 to 0x9cc, although that may not work either.
> I think we have some nasty i2c issues somewhere in the kernel.
The only I2C connected devices for analog audio are the analog tuner IF
demodulator chip for SIF audio and the CS5345 chip for baseband audio.
Unlike the PVR-150, which has an I2C connected CX25843 A/V decoder, the
CX23418's A/V decoder is integrated and accessed via PCI bus registers.
With that said, the CX23418 will sometimes have to let register access
over the PCI bus fail. For that, I have routines in cx18-io.[ch] to
perform retries. You may wish to add a log statement there to watch for
retry loops that completely fail.
Thanks for the troubleshooting and reporting.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-03-15 11:51 ` Andy Walls
@ 2010-03-16 4:49 ` Mark Lord
2010-03-16 11:11 ` Andy Walls
2010-04-10 22:28 ` Mark Lord
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-03-16 4:49 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel
[-- Attachment #1: Type: text/plain, Size: 3323 bytes --]
On 03/15/10 07:51, Andy Walls wrote:
> On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
>..
>> Digging through google, it appears this problem has been around as long
>> as the cx18 driver has existed, with no clear resolution. Lots of people
>> have reported it to you before, and nobody has found a silver bullet fix.
>
> Correct. I thought it was completely gone, but apparently, there just
> isn't a lot of reporting of this intermittent problem.
..
>> If the audio is not working after modprobe, then simply doing rmmod/modprobe
>> in a loop (until working audio is achieved) is enough to cure it.
..
Well, crap. Tonight our MythTV box proved that assertion to be false.
The cx18 audio was okay after modprobe, but went bad a few seconds later,
when mythbackend started up and did the initial channel tuning.
I have a script that attempts audio input toggling when that happens,
but it had no effect. rmmod/modprobe is still the only "solution",
and it's rather difficult to do those while mythbackend is running.
> Here are all the potential problem areas I can think of:
>
> 1. A/V digitizer/decoder audio detection firmware load and init. (I've
> added firmware readback verification to try and head this off.)
>
> 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> reset sequencing. (I think the cx18 driver has this wrong ATM.)
>
> 3. APU load and init. (The double load is to fix a DTV TS stream bug on
> every other APU& CPU firmware load sequence. The APU_AI_RESET is to
> fix the audio bitrate problem on first capture after a double firmware
> load.)
>
> 4. AI1 Mux setting failing when switching between the internal A/V
> decoder's I2S output and the external I2S inputs. (I thought I had this
> fixed, but I don't have detailed register specs for that register - so
> maybe not.)
>
> 5. A/V decoder audio clock PLL stops operating due to being programmed
> out of range. (This was a problem for 32 ksps audio a while ago, but
> I'm pretty confident I have it fixed.)
>
> 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
> to a problen Helen Buus reported with cable TV.)
>
>
> I think #2 is the real problem. I just started to disassmble the
> digitizer firmware 2 nights ago to see if I could get some insight as to
> how to properly reset it.
>
> I've got a first WAG at fixing the resets of the audio microcontroller's
> resets at:
>
> http://linuxtv.org/hg/~awalls/cx18-audio
>
> If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> from 0x810 to 0x9cc, although that may not work either.
..
I'll have a go at that, and anything else you can dream up as well.
But not for a few days -- really really crazy busy at work right now.
I am a Linux kernel developer, so I can handle patches and stuff
if you have any to offer.
Oh.. attached is a full log from a failure a few nights ago.
This one has the full card status dump included, which shows
where the audio is being muted at.
...
> With that said, the CX23418 will sometimes have to let register access
> over the PCI bus fail. For that, I have routines in cx18-io.[ch] to
> perform retries. You may wish to add a log statement there to watch for
> retry loops that completely fail.
..
I did that a while ago, and they didn't trigger back then.
Thanks
Mark
[-- Attachment #2: cx18_no_audio_log.txt --]
[-- Type: text/plain, Size: 63187 bytes --]
Mar 13 14:29:55 duke syslogd 1.5.0#2ubuntu6: restart.
Mar 13 14:29:56 duke ntpdate[3172]: step time server 10.0.0.2 offset 0.903835 sec
Mar 13 14:29:56 duke ntpd[3542]: ntpd 4.2.4p4@1.1520-o Fri Dec 4 19:14:37 UTC 2009 (1)
Mar 13 14:29:56 duke ntpd[3550]: precision = 1.000 usec
Mar 13 14:29:56 duke ntpd[3550]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Mar 13 14:29:56 duke ntpd[3550]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Mar 13 14:29:56 duke ntpd[3550]: Listening on interface #2 eth0, 10.0.0.18#123 Enabled
Mar 13 14:29:56 duke ntpd[3550]: Listening on interface #3 eth1, 169.254.4.100#123 Enabled
Mar 13 14:29:56 duke ntpd[3550]: kernel time sync status 0040
Mar 13 14:29:56 duke ntpd[3550]: frequency initialized 8.136 PPM from /var/lib/ntp/ntp.drift
Mar 13 14:29:56 duke kernel: Inspecting /boot/System.map-2.6.33
Mar 13 14:29:56 duke kernel: Inspecting /boot/System.map
Mar 13 14:29:56 duke kernel: Inspecting /usr/src/linux/System.map
Mar 13 14:29:56 duke kernel: Cannot find map file.
Mar 13 14:29:56 duke kernel: Loaded 43693 symbols from 76 modules.
Mar 13 14:29:56 duke kernel: fffffff] (base 0xe0000000)
Mar 13 14:29:56 duke kernel: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
Mar 13 14:29:56 duke kernel: PCI: Using configuration type 1 for base access
Mar 13 14:29:56 duke kernel: bio: create slab <bio-0> at 0
Mar 13 14:29:56 duke kernel: ACPI: EC: Look up EC in DSDT
Mar 13 14:29:56 duke kernel: ACPI: Interpreter enabled
Mar 13 14:29:56 duke kernel: ACPI: (supports S0 S3 S4 S5)
Mar 13 14:29:56 duke kernel: ACPI: Using IOAPIC for interrupt routing
Mar 13 14:29:56 duke kernel: ACPI: No dock devices found.
Mar 13 14:29:56 duke kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Mar 13 14:29:56 duke kernel: pci_root PNP0A08:00: ignoring host bridge windows from ACPI; boot with "pci=use_crs" to use them
Mar 13 14:29:56 duke kernel: pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7] (ignored)
Mar 13 14:29:56 duke kernel: pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff] (ignored)
Mar 13 14:29:56 duke kernel: pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored)
Mar 13 14:29:56 duke kernel: pci_root PNP0A08:00: host bridge window [mem 0x000c0000-0x000dffff] (ignored)
Mar 13 14:29:56 duke kernel: pci_root PNP0A08:00: host bridge window [mem 0x7ff00000-0xfebfffff] (ignored)
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1a.0: reg 20: [io 0xfc00-0xfc1f]
Mar 13 14:29:56 duke kernel: pci 0000:00:1a.1: reg 20: [io 0xf800-0xf81f]
Mar 13 14:29:56 duke kernel: pci 0000:00:1a.7: reg 10: [mem 0xfdfff000-0xfdfff3ff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:00:1a.7: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1b.0: reg 10: [mem 0xfdff4000-0xfdff7fff 64bit]
Mar 13 14:29:56 duke kernel: pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:00:1b.0: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1d.0: reg 20: [io 0xf400-0xf41f]
Mar 13 14:29:56 duke kernel: pci 0000:00:1d.1: reg 20: [io 0xf000-0xf01f]
Mar 13 14:29:56 duke kernel: pci 0000:00:1d.2: reg 20: [io 0xec00-0xec1f]
Mar 13 14:29:56 duke kernel: pci 0000:00:1d.7: reg 10: [mem 0xfdffe000-0xfdffe3ff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:00:1d.7: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.0: quirk: [io 0x0400-0x047f] claimed by ICH6 ACPI/GPIO/TCO
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.0: quirk: [io 0x0480-0x04bf] claimed by ICH6 GPIO
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800 (mask 003f)
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 003f)
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: reg 10: [io 0xe800-0xe807]
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: reg 14: [io 0xe400-0xe403]
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: reg 18: [io 0xe000-0xe007]
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: reg 1c: [io 0xdc00-0xdc03]
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: reg 20: [io 0xd800-0xd81f]
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: reg 24: [mem 0xfdffd000-0xfdffd7ff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: PME# supported from D3hot
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.2: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.3: reg 10: [mem 0xfdffc000-0xfdffc0ff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.3: reg 20: [io 0x0500-0x051f]
Mar 13 14:29:56 duke syslogd: /dev/console: Resource temporarily unavailable
Mar 13 14:29:56 duke kernel: pci 0000:00:1f.6: reg 10: [mem 0xfdffb000-0xfdffbfff 64bit]
Mar 13 14:29:56 duke kernel: pci 0000:01:00.0: reg 10: [mem 0xfb000000-0xfbffffff]
Mar 13 14:29:56 duke kernel: pci 0000:01:00.0: reg 14: [mem 0xb0000000-0xbfffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:01:00.0: reg 1c: [mem 0xce000000-0xcfffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:01:00.0: reg 24: [io 0x5c00-0x5c7f]
Mar 13 14:29:56 duke kernel: pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0007ffff pref]
Mar 13 14:29:56 duke kernel: pci 0000:01:00.1: reg 10: [mem 0xfcffc000-0xfcffffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: bridge window [io 0x5000-0x5fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: bridge window [mem 0xfb000000-0xfcffffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: bridge window [mem 0xb0000000-0xcfffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: PCI bridge to [bus 02-02]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: bridge window [io 0xa000-0xafff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdc00000-0xfdcfffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdb00000-0xfdbfffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.0: reg 24: [mem 0xfdafe000-0xfdafffff]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.0: reg 30: [mem 0x00000000-0x0000ffff pref]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.0: PME# supported from D3hot
Mar 13 14:29:56 duke kernel: pci 0000:03:00.0: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:03:00.1: reg 10: [io 0x9c00-0x9c07]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.1: reg 14: [io 0x9800-0x9803]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.1: reg 18: [io 0x9400-0x9407]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.1: reg 1c: [io 0x9000-0x9003]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.1: reg 20: [io 0x8c00-0x8c0f]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: PCI bridge to [bus 03-03]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: bridge window [io 0x8000-0x9fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfda00000-0xfdafffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfd900000-0xfd9fffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:04:00.0: reg 10: [mem 0xfdefc000-0xfdefffff 64bit]
Mar 13 14:29:56 duke kernel: pci 0000:04:00.0: reg 18: [io 0x6c00-0x6cff]
Mar 13 14:29:56 duke kernel: pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
Mar 13 14:29:56 duke kernel: pci 0000:04:00.0: supports D1 D2
Mar 13 14:29:56 duke kernel: pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:04:00.0: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: PCI bridge to [bus 04-04]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: bridge window [io 0x6000-0x6fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfde00000-0xfdefffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:05:00.0: reg 10: [mem 0xdbfff000-0xdbfff7ff]
Mar 13 14:29:56 duke kernel: pci 0000:05:00.0: reg 14: [io 0x7c00-0x7c7f]
Mar 13 14:29:56 duke kernel: pci 0000:05:00.0: supports D2
Mar 13 14:29:56 duke kernel: pci 0000:05:00.0: PME# supported from D2 D3hot D3cold
Mar 13 14:29:56 duke kernel: pci 0000:05:00.0: PME# disabled
Mar 13 14:29:56 duke kernel: pci 0000:05:02.0: reg 10: [mem 0xf4000000-0xf7ffffff pref]
Mar 13 14:29:56 duke kernel: pci 0000:05:03.0: reg 10: [mem 0xd4000000-0xd7ffffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: PCI bridge to [bus 05-05] (subtractive decode)
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: bridge window [io 0x7000-0x7fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xd4000000-0xdbffffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xf4000000-0xf7ffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci_bus 0000:00: on NUMA node 0
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 9 10 11 12 *14 15)
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 9 10 11 12 14 *15)
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 9 10 *11 12 14 15)
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 9 *10 11 12 14 15)
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 9 10 11 12 14 15) *0, disabled.
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *9 10 11 12 14 15)
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNK0] (IRQs *5 9 10 11 12 14 15)
Mar 13 14:29:56 duke kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs 5 9 10 11 12 14 *15)
Mar 13 14:29:56 duke kernel: vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
Mar 13 14:29:56 duke kernel: vgaarb: loaded
Mar 13 14:29:56 duke kernel: SCSI subsystem initialized
Mar 13 14:29:56 duke kernel: libata version 3.00 loaded.
Mar 13 14:29:56 duke kernel: PCI: Using ACPI for IRQ routing
Mar 13 14:29:56 duke kernel: PCI: pci_cache_line_size set to 64 bytes
Mar 13 14:29:56 duke kernel: hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
Mar 13 14:29:56 duke kernel: hpet0: 3 comparators, 64-bit 14.318180 MHz counter
Mar 13 14:29:56 duke kernel: Switching to clocksource tsc
Mar 13 14:29:56 duke kernel: pnp: PnP ACPI init
Mar 13 14:29:56 duke kernel: ACPI: bus type pnp registered
Mar 13 14:29:56 duke kernel: pnp: PnP ACPI: found 14 devices
Mar 13 14:29:56 duke kernel: ACPI: ACPI bus type pnp unregistered
Mar 13 14:29:56 duke kernel: system 00:01: [io 0x04d0-0x04d1] has been reserved
Mar 13 14:29:56 duke kernel: system 00:01: [io 0x0290-0x029f] has been reserved
Mar 13 14:29:56 duke kernel: system 00:01: [io 0x0800-0x087f] has been reserved
Mar 13 14:29:56 duke kernel: system 00:01: [io 0x0880-0x088f] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0a: [io 0x0400-0x04bf] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x000d6000-0x000d7fff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x000f0000-0x000f7fff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x000f8000-0x000fbfff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x000fc000-0x000fffff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x7ff00000-0x7fffffff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0xfed00000-0xfed000ff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x7fee0000-0x7fefffff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x00000000-0x0009ffff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x00100000-0x7fedffff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0xfec00000-0xfec00fff] could not be reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0xfed13000-0xfed1ffff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0xfed20000-0xfed9ffff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0xfee00000-0xfee00fff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0xffb00000-0xffb7ffff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0xfff00000-0xffffffff] has been reserved
Mar 13 14:29:56 duke kernel: system 00:0d: [mem 0x000e0000-0x000effff] has been reserved
Mar 13 14:29:56 duke kernel: pci 0000:01:00.0: BAR 6: assigned [mem 0xc0000000-0xc007ffff pref]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: PCI bridge to [bus 01-01]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: bridge window [io 0x5000-0x5fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: bridge window [mem 0xfb000000-0xfcffffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: bridge window [mem 0xb0000000-0xcfffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: PCI bridge to [bus 02-02]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: bridge window [io 0xa000-0xafff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdc00000-0xfdcfffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: bridge window [mem 0xfdb00000-0xfdbfffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:03:00.0: BAR 6: assigned [mem 0xfd900000-0xfd90ffff pref]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: PCI bridge to [bus 03-03]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: bridge window [io 0x8000-0x9fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfda00000-0xfdafffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: bridge window [mem 0xfd900000-0xfd9fffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:04:00.0: BAR 6: assigned [mem 0xfdd00000-0xfdd1ffff pref]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: PCI bridge to [bus 04-04]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: bridge window [io 0x6000-0x6fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfde00000-0xfdefffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: PCI bridge to [bus 05-05]
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: bridge window [io 0x7000-0x7fff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xd4000000-0xdbffffff]
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: bridge window [mem 0xf4000000-0xf7ffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Mar 13 14:29:56 duke kernel: pci 0000:00:01.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.2: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
Mar 13 14:29:56 duke kernel: pci 0000:00:1c.3: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pci 0000:00:1e.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffffffffffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:01: resource 0 [io 0x5000-0x5fff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:01: resource 1 [mem 0xfb000000-0xfcffffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:01: resource 2 [mem 0xb0000000-0xcfffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci_bus 0000:02: resource 0 [io 0xa000-0xafff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:02: resource 1 [mem 0xfdc00000-0xfdcfffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:02: resource 2 [mem 0xfdb00000-0xfdbfffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci_bus 0000:03: resource 0 [io 0x8000-0x9fff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:03: resource 1 [mem 0xfda00000-0xfdafffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:03: resource 2 [mem 0xfd900000-0xfd9fffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci_bus 0000:04: resource 0 [io 0x6000-0x6fff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:04: resource 1 [mem 0xfde00000-0xfdefffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:04: resource 2 [mem 0xfdd00000-0xfddfffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci_bus 0000:05: resource 0 [io 0x7000-0x7fff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:05: resource 1 [mem 0xd4000000-0xdbffffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:05: resource 2 [mem 0xf4000000-0xf7ffffff 64bit pref]
Mar 13 14:29:56 duke kernel: pci_bus 0000:05: resource 3 [io 0x0000-0xffff]
Mar 13 14:29:56 duke kernel: pci_bus 0000:05: resource 4 [mem 0x00000000-0xffffffffffffffff]
Mar 13 14:29:56 duke kernel: NET: Registered protocol family 2
Mar 13 14:29:56 duke kernel: IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
Mar 13 14:29:56 duke kernel: TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
Mar 13 14:29:56 duke kernel: TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
Mar 13 14:29:56 duke kernel: TCP: Hash tables configured (established 262144 bind 65536)
Mar 13 14:29:56 duke kernel: TCP reno registered
Mar 13 14:29:56 duke kernel: UDP hash table entries: 1024 (order: 3, 32768 bytes)
Mar 13 14:29:56 duke kernel: UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
Mar 13 14:29:56 duke kernel: NET: Registered protocol family 1
Mar 13 14:29:56 duke kernel: pci 0000:01:00.0: Boot video device
Mar 13 14:29:56 duke kernel: PCI: CLS 64 bytes, default 64
Mar 13 14:29:56 duke kernel: Scanning for low memory corruption every 60 seconds
Mar 13 14:29:56 duke kernel: HugeTLB registered 2 MB page size, pre-allocated 0 pages
Mar 13 14:29:56 duke kernel: SGI XFS with security attributes, realtime, large block/inode numbers, no debug enabled
Mar 13 14:29:56 duke kernel: msgmni has been set to 4019
Mar 13 14:29:56 duke kernel: alg: No test for stdrng (krng)
Mar 13 14:29:56 duke kernel: Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
Mar 13 14:29:56 duke kernel: io scheduler noop registered
Mar 13 14:29:56 duke kernel: io scheduler cfq registered (default)
Mar 13 14:29:56 duke kernel: pcieport 0000:00:01.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pcieport 0000:00:1c.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pcieport 0000:00:1c.2: setting latency timer to 64
Mar 13 14:29:56 duke kernel: pcieport 0000:00:1c.3: setting latency timer to 64
Mar 13 14:29:56 duke kernel: lp: driver loaded but no devices found
Mar 13 14:29:56 duke kernel: Generic RTC Driver v1.07
Mar 13 14:29:56 duke kernel: Non-volatile memory driver v1.3
Mar 13 14:29:56 duke kernel: Linux agpgart interface v0.103
Mar 13 14:29:56 duke kernel: [drm] Initialized drm 1.1.0 20060810
Mar 13 14:29:56 duke kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Mar 13 14:29:56 duke kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Mar 13 14:29:56 duke kernel: 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Mar 13 14:29:56 duke kernel: parport_pc 00:08: reported by Plug and Play ACPI
Mar 13 14:29:56 duke kernel: parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Mar 13 14:29:56 duke kernel: lp0: using parport0 (interrupt-driven).
Mar 13 14:29:56 duke kernel: loop: module loaded
Mar 13 14:29:56 duke kernel: ahci 0000:00:1f.2: version 3.0
Mar 13 14:29:56 duke kernel: ahci 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Mar 13 14:29:56 duke kernel: ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x33 impl SATA mode
Mar 13 14:29:56 duke kernel: ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio slum part ccc ems
Mar 13 14:29:56 duke kernel: ahci 0000:00:1f.2: setting latency timer to 64
Mar 13 14:29:56 duke kernel: scsi0 : ahci
Mar 13 14:29:56 duke kernel: scsi1 : ahci
Mar 13 14:29:56 duke kernel: scsi2 : ahci
Mar 13 14:29:56 duke kernel: scsi3 : ahci
Mar 13 14:29:56 duke kernel: scsi4 : ahci
Mar 13 14:29:56 duke kernel: scsi5 : ahci
Mar 13 14:29:56 duke kernel: ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
Mar 13 14:29:56 duke kernel: ata2: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd180 irq 17
Mar 13 14:29:56 duke kernel: ata3: DUMMY
Mar 13 14:29:56 duke kernel: ata4: DUMMY
Mar 13 14:29:56 duke kernel: ata5: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
Mar 13 14:29:56 duke kernel: ata6: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 17
Mar 13 14:29:56 duke kernel: ahci 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Mar 13 14:29:56 duke kernel: ahci 0000:03:00.0: JMB361 has only one port, port_map 0x3 -> 0x1
Mar 13 14:29:56 duke kernel: ahci 0000:03:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x1 impl SATA mode
Mar 13 14:29:56 duke kernel: ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
Mar 13 14:29:56 duke kernel: ahci 0000:03:00.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: scsi6 : ahci
Mar 13 14:29:56 duke kernel: scsi7 : ahci
Mar 13 14:29:56 duke kernel: ata7: SATA max UDMA/133 abar m8192@0xfdafe000 port 0xfdafe100 irq 18
Mar 13 14:29:56 duke kernel: ata8: DUMMY
Mar 13 14:29:56 duke kernel: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
Mar 13 14:29:56 duke kernel: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
Mar 13 14:29:56 duke kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Mar 13 14:29:56 duke kernel: mice: PS/2 mouse device common for all mice
Mar 13 14:29:56 duke kernel: md: raid0 personality registered for level 0
Mar 13 14:29:56 duke kernel: cpuidle: using governor ladder
Mar 13 14:29:56 duke kernel: ioatdma: Intel(R) QuickData Technology Driver 4.00
Mar 13 14:29:56 duke kernel: TCP cubic registered
Mar 13 14:29:56 duke kernel: NET: Registered protocol family 17
Mar 13 14:29:56 duke kernel: ata7: SATA link down (SStatus 0 SControl 300)
Mar 13 14:29:56 duke kernel: ata2: SATA link down (SStatus 0 SControl 300)
Mar 13 14:29:56 duke kernel: ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Mar 13 14:29:56 duke kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar 13 14:29:56 duke kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar 13 14:29:56 duke kernel: ata1.00: ATA-8: OCZ-VERTEX, 1.5, max UDMA/133
Mar 13 14:29:56 duke kernel: ata1.00: 125045424 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
Mar 13 14:29:56 duke kernel: ata1.00: configured for UDMA/133
Mar 13 14:29:56 duke kernel: scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX 1.5 PQ: 0 ANSI: 5
Mar 13 14:29:56 duke kernel: sd 0:0:0:0: [sda] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
Mar 13 14:29:56 duke kernel: sd 0:0:0:0: [sda] Write Protect is off
Mar 13 14:29:56 duke kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Mar 13 14:29:56 duke kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar 13 14:29:56 duke kernel: sda: sda1 sda2
Mar 13 14:29:56 duke kernel: ata5.00: ATA-8: WDC WD15EARS-00Z5B1, 80.00A80, max UDMA/133
Mar 13 14:29:56 duke kernel: ata6.00: ATAPI: PIONEER DVD-RW DVR-212D, 1.21, max UDMA/66
Mar 13 14:29:56 duke kernel: ata5.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
Mar 13 14:29:56 duke kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Mar 13 14:29:56 duke kernel: ata5.00: configured for UDMA/133
Mar 13 14:29:56 duke kernel: scsi 4:0:0:0: Direct-Access ATA WDC WD15EARS-00Z 80.0 PQ: 0 ANSI: 5
Mar 13 14:29:56 duke kernel: sd 4:0:0:0: [sdb] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
Mar 13 14:29:56 duke kernel: sd 4:0:0:0: [sdb] Write Protect is off
Mar 13 14:29:56 duke kernel: sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
Mar 13 14:29:56 duke kernel: sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar 13 14:29:56 duke kernel: sdb: sdb1
Mar 13 14:29:56 duke kernel: sd 4:0:0:0: [sdb] Attached SCSI disk
Mar 13 14:29:56 duke kernel: ata6.00: configured for UDMA/66
Mar 13 14:29:56 duke kernel: scsi 5:0:0:0: CD-ROM PIONEER DVD-RW DVR-212D 1.21 PQ: 0 ANSI: 5
Mar 13 14:29:56 duke kernel: sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Mar 13 14:29:56 duke kernel: Uniform CD-ROM driver Revision: 3.20
Mar 13 14:29:56 duke kernel: sr 5:0:0:0: Attached scsi CD-ROM sr0
Mar 13 14:29:56 duke kernel: md: Waiting for all devices to be available before autodetect
Mar 13 14:29:56 duke kernel: md: If you don't use raid, use raid=noautodetect
Mar 13 14:29:56 duke kernel: md: Autodetecting RAID arrays.
Mar 13 14:29:56 duke kernel: md: Scanned 0 and added 0 devices.
Mar 13 14:29:56 duke kernel: md: autorun ...
Mar 13 14:29:56 duke kernel: md: ... autorun DONE.
Mar 13 14:29:56 duke kernel: EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240)
Mar 13 14:29:56 duke kernel: EXT4-fs (sda2): mounted filesystem with ordered data mode
Mar 13 14:29:56 duke kernel: VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
Mar 13 14:29:56 duke kernel: Freeing unused kernel memory: 408k freed
Mar 13 14:29:56 duke kernel: fuse init (API version 7.13)
Mar 13 14:29:56 duke kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Mar 13 14:29:56 duke kernel: HDA Intel 0000:00:1b.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: hda_codec: ALC883: BIOS auto-probing.
Mar 13 14:29:56 duke kernel: HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
Mar 13 14:29:56 duke kernel: HDA Intel 0000:01:00.1: setting latency timer to 64
Mar 13 14:29:56 duke kernel: Linux video capture interface: v2.00
Mar 13 14:29:56 duke kernel: ivtv: Start initialization, version 1.4.1
Mar 13 14:29:56 duke kernel: ivtv0: Initializing card 0
Mar 13 14:29:56 duke kernel: ivtv0: Autodetected Hauppauge card (cx23416 based)
Mar 13 14:29:56 duke kernel: ivtv 0000:05:02.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Mar 13 14:29:56 duke kernel: tveeprom 0-0050: Hauppauge model 32062, rev B185, serial# 2842715
Mar 13 14:29:56 duke kernel: tveeprom 0-0050: tuner model is TCL 2002N 6A (idx 85, type 50)
Mar 13 14:29:56 duke kernel: tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
Mar 13 14:29:56 duke kernel: tveeprom 0-0050: audio processor is MSP3445 (idx 12)
Mar 13 14:29:56 duke kernel: tveeprom 0-0050: decoder processor is SAA7115 (idx 19)
Mar 13 14:29:56 duke kernel: tveeprom 0-0050: has no radio, has IR receiver, has no IR transmitter
Mar 13 14:29:56 duke kernel: ivtv0: Autodetected Hauppauge WinTV PVR-250
Mar 13 14:29:56 duke kernel: saa7115 0-0021: saa7115 found (1f7115d0e100000) @ 0x42 (ivtv i2c driver #0)
Mar 13 14:29:56 duke kernel: msp3400 0-0040: MSP3445G-B8 found @ 0x80 (ivtv i2c driver #0)
Mar 13 14:29:56 duke kernel: msp3400 0-0040: msp3400 supports radio, mode is autodetect and autoselect
Mar 13 14:29:56 duke kernel: tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
Mar 13 14:29:56 duke kernel: tuner-simple 0-0061: creating new instance
Mar 13 14:29:56 duke kernel: tuner-simple 0-0061: type set to 50 (TCL 2002N)
Mar 13 14:29:56 duke kernel: IRQ 17/ivtv0: IRQF_DISABLED is not guaranteed on shared IRQs
Mar 13 14:29:56 duke kernel: ivtv0: Registered device video0 for encoder MPG (4096 kB)
Mar 13 14:29:56 duke kernel: ivtv0: Registered device video32 for encoder YUV (2048 kB)
Mar 13 14:29:56 duke kernel: ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
Mar 13 14:29:56 duke kernel: ivtv0: Registered device video24 for encoder PCM (320 kB)
Mar 13 14:29:56 duke kernel: ivtv0: Initialized card: Hauppauge WinTV PVR-250
Mar 13 14:29:56 duke kernel: ivtv: End initialization
Mar 13 14:29:56 duke kernel: ACPI: Invalid PBLK length [0]
Mar 13 14:29:56 duke kernel: ACPI Error (psparse-0537): Method parse/execution failed
Mar 13 14:29:56 duke kernel: input: Power Button as /class/input/input0
Mar 13 14:29:56 duke kernel: ACPI: Power Button [PWRB]
Mar 13 14:29:56 duke kernel: usbcore: registered new interface driver usbfs
Mar 13 14:29:56 duke kernel: [\_PR_.CPU0._PDC] (Node ffff88007f858490)
Mar 13 14:29:56 duke kernel: usbcore: registered new interface driver hub
Mar 13 14:29:56 duke kernel: , AE_ALREADY_EXISTS
Mar 13 14:29:56 duke kernel: ACPI: Marking method _PDC as Serialized because of AE_ALREADY_EXISTS error
Mar 13 14:29:56 duke kernel: pata_jmicron 0000:03:00.1: enabling device (0000 -> 0001)
Mar 13 14:29:56 duke kernel: usbcore: registered new device driver usb
Mar 13 14:29:56 duke kernel: pata_jmicron 0000:03:00.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
Mar 13 14:29:56 duke kernel:
Mar 13 14:29:56 duke kernel: thermal LNXTHERM:01: registered as thermal_zone0
Mar 13 14:29:56 duke kernel: input: Power Button as /class/input/input1
Mar 13 14:29:56 duke kernel: ACPI: Power Button [PWRF]
Mar 13 14:29:56 duke kernel: ACPI: Thermal Zone [THRM] (36 C)
Mar 13 14:29:56 duke kernel: ACPI: Invalid PBLK length [0]
Mar 13 14:29:56 duke kernel: pata_jmicron 0000:03:00.1: setting latency timer to 64
Mar 13 14:29:56 duke kernel: ACPI: SSDT 000000007fee8750 000CE (v01 PmRef Cpu1Ist 00003000 INTL 20041203)
Mar 13 14:29:56 duke kernel: scsi8 : pata_jmicron
Mar 13 14:29:56 duke kernel: scsi9 : pata_jmicron
Mar 13 14:29:56 duke kernel: ata9: PATA max UDMA/100 cmd 0x9c00 ctl 0x9800 bmdma 0x8c00 irq 19
Mar 13 14:29:56 duke kernel: ata10: PATA max UDMA/100 cmd 0x9400 ctl 0x9000 bmdma 0x8c08 irq 19
Mar 13 14:29:56 duke kernel:
Mar 13 14:29:56 duke kernel: nvidia: module license 'NVIDIA' taints kernel.
Mar 13 14:29:56 duke kernel: firewire_ohci 0000:05:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
Mar 13 14:29:56 duke kernel: firewire_ohci 0000:05:00.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: uhci_hcd: USB Universal Host Controller Interface driver
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Mar 13 14:29:56 duke kernel: sky2 driver version 1.26
Mar 13 14:29:56 duke kernel: sky2 0000:04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
Mar 13 14:29:56 duke kernel: sky2 0000:04:00.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: sky2 0000:04:00.0: Yukon-2 EC Ultra chip revision 2
Mar 13 14:29:56 duke kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Mar 13 14:29:56 duke kernel: sd 4:0:0:0: Attached scsi generic sg1 type 0
Mar 13 14:29:56 duke kernel: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Mar 13 14:29:56 duke kernel: Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after
Mar 13 14:29:56 duke kernel: cx18: Start initialization, version 1.4.0
Mar 13 14:29:56 duke kernel: sr 5:0:0:0: Attached scsi generic sg2 type 5
Mar 13 14:29:56 duke kernel: firewire_ohci: Added fw-ohci device 0000:05:00.0, OHCI version 1.10
Mar 13 14:29:56 duke kernel: cx18-0: Initializing card 0
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.0: UHCI Host Controller
Mar 13 14:29:56 duke kernel: cx18-0: Autodetected Hauppauge card
Mar 13 14:29:56 duke kernel: sky2 eth0: addr 00:15:58:8a:ae:e5
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000fc00
Mar 13 14:29:56 duke kernel: ACPI: Fan [FAN] (on)
Mar 13 14:29:56 duke kernel: cx18 0000:05:03.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Mar 13 14:29:56 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2)
Mar 13 14:29:56 duke kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
Mar 13 14:29:56 duke kernel: cx18-0: cx23418 revision 01010000 (B)
Mar 13 14:29:56 duke kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Mar 13 14:29:56 duke kernel: usb usb1: Product: UHCI Host Controller
Mar 13 14:29:56 duke kernel: usb usb1: Manufacturer: Linux 2.6.33 uhci_hcd
Mar 13 14:29:56 duke kernel: usb usb1: SerialNumber: 0000:00:1a.0
Mar 13 14:29:56 duke kernel: hub 1-0:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 1-0:1.0: 2 ports detected
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1a.7: setting latency timer to 64
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1a.7: EHCI Host Controller
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 2
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfdfff000
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
Mar 13 14:29:56 duke kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
Mar 13 14:29:56 duke kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Mar 13 14:29:56 duke kernel: usb usb2: Product: EHCI Host Controller
Mar 13 14:29:56 duke kernel: usb usb2: Manufacturer: Linux 2.6.33 ehci_hcd
Mar 13 14:29:56 duke kernel: usb usb2: SerialNumber: 0000:00:1a.7
Mar 13 14:29:56 duke kernel: hub 2-0:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 2-0:1.0: 4 ports detected
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.1: setting latency timer to 64
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.1: UHCI Host Controller
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 3
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000f800
Mar 13 14:29:56 duke kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
Mar 13 14:29:56 duke kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Mar 13 14:29:56 duke kernel: nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Mar 13 14:29:56 duke kernel: usb usb3: Product: UHCI Host Controller
Mar 13 14:29:56 duke kernel: usb usb3: Manufacturer: Linux 2.6.33 uhci_hcd
Mar 13 14:29:56 duke kernel: usb usb3: SerialNumber: 0000:00:1a.1
Mar 13 14:29:56 duke kernel: hub 3-0:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 3-0:1.0: 2 ports detected
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1d.7: setting latency timer to 64
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1d.7: EHCI Host Controller
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfdffe000
Mar 13 14:29:56 duke kernel: ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
Mar 13 14:29:56 duke kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0002
Mar 13 14:29:56 duke kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Mar 13 14:29:56 duke kernel: usb usb4: Product: EHCI Host Controller
Mar 13 14:29:56 duke kernel: usb usb4: Manufacturer: Linux 2.6.33 ehci_hcd
Mar 13 14:29:56 duke kernel: usb usb4: SerialNumber: 0000:00:1d.7
Mar 13 14:29:56 duke kernel: hub 4-0:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 4-0:1.0: 6 ports detected
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.0: UHCI Host Controller
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000f400
Mar 13 14:29:56 duke kernel: usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
Mar 13 14:29:56 duke kernel: usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Mar 13 14:29:56 duke kernel: usb usb5: Product: UHCI Host Controller
Mar 13 14:29:56 duke kernel: usb usb5: Manufacturer: Linux 2.6.33 uhci_hcd
Mar 13 14:29:56 duke kernel: usb usb5: SerialNumber: 0000:00:1d.0
Mar 13 14:29:56 duke kernel: hub 5-0:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 5-0:1.0: 2 ports detected
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.1: setting latency timer to 64
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.1: UHCI Host Controller
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000f000
Mar 13 14:29:56 duke kernel: usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
Mar 13 14:29:56 duke kernel: usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Mar 13 14:29:56 duke kernel: usb usb6: Product: UHCI Host Controller
Mar 13 14:29:56 duke kernel: usb usb6: Manufacturer: Linux 2.6.33 uhci_hcd
Mar 13 14:29:56 duke kernel: usb usb6: SerialNumber: 0000:00:1d.1
Mar 13 14:29:56 duke kernel: hub 6-0:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 6-0:1.0: 2 ports detected
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.2: setting latency timer to 64
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.2: UHCI Host Controller
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
Mar 13 14:29:56 duke kernel: uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000ec00
Mar 13 14:29:56 duke kernel: usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
Mar 13 14:29:56 duke kernel: usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Mar 13 14:29:56 duke kernel: usb usb7: Product: UHCI Host Controller
Mar 13 14:29:56 duke kernel: usb usb7: Manufacturer: Linux 2.6.33 uhci_hcd
Mar 13 14:29:56 duke kernel: usb usb7: SerialNumber: 0000:00:1d.2
Mar 13 14:29:56 duke kernel: hub 7-0:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 7-0:1.0: 2 ports detected
Mar 13 14:29:56 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Mar 13 14:29:56 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Mar 13 14:29:56 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Mar 13 14:29:56 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Mar 13 14:29:56 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Mar 13 14:29:56 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Mar 13 14:29:56 duke kernel: tveeprom 1-0050: has radio
Mar 13 14:29:56 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600
Mar 13 14:29:56 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported
Mar 13 14:29:56 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
Mar 13 14:29:56 duke kernel: firewire_core: created device fw0: GUID 00016c200022ce9e, S400
Mar 13 14:29:56 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
Mar 13 14:29:56 duke kernel: tda9887 2-0043: creating new instance
Mar 13 14:29:56 duke kernel: tda9887 2-0043: tda988[5/6/7] found
Mar 13 14:29:56 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
Mar 13 14:29:56 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
Mar 13 14:29:56 duke kernel: tuner-simple 2-0061: creating new instance
Mar 13 14:29:56 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
Mar 13 14:29:56 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB)
Mar 13 14:29:56 duke kernel: DVB: registering new adapter (cx18)
Mar 13 14:29:56 duke kernel: nvidia 0000:01:00.0: setting latency timer to 64
Mar 13 14:29:56 duke kernel: vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
Mar 13 14:29:56 duke kernel: NVRM: loading NVIDIA UNIX x86_64 Kernel Module 195.36.08 Thu Feb 25 04:10:13 PST 2010
Mar 13 14:29:56 duke kernel: MXL5005S: Attached at address 0x63
Mar 13 14:29:56 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
Mar 13 14:29:56 duke kernel: cx18-0: DVB Frontend registered
Mar 13 14:29:56 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
Mar 13 14:29:56 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB)
Mar 13 14:29:56 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes)
Mar 13 14:29:56 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB)
Mar 13 14:29:56 duke kernel: cx18-0: Registered device radio1 for encoder radio
Mar 13 14:29:56 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600
Mar 13 14:29:56 duke kernel: cx18: End initialization
Mar 13 14:29:56 duke kernel: cx18-alsa: module loading...
Mar 13 14:29:56 duke kernel: usb 3-2: new low speed USB device using uhci_hcd and address 2
Mar 13 14:29:56 duke kernel: usb 3-2: New USB device found, idVendor=15c2, idProduct=ffdc
Mar 13 14:29:56 duke kernel: usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Mar 13 14:29:56 duke kernel: usb 4-6: new high speed USB device using ehci_hcd and address 3
Mar 13 14:29:56 duke kernel: usb 4-6: New USB device found, idVendor=0b95, idProduct=7720
Mar 13 14:29:56 duke kernel: usb 4-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 13 14:29:56 duke kernel: usb 4-6: Product: AX88772
Mar 13 14:29:56 duke kernel: usb 4-6: Manufacturer: ASIX Elec. Corp.
Mar 13 14:29:56 duke kernel: usb 4-6: SerialNumber: 000001
Mar 13 14:29:56 duke kernel: usb 5-2: new full speed USB device using uhci_hcd and address 2
Mar 13 14:29:56 duke kernel: usb 5-2: New USB device found, idVendor=0403, idProduct=6001
Mar 13 14:29:56 duke kernel: usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 13 14:29:56 duke kernel: usb 5-2: Product: Triple Relay Controller
Mar 13 14:29:56 duke kernel: usb 5-2: Manufacturer: RTR
Mar 13 14:29:56 duke kernel: usb 5-2: SerialNumber: A4SI153I
Mar 13 14:29:56 duke kernel: usb 1-1: new low speed USB device using uhci_hcd and address 2
Mar 13 14:29:56 duke kernel: eth1: register 'asix' at usb-0000:00:1d.7-6, ASIX AX88772 USB 2.0 Ethernet, 00:50:5b:04:a2:4b
Mar 13 14:29:56 duke kernel: usbcore: registered new interface driver asix
Mar 13 14:29:56 duke kernel: usb 1-1: New USB device found, idVendor=046d, idProduct=c51e
Mar 13 14:29:56 duke kernel: usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Mar 13 14:29:56 duke kernel: usbcore: registered new interface driver hiddev
Mar 13 14:29:56 duke kernel: input: HID 046d:c51e as /class/input/input2
Mar 13 14:29:56 duke kernel: generic-usb 0003:046D:C51E.0001: input: USB HID v1.11 Keyboard [HID 046d:c51e] on usb-0000:00:1a.0-1/input0
Mar 13 14:29:56 duke kernel: input: HID 046d:c51e as /class/input/input3
Mar 13 14:29:56 duke kernel: generic-usb 0003:046D:C51E.0002: input,hiddev0: USB HID v1.11 Mouse [HID 046d:c51e] on usb-0000:00:1a.0-1/input1
Mar 13 14:29:56 duke kernel: usbcore: registered new interface driver usbhid
Mar 13 14:29:56 duke kernel: usbhid: USB HID core driver
Mar 13 14:29:56 duke kernel: usb 2-3: new high speed USB device using ehci_hcd and address 4
Mar 13 14:29:56 duke kernel: usb 2-3: New USB device found, idVendor=05e3, idProduct=0608
Mar 13 14:29:56 duke kernel: usb 2-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Mar 13 14:29:56 duke kernel: usb 2-3: Product: USB2.0 Hub
Mar 13 14:29:56 duke kernel: hub 2-3:1.0: USB hub found
Mar 13 14:29:56 duke kernel: hub 2-3:1.0: 4 ports detected
Mar 13 14:29:56 duke kernel: usb 2-3.1: new full speed USB device using ehci_hcd and address 5
Mar 13 14:29:56 duke kernel: usb 2-3.1: New USB device found, idVendor=0c76, idProduct=1607
Mar 13 14:29:56 duke kernel: usb 2-3.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Mar 13 14:29:56 duke kernel: usb 2-3.1: Product: USB Headphone Set
Mar 13 14:29:56 duke kernel: input: USB Headphone Set as /class/input/input4
Mar 13 14:29:56 duke kernel: generic-usb 0003:0C76:1607.0003: input: USB HID v1.00 Device [USB Headphone Set] on usb-0000:00:1a.7-3.1/input3
Mar 13 14:29:56 duke kernel: usbcore: registered new interface driver snd-usb-audio
Mar 13 14:29:56 duke kernel: usb 2-3.2: new high speed USB device using ehci_hcd and address 6
Mar 13 14:29:56 duke kernel: usb 2-3.2: New USB device found, idVendor=2040, idProduct=7200
Mar 13 14:29:56 duke kernel: usb 2-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=10
Mar 13 14:29:56 duke kernel: usb 2-3.2: Product: WinTV HVR-950
Mar 13 14:29:56 duke kernel: usb 2-3.2: Manufacturer: Hauppauge
Mar 13 14:29:56 duke kernel: usb 2-3.2: SerialNumber: 4031688744
Mar 13 14:29:56 duke kernel: au0828 driver loaded
Mar 13 14:29:56 duke kernel: usb 2-3.3: new full speed USB device using ehci_hcd and address 7
Mar 13 14:29:56 duke kernel: usb 2-3.3: New USB device found, idVendor=0403, idProduct=6001
Mar 13 14:29:56 duke kernel: usb 2-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 13 14:29:56 duke kernel: usb 2-3.3: Product: Frankenswitch v3 4x4:1 matrix
Mar 13 14:29:56 duke kernel: usb 2-3.3: Manufacturer: RTR
Mar 13 14:29:56 duke kernel: usb 2-3.3: SerialNumber: A8S59W9K
Mar 13 14:29:56 duke kernel: usb 2-3.4: new low speed USB device using ehci_hcd and address 8
Mar 13 14:29:56 duke kernel: au0828: i2c bus registered
Mar 13 14:29:56 duke kernel: usb 2-3.4: New USB device found, idVendor=051d, idProduct=0002
Mar 13 14:29:56 duke kernel: usb 2-3.4: New USB device strings: Mfr=3, Product=1, SerialNumber=2
Mar 13 14:29:56 duke kernel: usb 2-3.4: Product: Back-UPS XS 1300 LCD FW:836.H8 .D USB FW:H8
Mar 13 14:29:56 duke kernel: usb 2-3.4: Manufacturer: American Power Conversion
Mar 13 14:29:56 duke kernel: usb 2-3.4: SerialNumber: BB0820009163
Mar 13 14:29:56 duke kernel: tveeprom 3-0050: Hauppauge model 72001, rev B3F0, serial# 5156904
Mar 13 14:29:56 duke kernel: tveeprom 3-0050: MAC address is 00:0d:fe:4e:b0:28
Mar 13 14:29:56 duke kernel: tveeprom 3-0050: tuner model is Xceive XC5000 (idx 150, type 76)
Mar 13 14:29:56 duke kernel: tveeprom 3-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88)
Mar 13 14:29:56 duke kernel: tveeprom 3-0050: audio processor is AU8522 (idx 44)
Mar 13 14:29:56 duke kernel: tveeprom 3-0050: decoder processor is AU8522 (idx 42)
Mar 13 14:29:56 duke kernel: tveeprom 3-0050: has no radio, has IR receiver, has no IR transmitter
Mar 13 14:29:56 duke kernel: hauppauge_eeprom: hauppauge eeprom: model=72001
Mar 13 14:29:56 duke kernel: au8522 3-0047: creating new instance
Mar 13 14:29:56 duke kernel: au8522_decoder creating new instance...
Mar 13 14:29:56 duke kernel: tuner 3-0061: chip found @ 0xc2 (au0828)
Mar 13 14:29:56 duke kernel: xc5000 3-0061: creating new instance
Mar 13 14:29:56 duke kernel: xc5000: Successfully identified at address 0x61
Mar 13 14:29:56 duke kernel: xc5000: Firmware has not been loaded previously
Mar 13 14:29:56 duke kernel: au8522 3-0047: attaching existing instance
Mar 13 14:29:56 duke kernel: xc5000 3-0061: attaching existing instance
Mar 13 14:29:56 duke kernel: xc5000: Successfully identified at address 0x61
Mar 13 14:29:56 duke kernel: xc5000: Firmware has not been loaded previously
Mar 13 14:29:56 duke kernel: DVB: registering new adapter (au0828)
Mar 13 14:29:56 duke kernel: DVB: registering adapter 1 frontend 0 (Auvitek AU8522 QAM/8VSB Frontend)...
Mar 13 14:29:56 duke kernel: Registered device AU0828 [Hauppauge HVR950Q]
Mar 13 14:29:56 duke kernel: usbcore: registered new interface driver au0828
Mar 13 14:29:56 duke kernel: generic-usb 0003:051D:0002.0004: hiddev1: USB HID v1.10 Device [American Power Conversion Back-UPS XS 1300 LCD FW:836.H8 .D USB FW:H8 ] on usb-0000:00:1a.7-3.4/input0
Mar 13 14:29:56 duke kernel: kjournald starting. Commit interval 5 seconds
Mar 13 14:29:56 duke kernel: EXT3-fs (sda1): using internal journal
Mar 13 14:29:56 duke kernel: EXT3-fs (sda1): mounted filesystem with writeback data mode
Mar 13 14:29:56 duke kernel: XFS mounting filesystem sdb1
Mar 13 14:29:56 duke kernel: Ending clean XFS mount for filesystem: sdb1
Mar 13 14:29:56 duke kernel: sky2 eth0: enabling interface
Mar 13 14:29:56 duke kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
Mar 13 14:29:56 duke kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
Mar 13 14:29:56 duke kernel: sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
Mar 13 14:29:56 duke kernel: warning: `ntpd' uses 32-bit capabilities (legacy support in use)
Mar 13 14:29:56 duke logger: /etc/rc2.d/S13local start
Mar 13 14:29:56 duke kernel: ata1.00: configured for UDMA/133
Mar 13 14:29:56 duke kernel: ata1: EH complete
Mar 13 14:29:56 duke kernel: ata5.00: configured for UDMA/133
Mar 13 14:29:56 duke kernel: ata5: EH complete
Mar 13 14:29:56 duke sshd[3662]: Server listening on 0.0.0.0 port 22.
Mar 13 14:29:56 duke /usr/sbin/gpm[3682]: *** info [daemon/startup.c(131)]:
Mar 13 14:29:56 duke /usr/sbin/gpm[3682]: Started gpm successfully. Entered daemon mode.
Mar 13 14:29:56 duke mysqld_safe[3761]: started
Mar 13 14:29:56 duke mysqld[3764]: 100313 14:29:56 [Warning] option 'net_buffer_length': unsigned value 8388608 adjusted to 1048576
Mar 13 14:29:56 duke mysqld[3764]: 100313 14:29:56 InnoDB: Started; log sequence number 0 2482424
Mar 13 14:29:56 duke mysqld[3764]: 100313 14:29:56 [Note] /usr/sbin/mysqld: ready for connections.
Mar 13 14:29:56 duke mysqld[3764]: Version: '5.0.67-0ubuntu6.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
Mar 13 14:29:57 duke /etc/mysql/debian-start[3803]: Upgrading MySQL tables if necessary.
Mar 13 14:29:57 duke /etc/mysql/debian-start[3807]: Looking for 'mysql' in: /usr/bin/mysql
Mar 13 14:29:57 duke /etc/mysql/debian-start[3807]: Looking for 'mysqlcheck' in: /usr/bin/mysqlcheck
Mar 13 14:29:57 duke /etc/mysql/debian-start[3807]: This installation of MySQL is already upgraded to 5.0.67, use --force if you still need to run mysql_upgrade
Mar 13 14:29:57 duke /etc/mysql/debian-start[3819]: Checking for insecure root accounts.
Mar 13 14:29:57 duke /etc/mysql/debian-start[3823]: WARNING: mysql.user contains 3 root accounts without password!
Mar 13 14:29:57 duke /etc/mysql/debian-start[3824]: Triggering myisam-recover for all MyISAM tables
Mar 13 14:29:58 duke acpid: client connected from 4050[113:122]
Mar 13 14:29:58 duke ntpd[3550]: ntpd exiting on signal 15
Mar 13 14:29:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Mar 13 14:29:59 duke ntpdate[4123]: step time server 10.0.0.2 offset 0.615512 sec
Mar 13 14:29:59 duke ntpd[4179]: ntpd 4.2.4p4@1.1520-o Fri Dec 4 19:14:37 UTC 2009 (1)
Mar 13 14:29:59 duke ntpd[4180]: precision = 1.000 usec
Mar 13 14:29:59 duke ntpd[4180]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Mar 13 14:29:59 duke ntpd[4180]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Mar 13 14:29:59 duke ntpd[4180]: Listening on interface #2 eth0, 10.0.0.18#123 Enabled
Mar 13 14:29:59 duke ntpd[4180]: Listening on interface #3 eth1, 169.254.4.100#123 Enabled
Mar 13 14:29:59 duke ntpd[4180]: kernel time sync status 0040
Mar 13 14:29:59 duke ntpd[4180]: frequency initialized 8.136 PPM from /var/lib/ntp/ntp.drift
Mar 13 14:29:59 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
Mar 13 14:29:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Mar 13 14:29:59 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
Mar 13 14:29:59 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
Mar 13 14:29:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Mar 13 14:29:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Mar 13 14:30:00 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-dig.fw
Mar 13 14:30:00 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
Mar 13 14:30:00 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
Mar 13 14:30:01 duke kernel: ivtv 0000:05:02.0: firmware: requesting v4l-cx2341x-enc.fw
Mar 13 14:30:01 duke kernel: ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
Mar 13 14:30:01 duke kernel: ivtv0: Encoder revision: 0x02060039
Mar 13 14:30:01 duke kernel: ata1.00: configured for UDMA/133
Mar 13 14:30:01 duke kernel: ata1: EH complete
Mar 13 14:30:01 duke kernel: ata5.00: configured for UDMA/133
Mar 13 14:30:01 duke kernel: ata5: EH complete
Mar 13 14:30:03 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: reconfiguring driver
Mar 13 14:30:04 duke kernel: input: i2c IR (Hauppauge) as /class/input/input5
Mar 13 14:30:04 duke kernel: Creating IR device irrcv0
Mar 13 14:30:04 duke kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0]
Mar 13 14:30:04 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: waiting for device(s)
Mar 13 14:30:04 duke logger[4278]: /usr/bin/input-kbd -f /usr/local/bin/hauppauge_remote.conf 5
Mar 13 14:30:04 duke logger: /dev/video1: fix_hvr1600_stutter.sh: Pre-initializing
Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: HVR1600/cx18 audio bug, reloading cx18 driver
Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: rmmod cx18 failed
Mar 13 14:30:09 duke nanny.mythbackend[4350]: mythbackend[4352] started
Mar 13 14:30:09 duke gdm[4386]: WARNING: Didn't understand `' (expected true or false)
Mar 13 14:30:09 duke acpid: client connected from 4399[0:0]
Mar 13 14:30:10 duke /usr/sbin/cron[4452]: (CRON) INFO (pidfile fd = 3)
Mar 13 14:30:10 duke /usr/sbin/cron[4453]: (CRON) STARTUP (fork ok)
Mar 13 14:30:10 duke /usr/sbin/cron[4453]: (CRON) INFO (Running @reboot jobs)
Mar 13 14:30:10 duke rpc.statd[4488]: Version 1.1.2 Starting
Mar 13 14:30:10 duke kernel: RPC: Registered udp transport module.
Mar 13 14:30:10 duke kernel: RPC: Registered tcp transport module.
Mar 13 14:30:10 duke kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 13 14:30:10 duke acpid: client connected from 4399[0:0]
Mar 13 14:30:10 duke kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Mar 13 14:30:10 duke kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Mar 13 14:30:10 duke kernel: NFSD: starting 90-second grace period
Mar 13 14:30:11 duke logger: /etc/rc2.d/S98local start
Mar 13 14:30:11 duke kernel: ata1.00: configured for UDMA/133
Mar 13 14:30:11 duke kernel: ata1: EH complete
Mar 13 14:30:11 duke kernel: ata5.00: configured for UDMA/133
Mar 13 14:30:11 duke kernel: ata5: EH complete
Mar 13 14:30:11 duke gdm[4393]: pam_unix(gdm-autologin:session): session opened for user mlord by (uid=0)
Mar 13 14:30:11 duke gdm[4393]: pam_ck_connector(gdm-autologin:session): nox11 mode, ignoring PAM_TTY :0
Mar 13 14:30:11 duke apcupsd[4427]: NIS server startup succeeded
Mar 13 14:30:11 duke apcupsd[4427]: apcupsd 3.14.4 (18 May 2008) debian startup succeeded
Mar 13 14:30:12 duke nanny.vfd_updater[4865]: vfd_updater[4866] started
Mar 13 14:30:12 duke vfd_updater[4866]: connect(): Connection refused
Mar 13 14:30:14 duke kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
Mar 13 14:30:14 duke kernel: usb 2-3.2: firmware: requesting dvb-fe-xc5000-1.6.114.fw
Mar 13 14:30:14 duke kernel: xc5000: firmware read 12401 bytes.
Mar 13 14:30:14 duke kernel: xc5000: firmware uploading...
Mar 13 14:30:21 duke kernel: xc5000: firmware upload complete...
Mar 13 14:30:22 duke /usr/local/bin/diseqc_switcher[4909]: Selecting '2B'
Mar 13 14:30:22 duke /usr/local/bin/diseqc_switcher[4909]: writing 0x04 [- - - - - 1 - -]
Mar 13 14:30:23 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. attempting workaround
Mar 13 14:30:24 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. workaround failed
Mar 13 14:30:25 duke /usr/local/bin/diseqc_switcher[4962]: Selecting '1B'
Mar 13 14:30:25 duke /usr/local/bin/diseqc_switcher[4962]: writing 0x05 [- - - - - 1 - 1]
Mar 13 14:30:30 duke logger: /usr/local/bin/set_wakeup_alarm.sh: mythbackend started by 'auto'
Mar 13 14:30:31 duke vfd_updater[4866]: mythbackend: ACCEPT, MYTH_PROTOCOL_VERSION 40
Mar 13 14:30:31 duke logger: /usr/local/bin/set_wakeup_alarm.sh: setting wakeup alarm the old fashioned way
Mar 13 14:30:31 duke logger: /usr/local/bin/set_wakeup_alarm.sh: setting wakeup alarm to (1268573430) UTC '2010-03-14 13:30:30' (local '2010-03-14 09:30:30')
Mar 13 14:30:31 duke logger: /usr/local/bin/set_wakeup_alarm.sh: echo 2010-03-14 13:30:30 > /proc/acpi/alarm
Mar 13 14:30:31 duke logger: /usr/local/bin/set_wakeup_alarm.sh: RTC alarm readback: 2010-03-14 13:30:30
Mar 13 14:30:31 duke logger: /usr/local/bin/set_wakeup_alarm.sh: UTC time now: 2010-03-13 19:30:31
Mar 13 14:30:31 duke logger: /usr/local/bin/set_wakeup_alarm.sh: next wakeup: 2010-03-14 09:30:30
Mar 13 14:30:31 duke /usr/local/bin/diseqc_switcher[5073]: Selecting '1C'
Mar 13 14:30:31 duke /usr/local/bin/diseqc_switcher[5073]: writing 0x06 [- - - - - 1 1 -]
Mar 13 14:30:33 duke /usr/local/bin/diseqc_switcher[5082]: Selecting '2B'
Mar 13 14:30:33 duke /usr/local/bin/diseqc_switcher[5082]: writing 0x06 [- - - - - 1 1 -]
Mar 13 14:30:36 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. attempting workaround
Mar 13 14:30:37 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. workaround failed
Mar 13 14:32:32 duke /usr/local/bin/diseqc_switcher[5485]: Selecting '2C'
Mar 13 14:32:32 duke /usr/local/bin/diseqc_switcher[5485]: writing 0x0a [- - - - 1 - 1 -]
Mar 13 14:32:34 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. attempting workaround
Mar 13 14:32:34 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. workaround failed
Mar 13 14:34:18 duke ntpd[4180]: synchronized to 10.0.0.2, stratum 3
Mar 13 14:34:19 duke ntpd[4180]: time reset +0.373377 s
Mar 13 14:34:19 duke ntpd[4180]: kernel time sync status change 0001
Mar 13 14:42:16 duke kernel: cx18-0: ================= START STATUS CARD #0 =================
Mar 13 14:42:16 duke kernel: cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600
Mar 13 14:42:16 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Mar 13 14:42:16 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Mar 13 14:42:16 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Mar 13 14:42:16 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Mar 13 14:42:16 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Mar 13 14:42:16 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Mar 13 14:42:16 duke kernel: tveeprom 1-0050: has radio
Mar 13 14:42:16 duke kernel: cx18-0 843: Video signal: present
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected format: NTSC-M
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified standard: NTSC-M
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified video input: Composite 7
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio mode: mono
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio standard: no detected audio standard
Mar 13 14:42:16 duke kernel: cx18-0 843: Audio muted: yes
Mar 13 14:42:16 duke kernel: cx18-0 843: Audio microcontroller: running
Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio standard: automatic detection
Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio system: BTSC
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audio input: Tuner (In8)
Mar 13 14:42:16 duke kernel: cx18-0 843: Preferred audio mode: stereo
Mar 13 14:42:16 duke kernel: cx18-0 gpio-reset-ctrl: GPIO: direction 0x00003001, value 0x00003001
Mar 13 14:42:16 duke kernel: tda9887 2-0043: Data bytes: b=0x14 c=0x30 e=0x44
Mar 13 14:42:16 duke kernel: tuner 2-0061: Tuner mode: analog TV
Mar 13 14:42:16 duke kernel: tuner 2-0061: Frequency: 531.25 MHz
Mar 13 14:42:16 duke kernel: tuner 2-0061: Standard: 0x0000b000
Mar 13 14:42:16 duke kernel: cs5345 1-004c: Input: 1
Mar 13 14:42:16 duke kernel: cs5345 1-004c: Volume: 0 dB
Mar 13 14:42:16 duke kernel: cx18-0: Video Input: Tuner 1
Mar 13 14:42:16 duke kernel: cx18-0: Audio Input: Tuner 1
Mar 13 14:42:16 duke kernel: cx18-0: GPIO: direction 0x00003001, value 0x00003001
Mar 13 14:42:16 duke kernel: cx18-0: Tuner: TV
Mar 13 14:42:16 duke kernel: cx18-0: Stream: MPEG-2 Program Stream
Mar 13 14:42:16 duke kernel: cx18-0: VBI Format: Private packet, IVTV format
Mar 13 14:42:16 duke kernel: cx18-0: Video: 720x480, 30 fps
Mar 13 14:42:16 duke kernel: cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 13000000, Peak 15000000
Mar 13 14:42:16 duke kernel: cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure
Mar 13 14:42:16 duke kernel: cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC
Mar 13 14:42:16 duke kernel: cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0
Mar 13 14:42:16 duke kernel: cx18-0: Temporal Filter: Manual, 8
Mar 13 14:42:16 duke kernel: cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
Mar 13 14:42:16 duke kernel: cx18-0: Status flags: 0x00200001
Mar 13 14:42:16 duke kernel: cx18-0: Stream encoder MPEG: status 0x0000, 0% of 2048 KiB (64 buffers) in use
Mar 13 14:42:16 duke kernel: cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20 buffers) in use
Mar 13 14:42:16 duke kernel: cx18-0: Stream encoder VBI: status 0x0000, 0% of 1015 KiB (20 buffers) in use
Mar 13 14:42:16 duke kernel: cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256 buffers) in use
Mar 13 14:42:16 duke kernel: cx18-0: Read MPEG/VBI: 9176956/20328 bytes
Mar 13 14:42:16 duke kernel: cx18-0: ================== END STATUS CARD #0 ==================
Mar 13 14:43:03 duke ntpd[4180]: synchronized to 10.0.0.2, stratum 3
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-03-16 4:49 ` Mark Lord
@ 2010-03-16 11:11 ` Andy Walls
0 siblings, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-03-16 11:11 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel
On Tue, 2010-03-16 at 00:49 -0400, Mark Lord wrote:
> On 03/15/10 07:51, Andy Walls wrote:
> > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> >> If the audio is not working after modprobe, then simply doing rmmod/modprobe
> >> in a loop (until working audio is achieved) is enough to cure it.
> ..
>
> Well, crap. Tonight our MythTV box proved that assertion to be false.
> The cx18 audio was okay after modprobe, but went bad a few seconds later,
> when mythbackend started up and did the initial channel tuning.
> I have a script that attempts audio input toggling when that happens,
> but it had no effect.
I'll note from your logs that you're capturing using the 48 ksps audio
sampling rate with tuner audio.
I've never had a problem with the AUX_PLL with 48 ksps audio, so I'm
going to assume the AUX_PLL isn't the problem's cause.
> rmmod/modprobe is still the only "solution",
> and it's rather difficult to do those while mythbackend is running.
> >
> > I've got a first WAG at fixing the resets of the audio microcontroller's
> > resets at:
> >
> > http://linuxtv.org/hg/~awalls/cx18-audio
> >
> > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > from 0x810 to 0x9cc, although that may not work either.
> ..
>
> I'll have a go at that, and anything else you can dream up as well.
Here's an easy one:
I see from the log your work-around is failing:
Mar 13 14:30:04 duke logger: /dev/video1: fix_hvr1600_stutter.sh: Pre-initializing
Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: HVR1600/cx18 audio bug, reloading cx18 driver
Mar 13 14:30:09 duke logger: /dev/video1: fix_hvr1600_stutter.sh: rmmod cx18 failed
If a cx18 video device node is open or a cx18-alsa device node is open
you won't be able to unload the cx18 and cx18-alsa modules.
Move the cx18-alsa.ko module out of the way so the kernel can't find it
and load it. Then you never have to worry about something like
pulseaduio keeping it held open.
I see in your log that this is a tuner audio standard autodetection
problem in the A/V digitizer/decoder:
Mar 13 14:42:16 duke kernel: cx18-0 843: Video signal: present
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected format: NTSC-M
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified standard: NTSC-M
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified video input: Composite 7
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio mode: mono
Mar 13 14:42:16 duke kernel: cx18-0 843: Detected audio standard: no detected audio standard
Mar 13 14:42:16 duke kernel: cx18-0 843: Audio muted: yes
Mar 13 14:42:16 duke kernel: cx18-0 843: Audio microcontroller: running
Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio standard: automatic detection
Mar 13 14:42:16 duke kernel: cx18-0 843: Configured audio system: BTSC
Mar 13 14:42:16 duke kernel: cx18-0 843: Specified audio input: Tuner (In8)
Mar 13 14:42:16 duke kernel: cx18-0 843: Preferred audio mode: stereo
The built-in A/V digitzer/decoder's microcontroller won't unmute the
audio until it has detected the standard and set the registers.
I also note the "channel change" (audio input toggling from tuner to
composite in and back?) is having no effect:
Mar 13 14:30:23 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. attempting workaround
Mar 13 14:30:24 duke logger: /dev/video1: channel_change: hit HVR1600/cx18 audio bug.. workaround failed
Which means the audio microcontroller didn't restart it's detection loop
or the detection loop is still failing to find anything. It should
restart on an input toggle.
This means your problem is occuring in the A/V digitizer or before it;
ruling out the APU or the APU firmware, given the current information.
So the areas to concentrate on here are:
a. digitizer audio standard detection microcontroller intitialization,
reset, and restart of the format detection loop
b. TDA9887 analog IF demodulator programming via the CX23418's I2C
master
c. digitizer audio standard detection microcontroller firmware load and
verification (the cx18 driver already does a lot here, but it may be
worth re-inspecting the code)
d. digitizer analog front end and AUX PLL settings for SIF audio (these
should be correct though, so it is unlikely to be the problem)
> But not for a few days -- really really crazy busy at work right now.
Same here. Crazy at work and home. I don't mind waiting.
> I am a Linux kernel developer, so I can handle patches and stuff
> if you have any to offer.
I'll keep that in mind.
> Oh.. attached is a full log from a failure a few nights ago.
> This one has the full card status dump included, which shows
> where the audio is being muted at.
>
> ...
> > With that said, the CX23418 will sometimes have to let register access
> > over the PCI bus fail. For that, I have routines in cx18-io.[ch] to
> > perform retries. You may wish to add a log statement there to watch for
> > retry loops that completely fail.
> ..
>
> I did that a while ago, and they didn't trigger back then.
OK.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-03-15 11:51 ` Andy Walls
2010-03-16 4:49 ` Mark Lord
@ 2010-04-10 22:28 ` Mark Lord
2010-04-10 22:54 ` Andy Walls
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-10 22:28 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel
[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]
On 15/03/10 07:51 AM, Andy Walls wrote:
> On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
>> On 03/02/10 07:40, Andy Walls wrote:
..
>> after updating to the tip of the v4l2-dvb git tree last week,
>> I've been hitting the "no audio" on analog recordings bug much more often.
>>
>> Digging through google, it appears this problem has been around as long
>> as the cx18 driver has existed, with no clear resolution. Lots of people
>> have reported it to you before, and nobody has found a silver bullet fix.
..
> Here are all the potential problem areas I can think of:
>
> 1. A/V digitizer/decoder audio detection firmware load and init. (I've
> added firmware readback verification to try and head this off.)
>
> 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> reset sequencing. (I think the cx18 driver has this wrong ATM.)
>
> 3. APU load and init. (The double load is to fix a DTV TS stream bug on
> every other APU& CPU firmware load sequence. The APU_AI_RESET is to
> fix the audio bitrate problem on first capture after a double firmware
> load.)
>
> 4. AI1 Mux setting failing when switching between the internal A/V
> decoder's I2S output and the external I2S inputs. (I thought I had this
> fixed, but I don't have detailed register specs for that register - so
> maybe not.)
>
> 5. A/V decoder audio clock PLL stops operating due to being programmed
> out of range. (This was a problem for 32 ksps audio a while ago, but
> I'm pretty confident I have it fixed.)
>
> 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
> to a problen Helen Buus reported with cable TV.)
>
> I think #2 is the real problem. I just started to disassmble the
> digitizer firmware 2 nights ago to see if I could get some insight as to
> how to properly reset it.
>
> I've got a first WAG at fixing the resets of the audio microcontroller's
> resets at:
>
> http://linuxtv.org/hg/~awalls/cx18-audio
>
> If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> from 0x810 to 0x9cc, although that may not work either.
..
> Thanks for the troubleshooting and reporting.
..
Back at this again today, after a month away from it -- getting tired
of watching "Survivor" with closed-captioning instead of audio. :)
I pulled your (Andy) repository today, and merged the cx18 audio reset
changes from it into today's tip from v4l-dvb. Patch attached for reference.
So far, so good. I'll keep tabs on it over time, and see if the audio
is stable, or if it still fails once in a while.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
[-- Attachment #2: xx_cx18_audio_resets.patch.v4l --]
[-- Type: text/plain, Size: 6264 bytes --]
--- v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-audio.c 2010-04-05 22:56:43.000000000 -0400
+++ patched/linux/drivers/media/video/cx18/cx18-av-audio.c 2010-03-13 22:06:55.000000000 -0500
@@ -305,14 +305,14 @@
struct cx18_av_state *state = &cx->av_state;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
+
/* stop microcontroller */
v = cx18_av_read(cx, 0x803) & ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
- /* assert soft reset */
- v = cx18_av_read(cx, 0x810) | 0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
/* Mute everything to prevent the PFFT! */
cx18_av_write(cx, 0x8d3, 0x1f);
@@ -330,16 +330,17 @@
set_audclk_freq(cx, state->audclk_freq);
- /* deassert soft reset */
- v = cx18_av_read(cx, 0x810) & ~0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
if (state->aud_input > CX18_AV_AUDIO_SERIAL2) {
+ /* start microcontroller */
/* When the microcontroller detects the
* audio format, it will unmute the lines */
v = cx18_av_read(cx, 0x803) | 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
+
+ /* deassert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) & ~0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
}
static int get_volume(struct cx18 *cx)
@@ -449,12 +450,13 @@
* changes to the mute register. */
v = cx18_av_read(cx, 0x803);
if (mute) {
- /* disable microcontroller */
+ /* stop microcontroller */
v &= ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
+ /* mute all of Path 1 */
cx18_av_write(cx, 0x8d3, 0x1f);
} else {
- /* enable microcontroller */
+ /* start microcontroller */
v |= 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
@@ -471,22 +473,29 @@
int retval;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x1;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
+
if (state->aud_input > CX18_AV_AUDIO_SERIAL2) {
+ /* stop microcontroller */
v = cx18_av_read(cx, 0x803) & ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
+ /* mute all of Path 1 */
cx18_av_write(cx, 0x8d3, 0x1f);
}
- v = cx18_av_read(cx, 0x810) | 0x1;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
retval = set_audclk_freq(cx, freq);
- v = cx18_av_read(cx, 0x810) & ~0x1;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
if (state->aud_input > CX18_AV_AUDIO_SERIAL2) {
+ /* start microcontroller */
v = cx18_av_read(cx, 0x803) | 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
+
+ /* deassert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) & ~0x1;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
return retval;
}
diff -u --recursive --new-file --exclude='.*' --exclude='*.[osa]' --exclude=System.map --exclude='*.orig' --exclude='*.lds' --exclude='*.symvers' --exclude='*.mod.c' --exclude='*.ko' v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-core.c patched/linux/drivers/media/video/cx18/cx18-av-core.c
--- v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-core.c 2010-04-05 22:56:43.000000000 -0400
+++ patched/linux/drivers/media/video/cx18/cx18-av-core.c 2010-04-10 17:10:13.618719139 -0400
@@ -525,6 +525,10 @@
cx18_av_and_or(cx, 0x401, ~0x60, 0);
cx18_av_and_or(cx, 0x401, ~0x60, 0x60);
+ /* assert soft reset of audio */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
+
if (std & V4L2_STD_525_60) {
if (std == V4L2_STD_NTSC_M_JP) {
/* Japan uses EIAJ audio standard */
@@ -549,14 +553,9 @@
cx18_av_write_expect(cx, 0x80b, 0x03, 0x03, 0x3f);
}
- v = cx18_av_read(cx, 0x803);
- if (v & 0x10) {
- /* restart audio decoder microcontroller */
- v &= ~0x10;
- cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
- v |= 0x10;
- cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
- }
+ /* deassert soft reset of audio */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) & ~0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
}
static int cx18_av_s_frequency(struct v4l2_subdev *sd,
diff -u --recursive --new-file --exclude='.*' --exclude='*.[osa]' --exclude=System.map --exclude='*.orig' --exclude='*.lds' --exclude='*.symvers' --exclude='*.mod.c' --exclude='*.ko' v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-core.h patched/linux/drivers/media/video/cx18/cx18-av-core.h
--- v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-core.h 2010-04-05 22:56:43.000000000 -0400
+++ patched/linux/drivers/media/video/cx18/cx18-av-core.h 2010-04-10 17:09:26.532890773 -0400
@@ -246,6 +246,7 @@
#define CXADEC_DW8051_INT 0x80C
#define CXADEC_GENERAL_CTL 0x810
+#define CXADEC_AUDIO_SOFT_RESET 0x810 /* 0x810 or 0x9cc ??? */
#define CXADEC_AAGC_CTL 0x814
#define CXADEC_IF_SRC_CTL 0x818
#define CXADEC_ANLOG_DEMOD_CTL 0x81C
diff -u --recursive --new-file --exclude='.*' --exclude='*.[osa]' --exclude=System.map --exclude='*.orig' --exclude='*.lds' --exclude='*.symvers' --exclude='*.mod.c' --exclude='*.ko' v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-firmware.c patched/linux/drivers/media/video/cx18/cx18-av-firmware.c
--- v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-firmware.c 2010-04-05 22:56:43.000000000 -0400
+++ patched/linux/drivers/media/video/cx18/cx18-av-firmware.c 2010-03-13 22:06:55.000000000 -0500
@@ -142,14 +142,20 @@
return -EIO;
}
+ /* Disable firmware upload, keeping the 8051 in reset */
cx18_av_write4_expect(cx, CXADEC_DL_CTL,
0x03000000 | fw->size, 0x03000000, 0x13000000);
CX18_INFO_DEV(sd, "loaded %s firmware (%d bytes)\n", FWFILE, size);
- if (cx18_av_verifyfw(cx, fw) == 0)
+ if (cx18_av_verifyfw(cx, fw) == 0) {
+ /* deassert soft reset */
+ v = cx18_av_read4(cx, CXADEC_AUDIO_SOFT_RESET) & ~0x01;
+ cx18_av_write4_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
+ /* deassert 8051 reset */
cx18_av_write4_expect(cx, CXADEC_DL_CTL,
0x13000000 | fw->size, 0x13000000, 0x13000000);
+ }
/* Output to the 416 */
cx18_av_and_or4(cx, CXADEC_PIN_CTRL1, ~0, 0x78000);
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-10 22:28 ` Mark Lord
@ 2010-04-10 22:54 ` Andy Walls
2010-04-11 0:58 ` Andy Walls
2010-04-11 3:21 ` Mark Lord
0 siblings, 2 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-10 22:54 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel
On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> On 15/03/10 07:51 AM, Andy Walls wrote:
> > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> >> On 03/02/10 07:40, Andy Walls wrote:
> ..
> >> after updating to the tip of the v4l2-dvb git tree last week,
> >> I've been hitting the "no audio" on analog recordings bug much more often.
> >>
> >> Digging through google, it appears this problem has been around as long
> >> as the cx18 driver has existed, with no clear resolution. Lots of people
> >> have reported it to you before, and nobody has found a silver bullet fix.
> ..
> > Here are all the potential problem areas I can think of:
> >
> > 1. A/V digitizer/decoder audio detection firmware load and init. (I've
> > added firmware readback verification to try and head this off.)
> >
> > 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> > reset sequencing. (I think the cx18 driver has this wrong ATM.)
> >
> > 3. APU load and init. (The double load is to fix a DTV TS stream bug on
> > every other APU& CPU firmware load sequence. The APU_AI_RESET is to
> > fix the audio bitrate problem on first capture after a double firmware
> > load.)
> >
> > 4. AI1 Mux setting failing when switching between the internal A/V
> > decoder's I2S output and the external I2S inputs. (I thought I had this
> > fixed, but I don't have detailed register specs for that register - so
> > maybe not.)
> >
> > 5. A/V decoder audio clock PLL stops operating due to being programmed
> > out of range. (This was a problem for 32 ksps audio a while ago, but
> > I'm pretty confident I have it fixed.)
> >
> > 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
> > to a problen Helen Buus reported with cable TV.)
> >
> > I think #2 is the real problem. I just started to disassmble the
> > digitizer firmware 2 nights ago to see if I could get some insight as to
> > how to properly reset it.
> >
> > I've got a first WAG at fixing the resets of the audio microcontroller's
> > resets at:
> >
> > http://linuxtv.org/hg/~awalls/cx18-audio
> >
> > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > from 0x810 to 0x9cc, although that may not work either.
> ..
> > Thanks for the troubleshooting and reporting.
> ..
>
> Back at this again today, after a month away from it -- getting tired
> of watching "Survivor" with closed-captioning instead of audio. :)
>
> I pulled your (Andy) repository today, and merged the cx18 audio reset
> changes from it into today's tip from v4l-dvb. Patch attached for reference.
>
> So far, so good. I'll keep tabs on it over time, and see if the audio
> is stable, or if it still fails once in a while.
Hmmm. Darren's having problems (loss of video/black screen) with my
patches under my cx18-audio repo, but I'm not quite convinced he doesn't
have some other PCI bus problem either.
Anyway, my plan now is this:
1. on cx18-av-core.c:input_change()
a. set register 0x808 for audio autodetection
b. restart the format detection loop
c. set or reset a 1.5 second timeout
2. after the timer expires, if no audio standard was detected,
a. force the audio standard by programming register 0x808
(e.g. BTSC for NTSC-M)
b. restart the format detection loop so the micrcontroller will
do the unmute when it detects audio
Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-10 22:54 ` Andy Walls
@ 2010-04-11 0:58 ` Andy Walls
2010-04-11 3:21 ` Mark Lord
1 sibling, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-11 0:58 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel
On Sat, 2010-04-10 at 18:54 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 18:28 -0400, Mark Lord wrote:
> > On 15/03/10 07:51 AM, Andy Walls wrote:
> > > On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
> > >> On 03/02/10 07:40, Andy Walls wrote:
> > ..
> > >> after updating to the tip of the v4l2-dvb git tree last week,
> > >> I've been hitting the "no audio" on analog recordings bug much more often.
> > >>
> > >> Digging through google, it appears this problem has been around as long
> > >> as the cx18 driver has existed, with no clear resolution. Lots of people
> > >> have reported it to you before, and nobody has found a silver bullet fix.
> > ..
> > > Here are all the potential problem areas I can think of:
> > >
> > > 1. A/V digitizer/decoder audio detection firmware load and init. (I've
> > > added firmware readback verification to try and head this off.)
> > >
> > > 2. A/V digitizer decoder audio microcontroller hard reset and "soft"
> > > reset sequencing. (I think the cx18 driver has this wrong ATM.)
> > >
> > > 3. APU load and init. (The double load is to fix a DTV TS stream bug on
> > > every other APU& CPU firmware load sequence. The APU_AI_RESET is to
> > > fix the audio bitrate problem on first capture after a double firmware
> > > load.)
> > >
> > > 4. AI1 Mux setting failing when switching between the internal A/V
> > > decoder's I2S output and the external I2S inputs. (I thought I had this
> > > fixed, but I don't have detailed register specs for that register - so
> > > maybe not.)
> > >
> > > 5. A/V decoder audio clock PLL stops operating due to being programmed
> > > out of range. (This was a problem for 32 ksps audio a while ago, but
> > > I'm pretty confident I have it fixed.)
> > >
> > > 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
> > > to a problen Helen Buus reported with cable TV.)
> > >
> > > I think #2 is the real problem. I just started to disassmble the
> > > digitizer firmware 2 nights ago to see if I could get some insight as to
> > > how to properly reset it.
> > >
> > > I've got a first WAG at fixing the resets of the audio microcontroller's
> > > resets at:
> > >
> > > http://linuxtv.org/hg/~awalls/cx18-audio
> > >
> > > If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
> > > from 0x810 to 0x9cc, although that may not work either.
> > ..
> > > Thanks for the troubleshooting and reporting.
> > ..
> >
> > Back at this again today, after a month away from it -- getting tired
> > of watching "Survivor" with closed-captioning instead of audio. :)
> >
> > I pulled your (Andy) repository today, and merged the cx18 audio reset
> > changes from it into today's tip from v4l-dvb. Patch attached for reference.
> >
> > So far, so good. I'll keep tabs on it over time, and see if the audio
> > is stable, or if it still fails once in a while.
>
> Hmmm. Darren's having problems (loss of video/black screen) with my
> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> have some other PCI bus problem either.
>
> Anyway, my plan now is this:
>
> 1. on cx18-av-core.c:input_change()
> a. set register 0x808 for audio autodetection
> b. restart the format detection loop
> c. set or reset a 1.5 second timeout
>
> 2. after the timer expires, if no audio standard was detected,
> a. force the audio standard by programming register 0x808
> (e.g. BTSC for NTSC-M)
> b. restart the format detection loop so the micrcontroller will
> do the unmute when it detects audio
>
>
>
> Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
Hey, I just found an OTA analog broadcast on channel 23! I even can
reproduce the problem of the audio microcontroller not detecting the
audio standard (shoot it just kicked in and figured it out).
Anyway this will help me turn around something.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-10 22:54 ` Andy Walls
2010-04-11 0:58 ` Andy Walls
@ 2010-04-11 3:21 ` Mark Lord
2010-04-11 4:56 ` Andy Walls
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-11 3:21 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel
On 10/04/10 06:54 PM, Andy Walls wrote:
>
> Hmmm. Darren's having problems (loss of video/black screen) with my
> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> have some other PCI bus problem either.
>
> Anyway, my plan now is this:
>
> 1. on cx18-av-core.c:input_change()
> a. set register 0x808 for audio autodetection
> b. restart the format detection loop
> c. set or reset a 1.5 second timeout
>
> 2. after the timer expires, if no audio standard was detected,
> a. force the audio standard by programming register 0x808
> (e.g. BTSC for NTSC-M)
> b. restart the format detection loop so the micrcontroller will
> do the unmute when it detects audio
>
> Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
..
I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
Cheers!
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-11 3:21 ` Mark Lord
@ 2010-04-11 4:56 ` Andy Walls
2010-04-11 5:03 ` [ivtv-devel] " Andy Walls
` (2 more replies)
0 siblings, 3 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-11 4:56 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> On 10/04/10 06:54 PM, Andy Walls wrote:
> >
> > Hmmm. Darren's having problems (loss of video/black screen) with my
> > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > have some other PCI bus problem either.
> >
> > Anyway, my plan now is this:
> >
> > 1. on cx18-av-core.c:input_change()
> > a. set register 0x808 for audio autodetection
> > b. restart the format detection loop
> > c. set or reset a 1.5 second timeout
> >
> > 2. after the timer expires, if no audio standard was detected,
> > a. force the audio standard by programming register 0x808
> > (e.g. BTSC for NTSC-M)
> > b. restart the format detection loop so the micrcontroller will
> > do the unmute when it detects audio
> >
> > Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
> ..
>
> I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
Try this:
http://linuxtv.org/hg/~awalls/cx18-audio2
this waits 1.5 seconds after an input/channel change to see if the audio
standard micrcontroller can detect the standard. If it can't, the
driver tells it to try a fallback detection. Right now, only the NTSC-M
fallback detection is set to force a mode (i.e. BTSC), all the others
"fall back" to their same auto-detection.
Some annoyances with the fallback to a forced audio standard, mode, and
format:
1. Static gets unmuted on stations with no signal. :(
2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
+R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
the fallback setting magic number (0x1101) in
cx18-av-core.c:input_change().
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [ivtv-devel] cx18: "missing audio" for analog recordings
2010-04-11 4:56 ` Andy Walls
@ 2010-04-11 5:03 ` Andy Walls
2010-04-11 11:47 ` Andy Walls
2010-04-11 19:49 ` Darren Blaber
2 siblings, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-11 5:03 UTC (permalink / raw)
To: Discussion list for development of the IVTV driver
Cc: Mark Lord, Darren Blaber, linux-media
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm. Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > > have some other PCI bus problem either.
> > >
> > > Anyway, my plan now is this:
> > >
> > > 1. on cx18-av-core.c:input_change()
> > > a. set register 0x808 for audio autodetection
> > > b. restart the format detection loop
> > > c. set or reset a 1.5 second timeout
> > >
> > > 2. after the timer expires, if no audio standard was detected,
> > > a. force the audio standard by programming register 0x808
> > > (e.g. BTSC for NTSC-M)
> > > b. restart the format detection loop so the micrcontroller will
> > > do the unmute when it detects audio
> > >
> > > Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
> > ..
> >
> > I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
>
>
> Try this:
>
> http://linuxtv.org/hg/~awalls/cx18-audio2
>
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard. If it can't, the
> driver tells it to try a fallback detection. Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
>
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
>
> 1. Static gets unmuted on stations with no signal. :(
>
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
^^^
Bah, wrong byte. That should have been the LSN of the MSB of the 0x1101
number. I'm too tired.
Regards,
Andy
> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().
>
>
> Regards,
> Andy
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-11 4:56 ` Andy Walls
2010-04-11 5:03 ` [ivtv-devel] " Andy Walls
@ 2010-04-11 11:47 ` Andy Walls
2010-04-11 13:24 ` Mark Lord
2010-04-11 19:49 ` Darren Blaber
2 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-11 11:47 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
> > On 10/04/10 06:54 PM, Andy Walls wrote:
> > >
> > > Hmmm. Darren's having problems (loss of video/black screen) with my
> > > patches under my cx18-audio repo, but I'm not quite convinced he doesn't
> > > have some other PCI bus problem either.
> > >
> > > Anyway, my plan now is this:
> > >
> > > 1. on cx18-av-core.c:input_change()
> > > a. set register 0x808 for audio autodetection
> > > b. restart the format detection loop
> > > c. set or reset a 1.5 second timeout
> > >
> > > 2. after the timer expires, if no audio standard was detected,
> > > a. force the audio standard by programming register 0x808
> > > (e.g. BTSC for NTSC-M)
> > > b. restart the format detection loop so the micrcontroller will
> > > do the unmute when it detects audio
> > >
> > > Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
> > ..
> >
> > I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
>
>
> Try this:
>
> http://linuxtv.org/hg/~awalls/cx18-audio2
>
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard. If it can't, the
> driver tells it to try a fallback detection. Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
>
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
>
> 1. Static gets unmuted on stations with no signal. :(
>
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().
I fixed #2. I had a bug so the first patch didn't properly set the
fallback audio mode.
I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
into consideration that we might be using a forced audio mode vs. auto
detection. However, that is not essential for testing; this should be
good enough for testing.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-11 11:47 ` Andy Walls
@ 2010-04-11 13:24 ` Mark Lord
2010-04-11 19:01 ` Andy Walls
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-11 13:24 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 11/04/10 07:47 AM, Andy Walls wrote:
> On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
>> Try this:
>>
>> http://linuxtv.org/hg/~awalls/cx18-audio2
>>
>> this waits 1.5 seconds after an input/channel change to see if the audio
>> standard micrcontroller can detect the standard. If it can't, the
>> driver tells it to try a fallback detection. Right now, only the NTSC-M
>> fallback detection is set to force a mode (i.e. BTSC), all the others
>> "fall back" to their same auto-detection.
>>
>> Some annoyances with the fallback to a forced audio standard, mode, and
>> format:
>>
>> 1. Static gets unmuted on stations with no signal. :(
>>
>> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
>> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
>> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
>> the fallback setting magic number (0x1101) in
>> cx18-av-core.c:input_change().
>
> I fixed #2. I had a bug so the first patch didn't properly set the
> fallback audio mode.
>
> I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
> into consideration that we might be using a forced audio mode vs. auto
> detection. However, that is not essential for testing; this should be
> good enough for testing.
..
Those new patches don't want to coexist with the earlier hard/soft reset
changes. There's always a chance that *both* things might be needed,
and the reset stuff didn't look obviously "bad". Why dropped?
Thanks
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-11 13:24 ` Mark Lord
@ 2010-04-11 19:01 ` Andy Walls
2010-04-11 20:52 ` Mark Lord
2010-04-12 20:08 ` Mark Lord
0 siblings, 2 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-11 19:01 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Sun, 2010-04-11 at 09:24 -0400, Mark Lord wrote:
> On 11/04/10 07:47 AM, Andy Walls wrote:
> > On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote:
> >> Try this:
> >>
> >> http://linuxtv.org/hg/~awalls/cx18-audio2
> >>
> >> this waits 1.5 seconds after an input/channel change to see if the audio
> >> standard micrcontroller can detect the standard. If it can't, the
> >> driver tells it to try a fallback detection. Right now, only the NTSC-M
> >> fallback detection is set to force a mode (i.e. BTSC), all the others
> >> "fall back" to their same auto-detection.
> >>
> >> Some annoyances with the fallback to a forced audio standard, mode, and
> >> format:
> >>
> >> 1. Static gets unmuted on stations with no signal. :(
> >>
> >> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> >> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> >> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
> >> the fallback setting magic number (0x1101) in
> >> cx18-av-core.c:input_change().
> >
> > I fixed #2. I had a bug so the first patch didn't properly set the
> > fallback audio mode.
> >
> > I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take
> > into consideration that we might be using a forced audio mode vs. auto
> > detection. However, that is not essential for testing; this should be
> > good enough for testing.
> ..
>
> Those new patches don't want to coexist with the earlier hard/soft reset
> changes. There's always a chance that *both* things might be needed,
> and the reset stuff didn't look obviously "bad". Why dropped?
Because...
1. Darren had problems with a black video screen with them and so did I
(once I found an analog OTA station).
2. I also suspect those previous patches were not performing the format
detection loop reset properly.
3. One could possibly reset the microcontroller all day long without
auto-detection ever working. Also autodetection will auto-mute, and
restart the detection loop, if it thinks the audio carrier went away.
4. Falling back to a known used audio standard, format, and mode is
guaranteed to work. I guess it can be a problem in some region for some
video stanadrd where one just can't know what each broadcaster is using.
For NTSC-M this is not the case: BTSC at 4.5 MHz is always used.
5. I don't understand the exact failure mode of why the microcontroller
is failing to detect the audio standard, so any other fix that doesn't
explicitly set a standard will likely be unreliable. I'm tired of audio
detection fixes with unpredictable outcomes based on variations in cable
and OTA signal sources. Forcing the microcontroller to a particular
standard, after autodetection fails, gives a deterministic outcome.
(BTW, we really do need the microcontroller to do some work for us. No
documentation accessable to me has enough detail to allow one to fully
program the audio decoder portion of the A/V core. We have to rely on
the microntroller firmware to set up some of the undocumented or
unexplained registers.)
I can always throw the other reset patches back in I guess, but this
latest patch set should dominate the behavior of the microcontroller (if
I didn't miss something because I was tired).
I would be interested in hearing how frequent these patches show "forced
audio standard" for you:
[ 389.388200] cx18-0 843: Detected format: NTSC-M
[ 389.388204] cx18-0 843: Specified standard: NTSC-M
[ 389.388208] cx18-0 843: Specified video input: Composite 7
[ 389.388212] cx18-0 843: Specified audioclock freq: 48000 Hz
[ 389.388232] cx18-0 843: Detected audio mode: forced mode
[ 389.388237] cx18-0 843: Detected audio standard: forced audio standard
[ 389.388241] cx18-0 843: Audio muted: no
[ 389.388245] cx18-0 843: Audio microcontroller: running
[ 389.388249] cx18-0 843: Configured audio standard: BTSC
[ 389.388253] cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B)
[ 389.388257] cx18-0 843: Specified audio input: Tuner (In8)
[ 389.388261] cx18-0 843: Preferred audio mode: stereo
meaning that the fallback audio settings were used because auto
detection failed.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-11 4:56 ` Andy Walls
2010-04-11 5:03 ` [ivtv-devel] " Andy Walls
2010-04-11 11:47 ` Andy Walls
@ 2010-04-11 19:49 ` Darren Blaber
2 siblings, 0 replies; 45+ messages in thread
From: Darren Blaber @ 2010-04-11 19:49 UTC (permalink / raw)
To: Andy Walls; +Cc: Mark Lord, Hans Verkuil, linux-media, ivtv-devel
Andy Walls wrote:
> On Sat, 2010-04-10 at 23:21 -0400, Mark Lord wrote:
>
>> On 10/04/10 06:54 PM, Andy Walls wrote:
>>
>>> Hmmm. Darren's having problems (loss of video/black screen) with my
>>> patches under my cx18-audio repo, but I'm not quite convinced he doesn't
>>> have some other PCI bus problem either.
>>>
>>> Anyway, my plan now is this:
>>>
>>> 1. on cx18-av-core.c:input_change()
>>> a. set register 0x808 for audio autodetection
>>> b. restart the format detection loop
>>> c. set or reset a 1.5 second timeout
>>>
>>> 2. after the timer expires, if no audio standard was detected,
>>> a. force the audio standard by programming register 0x808
>>> (e.g. BTSC for NTSC-M)
>>> b. restart the format detection loop so the micrcontroller will
>>> do the unmute when it detects audio
>>>
>>> Darren is in NTSC-M/BTSC land. What TV standard are you dealing with?
>>>
>> ..
>>
>> I'm in Canada, using the tuner for over-the-air NTSC broadcasts.
>>
>
>
> Try this:
>
> http://linuxtv.org/hg/~awalls/cx18-audio2
>
> this waits 1.5 seconds after an input/channel change to see if the audio
> standard micrcontroller can detect the standard. If it can't, the
> driver tells it to try a fallback detection. Right now, only the NTSC-M
> fallback detection is set to force a mode (i.e. BTSC), all the others
> "fall back" to their same auto-detection.
>
> Some annoyances with the fallback to a forced audio standard, mode, and
> format:
>
> 1. Static gets unmuted on stations with no signal. :(
>
> 2. I can't seem to force mode "MONO2 (LANGUAGE B)". I'm guessing the
> microcontroller keeps setting it back down to "MONO1 (LANGUAGE A/Mono L
> +R channel for BTSC, EIAJ, A2)" Feel free to experiment with the LSB of
> the fallback setting magic number (0x1101) in
> cx18-av-core.c:input_change().
>
>
> Regards,
> Andy
>
>
So far, it seems fine, no black screens, and audio seems to be fine.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-11 19:01 ` Andy Walls
@ 2010-04-11 20:52 ` Mark Lord
2010-04-12 20:08 ` Mark Lord
1 sibling, 0 replies; 45+ messages in thread
From: Mark Lord @ 2010-04-11 20:52 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 11/04/10 03:01 PM, Andy Walls wrote:
..
> I can always throw the other reset patches back in I guess, but this
> latest patch set should dominate the behavior of the microcontroller (if
> I didn't miss something because I was tired).
>
> I would be interested in hearing how frequent these patches show "forced
> audio standard" for you:
..
Thanks. Will do.
I've added a printk() to the fallback path, so that it will show up in
the syslog whenever the fallback is used.
So far, no problem. But prior to now, the HVR-1600 regularly failed about
once every 2-3 days according to the script I have which tests for the issue.
On a similar note, while checking the logs last evening, I discovered that
the muted episode of "Survivor Heros & Villians" (two weeks ago) was actually
recorded on the _PVR-250_ card. With no audio. This has happened before,
though rarely -- perhaps once every 3-6 months or so.
I wonder if a similar fix/workaround could be appropriate for that card as well?
In the mean while, I guess I'll update my scripts to test/report for that
one as well as the cx18/hvr1600.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-11 19:01 ` Andy Walls
2010-04-11 20:52 ` Mark Lord
@ 2010-04-12 20:08 ` Mark Lord
2010-04-12 21:17 ` Andy Walls
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-12 20:08 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 11/04/10 03:01 PM, Andy Walls wrote:
>
> I would be interested in hearing how frequent these patches show "forced
> audio standard" for you:
..
The MythTV box here has many tuners, most of which are not used every power-up.
But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel
each time the system boots up to record/play something.
So.. in the logs from the other night, there are some "fallback" messages.
But since the HVR1600 was not actually used to record anything,
I don't know for sure if the audio fallback actually "worked",
other than that v4l-ctl reported non-muted audio afterwards.
The abridged syslog is below.
Something I find interesting, is that it reported having to
fallback twice on this boot (once during the initial anti-stutter tune,
and again when mythbackend started up).
I wonder if this means that once the audio bug is present,
it remains present until the next time the driver is loaded/unloaded.
Which matches previous observations.
The fallback (hopefully) works around this, but there's still a bug
somewhere that is preventing the audio from working without the fallback.
Cheers
Mark Lord
* * * *
Apr 12 03:56:55 duke kernel: cx18: Start initialization, version 1.4.0
Apr 12 03:56:55 duke kernel: cx18-0: Initializing card 0
Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge card
Apr 12 03:56:55 duke kernel: cx18 0000:05:03.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
Apr 12 03:56:55 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2)
Apr 12 03:56:55 duke kernel: cx18-0: cx23418 revision 01010000 (B)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Apr 12 03:56:55 duke kernel: tveeprom 1-0050: has radio
Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600
Apr 12 03:56:55 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported
Apr 12 03:56:55 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
Apr 12 03:56:55 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1)
Apr 12 03:56:55 duke kernel: tda9887 2-0043: creating new instance
Apr 12 03:56:55 duke kernel: tda9887 2-0043: tda988[5/6/7] found
Apr 12 03:56:55 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
Apr 12 03:56:55 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: creating new instance
Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB)
Apr 12 03:56:55 duke kernel: DVB: registering new adapter (cx18)
Apr 12 03:56:55 duke kernel: MXL5005S: Attached at address 0x63
Apr 12 03:56:55 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
Apr 12 03:56:55 duke kernel: cx18-0: DVB Frontend registered
Apr 12 03:56:55 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB)
Apr 12 03:56:55 duke kernel: cx18-0: Registered device radio1 for encoder radio
Apr 12 03:56:55 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600
Apr 12 03:56:55 duke kernel: cx18: End initialization
Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
Apr 12 03:56:58 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
Apr 12 03:56:58 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-cpu.fw
Apr 12 03:56:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-apu.fw
Apr 12 03:56:59 duke kernel: cx18 0000:05:03.0: firmware: requesting v4l-cx23418-dig.fw
Apr 12 03:56:59 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
Apr 12 03:56:59 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
Apr 12 03:57:00 duke kernel: ivtv 0000:05:02.0: firmware: requesting v4l-cx2341x-enc.fw
Apr 12 03:57:00 duke kernel: ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
Apr 12 03:57:00 duke kernel: ivtv0: Encoder revision: 0x02060039
Apr 12 03:57:01 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: reconfiguring driver
Apr 12 03:57:01 duke kernel: cx18_av_aud_detect_work: cx18/hvr1600 audio bug: doing fallback detection <-------------------
Apr 12 03:57:01 duke kernel: input: i2c IR (Hauppauge) as /class/input/input5
Apr 12 03:57:01 duke kernel: irrcv0: i2c IR (Hauppauge) as /class/irrcv/irrcv0
Apr 12 03:57:01 duke kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0]
Apr 12 03:57:01 duke logger: /usr/local/bin/enable_hauppauge_remote.sh: waiting for device(s)
Apr 12 03:57:02 duke logger[4238]: /usr/bin/input-kbd -f /usr/local/bin/hauppauge_remote.conf 5
Apr 12 03:57:02 duke logger: /dev/video1: fix_hvr1600_audio.sh: Pre-initializing
Apr 12 03:57:04 duke logger: /dev/video1: fix_hvr1600_audio.sh: HVR1600/cx18 audio ok.
Apr 12 03:57:04 duke nanny.mythbackend[4263]: mythbackend[4265] started
Apr 12 03:57:20 duke /usr/local/bin/antenna_switcher[4828]: Selecting '2C' (hvr1600)
Apr 12 03:57:20 duke /usr/local/bin/antenna_switcher[4828]: writing 0x08 [- - - - 1 - - -]
Apr 12 03:57:22 duke logger: channel_change: /dev/video1: cx18/hvr1600 audio ok.
Apr 12 03:57:22 duke kernel: cx18_av_aud_detect_work: cx18/hvr1600 audio bug: doing fallback detection <-------------------
Apr 12 03:57:22 duke /usr/local/bin/antenna_switcher[4858]: Selecting '1D' (pvr250)
Apr 12 03:57:22 duke /usr/local/bin/antenna_switcher[4858]: writing 0x0b [- - - - 1 - 1 1]
Apr 12 03:57:23 duke logger: channel_change: /dev/video0: ivtv/pvr250 audio ok.
Apr 12 03:59:31 duke /usr/local/bin/antenna_switcher[5603]: Selecting '1C' (pvr250)
Apr 12 03:59:31 duke /usr/local/bin/antenna_switcher[5603]: writing 0x0a [- - - - 1 - 1 -]
Apr 12 03:59:32 duke logger: channel_change: /dev/video0: ivtv/pvr250 audio ok.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-12 20:08 ` Mark Lord
@ 2010-04-12 21:17 ` Andy Walls
2010-04-13 2:22 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-12 21:17 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
> On 11/04/10 03:01 PM, Andy Walls wrote:
> >
> > I would be interested in hearing how frequent these patches show "forced
> > audio standard" for you:
> ..
>
> The MythTV box here has many tuners, most of which are not used every power-up.
> But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel
> each time the system boots up to record/play something.
>
> So.. in the logs from the other night, there are some "fallback" messages.
> But since the HVR1600 was not actually used to record anything,
> I don't know for sure if the audio fallback actually "worked",
> other than that v4l-ctl reported non-muted audio afterwards.
Forcing BTSC for NTSC-M will always work. You should hear something.
> The abridged syslog is below.
> Something I find interesting, is that it reported having to
> fallback twice on this boot (once during the initial anti-stutter tune,
BTW you shouldn't need to do that anymore. The audio "stutter" was a
CX23418 APU and CPU firmware state problem about audio sampling rate
that the newer versions of the driver handle by loading those firmwares
twice and calling the APU firmware's APU_RESET_AI call. The first
analog capture should never "stutter" anymore.
> and again when mythbackend started up).
Whenever cx18_av_core.c:input_change() is called, the audio
microcontroller audio standard autodetection is restarted. This
function gets called at least once for each of these ioctl()s:
VIDIOC_S_STD
VIDIOC_S_FREQUENCY
VIDIOC_S_INPUT
and probably for some other ioctl()s as well. VIDIOC_S_FREQUENCY is
called for every channel tuning operation. Your logs are probably
showing the effects of calls to S_INPUT and S_FREQUENCY. You can
modprobe cx18 debug=0x10
to log cx18 ioctl calls if you are interested.
> I wonder if this means that once the audio bug is present,
> it remains present until the next time the driver is loaded/unloaded.
If we're talking about audio standard auto detection not working, I'll
guess "no". Too much really depends on the input signal quality.
Auto detection working requires the analog tuner assembly to output a
stable SIF signal (from the broadcaster) upon which the CX23418 A/V
decoder will operate.
The TV channels needs to have an audio signal. If you tune to a channel
with no signal, audio autodetection will always fail and fallback to the
forced mode. The cx18 driver defaults to channel 4 on startup.
> Which matches previous observations.
> The fallback (hopefully) works around this, but there's still a bug
> somewhere that is preventing the audio from working without the fallback.
A way to test your hypothesis is to run a script that repeatedly tunes
among known analog stations, perhaps with ivtv-tune, and then check the
results of audio detection, perhaps with v4l2-ctl, after a few seconds.
You could also save a short segment of PCM audio from /dev/video24 (or
whatever) that you can check later with your own ear.
My hypothesis is that once BTSC is forced once, autodetection of BTSC
will more likely work well for a good number of channel changes
thereafter.
I do not have enough analog stations to run a test.
Regards,
Andy
> Cheers
>
> Mark Lord
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-12 21:17 ` Andy Walls
@ 2010-04-13 2:22 ` Mark Lord
2010-04-13 2:30 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-13 2:22 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 12/04/10 05:17 PM, Andy Walls wrote:
> On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote:
..
>> I wonder if this means that once the audio bug is present,
>> it remains present until the next time the driver is loaded/unloaded.
>
>> Which matches previous observations.
>> The fallback (hopefully) works around this, but there's still a bug
>> somewhere that is preventing the audio from working without the fallback.
..
Okay, the "fallback" works -- recordings made with it do have good audio.
And.. my hypothesis appears to be true thus far: once the audio fails,
requiring the fallback, it stays failed until the driver is reloaded.
Every subsequent recording made (after a "fallback") also experiences the fallback.
This is with a good channel, with good audio. Subsequent recordings using the
exact same channel.
Weird, eh. I wonder how to discover the real cause?
Good workaround, though! Thanks.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-13 2:22 ` Mark Lord
@ 2010-04-13 2:30 ` Mark Lord
2010-04-13 2:34 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-13 2:30 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 12/04/10 10:22 PM, Mark Lord wrote:
..
> Okay, the "fallback" works -- recordings made with it do have good audio.
>
> And.. my hypothesis appears to be true thus far: once the audio fails,
> requiring the fallback, it stays failed until the driver is reloaded.
>
> Every subsequent recording made (after a "fallback") also experiences the fallback.
> This is with a good channel, with good audio. Subsequent recordings
> using the exact same channel.
..
Mmm.. further to that: the problem went away as soon as I told
it to tune to a different channel. No more fallbacks (for now).
It can now even retune the original channel without fallbacks.
So.. tuning to a new channel appears to fix whatever the bad state was
that was triggering the fallbacks. Based on my sample of one, anyway. ;)
Now that it is behaving again, I cannot poke further until the next time
I'm lucky enough to be around when it fails.
> Weird, eh. I wonder how to discover the real cause?
> Good workaround, though! Thanks.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-13 2:30 ` Mark Lord
@ 2010-04-13 2:34 ` Mark Lord
2010-04-13 10:35 ` Andy Walls
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-13 2:34 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 12/04/10 10:30 PM, Mark Lord wrote:
..
> Mmm.. further to that: the problem went away as soon as I told
> it to tune to a different channel. No more fallbacks (for now).
> It can now even retune the original channel without fallbacks.
>
> So.. tuning to a new channel appears to fix whatever the bad state was
> that was triggering the fallbacks. Based on my sample of one, anyway. ;)
..
Nope.. what that second email should have said, was
Changing channels in LiveTV, no fallbacks required
because the audio is already working from the initial fallback.
As soon as I quit from LiveTV, the next recording still needed
a new fallback. So the chip is still in some weird state where
auto-audio will continue to fail until I reload the module.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-13 2:34 ` Mark Lord
@ 2010-04-13 10:35 ` Andy Walls
2010-04-13 12:42 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-13 10:35 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> On 12/04/10 10:30 PM, Mark Lord wrote:
> ..
> > Mmm.. further to that: the problem went away as soon as I told
> > it to tune to a different channel. No more fallbacks (for now).
> > It can now even retune the original channel without fallbacks.
> >
> > So.. tuning to a new channel appears to fix whatever the bad state was
> > that was triggering the fallbacks. Based on my sample of one, anyway. ;)
> ..
>
> Nope.. what that second email should have said, was
> Changing channels in LiveTV, no fallbacks required
> because the audio is already working from the initial fallback.
>
> As soon as I quit from LiveTV, the next recording still needed
> a new fallback. So the chip is still in some weird state where
> auto-audio will continue to fail until I reload the module.
Thansk you for all the testing and feedback.
At this point I'm going to brush up the fixes by properly incorporating
support for the cx18_av_g_tuner()/cx18_av_s_tuner() calls so that user
space can still influence the audio mode (mono, stereo, Lang1, lang2,
etc.) even when audio standard and format are forced. I'll have time on
Friday for this.
The *only* other thing I can think of, that I have control over, is the
PLL charge pump current in the analog tuner. Right now it is set to low
current to minimize phase noise when tuned to a channel. Perhaps
setting the PLL charge pump to high current while chaning the channel to
get a faster lock, and low current after a short time, will help get a
good SIF output from the analog tuner assembly sooner. Perhaps when I
have time....
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-13 10:35 ` Andy Walls
@ 2010-04-13 12:42 ` Mark Lord
2010-04-14 1:45 ` Andy Walls
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-13 12:42 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 13/04/10 06:35 AM, Andy Walls wrote:
> On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
..
>> As soon as I quit from LiveTV, the next recording still needed
>> a new fallback. So the chip is still in some weird state where
>> auto-audio will continue to fail until I reload the module.
..
> The *only* other thing I can think of, that I have control over, is the
> PLL charge pump current in the analog tuner. Right now it is set to low
> current to minimize phase noise when tuned to a channel. Perhaps
> setting the PLL charge pump to high current while chaning the channel to
> get a faster lock, and low current after a short time, will help get a
> good SIF output from the analog tuner assembly sooner. Perhaps when I
> have time....
..
What's weird, is that things work most of the time.
But as soon as one fallback is needed, the chip then fails
continuously afterward, requiring fallback after fallback.
Until the driver is reloaded.
So to me, that suggests that perhaps some register has gotten corrupted,
or some part of the chip has gone wanky.
Perhaps if the driver could re-init more of the chip when tuning,
which might correct whatever bits/state happen to need fixing?
I might have a look later, and see if there are any obvious registers
that perhaps I could have it dump out prior to doing the fallback,
and then compare that state with a "good" tuning state. Or something.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-13 12:42 ` Mark Lord
@ 2010-04-14 1:45 ` Andy Walls
2010-04-14 4:32 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-14 1:45 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Tue, 2010-04-13 at 08:42 -0400, Mark Lord wrote:
> On 13/04/10 06:35 AM, Andy Walls wrote:
> > On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote:
> ..
> >> As soon as I quit from LiveTV, the next recording still needed
> >> a new fallback. So the chip is still in some weird state where
> >> auto-audio will continue to fail until I reload the module.
> ..
> > The *only* other thing I can think of, that I have control over, is the
> > PLL charge pump current in the analog tuner. Right now it is set to low
> > current to minimize phase noise when tuned to a channel. Perhaps
> > setting the PLL charge pump to high current while chaning the channel to
> > get a faster lock, and low current after a short time, will help get a
> > good SIF output from the analog tuner assembly sooner. Perhaps when I
> > have time....
> ..
>
> What's weird, is that things work most of the time.
> But as soon as one fallback is needed, the chip then fails
> continuously afterward, requiring fallback after fallback.
> Until the driver is reloaded.
Hmmm. Interesting observation.
> So to me, that suggests that perhaps some register has gotten corrupted,
> or some part of the chip has gone wanky.
>
> Perhaps if the driver could re-init more of the chip when tuning,
> which might correct whatever bits/state happen to need fixing?
If needed, once we're in a forced mode, we could stop the
microcontroller, reload all of the microcontroller firmware, and restart
it. Kind of heavy handed, but it may work.
> I might have a look later, and see if there are any obvious registers
> that perhaps I could have it dump out prior to doing the fallback,
> and then compare that state with a "good" tuning state. Or something.
# v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff
Keep in mind that some of these registers aren't settable and only read
out the state of various hardware blocks and functions.
Dumping the state of the microcontroller memory could also be done, but
I'd have to modify the driver to do it.
cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to
doing that.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-14 1:45 ` Andy Walls
@ 2010-04-14 4:32 ` Mark Lord
2010-04-14 4:34 ` Mark Lord
` (2 more replies)
0 siblings, 3 replies; 45+ messages in thread
From: Mark Lord @ 2010-04-14 4:32 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 13/04/10 09:45 PM, Andy Walls wrote:
..
> # v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff
>
> Keep in mind that some of these registers aren't settable and only read
> out the state of various hardware blocks and functions.
>
>
> Dumping the state of the microcontroller memory could also be done, but
> I'd have to modify the driver to do it.
> cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to
> doing that.
..
Thanks. I'll have a go at that some night.
Meanwhile, tonight, audio failed.
The syslog shows the usual "fallback" messages,
but the audio consisted of very loud static, the kind
of noise one gets when the sample bits are all reversed.
While it was failing, I tried retuning, stopping/starting
the recording, etc.. nothing mattered. It wanted a reload
of the cx18 driver to cure it.
> If needed, once we're in a forced mode, we could stop the
> microcontroller, reload all of the microcontroller firmware, and restart
> it. Kind of heavy handed, but it may work.
..
Perhaps that's what is needed here.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-14 4:32 ` Mark Lord
@ 2010-04-14 4:34 ` Mark Lord
2010-04-14 22:26 ` Mark Lord
2010-04-16 13:15 ` Andy Walls
2 siblings, 0 replies; 45+ messages in thread
From: Mark Lord @ 2010-04-14 4:34 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 14/04/10 12:32 AM, Mark Lord wrote:
..
> Thanks. I'll have a go at that some night.
>
> Meanwhile, tonight, audio failed.
..
Oh, I forgot to include this:
Apr 13 22:00:05 duke kernel: cx18-0: ================= START STATUS CARD #0 =================
Apr 13 22:00:05 duke kernel: cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31)
Apr 13 22:00:05 duke kernel: tveeprom 1-0050: has radio
Apr 13 22:00:05 duke kernel: cx18-0 843: Video signal: present
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected format: NTSC-M
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified standard: NTSC-M
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified video input: Composite 7
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio mode: forced mode
Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio standard: forced audio standard
Apr 13 22:00:05 duke kernel: cx18-0 843: Audio muted: no
Apr 13 22:00:05 duke kernel: cx18-0 843: Audio microcontroller: running
Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio standard: BTSC
Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B)
Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audio input: Tuner (In8)
Apr 13 22:00:05 duke kernel: cx18-0 843: Preferred audio mode: stereo
Apr 13 22:00:05 duke kernel: cx18-0 gpio-reset-ctrl: GPIO: direction 0x00003001, value 0x00003001
Apr 13 22:00:05 duke kernel: tda9887 2-0043: Data bytes: b=0x14 c=0x30 e=0x44
Apr 13 22:00:05 duke kernel: tuner 2-0061: Tuner mode: analog TV
Apr 13 22:00:05 duke kernel: tuner 2-0061: Frequency: 531.25 MHz
Apr 13 22:00:05 duke kernel: tuner 2-0061: Standard: 0x0000b000
Apr 13 22:00:05 duke kernel: cs5345 1-004c: Input: 1
Apr 13 22:00:05 duke kernel: cs5345 1-004c: Volume: 0 dB
Apr 13 22:00:05 duke kernel: cx18-0: Video Input: Tuner 1
Apr 13 22:00:05 duke kernel: cx18-0: Audio Input: Tuner 1
Apr 13 22:00:05 duke kernel: cx18-0: GPIO: direction 0x00003001, value 0x00003001
Apr 13 22:00:05 duke kernel: cx18-0: Tuner: TV
Apr 13 22:00:05 duke kernel: cx18-0: Stream: MPEG-2 Program Stream
Apr 13 22:00:05 duke kernel: cx18-0: VBI Format: Private packet, IVTV format
Apr 13 22:00:05 duke kernel: cx18-0: Video: 720x480, 30 fps
Apr 13 22:00:05 duke kernel: cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 12000000, Peak 14500000
Apr 13 22:00:05 duke kernel: cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure
Apr 13 22:00:05 duke kernel: cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC
Apr 13 22:00:05 duke kernel: cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0
Apr 13 22:00:05 duke kernel: cx18-0: Temporal Filter: Manual, 8
Apr 13 22:00:05 duke kernel: cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
Apr 13 22:00:05 duke kernel: cx18-0: Status flags: 0x00200001
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder MPEG: status 0x0118, 0% of 2048 KiB (64 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder VBI: status 0x0038, 5% of 1015 KiB (20 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB (256 buffers) in use
Apr 13 22:00:05 duke kernel: cx18-0: Read MPEG/VBI: 190420992/476784 bytes
Apr 13 22:00:05 duke kernel: cx18-0: ================== END STATUS CARD #0 ==================
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-14 4:32 ` Mark Lord
2010-04-14 4:34 ` Mark Lord
@ 2010-04-14 22:26 ` Mark Lord
2010-04-15 4:46 ` Andy Walls
2010-04-16 13:15 ` Andy Walls
2 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-14 22:26 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 14/04/10 12:32 AM, Mark Lord wrote:
..
> The syslog shows the usual "fallback" messages,
> but the audio consisted of very loud static, the kind
> of noise one gets when the sample bits are all reversed.
>
> While it was failing, I tried retuning, stopping/starting
> the recording, etc.. nothing mattered. It wanted a reload
> of the cx18 driver to cure it.
..
Since all of this happens rather randomly,
I'm beginning to more strongly suspect a race condition
somewhere in the driver.
Now, it's a rather large driver -- lots of complexity in that chip
-- so it will take me a while to sort through things.
But at first blush, I don't see any obvious locking around
the various read-modify-write sequences for the audio registers.
And a quick "grep spin *.[ch]" shows a few spin_lock/spin_unlock
calls in cx18-queue.c and cx18-stream.c (as well as the alsa code,
which shouldn't be in play in this scenario).
Oddly, none of those spinlocks use _irq or _irq_save/restore,
which means they aren't providing any sort of mutual exclusion
against the interrupt handler.
But like I said, I'm only just beginning to look more closely now.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-14 22:26 ` Mark Lord
@ 2010-04-15 4:46 ` Andy Walls
2010-04-15 5:16 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-15 4:46 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
> On 14/04/10 12:32 AM, Mark Lord wrote:
> ..
> > The syslog shows the usual "fallback" messages,
> > but the audio consisted of very loud static, the kind
> > of noise one gets when the sample bits are all reversed.
> >
> > While it was failing, I tried retuning, stopping/starting
> > the recording, etc.. nothing mattered. It wanted a reload
> > of the cx18 driver to cure it.
> ..
>
> Since all of this happens rather randomly,
> I'm beginning to more strongly suspect a race condition
> somewhere in the driver.
>
> Now, it's a rather large driver -- lots of complexity in that chip
> -- so it will take me a while to sort through things.
You can at least logically break it into components:
cx18-av-* : the integrated A/V decoder subdevice (very much like a CX25843)
cx18-gpio* : logical subdevices for functions controlled by GPIO
cx18-alsa* : the ALSA interface presented to userspace
cx18-fileops*, cx18-ioctl*, cx18-contorls* : The V4L2 interface
cx18-dvb* : The DTV interface
cx18-streams* : main streams management, and empty DMA buffer handover
cx18-queue* : queue routines used for all queues for all streams
cx18-mailbox*, cx18-scb* : driver-firmware API, main body of hard irq handler for incoming DMA, and workhandler for incoming DMA
cx18-io* : Insanity to handle CX23418 PCI MMIO quirks
cx18-irq* : The hard irq handler
cx18-driver* : main driver probe and shutdown
cx18-cards* : specifics on each supported card
cx18-firmware* : Bridge and MPEG encoder firmware load and init, but not A/V core firmware
cx18-i2c* : I2C master setup, bus driving, and device registration
cx18-audio* : Top level audio routing functions
cx18-video* : Top level video routing functions
cx18-vbi* : VBI data extraction
> But at first blush, I don't see any obvious locking around
> the various read-modify-write sequences for the audio registers.
The ioctl handling in the driver does it:
$ grep serialize_lock *
The serialize_lock is a bit overloaded, but it's frequent operational
use is ioctl() serialization. The A/V core is almost exclusively
manipulated by ioctl()s. The timer I added for fallback is an
exception.
> And a quick "grep spin *.[ch]" shows a few spin_lock/spin_unlock
> calls in cx18-queue.c and cx18-stream.c (as well as the alsa code,
> which shouldn't be in play in this scenario).
Correct.
What is involved are the three "reset" processes in the cx18-av-* files:
1. Stopping and restarting the microcontroller via register 803
2. Soft reset (of what exactly?) via register 0x810
3. Format detection loop restart via register 0x9cc
I have no idea if 2 & 3 above reset hardware and registers, or simply
set a flag for the microcontroller firmware to notice, or both.
So I've wondered about the exact sequencing of stopping the
microcontoller, peforming the other 2 resets, and restarting the
microcontroller.
> Oddly, none of those spinlocks use _irq or _irq_save/restore,
> which means they aren't providing any sort of mutual exclusion
> against the interrupt handler.
There is no need. The hard irq handler only really deals with firmware
mailbox ack and firmware mailbox ready notifications. It sucks off the
mailbox contents and shoves it over to the cx18-NN-in workhandler via
work orders placed on a workqueue. The work handler does grab the
spinlocks, but it is from a non-irq context.
> But like I said, I'm only just beginning to look more closely now.
Look at the publicly available CX25843 datasheet:
http://dl.ivtvdriver.org/
pages 107-116 and Section 5.7. In figure 3.30 we've got SIF coming in
from the analog tuner and the microcontoller is represented by the "Auto
Std/Mode Detection" block. In figure 3-38 the output of the "source
select" block is what then gets fed to the baseband processing chain as
digital audio from the tuner.
For reference, you may want to also grab FCC docment OET60 (Rev A from
1996?), which technically describes the BTSC audio subcarriers. Then
Google for a nice pciture of the MTS/BTSC spectrum.
This app note has a good picture in figure 1:
http://assets.fluke.com/appnotes/it_products/Anbtsc.pdf
although it is missing the "PRO" channel that is above SAP at 6fh IIRC.
I don't know what part of the BTSC spectrum the Conexant microcontroller
is keying off of, but I guessing the pilot for sure is part of the
decision process.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-15 4:46 ` Andy Walls
@ 2010-04-15 5:16 ` Mark Lord
2010-04-15 14:15 ` Mark Lord
2010-04-16 12:59 ` Andy Walls
0 siblings, 2 replies; 45+ messages in thread
From: Mark Lord @ 2010-04-15 5:16 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 15/04/10 12:46 AM, Andy Walls wrote:
> On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
..
>> Oddly, none of those spinlocks use _irq or _irq_save/restore,
>> which means they aren't providing any sort of mutual exclusion
>> against the interrupt handler.
>
> There is no need. The hard irq handler only really deals with firmware
> mailbox ack and firmware mailbox ready notifications. It sucks off the
> mailbox contents and shoves it over to the cx18-NN-in workhandler via
> work orders placed on a workqueue. The work handler does grab the
> spinlocks, but it is from a non-irq context.
..
Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling.
I suppose those might be "safe" groups, written to _only_ by the IRQ handler,
but maybe not.
From what I can see, (nearly?) all registers are read/written as full 32-bit units.
So when code wants to modify an 8-bit "register", this is converted into a read-
modify-write of the corresponding 32-bit register.
So if two threads, or any thread and the irq handler, want to modify parts
of the same 32-bit register, then there's a race. The code _appears_ to mostly
not have such a problem, but it would conveniently explain the sporadic failures. :)
So, for now, I've added lower level spinlock protection onto all register writes,
as well as to routines that themselves do a higher level read-modify-write:
eg. the routines to enable/disable specific IRQ sources.
This was easy enough to do, and it'll give us confidence that the r-m-w sequences
are not the issue. Or perhaps it'll cure some problems. Time will tell.
I'll run with that patch on top of yours for the next couple of days,
or until I see a "fallback" log again. None so far, though.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-15 5:16 ` Mark Lord
@ 2010-04-15 14:15 ` Mark Lord
2010-04-17 4:43 ` Andy Walls
2010-04-16 12:59 ` Andy Walls
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-15 14:15 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 15/04/10 01:16 AM, Mark Lord wrote:
>
> for now, I've added lower level spinlock protection onto all
> register writes,
..
As you expected, this doesn't seem to have cured anything obvious. :)
I had Mythtv wakeup/record/powerdown several times overnight,
and it still required "fallbacks" for about half of those.
And.. one of the "fallback" recordings still had muted audio.
Even though my script which checks for that reported "audio ok".
Enough for now.. I'll hack some more on the weekend.
cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-15 5:16 ` Mark Lord
2010-04-15 14:15 ` Mark Lord
@ 2010-04-16 12:59 ` Andy Walls
2010-04-17 12:18 ` Mark Lord
1 sibling, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-16 12:59 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Thu, 2010-04-15 at 01:16 -0400, Mark Lord wrote:
> On 15/04/10 12:46 AM, Andy Walls wrote:
> > On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote:
> .
>
> Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling.
> I suppose those might be "safe" groups, written to _only_ by the IRQ handler,
> but maybe not.
In the linux driver, the registers in CX23418 address range:
0x2c40000-0x2c409ff
are only written to by the files named cx18-av-*[ch], which is mostly
ioctl() call driven. (Those registers are logically mapped by the linux
driver code to 0x000-0x9ff to make the integrated A/V decoder look like
a CX25843 chip for convenience.)
Accesses to those are orthognal to the rest of the cx18 driver,
including the IRQ handler. (I agree, its hard to follow things in the
driver; it's very large.)
Do note, however, that the audio standard detection microcontroller
*does* write to the registers in 0x800-0x9ff *independent* of the linux
cx18 driver.
Locking with respect to the microcontroller would mean halting and
restarting the microcontroller. I don't know if that causes it to reset
or not, and I do not know how it affects it's internal timers.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-14 4:32 ` Mark Lord
2010-04-14 4:34 ` Mark Lord
2010-04-14 22:26 ` Mark Lord
@ 2010-04-16 13:15 ` Andy Walls
2010-04-16 13:29 ` Andy Walls
2 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-16 13:15 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Wed, 2010-04-14 at 00:32 -0400, Mark Lord wrote:
> On 13/04/10 09:45 PM, Andy Walls wrote:
> The syslog shows the usual "fallback" messages,
> but the audio consisted of very loud static, the kind
> of noise one gets when the sample bits are all reversed.
When in forced audio mode, the microcontroller will unmute. What you
hear is what the decoder is decoding for BTSC. And that makes your
observation *very* interesting.
The sample rate conversion for SIF is fixed at about 62.937 ksps. That
is 4 times the NTSC line rate of 15.734 kHz. Also note, that for
anything other than simple monaural L+R audio, the BTSC subcarrier pilot
and subcarrier center frequencies are based on multiples of Fh = 15.734
kHz.
So if you hear something that sounds like sampling being performed at
the wrong rate, I think we have one of two other problems:
a. The horizontal sync tracking loop in the A/V decoder is way off
(unlikely if you can see video properly)
or
b. the SIF signal from the analog tuner is off center.
> While it was failing, I tried retuning, stopping/starting
> the recording, etc.. nothing mattered. It wanted a reload
> of the cx18 driver to cure it.
Since you have a unit with FM radio, for a simple test, when you notice
the fallback happen:
1. stop your TV capture
2. perform a short FM radio capture with ivtv-radio (it doesn't have to
find a station, it shouldn't matter)
3. retry your TV capture.
I'm hoping that this reconfiguration of the analog tuner's IF
demodulator chip will correct any problem with the SIF output from the
analog tuner.
Regards,
Andy
BTW, that's for all your testing. It's really helpful.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-16 13:15 ` Andy Walls
@ 2010-04-16 13:29 ` Andy Walls
0 siblings, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-16 13:29 UTC (permalink / raw)
To: Discussion list for development of the IVTV driver
Cc: Mark Lord, Darren Blaber, linux-media
On Fri, 2010-04-16 at 09:15 -0400, Andy Walls wrote:
>
> Regards,
> Andy
>
> BTW, that's for all your testing. It's really helpful.
^^^^^^
That should be "thanks".
-Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-15 14:15 ` Mark Lord
@ 2010-04-17 4:43 ` Andy Walls
2010-04-17 12:09 ` Mark Lord
0 siblings, 1 reply; 45+ messages in thread
From: Andy Walls @ 2010-04-17 4:43 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Thu, 2010-04-15 at 10:15 -0400, Mark Lord wrote:
> And.. one of the "fallback" recordings still had muted audio.
> Even though my script which checks for that reported "audio ok".
>
> Enough for now.. I'll hack some more on the weekend.
I had to disassemble and study some of the microcontorller firmware, and
then reread some documents, to figure out how all the audio detection
"resets" must work.
I've just pushed some microcontroller reset related changes to the
cx18-audio2 repo. Please test and see if things are better or worse.
The analog stations I had last weekend I can't seem to pick up anymore.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-17 4:43 ` Andy Walls
@ 2010-04-17 12:09 ` Mark Lord
2010-04-17 13:01 ` Mark Lord
2010-04-17 17:03 ` Andy Walls
0 siblings, 2 replies; 45+ messages in thread
From: Mark Lord @ 2010-04-17 12:09 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 17/04/10 12:43 AM, Andy Walls wrote:
> I had to disassemble and study some of the microcontorller firmware, and
> then reread some documents, to figure out how all the audio detection
> "resets" must work.
>
> I've just pushed some microcontroller reset related changes to the
> cx18-audio2 repo. Please test and see if things are better or worse.
..
Mmm.. something is not right -- the audio is failing constantly with that change.
Perhaps if I could dump out the registers, we might see what is wrong.
I also tried:
v4l2-dbg -d /dev/video1 -c type=host,chip=1 --list-registers=min=0x800,max=0x9ff
but that fails to read any of the registers (ioctl: VIDIOC_DBG_G_REGISTER failed for 0xXXX).
I think I'll patch the driver to dump them for us.
Thank-you for your work on this. There are many of us here hoping
that we can figure out and fix whatever is wrong with our cards.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-16 12:59 ` Andy Walls
@ 2010-04-17 12:18 ` Mark Lord
2010-04-17 17:37 ` Andy Walls
0 siblings, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-17 12:18 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 16/04/10 08:59 AM, Andy Walls wrote:
..
> Accesses to those are orthognal to the rest of the cx18 driver,
> including the IRQ handler. (I agree, its hard to follow things in the
> driver; it's very large.)
>
> Do note, however, that the audio standard detection microcontroller
> *does* write to the registers in 0x800-0x9ff *independent* of the linux
> cx18 driver.
>
> Locking with respect to the microcontroller would mean halting and
> restarting the microcontroller. I don't know if that causes it to reset
> or not, and I do not know how it affects it's internal timers.
..
Since the problem really does behave like a "race condition" would behave,
I wonder if it could have something to do with how/when we modify any of
those registers which are shared with the microcontroller?
The cx18 driver *always* does read-modify-write (RMW) of 32-bits at at time,
even when just an "8-bit" register is being modified.
If the microcontroller is using/updating the other 24-bits of any of those
registers, then the cx18 driver's RMW will destroy values that the microcontroller
has written.
Is it possible to write only 8-bits, rather than having to do the RMW on 32-bits ?
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-17 12:09 ` Mark Lord
@ 2010-04-17 13:01 ` Mark Lord
2010-04-17 17:18 ` Andy Walls
2010-04-17 17:03 ` Andy Walls
1 sibling, 1 reply; 45+ messages in thread
From: Mark Lord @ 2010-04-17 13:01 UTC (permalink / raw)
To: Andy Walls; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On 17/04/10 08:09 AM, Mark Lord wrote:
..
> Mmm.. something is not right -- the audio is failing constantly with that change.
> Perhaps if I could dump out the registers, we might see what is wrong.
..
When the microcontroller is reset, does it put all settings back to defaults?
I wonder if this causes it to select a different audio input, as part of the reset?
If so, then we'll need to reselect the tuner-audio afterward.
Anything else?
??
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-17 12:09 ` Mark Lord
2010-04-17 13:01 ` Mark Lord
@ 2010-04-17 17:03 ` Andy Walls
1 sibling, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-17 17:03 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Sat, 2010-04-17 at 08:09 -0400, Mark Lord wrote:
> On 17/04/10 12:43 AM, Andy Walls wrote:
> > I had to disassemble and study some of the microcontorller firmware, and
> > then reread some documents, to figure out how all the audio detection
> > "resets" must work.
> >
> > I've just pushed some microcontroller reset related changes to the
> > cx18-audio2 repo. Please test and see if things are better or worse.
> ..
>
> Mmm.. something is not right -- the audio is failing constantly with that change.
Crud. I added an additional soft reset using register 0x810 with that
change; maybe that needs to be taken out.
> Perhaps if I could dump out the registers, we might see what is wrong.
> I also tried:
> v4l2-dbg -d /dev/video1 -c type=host,chip=1 --list-registers=min=0x800,max=0x9ff
> but that fails to read any of the registers (ioctl: VIDIOC_DBG_G_REGISTER failed for 0xXXX).
>
> I think I'll patch the driver to dump them for us.
Whatever's easiest. As root, this should work:
# v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff
ioctl: VIDIOC_DBG_G_REGISTER
00 04 08 0C 10 14 18 1C
00000800: 13248000 0000fefe 01010411 20000000 80ff0200 20140905 000031c0 478005d1
00000820: 80002800 e084e044 007e54a8 240107f2 0186a020 00000000 24010800 0186a020
00000840: 00000000 00801c00 00000020 00000000 00a14f72 00000030 00000000 00007800
[...]
000009c0: 80007ffc 00000000 0000c000 00000001 02000200 00000000 00000000 00000000
000009e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Or equivalently with the actual register addresses (vs. the logical remapping using host1):
# v4l2-dbg -d /dev/video0 --list-registers=min=0x2c40800,max=0x2c409ff
ioctl: VIDIOC_DBG_G_REGISTER
00 04 08 0C 10 14 18 1C
02c40800: 137d8000 0000fefe 01010411 20000000 80ff0200 20140905 000031c0 478005d1
02c40820: 80002800 e084e044 007e54a8 240107f2 0186a020 00000000 24010800 0186a020
02c40840: 00000000 00801c00 00000020 00000000 00a14f72 00000030 00000000 00007800
[...]
02c409c0: 7ffc27cc 00000000 0000c000 00000001 02000200 00000000 00000000 00000000
02c409e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Dumps of registers might help me figure out something.
> Thank-you for your work on this. There are many of us here hoping
> that we can figure out and fix whatever is wrong with our cards.
No problem. Sorry for all the shots in the dark so far. Without a
BTSC/MTS signal source I'm just trying to guess what might be wrong.
(Most VCR's, set top boxes, and RF modulators only seem to put out the
monaural L+R sound signal and not an MTS BTSC signal with the pilot tone
and stereo L-R as well).
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-17 13:01 ` Mark Lord
@ 2010-04-17 17:18 ` Andy Walls
0 siblings, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-17 17:18 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Sat, 2010-04-17 at 09:01 -0400, Mark Lord wrote:
> On 17/04/10 08:09 AM, Mark Lord wrote:
> ..
> > Mmm.. something is not right -- the audio is failing constantly with that change.
> > Perhaps if I could dump out the registers, we might see what is wrong.
> ..
>
> When the microcontroller is reset, does it put all settings back to defaults?
The microcontroller reset via register 0x803 causes the 8051 hardware to
go to reset state and jump back to execute at address 0x0000 of the
loaded v4l-cx23418-dig.fw firmware image.
> I wonder if this causes it to select a different audio input, as part of the reset?
The microcontroller doesn't control much in the way of routing except
what outputs of the SIF decoding (L+R, L-R, SAP, dbx, NICAM) to route to
the dematrix and the baseband audio processing path.
> If so, then we'll need to reselect the tuner-audio afterward.
> Anything else?
I think the extra soft reset I added might be doing something bad.
Based on what I can tell:
1. Register 0x803 start/stop of the microcontroller is for sure a
microcontroller hardware reset and likely nothing else
2. Register 0x9cc bit 1 is almost certainly only a software flag to the
microcontroller program. It doesn't appear to affect hardware.
3. Soft reset via register 0x810 must affect hardware units and
registers and not the micrcontroller itself.
So perhaps you could try removing the extra soft rest I added in my
changes to cx18-av-core.c
I also added a mute of baseband processing path 1 to the firmware load
and init in cx18-av-firmware.c. The microcontroller should be unmuting
things when it detects a broadcast standard, so I didn't think it was a
problem. Maybe it is.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: cx18: "missing audio" for analog recordings
2010-04-17 12:18 ` Mark Lord
@ 2010-04-17 17:37 ` Andy Walls
0 siblings, 0 replies; 45+ messages in thread
From: Andy Walls @ 2010-04-17 17:37 UTC (permalink / raw)
To: Mark Lord; +Cc: Hans Verkuil, linux-media, ivtv-devel, Darren Blaber
On Sat, 2010-04-17 at 08:18 -0400, Mark Lord wrote:
> On 16/04/10 08:59 AM, Andy Walls wrote:
> ..
> > Accesses to those are orthognal to the rest of the cx18 driver,
> > including the IRQ handler. (I agree, its hard to follow things in the
> > driver; it's very large.)
> >
> > Do note, however, that the audio standard detection microcontroller
> > *does* write to the registers in 0x800-0x9ff *independent* of the linux
> > cx18 driver.
> >
> > Locking with respect to the microcontroller would mean halting and
> > restarting the microcontroller. I don't know if that causes it to reset
> > or not, and I do not know how it affects it's internal timers.
> ..
>
> Since the problem really does behave like a "race condition" would behave,
> I wonder if it could have something to do with how/when we modify any of
> those registers which are shared with the microcontroller?
It certainly could. The changes where we set our preferences in
registers 0x808-0x80b need to be protected. We then need to notify the
microcontroller properly that we have set things.
Currently tmy latest changes do this:
1. halt the microcontroller by holding it in reset via register 0x803
(This is our lock out of the microcontroller from modifying registers)
2. assert the soft reset via register 0x810
3. set our preferences in register 0x808-0x80b
4. deassert soft reset via register 0x810
5. restart the microcontroller via register 0x803
6. Pulse the format detection reset flag via register 0x9cc
7. Schedule a 1.5 second delay to come back and check if the
microcontroller found something.
So I'm unsure about
a. the exact sequencing of the current steps 2-4 (and if steps 2 & 4 are
needed at all)
b. if we're pulsing the bit in 0x9cc too rapidly in step 6
c. if we should wait a little longer than 1.5 seconds in step 7.
> The cx18 driver *always* does read-modify-write (RMW) of 32-bits at at time,
> even when just an "8-bit" register is being modified.
>
> If the microcontroller is using/updating the other 24-bits of any of those
> registers, then the cx18 driver's RMW will destroy values that the microcontroller
> has written.
The micrcontroller should only read registers 0x808-0x80b and never
write them.
I suspect the micrcontroller does check and modify the soft reset bit in
register 0x810 itself at times. (I do not know what hardware units that
bit resets, if any.)
Register 0x9cc only ever appears to be read by the microcontroller.
>
> Is it possible to write only 8-bits, rather than having to do the RMW on 32-bits ?
Yes it should be possible. PCI read of bytes are possible PCI bus
transactions. I've never tried it, and there are no routines in
cx18-io.[ch] presently to assist with the occasional failure to write a
CX23418 register.
You're welcome to check to se if it makes a difference, but please make
sure you don't modify the firmware loading process, it's pretty touchy.
Regards,
Andy
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2010-04-17 17:37 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-01 16:07 cx18: Unable to find blank work order form to schedule incoming mailbox Mark Lord
2010-03-02 1:34 ` Andy Walls
2010-03-02 5:57 ` Mark Lord
2010-03-02 12:40 ` Andy Walls
2010-03-02 15:00 ` Mark Lord
2010-03-03 1:05 ` Andy Walls
2010-03-15 2:48 ` cx18: "missing audio" for analog recordings Mark Lord
2010-03-15 11:51 ` Andy Walls
2010-03-16 4:49 ` Mark Lord
2010-03-16 11:11 ` Andy Walls
2010-04-10 22:28 ` Mark Lord
2010-04-10 22:54 ` Andy Walls
2010-04-11 0:58 ` Andy Walls
2010-04-11 3:21 ` Mark Lord
2010-04-11 4:56 ` Andy Walls
2010-04-11 5:03 ` [ivtv-devel] " Andy Walls
2010-04-11 11:47 ` Andy Walls
2010-04-11 13:24 ` Mark Lord
2010-04-11 19:01 ` Andy Walls
2010-04-11 20:52 ` Mark Lord
2010-04-12 20:08 ` Mark Lord
2010-04-12 21:17 ` Andy Walls
2010-04-13 2:22 ` Mark Lord
2010-04-13 2:30 ` Mark Lord
2010-04-13 2:34 ` Mark Lord
2010-04-13 10:35 ` Andy Walls
2010-04-13 12:42 ` Mark Lord
2010-04-14 1:45 ` Andy Walls
2010-04-14 4:32 ` Mark Lord
2010-04-14 4:34 ` Mark Lord
2010-04-14 22:26 ` Mark Lord
2010-04-15 4:46 ` Andy Walls
2010-04-15 5:16 ` Mark Lord
2010-04-15 14:15 ` Mark Lord
2010-04-17 4:43 ` Andy Walls
2010-04-17 12:09 ` Mark Lord
2010-04-17 13:01 ` Mark Lord
2010-04-17 17:18 ` Andy Walls
2010-04-17 17:03 ` Andy Walls
2010-04-16 12:59 ` Andy Walls
2010-04-17 12:18 ` Mark Lord
2010-04-17 17:37 ` Andy Walls
2010-04-16 13:15 ` Andy Walls
2010-04-16 13:29 ` Andy Walls
2010-04-11 19:49 ` Darren Blaber
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.