tags 348975 + moreinfo thanks #include <hallo.h> * David Liontooth [Fri, Jan 20 2006, 12:02:10AM]: > Package: sl-modem-daemon > Version: 2.9.9d+e-pre2-2 > Severity: normal > > > This version of the sl-modem source and daemon doesn't appear to create > a logical device for the modem. After inserting the module I get this in > dmesg: > > slamr: SmartLink AMRMO modem. > slamr: probe 10b9:5457 SL1800 card... > PCI: Enabling device 0000:00:08.0 (0000 -> 0003) > ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11 > ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKG] -> GSI 11 (level, low) -> > IR$slamr: mc97 codec is SIL27 > slamr: slamr0 is SL1800 card. > > Does this mean the device is now /dev/slamr0? It is not created (I'm > using udev). When I start the daemon, I get this:
It should be created. If it is not created, your kernel has a problem. Sometimes I see similar symptoms with 2.6.14.2 after the ALSA driver has been loaded once. It looks like if the device is locked by the ALSA driver and then slamr loads, then it recognisses the hardware (exactly like in your messages) but cannot allocate the PCI ressources and so does not register a driver, though messages are printed. I have also seen a situation where apparently snd-intel8x0m driver died - it was displayed as busy and did not release the modem but disappeared from procfs. And so the slamr module was not running properly either, only the reboot did help. > Starting SmartLink Modem driver for: slamr0. > Creating /dev/modem symlink, pointing to: /dev/ttySL0. > > However, there is no /dev/ttySL0. Perhaps the ALi5451 audio controller > is not supported by the current driver? It used to work fine. Hmmm. May be an udev problem (which version? Upgrade to 0.080). May be a silent failure of slmodemd (since it should have created the ttySL0 symlink). Or the hardware locking problem described above. The only relevant change in this release is the move to new style sysfs methods which became mandatory with kernel 2.6.13. However the old-compatible code should still work. Please try: a) upgrading the kernel b) watching output of "udevmonitor --env" while slamr loads. It should print MAJOR and MINOR numbers somewhere. c) running slmodemd manually and look what it does. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
