Bug 3048
Summary: | (IRDA) smsc-ircc2: can't get sir_base of 0x2f8 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Roger (rogerx.oss) |
Component: | Network | Assignee: | Jeff Garzik (jgarzik) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | bunk, jt, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | >=2.6.6 | Subsystem: | |
Regression: | Yes | Bisected commit-id: |
Description
Roger
2004-07-11 09:32:12 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 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? Is this issue still present in kernel 2.6.14? 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. 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 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 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 Eric, is it still broken in the latest kernel? Thanks. fyi: I haven't used the smsc-ircc2 device on my laptop for a year or so. 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 This is not a kernel problem but a load order / kernel configuration problem. |