Since kernel-2.6.31, pci_find_device() is no longer available, even if PCI_LEGACY is used. I tried to patch ltmodem-20090420 by using pci_get_device() instead (just modifying the arguments). Although I expected problems with the proprietery assembler code, the result did boot and the device appeared (I currently have no phone cable) - however, this might be accidental and is certainly no clean solution. There seems to be a "martian" project which seems to provide the same functionality and which does not have the problem that it relies on pci_get_device(). I attach a preliminary ebuild which made the modem appear (as mentioned, I currently have no phone cable, so I did not really test it).
Created attachment 204139 [details] Ebuild for the ltmodem alternative martian The ebuild is a quick modification of the ltmodem ebuild. I did neither check the correctness of the license nor whether the SERIAL_8250 is required also for this project. Moreover, I did not check whether it should block ltmodem (although I suppose so, I did not set this block).
I just tried to build directly with the Martian sources against kernel-2.6.31 and seems there are now missing header files. Hard coding in the missing location of the header files resulted in numerous errors. I'll toss some votes onto this one and add myself to the CC list as I too have an Agere winmodem on my laptop.
Surprisingly, I got a good compile using this ebuild. The source I was trying to compile were the tarballs dated "martian*-20080617" I'll perform some testing with the modem device when I get more time.
The SMP restriction (noted in your ebuild) seems problematic as far as a long term solution goes. Can you provide some details about how you patched ltmodem-20090420? I would like to take a closer look at that (and do some testing). Thanks.
OK. I should have read more before replying. I just spent some time looking at Changelogs, mailing lists, and various other references. It seems the original ltmodem does not support SMP, but martian does (according to the Changelog). However, martian has no fax support, and the original ltmodem does. Also, someone (just a few days ago) posted some patches for the original ltmodem (but seems less interested in porting those patches to martian. This is one of the most difficult to navigate mailing lists I have ever seen, but look here (the ones at the bottom whose subjects begin with "[PATCH n/9]": http://linmodems.org/cgi-bin/ezmlm-cgi?1:iis:35527:201001
(In reply to comment #4) > The SMP restriction (noted in your ebuild) Actually, I made the ebuild based on the ltmodem ebuild. Since both use the same proprietary binary code (and I cannot test anyway), I supposed that martian would have the same restriction and just left the comment in without seriously thinking about it.
I tried this module on my laptop modem and no serial device was created (ie. /dev/ttyS*) upon loading. After searching bugs.gentoo.org, found throw_away_2002 had submitted a working ltmodem ebuild (See Bug #300047) for kernel-2.6.32. I fixed it up to include the kernel patch upon detection and ltmodem now works again for me.
BTW, my laptop modem is a mini-pci intel (e100) with an Agere 56k modem chipset. (I can further submit the chip model numbers if anybody is curious.)
Think I found an issue where "emerge -C martian" leaves behind the *.ko module file. Also, martian conflicts & seems to prevent ltmodem from finding & creating the the ttyS* device file. Seems like a nobrainer for a kernel dev, but likely overlooked.
(In reply to comment #9) > Think I found an issue where "emerge -C martian" leaves behind the *.ko module > file. This is supposed to be so for kernel modules, since /lib/modules is by default listed in CONFIG_PROTECT. You have to set CONFIG_PROTECT=-* if you want to override this default. > Also, martian conflicts & seems to prevent ltmodem martian is supposed to be an alternative to the ltmodem driver; they are not meant to be installed both.
Created attachment 221405 [details] net-dialup/martian-modem/martian-modem-20080625.ebuild OK, polished the ebuild a bit, so enjoy. Will attach the initscript later, when finished. :)
Created attachment 221407 [details, diff] files/martian-modem-20080625-include_2.6.32-scheduler.patch
Created attachment 221429 [details, diff] files/martian-modem.init.d initscript
Created attachment 221431 [details] files/martian-modem.conf.d configuration file
Created attachment 221433 [details] net-dialup/martian-modem/martian-modem-20080625.ebuild OK, I added the Debian "homepage" since the Israeli site has been completely unreachable for me for quite a while. Also a quick fix for compile on amd64 (no, won't work on no-multilib profile :P)
The last time I tried martian for my modem, it never picked up the device file, but did associate it with the pci device. lspci -vvvv 08:08.0 Communication controller: Agere Systems WinModem 56k (rev 01) Subsystem: Actiontec Electronics Inc LT WinModem 56k (MiniPCI Ethernet+Modem) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 10 Region 0: Memory at f8ffec00 (32-bit, non-prefetchable) [size=256] Region 1: I/O ports at ecb8 [size=8] Region 2: I/O ports at e800 [size=256] Capabilities: [f8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: ltmodem Kernel modules: martian_dev, ltmodem kernel: bus: 'pci': add driver ltmodem kernel: bus: 'pci': driver_probe_device: matched device 0000:08:08.0 with driver ltmodem kernel: bus: 'pci': really_probe: probing driver ltmodem with device 0000:08:08.0 kernel: ltmodem 0000:08:08.0: PCI INT A -> Link[LNKD] -> GSI 10 (level, low) -> IRQ 10 kernel: ttySV0 at I/O 0xecb8 (irq = 10) is a VUART kernel: device: 'ttySV0': device_add kernel: PM: Adding info for No Bus:ttySV0 kernel: ltmodem: added device 11c1:448, base=0xe800, comm=0xecb8, irq=10 (Modem Device ID is on the last line.) I'm somewhat stupified as to the fact both, ltmodem and martian supposedly use the same binary code, martian being abandoned from what you just stated -- and ltmodem is just hanging being unmaintained. Also, the fact Martian omits most functionality. Also, throw_away's Bug #300047 fixes ltmodem-20090420 along with my maintenance. Although I rely on smp only for building and distributing kernels, I don't explicitly have the modem installed on smp h/w, so nosmp used to work with ltmodem and smp enabled kernels -- until recently -- kernel updates? -- nosmp kernel boot parameter no longer hack/fixes.
Regards to comment #5 concerning smp support, a Changelog noting ltmodem-8.31b1.tar.gz containing some of the first SMP code. Diff this against the version stating "ltmodem-8.26b1tar.gz" no smp code, might give you the changes required, whether they're strictly binary related, or source code related. I couldn't find any 8.31 versions to download & diff. Also, seems I had to read the fine manual to find one needs to also run a binary "martian" to create a device file called /dev/ttySM0 -- wonder if it has anything to do with begging for S&M??
Comment on attachment 204139 [details] Ebuild for the ltmodem alternative martian Obsolete by martian-modem-20080625.ebuild
OK. martian-modem-20080625.ebuild works here on my Dell Inspiron 8100. Getting use to running a binary after loading the driver was the issue. And, I can verify martian-modem --smp works on a single cpu laptop using a smp enabled kernel. For which, ltmodem currently doesn't, even with nosmp kernel boot parameter, unless i fully rebuild the kernel. One other note, the "*.d" at the end of the files seems a little unecessary, but it's just my opinion as it looks funny -- even after grepping /usr/portage for similar. "*.init" & "*.conf" seem just fine IMO. Cheers!
(In reply to comment #19) > OK. martian-modem-20080625.ebuild works here on my Dell Inspiron 8100. > Getting use to running a binary after loading the driver was the issue. `rc-update add martian-modem default` and it will run automatically on every boot :) I didn't add this to elog info since it seemed kinda obvious to me, it's the same thing you do for anything that provides its own initscript. Oh well :) > And, I can verify martian-modem --smp works on a single cpu laptop using a smp > enabled kernel. For which, ltmodem currently doesn't, even with nosmp kernel > boot parameter, unless i fully rebuild the kernel. Glad to hear it works.
Created attachment 223113 [details] net-dialup/martian-modem/martian-modem-20080625.ebuild Tell people about the initscript to avoid confusion. *g*
<shrugs> most know what an init script is, most just are going to think "modprobe blah" is going to get them "/dev/blah" on modprobe. This is the first time I've seen a binary spawn a /dev ... well, guess except for lvm/lukes. Just really wish these ebuilds (ie. ltmodem, martian-modem, kompozer, ...) would get pushed into Portage a lot faster! Even binary games have a higher priority.
I found new source of martian-modem: http://linmodems.technion.ac.il/packages/ltmodem/kernel-2.6/martian/martian-full-20100123.tar.gz
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Michał. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 277289 [details] martian-modem-20100123.ebuild Version 20100123: - 2.6.32-scheduler.patch is no longer needed - This pulls the martian-full sources instead of from the debian mirror! - $PN-$PV (blah) may need work, but works fine, and might be just fine - during/after compile, something tries to create a link, but is already existing (within emerge output), but is only a warning & continues. In brief, this 2010 version ebuild might need tidying, but might be fine & dandy as is. Also, I haven't testing it's functionality, but I do know 2008 version works here for sure. If you try it, please post your experience. (works or doesn't work) (Kinda got bored and decided to give this ebuild a quick whirl.)
Here are some clarifications for this martian-modem driver. MARTIAN-MODEM-FULL-20080617 ONLY FOR OLDER KERNELS Page.h header support was supposedly yanked from kernel's >kernel-2.6.20? As such, martian-modem-full-20080617.tar.gz compiles and works for earlier kernels. (From what I hear a from Paco (gentoo-dev), we no longer want packages only supporting older kernel versions. As such, we should deprecate these old files. However, martian-modem-20100123.tar.gz is mirrored at one location, while martian-modem-20080625 appears to be mirrored at several redundant locations.) MARTIAN-MODEM-FULL-20100123 ONLY FOR >KERNEL-2.6.20 The Makefile within martian-modem-full-20100123.tar.gz tarball is hard-coded to check and compile only for >kernel-2.6.20. Simply comment these lines out within the Makefile and use the Portage ebuild built-in kernel version checking. /DEV/TTYSM0 REQUIRES TWO PROCESSES FOR THE DEVICE TO BE CREATED! The package requires two processes to occur in order to create the /dev/ttySM0 device for dialing out on. First, modprobe or insmod martian_dev.ko and then run modem/martian_modem. The "martian_modem" binary will then create the /dev/ttySM0 device and continue to run in the foreground. (This is why the Attachments contain a init.d and conf.d files.)
Created attachment 326044 [details] martian-modem-20100123-makefile.patch This patches the main Makefile to exclude it's kernel version checking. (I merrily commented-out the kernel version checking related statements.) Basically, martian-modem-20100123's main Makefile tries to check for >kernel-2.6.20 and stops if it fails to be satisfied. However, this Makefile is broken with gentoo systems for some reason, and furthermore, the kernel version checking should/can be handled within the ebuild provided functions.
Created attachment 326046 [details] martian-modem-20100123-r1.ebuild Updates to martian-modem-20100123.ebuild-r1. - Default Makefile is broken, and fixed by commenting kernel version checking related statements and allowing ebuild functions to handle this. - Updated SRC_URI to the exact location of the tarball instead of using a mirror/bouncer.
martian-modem-20100123-r1 works on x86. *TODO: No docs are installed! From my view, "Concepts" and "README" should be included and maybe scripts/wv.conf? After further comparing the docs, INSTALL should also be included as it includes further insight (x86/64) and requires "Check Carrier = No" within wvdial config. *TODO: I don't have 64 bit platform yet, but the ebuild requires a check for 32bit (x86) build environment. For 64 bit platforms, ensure the 32 bit build environment exists.
OK, probably I won't be able to look at this until probably next week because during week I am in the lab around 9 hours and this weekend I will go to my home... then, probably next weekend I will be able to take care of it. Anyway, I also CC proxy-maint people as maybe some of that team can look at this before ;)
+*martian-modem-20100123 (15 Dec 2012) + + 15 Dec 2012; Pacho Ramos <pacho@gentoo.org> + +files/martian-modem-20100123-makefile.patch, +files/martian-modem.conf.d, + +files/martian-modem.init.d, +martian-modem-20100123.ebuild, +metadata.xml: + Add alternative for net-dialup/ltmodem maintained by Roger (#285016)
