* 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 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 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-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 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: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-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-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: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
* 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-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
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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox