Bugzilla – Bug 113038
Failure to load slamr module
Last modified: 2005-09-09 15:51:52 UTC
The module slamr can't be loaded: slamr: Unknown symbol class_destroy slamr: Unknown symbol class_create slamr: Unknown symbol class_device_create slamr: Unknown symbol class_device_destroy
The module's license is MODULE_LICENSE("Smart Link Ltd."); The symbols listed above are exported to GPL modules only. So we won't be able to support the driver in 10.0 unless SmartLink changes their license.
Well, but this module is chosen by YaST. If this can't work, we should disable the yast functionality.
Greg, can this be worked-around somehow in the module?
You can simply remove class_* stuff from the code. But this will remove the entries in sysfs, too, of course, so udev won't work together... BTW, I'll be possibly able to try snd-intel8x0m instead of slamr.
*** Bug 113165 has been marked as a duplicate of this bug. ***
Takashi, can you elaborate - is the snd-intel8x0m driver a fully functional replacement for slamr?
snd-intel8x0m, snd-via82xx-modem and snd-atiixp-modem drivers provide the ALSA interface to access to the AC97 modem. Then user-space slmodemd talks with the device (when started with a specific option). Since the binary-only part belongs only to slmodemd, the kernel modules are all clean GPL. I'm not sure whether all devices can be covered by ALSA modem drivers. Need to check PCI table. Nevertheless, we don't provide a way to configure these modules on YaST yet...
This is a regression from 9.1 and 9.2 at least, and means that Novell employees (like me) with a corporate Thinkpad notebook won't be able to upgrade. Raising severity.
I don't like a pingpong game, but this isn't a bug I should solve. I guess it's too late to build up the yast configurator for ALSA modem drivers. Thus we need to fix slarmr somehow. So I'll pass this to Marian :)
Kay, what do you think about a /etc/udev/static-devices.d/, much like the /etc/modprobe.d/? That would allow sane management of the entries from packages and other tools.
How is that related to this bug? No, I don't want to spread this hack all over the packages. For now I want all the static crap in the udev package itself. Most cases are just "bugs" or lazy subsystem maintainers. I will continuously bug the people to fix it instead of playing old tricks here.
The problem is that this driver can't use kernel sysfs API because of GPL restriction. Thus the device wouldn't be created if the driver is patched to remove the access to class_* functions.
With all the static nodes in udev everybody will get them unconditionaly.
I think simply adding to static_devices.txt is safer at this stage. Also, I agree with Kay, that the static devices should be as restricted as possible.
I think there should be as few static devices under /dev as possible. For virtual devices and now also for devices with non-GPL drivers there is no other way. I maintain four such modem drivers and I don't feel comfortable poluting the /dev with the static nodes unless neccessary, ie when the customer installs the rpm.
If the module is crippled that way, why not add the stuff to the slmodemd init script then? That sounds like the best option to me. I still try to avoid providing a generic infrastructure create static nodes. It should be a uncomfortable and well reasoned exception, otherwise it will end in the same mess we are currently try to get rid of.
Ok, I will do that for the slmodem. The others are pure kernel driver without initscripts, the nodes will have to be in udev then.
I'll be able to do basic tests (w/o actual dialing in) at any time, and could do functionality tests next Friday and Saturday if you want.
fixed, could you please test, Gerald?
Thanks, Marian. I installed a the current autobuild kernel and mbuilt your latest smartlink-softmodem submission, but unfortunately I still get the following, even after a reboot: # rpm -qa | egrep 'kernel|smart' kernel-default-nongpl-2.6.13-3 kernel-default-2.6.13-3 smartlink-softmodem-2.9.10-13 kernel-default-debuginfo-2.6.13-3 km_smartlink-softmodem-2.9.10-13 # /etc/init.d/slmodemd status Status of SmartLink Modem driver: unused # /etc/init.d/slmodemd start Starting SmartLink Modem driver: FATAL: Module slamr not found. FATAL: Module slusb not found. startproc: exit status of parent of /usr/sbin/slmodemd: 255 failed
The fix has not been checked in yet, you can grab the source from /work/src/done/STABLE/smartlink-softmodem
That's what I used for last night's testing (cf. the comment on me mbuilding your latest smartlink-softmodem submission) in comment #22.
I confirmed this today by installing Beta 4 and then replacing the smartlink-softmodem package by /work/built/mbuild/lifschitz-gp-3/.
has been caused by a typo in the patch and the devices created staring from 1 instead of 0, fixed
there was yet another error in the initscript, the device has to be with full path, ie /dev/...