Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
Mikhail Gusarov [EMAIL PROTECTED] wrote: You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. The complete list of changes needed to turn off ieee80211 seems to be: # CONFIG_HOSTAP is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IEEE80211_CRYPT_TKIP is not set # CONFIG_IEEE80211_CRYPT_WEP is not set # CONFIG_IEEE80211_CRYPT_CCMP is not set # CONFIG_IEEE80211 is not set Or in other words HOSTAP and IPW2100, IPW2200 and HOSTAP (Prism) also needs to be disabled. Is the latter acceptable collateral dammage? I was under the impression that upstream had recently updated ieee80211. Is it still out of date in 2.6.14 ? Below is a patch that effects the change in the current 2.6.14 tree. Note that it probably will not apply cleanly as soon as any other changes are made to the configs due to some quirks in the way that split config. Note also that it consolodates some spurious arm and m68k configs for these options into the global config. Index: a/debian/arch/arm/config.s3c2410 === --- a/debian/arch/arm/config.s3c2410(revision 4929) +++ a/debian/arch/arm/config.s3c2410(working copy) @@ -279,11 +279,7 @@ # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers Index: a/debian/arch/arm/config.footbridge === --- a/debian/arch/arm/config.footbridge (revision 4929) +++ a/debian/arch/arm/config.footbridge (working copy) @@ -305,11 +305,7 @@ # CONFIG_VLSI_FIR is not set # CONFIG_VIA_FIR is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers @@ -687,7 +683,6 @@ # # CONFIG_NET_RADIO is not set # CONFIG_IPW_DEBUG is not set -CONFIG_IPW2200=m # # Wan interfaces Index: a/debian/arch/arm/config.ixp4xx === --- a/debian/arch/arm/config.ixp4xx (revision 4929) +++ a/debian/arch/arm/config.ixp4xx (working copy) @@ -437,11 +437,7 @@ # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers @@ -856,10 +852,8 @@ # # Wireless 802.11b ISA/PCI cards support # -CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW_DEBUG is not set -CONFIG_IPW2200=m CONFIG_HERMES=y # CONFIG_PLX_HERMES is not set # CONFIG_TMD_HERMES is not set @@ -871,7 +865,6 @@ # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support # # CONFIG_PRISM54 is not set -CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_PCI=m Index: a/debian/arch/arm/config.rpc === --- a/debian/arch/arm/config.rpc(revision 4929) +++ a/debian/arch/arm/config.rpc(working copy) @@ -251,11 +251,7 @@ # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers Index: a/debian/arch/m68k/config === --- a/debian/arch/m68k/config (revision 4929) +++ a/debian/arch/m68k/config (working copy) @@ -344,7 +344,3 @@ CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_IEEE80211_CRYPT_CCMP=n -CONFIG_IEEE80211_CRYPT_TKIP=n -CONFIG_IEEE80211_CRYPT_WEP=n -CONFIG_IEEE80211=n Index: a/debian/arch/config === --- a/debian/arch/config(revision 4929) +++ a/debian/arch/config(working copy) @@ -585,7 +585,6 @@ CONFIG_USB_NET_AX8817X=m CONFIG_USB_YEALINK=m CONFIG_FUSE_FS=m -CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_PHYCONTROL=y # CONFIG_IPW_DEBUG is not set # CONFIG_EV64360 is not set @@ -601,7 +600,6 @@ CONFIG_INET_TCP_DIAG=m CONFIG_RAID_ATTRS=m CONFIG_USB_NET_CDCETHER=m -CONFIG_IPW2100=m CONFIG_DVB_USB_VP702X=m CONFIG_VIDEO_SAA6588=m CONFIG_CHELSIO_T1=m @@ -631,7 +629,6 @@ CONFIG_DRM_SAVAGE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_PHYLIB=m -CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_MARVELL_PHY=m CONFIG_SCSI_SATA_MV=m CONFIG_SND_GENERIC_DRIVER=y @@ -645,7 +642,6 @@ CONFIG_IP6_NF_TARGET_REJECT=m #
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 30, 2005 at 06:51:44AM +, Horms wrote: Mikhail Gusarov [EMAIL PROTECTED] wrote: You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. The complete list of changes needed to turn off ieee80211 seems to be: # CONFIG_HOSTAP is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IEEE80211_CRYPT_TKIP is not set # CONFIG_IEEE80211_CRYPT_WEP is not set # CONFIG_IEEE80211_CRYPT_CCMP is not set # CONFIG_IEEE80211 is not set Or in other words HOSTAP and IPW2100, IPW2200 and HOSTAP (Prism) also needs to be disabled. Is the latter acceptable collateral dammage? I was under the impression that upstream had recently updated ieee80211. Is it still out of date in 2.6.14 ? yes. 2.6.15 ipw2XXX are fine and with up2date ieee80211 stack. there we should really enable those. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 30, 2005 at 10:09:54AM +0100, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:51:44AM +, Horms wrote: Mikhail Gusarov [EMAIL PROTECTED] wrote: You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. The complete list of changes needed to turn off ieee80211 seems to be: # CONFIG_HOSTAP is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IEEE80211_CRYPT_TKIP is not set # CONFIG_IEEE80211_CRYPT_WEP is not set # CONFIG_IEEE80211_CRYPT_CCMP is not set # CONFIG_IEEE80211 is not set Or in other words HOSTAP and IPW2100, IPW2200 and HOSTAP (Prism) also needs to be disabled. Is the latter acceptable collateral dammage? I was under the impression that upstream had recently updated ieee80211. Is it still out of date in 2.6.14 ? yes. 2.6.15 ipw2XXX are fine and with up2date ieee80211 stack. there we should really enable those. Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote: On Wed, Nov 30, 2005 at 10:09:54AM +0100, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:51:44AM +, Horms wrote: Mikhail Gusarov [EMAIL PROTECTED] wrote: You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. The complete list of changes needed to turn off ieee80211 seems to be: # CONFIG_HOSTAP is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IEEE80211_CRYPT_TKIP is not set # CONFIG_IEEE80211_CRYPT_WEP is not set # CONFIG_IEEE80211_CRYPT_CCMP is not set # CONFIG_IEEE80211 is not set Or in other words HOSTAP and IPW2100, IPW2200 and HOSTAP (Prism) also needs to be disabled. Is the latter acceptable collateral dammage? I was under the impression that upstream had recently updated ieee80211. Is it still out of date in 2.6.14 ? yes. 2.6.15 ipw2XXX are fine and with up2date ieee80211 stack. there we should really enable those. Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe depends if d-i will base itself on 2.6.14 for next beta than it's maybe nicer to have those ancient than nothing. there are still some -rc expected, maybe we get a christmas present? ;) -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wednesday 30 November 2005 11:44, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote: Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe depends if d-i will base itself on 2.6.14 for next beta than it's maybe nicer to have those ancient than nothing. We will use whatever is in testing at the time of the release. So it depends very much on when 2.6.15 will be uploaded (and even if 2.6.14 will have moved to testing before then). Are there major changes from .14 to .15? If not, we should be able to change over to .15 relatively fast. My preliminary target for d-i beta2 is 2nd half of January. We'll need at least .14 in testing for the release. Cheers, FJP P.S. Expect an RC for 2.6.14-4 from me. From dmesg in vmware: kernel BUG at mm/slab.c:1807! invalid operand: [#1] pgp2Nf92jooKD.pgp Description: PGP signature
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 30, 2005 at 12:49:28PM +0100, Frans Pop wrote: On Wednesday 30 November 2005 11:44, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote: Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe depends if d-i will base itself on 2.6.14 for next beta than it's maybe nicer to have those ancient than nothing. We will use whatever is in testing at the time of the release. So it depends very much on when 2.6.15 will be uploaded (and even if 2.6.14 will have moved to testing before then). Are there major changes from .14 to .15? If not, we should be able to change over to .15 relatively fast. better ntfs support, up2date ipw2XXX, vfs support shared subtree, fbcon console rotation + usual bunch of fixes and driver upgrades. no acpi change. My preliminary target for d-i beta2 is 2nd half of January. We'll need at least .14 in testing for the release. .15 should come around christmas, so it should be early enough for all archs to focus on. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wednesday 30 November 2005 16:06, Maximilian Attems wrote: better ntfs support, up2date ipw2XXX, vfs support shared subtree, fbcon console rotation + usual bunch of fixes and driver upgrades. no acpi change. Nothing that should give us problems I think. Thanks. FB console rotation could be nice to play with :-) .15 should come around christmas, so it should be early enough for all archs to focus on. If it gets into Debian as quickly as .14 and does not draw the number of RC bugs that .14 seems to do, we should be fine. pgpdojiR6kZtk.pgp Description: PGP signature
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 30, 2005 at 12:49:28PM +0100, Frans Pop wrote: On Wednesday 30 November 2005 11:44, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote: Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe depends if d-i will base itself on 2.6.14 for next beta than it's maybe nicer to have those ancient than nothing. We will use whatever is in testing at the time of the release. So it depends very much on when 2.6.15 will be uploaded (and even if 2.6.14 will have moved to testing before then). Are there major changes from .14 to .15? If not, we should be able to change over to .15 relatively fast. .15 will bring a non-negligible amount of change to powerpc, going from ARCH=ppc|ppc64 to ARCH=powerpc, which may entail modifications in the boot-wrapper and kernel with builtin initrds, and maybe some subarch being broken or partially broken. But we are/will be working on the -rc releases in experimental, so hopefully this will work out fast, apus may only be there a couple of weeks after the .15 release though. My preliminary target for d-i beta2 is 2nd half of January. We'll need at least .14 in testing for the release. Should be nice, i think. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wednesday 30 November 2005 21:04, Sven Luther wrote: Are there major changes from .14 to .15? If not, we should be able to change over to .15 relatively fast. .15 will bring a non-negligible amount of change to powerpc, going from ARCH=ppc|ppc64 to ARCH=powerpc, which may entail modifications in the boot-wrapper and kernel with builtin initrds, and maybe some subarch being broken or partially broken. But we are/will be working on the -rc releases in experimental, so hopefully this will work out fast, apus may only be there a couple of weeks after the .15 release though. Well, to be honest I'm not too worried about ppc as it has good support. Please keep d-boot informed if anything really unexpected crops up. pgp3hYI63qhM4.pgp Description: PGP signature
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 30, 2005 at 11:58:17PM +0100, Frans Pop wrote: On Wednesday 30 November 2005 21:04, Sven Luther wrote: Are there major changes from .14 to .15? If not, we should be able to change over to .15 relatively fast. .15 will bring a non-negligible amount of change to powerpc, going from ARCH=ppc|ppc64 to ARCH=powerpc, which may entail modifications in the boot-wrapper and kernel with builtin initrds, and maybe some subarch being broken or partially broken. But we are/will be working on the -rc releases in experimental, so hopefully this will work out fast, apus may only be there a couple of weeks after the .15 release though. Well, to be honest I'm not too worried about ppc as it has good support. Yeah, but the change from ARCH=ppc | ARCH=ppc64, to a single re-unified ARCH=powerpc kernel will not go without glitch, especially for the lesser subarches (oldworld, prep, apus come to mind), and may cause some sever disfunction in even the mainline arches, let's hope this will be resolved before the 2.6.15 release though. I know i will already have to do some adaptation on the pegasos for the interrupt handling and the serial port for example. Please keep d-boot informed if anything really unexpected crops up. I will, no problem. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Thu, Dec 01, 2005 at 12:26:25AM +0100, Frans Pop wrote: On Thursday 01 December 2005 00:09, Sven Luther wrote: Yeah, but the change from ARCH=ppc | ARCH=ppc64, to a single re-unified ARCH=powerpc kernel will not go without glitch, especially for the lesser subarches (oldworld, prep, apus come to mind), and may cause some sever disfunction in even the mainline arches, let's hope this will be resolved before the 2.6.15 release though. Getting it in d-i beta2 may be an opportunity to get some testing exposure for lesser arches, so that may be worth considering even if there are some known issues. We could easily make a note about it in the errata. Hehe, i guess i will be able to test most of the lesser arches myself, except apus, and well, oldworld miboot will not work, and benh told me oldworld/bootx is currently broken, altough he hoped to have the fix in time for 2.6.15. Given the major impact on ppc, is it an option for the kernel team to upload 2.6.15 to experimental first, so we keep a little bit more room for maneuvering towards the d-i release? Nope, we will upload the -rc kernels to experimental, but i don't think we should upload the actual released kernels to experimental, those should go into sid, and preferably the day of the release. That said, we have a few weeks, and working on the -rc tree in experimental should help sort out all issues, hopefully. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
In gmane.linux.debian.devel.kernel Maximilian Attems [EMAIL PROTECTED] wrote: On Wed, Nov 30, 2005 at 12:49:28PM +0100, Frans Pop wrote: On Wednesday 30 November 2005 11:44, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote: Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe depends if d-i will base itself on 2.6.14 for next beta than it's maybe nicer to have those ancient than nothing. We will use whatever is in testing at the time of the release. So it depends very much on when 2.6.15 will be uploaded (and even if 2.6.14 will have moved to testing before then). Are there major changes from .14 to .15? If not, we should be able to change over to .15 relatively fast. Ok, in this case I am inclided to leave things as is in .14, and make changes as required, if any, to .15. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. -- Mikhail Gusarov ICQ UIN: 111575219 JID: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Sat, Nov 05, 2005 at 12:21:00AM +, Christoph Hellwig wrote: On Fri, Nov 04, 2005 at 12:29:20PM +0900, Horms wrote: do I take that comment to mean that upstream can't update the drivers but Debian can? And if so, do you recommend updating Debian's kernel packages, or putting the updates elsewhere? Well, we could upstream, but so far no one is annoyed enough to overrid the driver maintainer. This is outrageous. Do you know any contacts at Intel to whom we could complain? I guess there would be many people willing to write a nice email about how impractical (actually, insane) such a policy is? -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgptj6y6wwuGN.pgp Description: PGP signature
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Fri, Nov 04, 2005 at 01:51:24AM -0500, Joey Hess wrote: Horms wrote: I don't have a particular problem with disabling those drivers from the build. But the d-i guys might. I've CCed them for comment (and dropped the netdev CC). No d-i udebs contain ipw2200 or ieee80211. The system does allow building udebs containing externally packages kernel modules, although we've not done that yet, partly because externally packages kernel modules rately seem to be built in time to keep up with new releases of the debian kernels.. Thanks for the clarification. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
[dropping debian-boot from CC, they've indicated this isn't a packaging issue for them at this time] Hi, Sorry for the confusion surround this, I was not at all aware of the somewhat special state of ieee80211/ipw2200 upstream. Let me answer some questions, now I have done a little bit or research. Note these are the answers to the best of my knowledge, which is limited. If you know more, please add your knowledge below. 1. Why is ipw2200 so out of date in Debian's 2.6.14? ipw2200 is out of date in Debian's 2.6.14 because it is out of date in Linus' 2.6.14. I have been told by several sources that this is because of Intel not pushing the driver into the upstream tree untill it has gone through some certification process. Or at the very least, its fair to say that Intel are not pushing changes upstream as fast as a lot of people might like. So in short, there are newer versions of the driver floating around than what is in 2.6.14. 2. Why is ipw2200 in Debian's 2.6.14 source but not compiled. As I undestand it, the ipw2200 driver requires some non-free firmware to run. The firmware is not embeded in the code, so there is no problem with distributing it. But the driver isn't particularly useful (perhaps dosn't work at all?), so it isn't compiled. 3. Can you disable the ieee80211/ipw2200 drivers in 2.6.14 Unless I am very much mistaken, they are disabled. 4. Can you mangles the headers to make compilation of ieee80211-source and/or ipw2200-source easier? Given the unusual standing of these drivers, that is, they really are out of date in Linus' tree because the developers aren't pushing updates, I think we can consider a departure from the usual policy of only accepting upstream (that is Linus') changes. My prefered option would be a minimal patch to allow ieee80211-source and ipw2200-source to compile sensibly. However, if someone wants to maintain a backport of ipw2200/ieee80211 as a patch included in linux-2.6, then I think we should consider that. My main reservation there is that it might hold up releases. For insance, are we confident that updates to ipw2200/ieee80211 will be ready the day Linus releases 2.6.15? Also, someone needs to take responsibility for this task. Without that its going to end up a s broken patch in the tree. Ultimately the best option is to get newer versions of these drivers into Linus' tree. If there is any way that Debian can help with that, then thats help that should be given IMHO. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Fri, Nov 04, 2005 at 01:51:24AM -0500, Joey Hess wrote: Horms wrote: I don't have a particular problem with disabling those drivers from the build. But the d-i guys might. I've CCed them for comment (and dropped the netdev CC). No d-i udebs contain ipw2200 or ieee80211. The system does allow building udebs containing externally packages kernel modules, although we've not done that yet, partly because externally packages kernel modules rately seem to be built in time to keep up with new releases of the debian kernels.. We plan to change that though with the new external kernel module policy, and will probably add the building of a real .udeb into said policy. If this plan goes well, the external module .udebs will probably be there *before* the kernel .udebs in general :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Fri, Nov 04, 2005 at 12:29:20PM +0900, Horms wrote: do I take that comment to mean that upstream can't update the drivers but Debian can? And if so, do you recommend updating Debian's kernel packages, or putting the updates elsewhere? Well, we could upstream, but so far no one is annoyed enough to overrid the driver maintainer. I'd suggest merging a more recent driver into the debian kernel package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote: You ([EMAIL PROTECTED]) wrote: I've encountered the problem with 2.6.14 kernels: they are shipped with ancient version of ipw2200 drivers (1.0.0 while current version is 1.0.7) and ancient version of ieee80211 subsystem (copyrighted as 2004, so also outdated). This breaks compilation of module from ipw2200-source package (because it links against in-kernel ieee80211). H I assume the problem you are seeing is a headers problem. Ah, yes. The other problem is two copies ipw2200.ko ieee80211*.ko modules being installed: the ones included in kernel and others compiled as external modules. I suppose this may lead to the problems with depmod. Is there way to modularize builds to exclude ieee80211 or just disable it (along with ipw2200) because it is outdated and current vesion is shipped in ieee80211-source package? H Probably the best place to start is to ping netdev to find out if H there are any plans to update IPW2200 in Linus's tree. I've CCed H that list, hopefully someone can shed some light on this. So, having in mind the two levels of 'stablenesss': kernel 'stableness' and modules 'stableness' :) we should find the way to exclude discussed modules from the build, because in-kernel versions will always be, erm..., slightly (1.0.0 is mentioned only as 'stone age' in the mailing list of ipw2200 developers) outdated due to fact integration and testing gets some time in upstream kernels. I propose just to disable compilation of this drivers: everyone will be able to compile the recent version using ipw2200-source we provide. I don't have a particular problem with disabling those drivers from the build. But the d-i guys might. I've CCed them for comment (and dropped the netdev CC). -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 02, 2005 at 04:26:21PM +, Christoph Hellwig wrote: On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote: So, having in mind the two levels of 'stablenesss': kernel 'stableness' and modules 'stableness' :) we should find the way to exclude discussed modules from the build, because in-kernel versions will always be, erm..., slightly (1.0.0 is mentioned only as 'stone age' in the mailing list of ipw2200 developers) outdated due to fact integration and testing gets some time in upstream kernels. I propose just to disable compilation of this drivers: everyone will be able to compile the recent version using ipw2200-source we provide. The kernel drivers aren't stable but obsolete. Because of that ever distribution that supports it's users must patch in a more recent one, which is what we should do for debian aswell. It's a pity the braindead Intel policies don't allow us to have an uptodate driver in mainline. Christoph, do I take that comment to mean that upstream can't update the drivers but Debian can? And if so, do you recommend updating Debian's kernel packages, or putting the updates elsewhere? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote: So, having in mind the two levels of 'stablenesss': kernel 'stableness' and modules 'stableness' :) we should find the way to exclude discussed modules from the build, because in-kernel versions will always be, erm..., slightly (1.0.0 is mentioned only as 'stone age' in the mailing list of ipw2200 developers) outdated due to fact integration and testing gets some time in upstream kernels. I propose just to disable compilation of this drivers: everyone will be able to compile the recent version using ipw2200-source we provide. The kernel drivers aren't stable but obsolete. Because of that ever distribution that supports it's users must patch in a more recent one, which is what we should do for debian aswell. It's a pity the braindead Intel policies don't allow us to have an uptodate driver in mainline. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
