[mythtv-users] Can't get LIRC to work with my Serial card - IRQ tied up?

Jay Mallar jaymallar at gmail.com
Sun Sep 23 16:24:45 UTC 2007


I forgot to mention that - but I had already done the uart none stuff.

Ryan Steffes wrote:
> On 9/22/07, Jay Mallar <jaymallar at gmail.com> wrote:
>   
>> First, I realize this isn't necessarily a good topic for this list, but
>> I'm sort of stuck on what to do next.  My problem isn't really with IRC,
>> I don't think it's with my serial card, and I just don't know where to turn.
>>
>> My machine:
>>
>> Motherboard: Asus P5N32-E SLI Plus
>> http://usa.asus.com/products.aspx?l1=3&l2=11&l3=495&l4=0&model=1567&modelmenu=1
>>
>> 4 PCI-e Serial Port Card:
>> http://www.qualitycables.com/productdetails1.cfm?sku=CM-4SRS232&cats=99172&catid=495%2C538%2C472%2C538%2C882%2C909
>>
>> Homebrew Serial IR Receiver:
>> http://www.irblaster.info/receiver.html
>>
>> Everything seems to be recognized by my machine during startup:
>>
>> ...
>> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
>> ACPI: PCI Interrupt Link [APC6] enabled at IRQ 16
>> ACPI: PCI Interrupt 0000:0a:00.0[A] -> Link [APC6] -> GSI 16 (level,
>> low) -> IRQ 16
>> ttyS0: detected caps 00000700 should be 00000100
>> 0000:0a:00.0: ttyS0 at I/O 0x5f00 (irq = 16) is a 16C950/954
>> ttyS1: detected caps 00000700 should be 00000100
>> 0000:0a:00.0: ttyS1 at I/O 0x5f08 (irq = 16) is a 16C950/954
>> ttyS2: detected caps 00000700 should be 00000100
>> 0000:0a:00.0: ttyS2 at I/O 0x5f10 (irq = 16) is a 16C950/954
>> ttyS3: detected caps 00000700 should be 00000100
>> 0000:0a:00.0: ttyS3 at I/O 0x5f18 (irq = 16) is a 16C950/954
>> ...
>>
>> lspci -v shows:
>>
>> 0a:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
>> 16950 UART) function 0 (Uart) (prog-if 06 [16950])
>>         Subsystem: Oxford Semiconductor Ltd Unknown device 0000
>>         Flags: medium devsel, IRQ 16
>>         I/O ports at 5f00 [size=32]
>>         Memory at ef1ff000 (32-bit, non-prefetchable) [size=4K]
>>         I/O ports at 5e00 [size=32]
>>         Memory at ef1fe000 (32-bit, non-prefetchable) [size=4K]
>>         Capabilities: [40] Power Management version 1
>>
>> 0a:00.1 Parallel controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
>> 16950 UART) function 1 (parallel port) (prog-if 01 [BiDir])
>>         Subsystem: Oxford Semiconductor Ltd Unknown device 0000
>>         Flags: medium devsel, IRQ 16
>>         I/O ports at 5d00 [size=8]
>>         I/O ports at 5c00 [size=8]
>>         I/O ports at 5b00 [size=32]
>>         Memory at ef1fd000 (32-bit, non-prefetchable) [size=4K]
>>         Capabilities: [40] Power Management version 1
>>
>> I have my IR receiver hooked to the first serial port, which I believe
>> is at 0x5f00 IRQ 16.
>>
>> I'm using the latest CVS LIRC drivers (which appear to be 0.8.3).
>>
>> When running setup.sh, I told the tool I'm using a homebrew IR receiver
>> configured at 0x5f00 IRQ 16 (I chose the Other option to configure my
>> values rather than choose the COM1 option which defaulted to a different
>> address):
>>
>> I did get the msg:
>>
>> You will have to use the lirc_serial kernel module.
>>
>> Ran 'make' and 'make install' which did install the lirc_serial.ko file.
>>
>> Now to load everything up.  First the modules:
>>
>> 'modprobe lirc_serial' returned with no errors and the following in my log:
>>
>> Sep 22 10:35:46 localhost kernel: lirc_dev: IR Remote Control driver
>> registered, at major 61
>> Sep 22 10:35:46 localhost kernel: lirc_serial: auto-detected active low
>> receiver
>> Sep 22 10:35:46 localhost kernel: lirc_dev: lirc_register_plugin:
>> sample_rate: 0
>>
>> The sample rate seemed weird to me - but I let that go for now.
>>
>> :lsmod | grep irc
>> lirc_serial            17156  0
>> lirc_dev               18676  1 lirc_serial
>>
>> Now I run lircd:
>>
>> :lircd
>>
>> It returns immediately without error.  Logs show:
>>
>> Sep 22 10:38:33 localhost lircd-0.8.3-CVS[31147]: lircd(serial) ready
>>
>> Okay - should be good to go now, so I try 'irw' to test it:
>>
>> :irw
>>
>> This also returns immediately with no error, but this in the logs:
>>
>> Sep 22 10:39:25 localhost kernel: lirc_serial: IRQ 16 busy
>> Sep 22 10:39:25 localhost lircd-0.8.3-CVS[31147]: default_init(): Device
>> or resource busy
>> Sep 22 10:39:25 localhost lircd-0.8.3-CVS[31147]: caught signal
>>
>> And that's where I get stuck.  I do think my problem is IRQ 16 being
>> busy, but just not sure how to fix it.
>>
>> Here's some other info:
>>
>> :cat /proc/interrupts
>>            CPU0       CPU1       CPU2       CPU3
>>   0:       1843          0          0          0   IO-APIC-edge      timer
>>   1:        276          0        997          0   IO-APIC-edge      i8042
>>   8:          0          0          0          0   IO-APIC-edge      rtc0
>>   9:          0          0          0          0   IO-APIC-fasteoi   acpi
>>  12:       2838          0       2639          0   IO-APIC-edge      i8042
>>  14:          0          0          0          0   IO-APIC-edge      libata
>>  15:          0          0          0          0   IO-APIC-edge      libata
>>  16:   19731235          0   13793052          0   IO-APIC-fasteoi   nvidia
>>  17:   18967670          0      55609          0   IO-APIC-fasteoi
>> ohci_hcd:usb1, sata_nv
>>  18:          0          0          0          0   IO-APIC-fasteoi
>> ehci_hcd:usb2
>>  19:      81751       5388     110312          0   IO-APIC-fasteoi   sata_nv
>>  20:       7157          0      18186          0   IO-APIC-fasteoi
>> sata_nv, HDA Intel
>>  21:       2128          0       1768          0   IO-APIC-fasteoi
>> firewire_ohci
>>  22:       1732          0     210608          0   IO-APIC-fasteoi   ivtv0
>> 214:       1654          0          0   25535507   PCI-MSI-edge      eth0
>> NMI:          0          0          0          0
>> LOC:   24847603   20553428   29031709   24752948
>> ERR:          1
>> MIS:          0
>>
>> :cat /proc/ioports
>> 0000-001f : dma1
>> 0020-0021 : pic1
>> 0040-0043 : timer0
>> 0050-0053 : timer1
>> 0060-006f : keyboard
>> 0070-0073 : rtc0
>> 0080-008f : dma page reg
>> 00a0-00a1 : pic2
>> 00c0-00df : dma2
>> 00f0-00ff : fpu
>> 0170-0177 : 0000:00:0d.0
>>   0170-0177 : libata
>> 01f0-01f7 : 0000:00:0d.0
>>   01f0-01f7 : libata
>> 0376-0376 : 0000:00:0d.0
>>   0376-0376 : libata
>> 03c0-03df : vga+
>> 03f6-03f6 : 0000:00:0d.0
>>   03f6-03f6 : libata
>> 0960-0967 : 0000:00:0e.1
>>   0960-0967 : libata
>> 0970-0977 : 0000:00:0e.0
>>   0970-0977 : libata
>> 09e0-09e7 : 0000:00:0e.1
>>   09e0-09e7 : libata
>> 09f0-09f7 : 0000:00:0e.0
>>   09f0-09f7 : libata
>> 0b60-0b63 : 0000:00:0e.1
>>   0b60-0b63 : libata
>> 0b70-0b73 : 0000:00:0e.0
>>   0b70-0b73 : libata
>> 0be0-0be3 : 0000:00:0e.1
>>   0be0-0be3 : libata
>> 0bf0-0bf3 : 0000:00:0e.0
>>   0bf0-0bf3 : libata
>> 0cf8-0cff : PCI conf1
>> 1000-107f : pnp 00:01
>>   1000-1003 : ACPI PM1a_EVT_BLK
>>   1004-1005 : ACPI PM1a_CNT_BLK
>>   1008-100b : ACPI PM_TMR
>>   101c-101c : ACPI PM2_CNT_BLK
>>   1020-1027 : ACPI GPE0_BLK
>> 1080-10ff : pnp 00:01
>> 1400-147f : pnp 00:01
>> 1480-14ff : pnp 00:01
>>   14a0-14af : ACPI GPE1_BLK
>> 1800-187f : pnp 00:01
>> 1880-18ff : pnp 00:01
>> 1c00-1c3f : 0000:00:0a.1
>>   1c00-1c3f : nForce2_smbus
>> 1c80-1cbf : 0000:00:0a.1
>>   1c80-1cbf : nForce2_smbus
>> 4000-4fff : PCI Bus #0b
>> 5000-5fff : PCI Bus #09
>>   5000-5fff : PCI Bus #0a
>>     5b00-5b1f : 0000:0a:00.1
>>     5c00-5c07 : 0000:0a:00.1
>>     5d00-5d07 : 0000:0a:00.1
>>       5d00-5d02 : parport0
>>     5e00-5e1f : 0000:0a:00.0
>>     5f00-5f1f : 0000:0a:00.0
>>       5f00-5f07 : lirc_serial
>>       5f08-5f0f : serial
>>       5f10-5f17 : serial
>>       5f18-5f1f : serial
>> 6000-6fff : PCI Bus #08
>> 7000-7fff : PCI Bus #07
>> 8000-8fff : PCI Bus #06
>> 9000-9fff : PCI Bus #05
>> a000-afff : PCI Bus #03
>> b000-bfff : PCI Bus #02
>> c000-cfff : PCI Bus #04
>>   cf00-cf7f : 0000:04:0b.0
>> d000-dfff : PCI Bus #01
>> eb00-eb07 : 0000:00:12.0
>>   eb00-eb07 : forcedeth
>> ec00-ec07 : 0000:00:11.0
>>   ec00-ec07 : forcedeth
>> ed00-ed0f : 0000:00:0e.2
>>   ed00-ed0f : libata
>> ee00-ee03 : 0000:00:0e.2
>>   ee00-ee03 : libata
>> ef00-ef07 : 0000:00:0e.2
>>   ef00-ef07 : libata
>> f000-f003 : 0000:00:0e.2
>>   f000-f003 : libata
>> f100-f107 : 0000:00:0e.2
>>   f100-f107 : libata
>> f200-f20f : 0000:00:0e.1
>>   f200-f20f : libata
>> f700-f70f : 0000:00:0e.0
>>   f700-f70f : libata
>> fc00-fc0f : 0000:00:0d.0
>>   fc00-fc0f : libata
>> ff00-ff3f : 0000:00:0a.1
>>
>> The IO port output looks good, but the IRQ output appears to have
>> assigned IRQ 16 to nvidia.  I do have aN NVidia GeForce 6200 installed
>> as my video card (which works perfectly).
>>
>> So if I had to guess, I'm hitting an IRQ sharing issue, but not sure how
>> to correct it.  Neither my Video card not my Serial port card have any
>> jumpers or any ability to change IRQs via the hardware.
>>
>> Suggestions?
>>
>>
>>     
>
> Likely you're getting the default device bound to the serial port.
> See if you can free it up with setserial:
>
> # setserial /dev/ttyS0 uart none
>
> There's a guide to setting up mythtv on the wiki
> (http://www.mythtv.org/wiki/index.php/Installing_MythTV_on_an_Athlon64_using_Fedora_Core)
> that mentions how to do it automatically in your modprobe.conf, or you
> can put it in the lircd start up script like I did.
>
> Ry
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20070923/b3bf4772/attachment.htm 


More information about the mythtv-users mailing list