Description of problem: I and many people use an usermode usb adsl modem driver for ECI-chipset based modems. This driver needs kernel 2.6 to be patched ( http://eciadsl.flashtux.org/download/beta/2.6.x-usb.patch ) to work. It would be a pity to force people who use that driver to patch and recompile the kernel Version-Release number of selected component (if applicable): kernel >= 2.6.0 How reproducible: Always Actual results: Patch not included in distribution kernel rpm. Expected results: Patch included
do you know why this patch hasn't been submitted for inclusion in the kernel.org kernel ?
No sorry, I have no idea... :-( Another problem is that the driver maintainer never hacked 2.6 code and i can't reach the patch maintainer
There's a new: an eciadsl driver developer proposed this patch: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg21746.html that guy says that interval of iso urb doesn't get initialized I have to say that both patches do not resolve a problem: if you detach the modem before the driver starter exits, the comp gets locked. It looks like a deadlock in interrupt system...
Hello! There are good news! As you can see from http://eciadsl.flashtux.org/index.php?lang=en&id=171 the bug of linux 2.6 about ISO URB has been resolved in 2.6.7-rc2 (havent tested it yet, I'm still downloading 2.6.7-rc3)... Please, whatever they did to the kernel, backport it! :)
please try the 424 kernel from http://people.redhat.com/arjanv/2.6/
Well done! The modem works great! Thank you very much! But there is still something weird (apart the wrong disk geometry guessing, but this is another bug)... Well, I made a "service" that starts the modem at boot and I probably made a mistake while giving it the stopping priority so the kernel sends some "Badness" message... This doesnt happen if I stop the driver before I reboot/halt the machine. I know there's something wrong in the script I built but I guess this shouldn't happen anyway. Look this happens _NOT_ only on your kernel but also on patched <2.6.7-rc2 kernels (vanilla and not) and on unpatched >= 2.6.7-rc3 kernels. The only difference is that on your 424 kernel the Badness weirdly isn't reported on /var/log/messages*. This is the output: Sending all processes the TERM signal... Badness in local_bh_enable at kernel/softirq.c:136 [<0212407a>] local_bh_enable+0x39/0x5c [<42f0499e>] ppp_sync_push+0xd2/0x149 [ppp_synctty] [<42f044aa>] ppp_sync_wakeup+0x1d/0x35 [ppp_synctty] [<021d549f>] do_tty_hangup+0x12d/0x34c [<021d652d>] release_dev+0x1c0/0x53f [<0222e096>] usb_unbind_interface+0x41/0x50 [<021f4a8d>] device_release_driver+0x3c/0x46 [<0222e27e>] usb_driver_release_interface+0x2c/0x40 [<02235b32>] releaseintf+0x76/0x8f [<021d6bc6>] tty_release+0x29/0x4e [<02152baf>] __fput+0x3f/0xe3 [<0215189c>] filp_close+0x59/0x5f [<02122006>] put_files_struct+0x57/0xaa [<02122b45>] do_exit+0x211/0x390 [<02122dc0>] sys_exit_group+0x0/0xd [<0212986b>] get_signal_to_deliver+0x34c/0x372 [<02107208>] do_signal+0x4e/0xbb [<02160dc3>] file_ioctl+0x167/0x17b [<02161010>] sys_ioctl+0x239/0x243 [<0210729d>] do_notify_resume+0x28/0x37 [ OK ] Well that's all... Anyway thanks a lot! :)
the ppp trace should now also be fixed. if not, please open a seperate bug for that. thanks.