Bug 3048 - (IRDA) smsc-ircc2: can't get sir_base of 0x2f8
(IRDA) smsc-ircc2: can't get sir_base of 0x2f8
Status: REJECTED INVALID
Product: Drivers
Classification: Unclassified
Component: Network
i386 Linux
: P2 normal
Assigned To: Jeff Garzik
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-11 09:32 UTC by Roger
Modified: 2007-11-02 08:41 UTC (History)
3 users (show)

See Also:
Kernel Version: >=2.6.6
Tree: Mainline
Regression: Yes


Attachments

Description Roger 2004-07-11 09:32:12 UTC
Distribution: Gentoo (using vanilla-2.6.7 kernel)
Hardware Environment: Dell Inspiron 8100 laptop
Software Environment: Linux? ;-) -- vanilla kernel
Problem Description: In dmesg -> smsc-ircc2:  can't get sir_base of 0x2f8

Steps to reproduce: Seems to start to appear in kernels >=2.6.6, the smsc-ircc2
driver had no problems with kernel-2.6.5 | (crap!. I'm going from memory and now
cannot remember for sure if this bug was present in 2.6.6, but is for sure in
2.6.7!)

I'm in the process of troubleshooting now.

Also note, there is little documentation on this driver on specifying alternate
ports, and when doing so, you must explicitly declare all other varaibles such
as IRQ (etc), or else the driver will not utilize your custom port (or sir_base
value).
Comment 1 Roger 2004-07-11 09:45:47 UTC
Um, gee, this might help:

In dmesg:

Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Using anticipatory io scheduler

found SMC SuperIO Chip (devid=0x0e rev=01 base=0x002e): LPC47N252
smsc_ircc_present: can't get sir_base of 0x2f8

I just compared the code between 2.6.5/2.6.6 & 2.6.7 for
"linux/drivers/net/irda/smsc-ircc2.h" and only found trivial or minor changes --
example follows:

2.6.5 <       /*printk(KERN_WARNING __FUNCTION__ "(): mode: 0x%02x\n", mode);*/
---
2.6.6 >       /*printk(KERN_WARNING "%s(): mode: 0x%02x\n", __FUNCTION__, mode);*/


And nothing seems to have changed from 2.6.6 to 2.6.7
Comment 2 Roger 2004-07-11 22:55:47 UTC
OK. Confirmed that this bug started during kernel-2.6.6.

I have found the problem and a work around.

The ioports were conflicting.

$ cat /proc/ioports
4: cascade
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial
0800-087f : 0000:00:1f.0
  0808-080b : ACPI timer
  0810-0815 : ACPI CPU throttle
0880-08bf : 0000:00:1f.0
0cf8-0cff : PCI conf1
4000-40ff : PCI CardBus #09
4400-44ff : PCI CardBus #09
4800-48ff : PCI CardBus #0d
4c00-4cff : PCI CardBus #0d
bce0-bcff : 0000:00:1f.2
  bce0-bcff : uhci_hcd
bfa0-bfaf : 0000:00:1f.1
  bfa0-bfa7 : ide0
  bfa8-bfaf : ide1
c000-cfff : PCI Bus #01
dc00-dcff : 0000:02:03.0
  dc00-dcff : Maestro3
e000-efff : PCI Bus #08
  e800-e8ff : 0000:08:08.0
  ecb8-ecbf : 0000:08:08.0
  ecc0-ecff : 0000:08:04.0
    ecc0-ecff : eepro100

As you can see, the serial driver will grab the ports the smsc-ircc2 likes.  I
already have init.d/irda being started at boot & init.d/pcmcia being started at
default levels (yes, reversed but required for smsc-ircc2 to acquire it's
preferred ports & irq).

Now.  I had the serial & serial_cs compiled statically but as of kernel-2.6.7,
the resources seem to be more strict.  So I compiled serial drivers as modules
and voila.  Everything appears to be running happy again.

Here's what ioports/dmesg now look like with irda-smsc-ircc2 working:

# cat /proc/ioports 
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0280-0287 : smsc-ircc2
02f8-02ff : smsc-ircc2
03c0-03df : vesafb
03e8-03ef : serial_cs
03f6-03f6 : ide0
03f8-03ff : serial
0800-087f : 0000:00:1f.0
  0808-080b : ACPI timer
  0810-0815 : ACPI CPU throttle
0880-08bf : 0000:00:1f.0
0cf8-0cff : PCI conf1
4000-40ff : PCI CardBus #09
4400-44ff : PCI CardBus #09
4800-48ff : PCI CardBus #0d
4c00-4cff : PCI CardBus #0d
bce0-bcff : 0000:00:1f.2
  bce0-bcff : uhci_hcd
bfa0-bfaf : 0000:00:1f.1
  bfa0-bfa7 : ide0
  bfa8-bfaf : ide1
c000-cfff : PCI Bus #01
dc00-dcff : 0000:02:03.0
  dc00-dcff : Maestro3
