From: Martin D. <li...@md...> - 2004-01-21 18:26:21
|
On Wed, 21 Jan 2004, Sebastian Henschel wrote: > perhaps one of you can give me an idea why irda does not work on an ASUS > M2400N laptop with kernel 2.6.x. of course, i went through > http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/IrDA.html and the > howto. > > - using kernel 2.4.24 + xfs-patch runs fine in SIR-mode. when i try to SIR using irtty I assume? > load the driver for FIR, which seems to be nsc-ircc, i get: > > nsc-ircc, Found chip at base=0x02e > nsc-ircc, Wrong chip version ff No idea about NSC > now for kernel 2.6.1 + swsusp2 + acpi20031210, debian testing/suse 9.0: > > - the irda stuff is configured as modules. > - module 8250 is loaded and recognizes a NS16550A uart at ttyS1: > > ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A > > - when running irattach /dev/ttyS1 -s, i get: > > irattach: ioctl(SIOCGIFFLAGS): No such device Please make sure the sir_dev and irtty-sir modules are loaded. In case of problems with autoloading just load them by hand. > to be sure, i also tried ttyS0-S4. there is no option in the bios to set > up the infrared port. i looked at the descriptions of the patches not > yet in 2.6, but they are not obviously relevant. and could someone please > put them altogether into one patch? currently, there are 26 not yet > merged patches and to apply them in single is a real pita. Most of them are dongle related and are irrelevant in your case. None of the post-2.6.1 irda patches are expected to be related to the error message above from the ioctl. Please, make sure CONFIG_IRDA_DEBUG is enabled and after loading the irda module enable irda loglevel three (echo "3" > /proc/sys/net/irda/debug). Then make sure sir_dev and irtty-sir modules are/get loaded. Now, when repeating the irattach there should be some messages printed in syslog/dmesg. Please post them, this should help identifying the cause. > - it looks better, when trying FIR. after > > setserial /dev/ttyS1 uart none > rmmod 8250 Ok. > the module for FIR is loaded succesfully: > > nsc-ircc, Found chip at base=0x02e > nsc-ircc, driver loaded (Dag Brattli) > IrDA: Registered device irda0 > nsc-ircc, Found dongle: HP HSDL-1100/HSDL-2100 > > but when i irattach irda0 -s: > > nsc-ircc, unable to allocate irq=3 > > > looking at /proc/interrupts, i get: > > 3: 1 XT-PIC ICH4, Intel 82801DB-ICH4, yenta Looks like the irq=3 is shared with other stuff and for some reason nsc-ircc failed to request it. Seems one if the irq=3 users (ICH4, yenta, nsc-ircc itself) doesn't agree on sharing it. Note there was a patch from Stephen Hemminger the other day to improve the nsc-ircc's interrupt handler for sharing interrupts. But I think in your case where nsc-ircc already fails to register the handler it's either nsc-ircc needs more fixing or one of the other drivers using irq=3 are in the way. But I'm not familiar with nsc-ircc and without the hardware this is only my interpretation of the symptoms. > ok, i can unload the pcmcia stuff, but the southbridge? afterwards i So you tried without success with yenta unloaded? Just to confirm - I'm pretty sure it won't help since yenta is a pci driver in the first place so this being the culprit with interrupt sharing is rather unlikely, IMHO. Wrt. the ICH4 - do you have an ide which driver might have requested the irq - might be IDE, SMM or ACPI or something? > tried to boot a kernel with enabled Local-APIC and I/O-APIC which > totally failed, even acpi=off and noapic did not boot it. ususally i > disable the APICs, because they interfered with the external VGA on > this type of laptop in former times. Was ACPI compiled in the kernel? If not, could you try booting a kernel with ACPI support (but withou APIC) and acpi not disabled. By luck this might change the interrupt routing sufficiently to help you out. > - the next funny thing is, when i unload nsc-ircc and reload 8250, i get: > > ttyS1 at I/O 0x2f8 (irq = 3) is a 8250 > > where has the NS16550A gone? Interesting. In fact I was even surprized above when the 8250 driver reported NS16550A (not generic 16550A). Looks like there is some means there to detect the NS flavour and the detection failed because nsc-ircc didn't restore something there - just speculation. > - CONFIG_IRDA_DEBUG is enabled, but the system does not seem to show more > info than without debugging. See above: increase the irda debug level > - if i recall correctly, with 2.6.0 on a suse 9.0, irattach had problems > with SIR and tcgetattr which transformed to no such device now. though > i am not really sure about that. 2.6.0-vanilla or -suse? But anyway, we should get your 2.6.1 working. > - irda-utils is 0.9.15 from debian, 0.9.16 from jean's website (0.9.16 > for debian should hit the shelves today or tomorrow). btw, there is no > 0.9.17-pre3 for download, the link seems to be broken. AFAIC -pre2 is the latest one. > - i also tried loading irtty-sir and sir-dev by hand before > irattaching, but this made no difference. and no, they were not loaded > when trying FIR. Ah, ok. See above: we need the irda debug messages when irattach gets invoked. If it`s working with 2.4+irtty it _should_ work with 2.6+irtty-sir. Let's find out what went wrong. > - all other FIR drivers were tried, too. some load with neither error > nor success, some fail to load. Yes, PCI and USB drivers support hotplugging - they will always load just sitting there waiting for the hardware to appear... But it looks like what you have is NSC and should work with irtty-sir too. > - no there is no other serial port (at the outside, dunno for the chip) > and yes there is an infrared port to be seen. :) Well, sounds reasonable to assume, given it is working with 2.4 ;-) > - there is a compiler warning (gcc 3.3.2) when making the kernel: > > CC [M] net/irda/af_irda.o > net/irda/af_irda.c: In function `irda_setsockopt': > net/irda/af_irda.c:1894: Warning: comparison is always false due to > limited range of data type > > hm, setsockopt? set socket options? for a serial device, perhaps? > >:) Nope, for the irdaX network device. You can safely ignore this warning and IIRC one of the pending patches fixes this. Martin |