Hi there, The ebuilds currently in the tree for the BeWAN ADSL modem fail (at least for me with the PCI version of the modem) fail with the output below. This appears to be due to an API change within the kernel but is alleged to be fixed with 0.9.3 of BeWAN's drivers. This is discussed at http://kerneltrap.org/node/5955 The updated drivers are available from BeWAN's website: http://www.bewan.com/bewan/users/downloads/index.php http://www.bewan.com/bewan/drivers/A1012-A1006-A904-A888-A983-0.9.3.tgz Will test immediately. TIA, Stroller. CC [M] /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_pci/../unicorn_atm/unicorn_atmdrv.o In file included from /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_atm/unicorn_atmdrv.c:25: /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/amu/amas.h:373:5: warning: "WIN32" is not defined /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/amu/amas.h:389:5: warning: "WIN32" is not defined /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_atm/unicorn_atmdrv.c: In function `unicorn_atm_stopdevice': /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_atm/unicorn_atmdrv.c:200: warning: implicit declaration of function `shutdown_atm_dev' /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_atm/unicorn_atmdrv.c: In function `snd_poll': /var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_atm/unicorn_atmdrv.c:507: error: too few arguments to function `skb_unlink' make[2]: *** [/var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_pci/../unicorn_atm/unicorn_atmdrv.o] Error 1 make[1]: *** [_module_/var/tmp/portage/bewan-adsl-0.9.0/work/unicorn/unicorn_pci] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.15-gentoo-r1' make: *** [modules] Error 2 !!! ERROR: net-dialup/bewan-adsl-0.9.0 failed. !!! Function linux-mod_src_compile, Line 505, Exitcode 2 !!! Unable to make KERNEL_SOURCES=/usr/src/linux KVERS=2.6.15-gentoo-r1 modules. !!! If you need support, post the topmost build error, NOT this status message.
fixed in cvs. I hope it works, 'cause I don't have the hardware to test on it. If not, let me know. btw, the tarball have a really funky name. what were they thinking?!?
Thanks! This compiles great here. I actually have a separate issue with SMP which the author at BeWAN has addressed separately, so I'll be installing the driver manually until next release, I think. Will update at that time.
Can the SMP issue be fixed within the ebuild?
Created attachment 79417 [details, diff] Fixes my problem with Unknown symbol set_cpus_allowed Don't know how this affects non-SMP users & other kernels, tho'!
Yeah, the fix could easily be applied to the ebuild - it's simply commenting out one line. Patch attached. I don't really know enough about it to say whether it'd be safe for other peopl, tho'. I think 0.9.3 would probably be safe for =< 2.6.14, but not sure whether still so with this fix applied? Please also note that I'm not in a position to fully test this driver at the moment - the card is installed in one of my machines & it now modprobes fine & the `unicorn_status ` and `unicorntest` tools both seem to behave OK but I'm not able right now to disconnect my current router & take my LAN offline to test. Hope to be able to do so within a week or two. For the benefit of otheres, the problem that this fix addresses is failure of modprobe and "unicorn_pci_eth: Unknown symbol set_cpus_allowed" in `dmesg`
your patch uncomment the line set_cpus_allowed line! are you sure it isn't the reverse? it looks pretty harmless to me. presumably, set_cpus_allowed force the driver to run only on the first processor (the driver's code probably isn't thread safe), which in case of a non-SMP machine is also the only one.
Created attachment 79418 [details, diff] Ooooops! Yes, here's ther corrected patch Ooops, yes, my bad. I guess it'll be obvious to you that I don't need to make patches very often!! The only thing I had to do to fix my problem with "Unknown symbol set_cpus_allowed" was to COMMENT OUT that line (not uncomment it, as it's not commented in the SRC_URI)
This patch looks dangerous to me. set_cpus_allowed(k->thread,CPU_MASK_CPU0) force the driver to run on a single processor. Please post here your kernel version and current .config . I think the driver cannot find the symbol because your current kernel is compiled without CONFIG_SMP while your driver is compiled against a kernel with CONFIG_SMP.
$ zcat /proc/config.gz | grep -i smp # CONFIG_X86_BIGSMP is not set CONFIG_SMP=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_SMP=y $ uname -a Linux quattro 2.6.15.1 #1 SMP Thu Feb 9 07:53:59 GMT 2006 i686 Pentium II (Deschutes) GenuineIntel GNU/Linux $ lsmod | grep uni unicorn_pci_eth 691600 0 $ ifconfig dsl0 dsl0 Link encap:Ethernet HWaddr 00:63:96:D6:66:0A BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Sorry, Alin, but I _am_ clueful enough to recompile my driver for the current kernel - and have done so a number of times now. I only commented out this line after being advised to by the driver's author. Running a non-SMP system would be quite an inconvenience for me - and not something I'd be likely to undertake - as this system is an old quad-Xeon Penitum II. I have to confess I am sceptical about this "patch" myself, which is why I didn't post it as Comment #2 and obviously hope things'll be fixed in the next release.
Strange thing. Probably is generated by the EXPORT_SYMBOL_GPL(set_cpus_allowed). The patch is included in 0.9.3-r1. Please let me know if you experience any instabilities on your SMP configuration.