e000-efff : PCI Bus #08
  e800-e8ff : 0000:08:08.0
  ecb8-ecbf : 0000:08:08.0
  ecc0-ecff : 0000:08:04.0
    ecc0-ecff : eepro100

dmesg/syslog
Jul 12 00:32:03 found SMC SuperIO Chip (devid=0x0e rev=01 base=0x002e): LPC47N252
Jul 12 00:32:03 SMsC IrDA Controller found
Jul 12 00:32:03 IrCC version 2.0, firport 0x280, sirport 0x2f8 dma=3, irq=3
Jul 12 00:32:03 No transceiver found. Defaulting to Fast pin select
Jul 12 00:32:03 IrDA: Registered device irda


When I get some time, I'll document this issue on my website.

Since everythign is working again, I'll try altering the config for pcmcia to
exclude this port range and to see if I can specify a port range for the serial
drivers during boot.  Once done, maybe I can then compile everything statically
again.  

Isn't there a way for us to make the kernel initialize devices in a certain
order oursevles, instead of having to specify port ranges or irqs or even
excludes?  Or does the kernel always load device drivers in a specific order?
Comment 3 Adrian Bunk 2006-01-01 04:39:16 UTC
Is this issue still present in kernel 2.6.14?
Comment 4 Roger 2006-01-02 17:44:16 UTC
I haven't the slightest idea as I no longer actively use any irda devices.

It would probably be a safe thing to leave this bug open as it has been a long
standing issue with conflicting drivers.
Comment 5 Eric L. 2007-04-15 07:40:52 UTC
Hi,

I've reported a very similar bug under Debian Etch (Kernel 2.6.18) and would be
happy to provide more information if this can help solve the issue:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391459

Thanks, Eric
Comment 6 Roger 2007-04-15 15:41:48 UTC
Thanks for contacting me on this.

Right. I remember a conflict with the kernel loading the drivers within
a specific order.

Basically, pcmcia would grab the irda port address and then the
smsc-ircc2 could not grab it's wanted address.

Disabled pcmcia, and irda would work.  So I changed the boot order
within init.d and started irda (set to "boot level") before pcmcia (set
to "default level").

Since I haven't used irda for the past year with my laptop, as it was
something i needed when using my old nokia irda phone for connecting to
the laptop via it's internal gprs modem or grabbing it's contacts.
Since I don't use the old nokia, I don't use the irda laptop feature.



On Sun, 2007-04-15 at 07:40 -0700, bugme-daemon@bugzilla.kernel.org
wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=3048
> 
> 
> 
> 
> 
> ------- Additional Comments From kernel.org@zorglub.s.bawue.de  2007-04-15 07:40 -------
> Hi,
> 
> I've reported a very similar bug under Debian Etch (Kernel 2.6.18) and would be
> happy to provide more information if this can help solve the issue:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391459
> 
> Thanks, Eric
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61

Sun Apr 15 15:34:40 PDT 2007

Comment 7 Eric Maryniak 2007-04-16 05:39:12 UTC
The following article may also be of value, since it contains problems and
workarounds of a similar nature for another IrDA module, nsc-ircc:

    http://www.thinkwiki.org/wiki/How_to_make_use_of_IrDA

Note that nsc-ircc and smsc-ircc2 do not share the same irq's.
The author suggests that the "ttyS0: LSR safety check engaged!" message (which
may need a more helpful re-formulation?) can in some cases also have to do with
the baud rate (being to high).

By the way (maybe not really relevant for the kernel devels, as it may have to
do with distribution specific packaging/fixes): on Fedora's 5 and 6 (2.6.20)
everythinks works ok, while Fedora 7 and openSUSEs 10.2 and 10.3 alpha 2 (also
2.6.20) ttyS0 (as used by a serial Palm Vx or mouse) it's broken again.

Regards, (yet another ;-) Eric
Comment 8 Natalie Protasevich 2007-09-18 01:06:11 UTC
Eric, is it still broken in the latest kernel?
Thanks.
Comment 9 Roger 2007-09-18 15:25:52 UTC
fyi: I haven't used the smsc-ircc2 device on my laptop for a year or so.
Comment 10 George Deligeorgis 2007-09-22 05:59:21 UTC
Gentoo amd64 kernel 2.6.22-r6
smsc_ircc2 will not load automatically
rmmod 8250 8250_pnp (these bind to 0x2f8)
and run 
modprobe -v smsc_ircc2 ircc_dma=1 ircc_irq=4 ircc_sir=0x2f8 ircc_fir=0x230
I got  the resources from /sys/bus/pnp/devices/00\:0a/resources
the id file in the same directory reads: SMCf010

The module loaded.correctly. Hope this helps

Comment 11 Jeff Garzik 2007-11-02 08:41:29 UTC
This is not a kernel problem but a load order / kernel configuration problem.

Note You need to log in before you can comment on or make changes to this bug.