Bug#535922: firmware-nonfree: Need to include 'advansys' firmware
Package: firmware-nonfree Version: 0.17 Severity: important Starting with Linux 2.6.30, the advansys firmware is not built into the kernel, but loaded. This firmware is BSD-licensed so it's safe to put it in non-free (it has no source so it's not free). These are the four files needed: 3550.bin 38C0800.bin 38C1600.bin mcode.bin They go in /lib/firmware/advansys. It's in the linux/kernel/git/dwmw2/linux-firmware.git repo. It seems important to me that firmware-nonfree start distributing these files before the 2.6.30 kernel hits 'testing', in order that users of the advansys SCSI cards can have a smooth transition. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (499, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524382: firmware-linux: Package description written in broken English
Package: firmware-linux Version: 0.16 Severity: minor The package description for firmware-linux currently reads: This package contains the binary firmware for all firmwares which was formally shipped in the Linux image. Note subject-verb agreement problem (firmwares was) and sound-alike word confusion (formally instead of formerly). The package description SHOULD read as follows: This package contains the binary firmware for all firmwares which were formerly shipped in the Linux image. Thanks. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash firmware-linux depends on no packages. firmware-linux recommends no packages. Versions of packages firmware-linux suggests: ii initramfs-tools 0.92o tools for generating an initramfs ii linux-image-2.6.26-1-686 [lin 2.6.26-12 Linux 2.6.26 image on PPro/Celeron -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian's Linux kernel continues to regress on freedom
I'm not sure I can take the Debian kernel team seriously any more. http://wiki.debian.org/KernelFirmwareLicensing states, in part: Debian kernel team identifies the following three types of firmware, currently found in the Linux kernel: 1. Sourceless binary blobs with no license, no explicit permission to redistribute, or an explicit prohibition to redistribute. This category currently includes the dabusb, dgrs, emi62, keyspan, smctr, cops, emi26, and 3c359 drivers. Removal of these drivers will have minimal impact on the users, as they are believed to be unpopular and not likely to be required during the installation. It has been agreed within Debian kernel team, that the firmware in category 1 is not acceptable in Debian. It is the intention of the kernel team to prune the affected drivers from the upstream tarball. The most recent linux-source-2.6.22 contains the following files: drivers/media/video/dabfirmware.h drivers/net/drgs_firmware.c drivers/usb/misc/emi26_fw.h drivers/usb/misc/emi62_fw_m.h drivers/usb/misc/emi62_fw_s.h drivers/usb/serial/keyspan_mpr_fw.h drivers/usb/serial/keyspan_usa*_fw.h (11 files) drivers/net/tokenring/smctr_firmware.h drivers/net/appletalk/cops_ltdrv.h drivers/net/appletalk/cops_ffdrv.h drivers/net/tokenring/3c359_microcode.h In other words, *all* of the above drivers. It's even worse than that. Look at the information about drgs: may 20: Dear Andres: After further research, we found that this product was killed in place and never reached the market. We would like to request that this not be included. There will be no users impacted by pulling support. -dil Non-free material is being included in main for the benefit of *precisely zero* users. There's no two ways about this: this is a Social Contract violation. Coming back to looking at Debian after being preoccupied by family business, I see that the kernel team is not even seriously trying to separate out any non-free material. There have been severe regressions from sarge and no attempt is being made to fix them. I guess the Social Contract really is a joke. I don't know why new applicants are supposed to agree to it. Old members apparently violate it at will for years with no consequences. It doesn't make me respect Debian very much. -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390978: Yes, I can reproduce
Yes, I can reproduce this bug with 2.6.18-3-686. I've worked around it permanently by adding the line blacklist ehci_hcd to the file modprobe.d/ncn so if you need any testing you'll have to ask. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release team position on the state of kernel firmware, post GR2006-007
Steve Langasek wrote: With the conclusion of GR 2006-007[1], we now have a clear statement from the Debian developers that it is acceptable to release etch with firmware that does not meet our usual requirements for inclusion in main, subject to three principal conditions: 1. the freedom of the kernel for etch will not be a regression relative to sarge Unfortunately, the following additional hex lumps which you did not mention fall in this category: net/bnx2_fw.h net/cassini.h net/e100.c (e100 is salvagable for reasons noted in its specific bug.) net/starfire_firmware.h usb/serial/ti_fw_3410.h usb/serial/ti_fw_5052.h In addition, the readdition of tg3 and acenic are clearly regressions. Interpreting the meaning of the GR to be directly contrary to its actual text is, shall we say, questionable. I'm not going to complain too much about that because I expect this will be fixed immediately after etch. If it's not, I shall be ticked. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390994: Interesting discoveries in e100 microcode!
* D102_E_RCVBUNDLE_UCODE is identical in OpenBSD and Linux. * D101M_B_RCVBUNDLE_UCODE is not. OpenBSD contains version 2.10. Linux 2.6.17 contains an unknown version. The differing sequence is near the end: 0x00041000, 0x00010004, 0x003806A8 in Linux 0x00041000, 0x003806A8 in BSD Looks like an extra opcode. * D101S_RCVBUNDLE_UCODE is not. OpenBSD contains version 1.20; Linux 2.6.17 contains an unknown version. There are two differences this time. A one-bit difference: 0x000C0001, 0x00101213, 0x00260FF8, 0x00041000, 0x00010004 in BSD 0x000C0001, 0x00101213, 0x00260FF7, 0x00041000, 0x00010004 in Linux And another difference later: 0x003805A7, 0x, 0x, 0x, 0x, \ 0x, 0x, 0x, 0x, 0x, \ 0x00130831, 0x0010090B, 0x00124813, 0x000CFF80, 0x00260703, \ 0x00041000, 0x00380700, 0x, in BSD 0x003805A7, 0x, 0x, 0x, 0x, \ 0x, 0x, 0x, 0x, \ 0x00130831, 0x0010090B, 0x00124813, 0x000CFF80, 0x00260703, \ 0x00041000, 0x00010004, 0x00380700 in Linux Notice that the sequence is moved back one byte in Linux, and the 0x0010004 is inserted (as in M_B). There should be a trailing zero word in Linux; this is clearly a bug in the Linux driver, which currently writes a garbage byte to the hardware instead! If we had source, we would know what these changes meant. As it is, we don't know what they mean, but legally we cannot distribute them unless they are considered insignificant to copyright. Now, it's likely that they *are* insignificant-- they're *tiny*. The e100 firmware in the BSDs originates from a Linux e100 driver release from Intel, but a very old one (the 1.x series) which Intel is no longer distributing. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... pgp0t4hXJS6Qo.pgp Description: PGP signature
Bug#390994: that e100 bit
Sven Luther wrote: Can you check that those binary blobs are indeed bit-to-bit identic ? I checked the first and last 20 or so bytes of each one -- it will require a little program-writing work to put them in a form where I can cmp them, but I'm pretty sure what the result will be. snip However, the microcode is still non-free (lack of source). Conversion to userland firmware loading should be done (and I might even get around to it myself). If this is done, I strongly advise that the *same format* and *same filenames* be used as in OpenBSD, so that the firmware files are interchangable; no point in deliberate incompatibility. Indeed. Do you agree that we can do this post-etch, as the current GRs propose ? Yes. -- Nathanael Nerode [EMAIL PROTECTED] A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! pgpoxNbOUZhcL.pgp Description: PGP signature
Bug#390978: linux-image-2.6.17-2-686: USB support regression: USB stick fails with ehci_hcd loaded
Package: linux-image-2.6.17-2-686 Version: 2.6.17-9 Severity: normal In 2.6.15-*, my USB pen drive worked normally. In 2.6.16-* and 2.6.17-*, if I 'rmmod ehci_hcd' before inserting it, it works normally. But if ehci_hcd is loaded, it flakes out badly. The way it flakes out varies. This is a Dell Dimension 4600. I would be perfectly happy if I could force the kernel to recognize the pen drive as full speed and not high speed. But I don't really want to lose the ability to have other high speed devices. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages linux-image-2.6.17-2-686 depends on: ii module-init-tools 3.2.2-3tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-18 Yet Another mkInitRD Versions of packages linux-image-2.6.17-2-686 recommends: ii libc6-i686 2.3.6.ds1-4 GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.17-2-686/postinst/old-initrd-link-2.6.17-2-686: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.17-2-686/postinst/old-dir-initrd-link-2.6.17-2-686: true linux-image-2.6.17-2-686/preinst/lilo-initrd-2.6.17-2-686: true linux-image-2.6.17-2-686/preinst/failed-to-move-modules-2.6.17-2-686: linux-image-2.6.17-2-686/postinst/depmod-error-initrd-2.6.17-2-686: false linux-image-2.6.17-2-686/postinst/create-kimage-link-2.6.17-2-686: true linux-image-2.6.17-2-686/postinst/bootloader-test-error-2.6.17-2-686: linux-image-2.6.17-2-686/preinst/lilo-has-ramdisk: linux-image-2.6.17-2-686/prerm/removing-running-kernel-2.6.17-2-686: true linux-image-2.6.17-2-686/preinst/abort-overwrite-2.6.17-2-686: linux-image-2.6.17-2-686/preinst/already-running-this-2.6.17-2-686: linux-image-2.6.17-2-686/postinst/old-system-map-link-2.6.17-2-686: true linux-image-2.6.17-2-686/preinst/bootloader-initrd-2.6.17-2-686: true linux-image-2.6.17-2-686/preinst/initrd-2.6.17-2-686: linux-image-2.6.17-2-686/preinst/abort-install-2.6.17-2-686: linux-image-2.6.17-2-686/preinst/overwriting-modules-2.6.17-2-686: true linux-image-2.6.17-2-686/postinst/kimage-is-a-directory: linux-image-2.6.17-2-686/preinst/elilo-initrd-2.6.17-2-686: true linux-image-2.6.17-2-686/prerm/would-invalidate-boot-loader-2.6.17-2-686: true linux-image-2.6.17-2-686/postinst/depmod-error-2.6.17-2-686: false linux-image-2.6.17-2-686/postinst/bootloader-error-2.6.17-2-686: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390994: linux-2.6: e100 microcode: distributable with BSD license, but license not in Linux source
Package: linux-2.6 Severity: serious Justification: copyright OK. So the e100 microcode situation isn't as bad as we expected -- thanks entirely to OpenBSD. I'm opening this bug to track this issue because I expect it will be resolved relatively quickly, and because the 'big bug' is getting to be way too much. There are three different bundles of microcode: /* Micro code for 8086:1229 Rev 8 */ ... #define D101M_B_RCVBUNDLE_UCODE \ This is present in OpenBSD, in http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2content-type=text/plain under a 3-clause BSD license. Under the same name. /* Micro code for 8086:1229 Rev 9 */ ... #define D101S_RCVBUNDLE_UCODE \ This is present in OpenBSD, in http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2content-type=text/plain under a 3-clause BSD license. Under the same name. /* Micro code for the 8086:1229 Rev F/10 */ ... #define D102_E_RCVBUNDLE_UCODE \ This is present in OpenBSD, in http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/microcode/fxp/rcvbundl.h?rev=1.2content-type=text/plain under a 3-clause BSD license. Under the same name. It's worth noting that OpenBSD has substantial additional downloadable microcode in that file. The copyright problem will be fixed as soon as the proper copyright notice and license from OpenBSD's copy is added to Debian's copy. Simple and excellent. :-) Thanks OpenBSD! However, the microcode is still non-free (lack of source). Conversion to userland firmware loading should be done (and I might even get around to it myself). If this is done, I strongly advise that the *same format* and *same filenames* be used as in OpenBSD, so that the firmware files are interchangable; no point in deliberate incompatibility. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederik Schueler wrote: Hello, On Mon, Sep 25, 2006 at 02:15:54PM -0400, Nathanael Nerode wrote: Change this policy. You really must make two exceptions: (1) Removal of material which Debian cannot legally distribute, if upstream insists on keeping it. (2) Removal of material which does not satisfy the DFSG, if upstream insists on keeping it. Indeed, this should be another topic for the next kernel-team meeting. One piece of broken functionality is loading firmware before the root partition is mounted -- the lack of this breaks netbooting on the boards which need the firmware. However, I can't do anything about this: it requires running udev in the initramfs. This problem is not specific to this driver. the needed functionality is provided by the initramfs-hook in the firmware-nonfree package, which makes sure the firmware.agent from udev is present in the initramfs too. Rocking! I didn't know that was ready. A second piece of broken functionality is the functionality provided by the firmware: if the firmware isn't there and isn't loaded, the functionality isn't there. Duh. I also can't do anything about this. Which functionality? TSO? I believe so. Then, firmware-loading support in d-i is still missing, this issue should be be fixed too before we consider the patch. Firmware loading support patches are being refused in d-i until after etch is released. Therefore, this amounts to a We will not accept any firmware loading patches until after we release etch policy. Good to know. I can still queue them up for you to commit afterwards, though. if we want to release in time, we should indeed collect the patches for post-etch. Excellent. 2.6.20 should be the target for the first patches, as the merge window for 2.6.19 will not be open long enough anymore, except for the dgrs removal. Okey-dokey. I'm all happy now. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFIbuSRGZ0aC4lkIIRArC3AJ99p6DQhY20+vGAO0eIjsWwcHjMZACeNr85 j4rC2towsqrguFtUIuiMc+4= =5aGE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederik Schueler wrote: Hello, On Mon, Sep 25, 2006 at 01:30:34PM -0400, Nathanael Nerode wrote: I emailed the contact address at Intel about e100, but it seems to forward to tech support. We'll see if anything comes back. what did you write them? Tried to describe the problem in detail and asked for either source or a distribution license which didn't require source. Fool at the other end said It's licensed under GPL, so you don't need anything more (even though I *said* that didn't work in my email). I told him You're wrong. Please forward this to Intel's lawyers. IMHO, the topmost priority should be to get DFSG-free sources and an in-tree build infrastructure for the firmwares, like the aic7xxx driver. We should ask the vendors to relicense the blob and implement request_firmware only if they strictly refuse to provide sources. It also would be interesting to know if the blobs are actually code or register bank settings, as they don't need to be removed in the latter case, not being software at all. Maybe we should prepare a document template which we can send to all vendors, listing the reasons for our actions and possible actions we see they could take, everything in a friendly legalese so we can expect a real answer. We should. I've had such bad luck that I suggest someone else write the template. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFIbwnRGZ0aC4lkIIRAkVMAJ9hyCXGFWAsAKToY1bXuevfaxvm8gCeIp1X FSGVya7Z10aARlLz1B+OYRw= =mOI0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Mon, Sep 25, 2006 at 05:55:22AM -0400, Nathanael Nerode wrote: tg3 may follow, if there is a good enough patch to do it nicely. This may come, either from someone like you (but the patch has to be upstream-quality, which apparently your patch was not), Yes, it was upstream-quality. (Although to be honest the *driver* is pretty ugly stuff.) There was one bug spotted by Herbert Xu and fixed by him. This is not the opinion of others of the kernel team who looked at it. Name one specific problem with it, or stop slandering it. Really. Seriously. I've never gotten an actual technical criticism, besides the ones I mentioned before, which are all problems with firmware loading in general, and not problems with my patch itself. I'd be happy to fix any actual problems, but I can't fix mythical problems which nobody is willing to describe. The code *is* ugly. It's ugly because the upstream code is ugly -- nearly the whole driver is in a spinlock. I'm not up to rewriting the entire driver to increase lock granularity: that requires an extremely detailed understanding of the hardware and driver. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD4DBQFFIcY0RGZ0aC4lkIIRAngFAJ91LnvcBaFsz4XqvYTkFrWbZXRbHwCXVQXI 1tNQYIBlsz4OFrhL78uP5A== =Y6s8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383403: Vicam driver appears to contain misappropriated code
In the Linux kernel, drivers/media/video/usbvideo/vicam.c contains *long* sequences which appear to have been lifted from some other driver without permission or attribution, probably by wire-sniffing. Not short sequences, really long ones. This is not just nondistributable, it's actually likely to be sued over: the company clearly didn't authorize this use. -- Nathanael Nerode [EMAIL PROTECTED] A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposal: kernel team IRC meeting on Saturday, 30th September 16:00 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: Or you could also help us on this in making sure the tg3 patch in question is upstream-quality, I think it is better than upstream. What can I say? :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFF5VGRGZ0aC4lkIIRAt3sAJ96Xshq2E2e6B4SCNAbmLcSbvnVEQCZAf8g ctxRAWtOy+wB98alDKZcgeg= =OrB5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: The reality is not that the kernel team don't want those firmware in main, but that in the current state of the debian technology, it is not feasible to do it right, and it will take time, and will be best done during the etch+1 development cycle. (In some cases, nonexistent users. drivers/net/dgrs was killed in place and never reached the market. No users were impacted by removing this driver, and we know that for a fact. Why readd it?) Because it is a pain to remove them ? Try looking at the X.org packages: they have a fairly simple prune-non-free system. snip Upstream is making progress, see the qlogic firmware for example, and the debian kernel team, which is the one who will be making this work, not the release team, has a strict policy of following upstream closely, in part because we don't have the ressources and work-force to maintain a huge set of forked patches. See below. I'm afraid we can't trust upstream to fix everything. Some driver and subsystem maintainers are quite aggressive about fixing this stuff. Somenot so much. A good start would be the tg3 patches. Reintroducing the dgrs driver, which drives *no existing hardware at all*, would be a very bad move. So, you dismiss the qlogic firmware out of hand ? No, it's good stuff. Thanks to whoever did this upstream! tg3 may follow, if there is a good enough patch to do it nicely. This may come, either from someone like you (but the patch has to be upstream-quality, which apparently your patch was not), Yes, it was upstream-quality. (Although to be honest the *driver* is pretty ugly stuff.) There was one bug spotted by Herbert Xu and fixed by him. Upstream was a couple of people who at the time of last submission had a marked hostility to all userland firmware loading, of any quality. This may have changed. The patch is difficult to maintain because the *entire driver* must be removed and replaced -- this is because upstream refuses to separate the firmware into a separate file. At the time of previous submission, I suddenly realized -- after testing was done -- that distribution of the firmware was not legally safe, and I stopped doing it. This meant that the firmware-loading code lay unused, obviously causing complaints from those few people who needed the firmware. It also meant that I could not satisfy the transition requirements which were requested by upstream, which were to include the firmware in the hex blobs in the driver *and* have userland firmware loading simultaneously. I have asked more recently whether this transition scheme is still desired, with no answer. Thank goodness the firmware license has been fixed now. These are the reasons the patch is not upstream: note that the only technical one is the transition scheme request. I will try again and see what happens. or from the kernel team. tg3 is not the only case of such though, is it emblematic to you because you provided a patch when Herbert was still around ? Yep. And for the following other reasons: * because the patch was accepted and later retracted. * because I'm not aware of fully functional patches for any of the other cases. (My radeon and r128 patches don't work properly, FYI.) * because it represents a case where, given upstream's previous behavior, Debian may very well *have* to apply the fix itself, even if Debian wants to track upstream closely. * because users don't lose any hardware support if it's applied now -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFF6eKRGZ0aC4lkIIRAsbCAJ9z1XvUPo9blgLIE4a4bKF0hD1qDwCdGR+H Kmd6BOs/J7Z0hST2Oee/M6A= =K8N2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Sven Luther wrote: Also, i have many time asked for help on working on Larry's list, and find out the copyright holders of those files, and continue to fine-tune the I emailed the contact address at Intel about e100, but it seems to forward to tech support. We'll see if anything comes back. analysis he has done, but upto now, nobody gave any indication that they are ready to help in this regard, and this includes you. So, what are you going to do to help us make sure the non-free firmware finds an adequate solution for etch+1 ? -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Sven Luther wrote: Please add that information to the firmware wiki page, so that it is not forgoten in a few days. It was generated from Larry's page. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Frederik Schueler wrote: On Sun, Sep 24, 2006 at 11:25:15AM -0400, Nathanael Nerode wrote: If the firmware-loading tg3 driver is present in the next kernel package version, I will believe that the kernel team is acting in good faith to try to satisfy the Social Contract. According to the kernel-team patch policy, this patch needs to be either a backport from a newer version, or a patch submitted and accepted upstream. I'm afraid this is an unacceptable policy. According to this policy, an intransigent upstream maintainer can and will hold Debian hostage by forcing Debian to continue distributing unlicensed material in violation of law, or by forcing Debian to violate its Social Contract. I expect this to happen, though of course I hope it won't. Change this policy. You really must make two exceptions: (1) Removal of material which Debian cannot legally distribute, if upstream insists on keeping it. (2) Removal of material which does not satisfy the DFSG, if upstream insists on keeping it. If you want to wait to remove material until it's clear that upstream is intransigent, that's one thing, but if it becomes clear that upstream is intransigent, that's another thing. Where can I find the current version of your patch? ldoolitt updated it to the current kernel: he's sending me a copy. If he doesn't send you a copy, I will. Would you like it in a new bug report, attached to the giant monolithic linux-2.6 license and freeness bug, or what? :-) (This is one reason I supported one bug per driver: it allows tracking the individual problems separately in a straightforward way.) I'm thinking of adding slightly more verbose logging to help testers identify which board they're dealing with. AFAIK it was rejected upstream because some functionality was broken, This is, essentially, wrong. I have explained the reasons why it was rejected upstream elsewhere. I will submit it again, of course, but I expect hostility to any firmware loading patch for tg3, and I will be pleasantly surprised if I get a fair hearing. One piece of broken functionality is loading firmware before the root partition is mounted -- the lack of this breaks netbooting on the boards which need the firmware. However, I can't do anything about this: it requires running udev in the initramfs. This problem is not specific to this driver. A second piece of broken functionality is the functionality provided by the firmware: if the firmware isn't there and isn't loaded, the functionality isn't there. Duh. I also can't do anything about this. Apart from those, the patch has no known functional regression (there was one bug fixed by Herbert Xu related to machines with multiple tg3 cards), and I wish people would stop slandering my work. this regression needs be fixed and the patch resubmitted in order for us to consider an inclusion. Then, firmware-loading support in d-i is still missing, this issue should be be fixed too before we consider the patch. Firmware loading support patches are being refused in d-i until after etch is released. Therefore, this amounts to a We will not accept any firmware loading patches until after we release etch policy. Good to know. I can still queue them up for you to commit afterwards, though. I have a board with tg3, so I can perform the needed testing. Maybe you can, maybe you can't. The firmware is only used on certain boards: you are quite likely to have one of the needs-no-firmware boards. Thanks for the offer; any testing is good, even on the needs-no-firmware boards. I'll try to get you a slightly revised patch relative to ldoolitt's version: I want to add a little extra logging. Best regards Frederik Schueler Thanks for your time. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Frederik Schueler wrote: Second: this release contains ALL binary firmware blobs shipped upstream, even those we kept pruning since the day Herbert Xu removed them the first time in 2004. My apologies for blowing up, although it looks like my flaming message died in transit. Anyway, it's neither acceptable or reasonable to regress the freeness status of linux-2.6 to this extent. At a minumum, the patch for tg3 exists and is fully functional: check with [EMAIL PROTECTED] for the version against the up-to-date kernel, and the corresponding loadable firmware files. It works fine on at least the numerous boards which don't need firmware; the previous version worked on boards which do need firmware, and there's no substantial change, so I trust the patch. If the firmware-loading tg3 driver is present in the next kernel package version, I will believe that the kernel team is acting in good faith to try to satisfy the Social Contract. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposal: kernel team IRC meeting on Saturday, 30th September 16:00 UTC
Frederik Schueler wrote: Hello, I would like to propose an IRC meeting for all kernel team members, to discuss where we stand and what we want to do in the future, concerning kernel firmwares. Or, you could get the damn tg3 patches into Debian's kernel already. It would prove that you actually are interested in trying to follow the SC, which would get some of us off your back and back to writing firmware loading code. :-) (It's an egregious case, because the vast majority of tg3 users don't need firmware at all. Including the firmware in main in order to support network installs by the tiny number of users who do need it -- I have heard of three such users ever -- can't be considered sufficiently important to break the 100% free promise for, can it? Furthermore, this is a case where the kernel team has *regressed* from a previous release.) Of course, it would be a good idea to come to a common policy on what to do about material which is technically illegal to distribute. Perhaps some members of the kernel team would like to indemnify the rest of Debian and Debian's users from any future liability which may (if very unlikely things happen) arise from this distribution. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Steve Langasek wrote: If it is the consensus of the project that sourceless firmware doesn't belong in main, this is a conscious regression in DFSG-compliance relative to sarge. I don't think that's acceptable. We obviously do have the means to remove this particular subset of non-free firmware from main (technically imperfect though it may be), and of the firmware that was removed for sarge the only one that was important enough to get me glared at personally was qla2xxx -- so what are these other already-removed firmwares that are so important to have re-added now? (I did ask for a list, which no one has provided yet; I can't find the pruning script in the kernel team's svn repo, or I would look it up myself.) Here you go, Steve. drivers/media/video/dabfirmware.h drivers/net/acenic_firmware.h drivers/net/dgrs_firmware.c drivers/net/tokenring/smctr_firmware.h drivers/usb/misc/emi62_fw_m.h drivers/usb/misc/emi62_fw_s.h The above are all undistributable: smctr_firmware.h under a use-only license, the others because they are GPL without source or have no license at all. drivers/usb/serial/keyspan_mpr_fw.h drivers/usb/serial/keyspan_usa18x_fw.h drivers/usb/serial/keyspan_usa19_fw.h drivers/usb/serial/keyspan_usa19qi_fw.h drivers/usb/serial/keyspan_usa19qw_fw.h drivers/usb/serial/keyspan_usa19w_fw.h drivers/usb/serial/keyspan_usa28_fw.h drivers/usb/serial/keyspan_usa28xa_fw.h drivers/usb/serial/keyspan_usa28xb_fw.h drivers/usb/serial/keyspan_usa28x_fw.h drivers/usb/serial/keyspan_usa49w_fw.h drivers/usb/serial/keyspan_usa49wlc_fw.h These are all under a unique and annoying license: redistributable as part of a Linux or other Open Source operating system kernel Additional regressions relative to sarge: * tg3 was readded with the upstream firmware at some point after the release of sarge, despite the existing firmware loading patches, and is already in the 2.6.17 packages * The bnx2 driver was introduced upstream with sourceless, but distributable, firmware. * e100 and starfire acquired sourceless, undistributable firmware upstream between the sarge release and now (God only knows why) * New drivers were introduced upstream between the sarge release and now with the following sourceless, undistributable firmware: - drivers/net/cassini.h - drivers/scsi/ql1040_fw.h - drivers/usb/serial/ti_fw_3410.h - drivers/usb/serial/ti_fw_5052.h -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Sven Luther wrote: On Fri, Sep 22, 2006 at 03:25:12AM -0700, Steve Langasek wrote: snip On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote: snip (someone, I'm not sure who, wrote:) Re-adding them at this stage 1) is against the current social contract Yes, but then so is shipping the firmware actually still in main, So two bugs is better than one? Yes, because re-adding the drivers which used to be pruned, allow a category of users to install, which they did not previously. Thus, your arithmetic is wrong, because you don't count the can't install bug, and if you do, it sorts out evenly, especially if you take in account that we put non-free software and users equally in the SC. Our users cuts both ways. There are users who use Debian *because* the contents of main are (supposed to be) 100% free. I'm one. The two users complaining of Debian's hypocrisy on debian-legal recently are two more. Undoubtedly there are others, probably including many DDs. Those users are being mistreated in order to benefit some other users. (In some cases, nonexistent users. drivers/net/dgrs was killed in place and never reached the market. No users were impacted by removing this driver, and we know that for a fact. Why readd it?) Meanwhile, Debian will remain 100% free doesn't really leave much room for argument. Our users is a priority, as is free software, but Debian will remain 100% free is a *promise*. snip Indeed, but then you also need to backport all the fixes that the kernel team will put in 2.6.18 to 2.6.17, fine sharing of effort. Did you not read Frederik's GR, where the kernel team states that kernel dev ressources are rare, which is why we request a waival of the requirement for etch, in order to be able to work on this issue in peace for etch+1, To be honest, if the release team was clearly making progress on removing the non-free firmware, you'd be a *lot* more likely to get a waiver. A good start would be the tg3 patches. Reintroducing the dgrs driver, which drives *no existing hardware at all*, would be a very bad move. Today I sent an email asking upstream to remove dgrs based on its uselessness; we'll see what happens. without having to deal with the two new GRs a week over highly emotional issues, not mentioning the remaining bullshit that is going on beside it (RM payement, duck stuff, Duck stuff? Quack, Quack? looks confused I have a wild turkey living in my front yard, but no ducks. DPL recall, assorted GRs for various stuff). -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298099: Bug appears fixed
AGP_INTEL is on by default for x86_64 in the current 2.6 Linux kernels. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Could someone help me recover my tg3 patch?
I lost my copy. If someone could point me to the last version of Debian's Linux kernel package which shipped with the tg3 firmware loading patch -- I'm not sure which version it was and I can't seem to figure it out -- I would greatly appreciate it. (Heck, if you just sent me a copy of the most recent version of the patch, I would greatly appreciate it.) Thanks in advance. -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6: includes nondistributable and non-free binary firmware
will probably bring more problematic firmware in in unsuspecting ways. Actually, it probably won't bring very many: most of the identified items in 2.6 were already in linux 2.4. I attribute this to three things: * the new Signed-off-by scheme required for new submissions to upstream: unattributed material doesn't get in any more * the greater attention to licensing since the SCO cases: material with licensing of questionable distributability doesn't get in as often any more * and most importantly, the presence of firmware loading code, and the upstream policy that new drivers should use it. Not for freeness reasons, but because embedding these large blobs into the kernel image is not a wise use of space, and because it allows the firmware to be updated without changing the kernel. (There are exceptions, blobs which are new to linux-2.6. I believe that most of these merged early in the 2.6 development process, before any of the factors I described above were true. In particular, there are some blobs added to already-blobby drivers; several blobs arrived with the ALSA merge; ttusb-budget arrived before 2.6.0. Howeveer, the cassini blob in arrived in 2.6.14-rc3 in September 2005, the starfire blob arrived in 2.6.13, the bnx2 blob arrived in 2.6.12 in June 2005, and the ti_usb_3410_5052 blobs arrived in 2.6.10 in January 2005. So there are clearly *some* new blobs arriving upstream. The starfire blob is a really sad case of incompetence. The 2.4 driver states that the firmware is nondistributable, and not included. The 2.6 driver includes binary-only firmware, probably due to the work of someone who contacted Adaptec -- but due to incompetence, it's licensed under the GPL, which means that it's nondistributable. AARGH! I wish people would contact someone with a clue before contacting companies... GPLed material without source code is equivalent to you may not distribute this material.) snip There is not much time before the actual etch release is at hand, which is Do I remember something to the effect of Debian releases when it is ready? ;-) -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel schedule proposal for Etch
Frederik Schueler wrote: Hello, we should finally agree on which kernel version we want to release etch with, and on an appropriate timeframe. The goal should be obvious: release Etch on December, 4th. All kernel team members I asked so far would prefer a release with 2.6.18, which is likely to be released upstream within the next 4 weeks. The Debian installer team obviously would like as much time as possible to find out and fix all emerging bugs. Trying to put both requirements together, the kernel release schedule could look as follows: today: start migration of 2.6.17 kernel and udebs to testing 15.09: upload 2.6.18 to unstable [1] This is barely feasible. It would mean that the kernel team will have to spend the next month doing the work to make 2.6.18 DFSG-free. This could of course be done very quickly by stripping out all the problematic drivers, but this would probably be a very bad solution from the installer point of view. 01.10: migrate 2.6.18 kernel and udebs to testing 04.11: freeze kernel - No more changes to the testing version. Start of security support for the kernel on security.d.o [2] 04.12: release I would like to keep the non-free firmware discussion as a separate topic, thus it is not considerer in this schedule. That's simply unrealistic. Ignoring what amounts to about 50 RC bugs in designing a schedule is just stupid. I'd like some feedback from both the installer and release team if they think this is a feasible way for further action; if so, I'll also contact the security team for begin of security support. Best regards Frederik Schueler [1] The 2.6.18 release obviously depends on the upstream schedule, but 4 weeks from now is realistic considering the 2.6.18-rc4 status. [2] Kernel freeze as in: security fixes will go into a branch targeted at security.d.o and proposed-updates. We won't touch the kernel in Etch after the freeze, That means it *must* be DFSG-free. See above. For the smoothest results, the upload of a DFSG-free kernel (which is to say, a freezable kernel) should come after the installer is capable of loading non-free kernel modules from separate non-free udebs. So the design of a plausible kernel upload schedule is primarily dependent on non-free udeb support. Anyone know what the ETA for that is? but for extreme security issues affecting the installation process, like remote root exploits. All other issues will be addressed as needed in a security update and future point releases. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
[EMAIL PROTECTED] wrote: On 08/02/06 22:17, Nathanael Nerode wrote: Start with drivers/char/drm/mga_ucode.h. This is distributable, because it's under a BSD license, but it's not free software, because there's no source code. There is no source code, because there never was any source code. Do you have *actual evidence* of this? Are you a Matrox employee? Do you have an email from one? Do you know the microcode format and can you explain how to easily edit the hex to make the microcode do different things? If any of the above, please provide your evidence. If the microcode was wriiten in hex, hex is the sorurce code and we can include it. Otherwise, I contend that you are just making this up and Matrox actually has source code which it is withholding. Replies to debian-kernel please. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
I apologize for responding to Marco's post; in retrospect he was clearly trolling and I should not have responded to him. The point of my initial message was not to argue: it was that the etch timeline is unrealistic, because I see no progress on removing the substantial number of sourceless binaries from the Linux kernel source package, and it's *after* the kernel was supposed to have frozen! Is there a plan for dealing with this fast enough to avoid delaying the release of etch? If so, please post it. If not, I suggest the following process improvements: For each driver containing a sourceless binary, someone (probably me) will file a single bug against the source package linux-2.6. Currently there is a single bug (242866/243022) covering multiple issues, against 'kernel', which is a pseudo-package. Looking at the list of antique bugs against 'kernel', I don't think anyone is reading them. Also, with the planned removal of pre-2.6 kernel packages, a bug against linux-2.6 seems sufficient to cover everything. Why one bug per driver? Because each driver's bug is slightly different and I expect each to be fixed in a slightly different way. Some bugs are distributability issues, while some are clearly distributable and simply non-free. Some may be fixed by a new upstream version. Some may be fixed by implementing firmware loading and a non-free firmware package; some may be fixed by moving the driver to an out-of-tree kernel module; others may be fixed by removing the driver entirely; others (where the firmware is unimportant) may be fixed by removing the firmware and the support for whatever feature it enables. In the case of the DRM modules, the result may depend on the implementation of features in X, and bugs may block on that. The point is that each case is going to be different. The progress on the different drivers is already different. This should make tracking the issues significantly clearer: specifically it will make it clear exactly what needs to be done to fix this. It would also make it look a bit less like an infinite tentacled monster, perhaps making it easier for people to bite off one bug at a time. (Certainly I get confused posting fixes for different drivers to the same bug.) We would then convert 242866 to a meta-bug blocking on each individual bug. How does that sound? http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I will integrate the relevant information from that in the process. Alternative option: the Wiki page could be revived and used to coordinate the process. Unfortunately it's quite out-of-date, and it's unwieldly. I prefer the BTS option because it's more permanent, harder to ignore, and better at holding patches and whatnot. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote: What can be done about this? Accept that most people do not consider this a problem? First of all, this is false. Most Debian developers agree with me. You think not? Prove it by proposing a GR. More importantly, the release team agrees with me that this is a problem, and it is explicitly a release blocker. Further, majority opinion is irrelevant on issues of honesty. Debian is lying to its users. Debian needs to stop doing that. Frankly, I no longer care which way Debian becomes honest: (1) A GR amending the Social Contract to explicitly allow sourceless, non-free binary material in Debian (2) Removing the sourceless, non-free binary material from Debian main. Debian must do one of the two if it is to be honorable. I don't care which. You probably agreed to uphold the Social Contract in your Debian work. (Or were you grandfathered in before NM?) If so *you agreed* to remove this firmware. You have two honorable options: (1) Propose a GR amending the Social Contract to allow it. Please do so! (2) Remove it whenever it falls into your sphere of responsibility. You have historically chosen to take the dishonorable option, and I do not expect you to change, but I can hope. -- Nathanael Nerode [EMAIL PROTECTED] Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Etch timeline is unrealistic because non-free firmware is NOT being dealt with
The kernel freeze must be delayed quite significantly for a fairly obvious reason: the Debian kernel *still* has a lot of non-free and sourceless firmware in it. Unfortunately, little to no progress has been made on this. I'm sorry to be the bearer of bad news, but this is pretty obvious from looking at the linux-source-2.6.17 package: they're not trying very hard. Start with drivers/char/drm/mga_ucode.h. This is distributable, because it's under a BSD license, but it's not free software, because there's no source code. Continue with drivers/chare/drm/radeon_cp.h. This is from ATI and has no copyright notices from ATI or license from ATI, so it's likely undistributable. And those are two of the more prominent ones. I could list dozens. If people will not take the firmware issue seriously, either etch will not release on time, or etch will be *yet another* release where Debian *breaks* its Social Contract. My patches for firmware loading for tg3 have been *removed* from the Debian kernel. drivers/net/tg3.c *again* contains the proprietary firmware, compiled into the kernel. At least it has proper copyright and license notices, so it's distributable, but it's *still non-free*. This is a positive disincentive to work on fixing these issues: my fully functional work was simply rejected in favor of breaking the Social Contract. What can be done about this? If there is no plan for progress, I intend to file 'serious' bugs against each kernel package for each piece of firmware, which might at least make *someone* pay *some* attention. -- Nathanael Nerode [EMAIL PROTECTED] This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#256374: Still having this problem: CD-ROM Compaq Presario 1220
With only one distribution exception (which later fails for a different reason), most of the 2.6 kernel distributions do NOT install on a Compaq Presario 1220 including Debian GNU/Linux testing Etch. I'm getting this exact problem; the exact problem described in the bug report. With a Compaq Preasio 1230. I can't install with 2.4 for various other reasons. Is there any way to force it to use IRQ 15 for ide1? That seems to be the primary difference between the functional 2.4 kernel and the broken 2.6 kernel. I've tried adding options to the kernel command line, but it doesn't seem to work. -- Nathanael Nerode [EMAIL PROTECTED] This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
Sven Luther wrote: No, i don't think this was the kind of framework i was refering to, Well, another related issue is what format the firmware file should be stored in -- I advocate a fixed endianness so it doesn't depend on the host CPU details, for instance. more of a set of rules on how we would patch the drivers to make them request_firmware aware. Ideally, you call request_firmware in the driver code immediately before the microcode is uploaded to the peripheral. The firmware is stored in main memory until the upload and then the memory is released. In a driver which minimizes its lock use, this gives pretty good results. Since it depends on hotplug to get the firmware, it won't work until root is mounted (until udev is made to run in the initramfs). Spinlocks made this more complicated. request_firmware must be called in a situation where sleeping is permitted. Accordingly, you must trace the call sequence (of the function uploading the microcode to the peripheral) back upwards to the first point where no spinlocks are held, and call it there. The memory should be released on all exit paths after the upload, which can usually be done in the very same function you call request_firmware in. The tg3 driver was a bear, because spinlocks are held in virtually the entire driver. The latest point at which request_firmware could be called was driver initialization for a particular card. This meant that the earliest point at which it could be released was driver unload for that card. The conservative solution for a driver which is lock-happy is to load the firmware files at module load time and hang on to it until module unload time. This loses the memory savings benefit but retains the other benefits. The tg3 is unusual in that some of its firmware was optional. In the case of tg3 this was pretty easy to handle by converting some #ifdefs to if () statements. --- This was all before request_firmware_nowait was available and functional. This provides a callback interface instead of a synchronous sleeping interface. Of course, coding to a callback interface is more invasive because the existing modules are generally not designed for it. However, it is preferred long term. Software suspend (Power Management) with hardware resets is the main function for which request_firmware_nowait is essential -- but also needed is a substantial amount of additional kernel infrastructure which isn't present yet, so it's not as if using request_firmware_nowait will just make software suspend work. For instance, one thing needed is an event which goes to the driver *before* the suspend, in response to which the driver grabs the firmware into RAM, since userspace may not be available at the beginning of the resume. I haven't played around a lot with the asynchronous interface. I expect that it will require essentially the same treatment of drivers as the synchronous interface, but perhaps with more code rearrangement. After all, you can call it with a spinlock held, but I believe you still have to get out of the spinlock in order for the userland hotplug event to run, and therefore in order for the callback to actually arrive. I believe there is also a request_firmware_nowait_nohotplug variety, which simply expects that the firmware has been manually dumped into sysfs before the driver starts initializing. This might be suitable for some early-loading modules. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Kyle McMartin wrote: The question is: when you remove the firmware from the driver, and all it is, is a file sitting in /lib/firmware/; and it's contents are just non-executable hex, Sorry, it is executable. For instance, the tg3 code is simply MIPS binary which can be disassembled with binutils. Factual error. Try again! with no C-code structure, is it just a BSD-licensed (in the qla2xxx case) data file, or is it still regarded as a piece of code. This, to me, is no different from a BSD licensed JPEG. I would argue it's the former. I can see the argument when it's a part of the source code, but not when it's a completely seperate entity. Of course, firmwares where the license has not been clarified by the copyright holder/IP owner would still be a problem; or where something is clearly unredistributable (ie: Intel IPW firmwares.) Or where it's licensed without permission to modify, e.g. tg3 firmware. Which is actually a very common result when the licenses do get cleared up with the copyright holder. :-P -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Sven Luther wrote: Hi all, I am cross posting to debian-release and debian-boot, since this will affect them too. snip Basically, the situation is like this : 1) there where drivers under implicit GPL licence with binary only firmware. Since there was no explicit licence for this firmware, it was GPL, and since it was sourceless, it was non-distributable. We started work to get upstreams to relicence their code, which happened with the tg3 and qla2xxx drivers, but failed for others, like the acenic one, partly because of the demise of the company producing them and various acquisitions which left the IP in an unknown state nobody seems to bother with. 2) there are now drivers which contains non-free firmware blobs, with explicit licence, and these are thus distributable. A quick search for fw_ revealed 159 such files in 2.6.15. I would like to add that I have volunteered to (a) assist with converting these to the request_firmware infrastructure (b) package the blobs for 'non-free'. Udebs provided on request. I actually *did* this for tg3 (back when the firmware was undistributable, but before I'd noticed that). However, all my work so far has been rejected by upstream for reasons which I can only call pure hostility (I have seen few technical reasons, and have received no response to requests regarding what would be an acceptable patch). The corresponding patches have been removed from the Debian kernel because the kernel maintainers at the time did not want to maintain patches relative to upstream. This does not exactly encourage me to work on other drivers. I have since misplaced my tg3 work, and would have to retrieve it from an old Debian kernel package. Help doing so would be appreciated :-) 3) an effort seems to be happening inside the upstream kernel to use the request_firmware infrastructure which allows to load firmware code from userland through an hotplug mechanism. There seem to be more and more drivers going this way, since there aare more in current git than in 2.6.15 which was released a week ago, qla2xxx being among them. Here is a link to the relevant wiki page about the cleaning up of messy licences : http://wiki.debian.org/KernelFirmwareLicensing So, basically this means we have the following options : a) we move the whole kernel to non-free :) b) we move the affected modules to non-free. Well those that have their licencing solved, the others will simply no more be distributed, or distributed form an unofficial source. OK, but (c) is better. However, we can use a combination of (b) and (c). c) we move the firmware in non-free, and actively use the request_firmware mechanism. Great idea! d) we go for a new GR, asking for an exception for the linux kernel, in order to still stay in main, even though the firmware is non-free, arguing that said firmware is more akin to hardware, since it replaces firmware on a prom or flash on the expansion card, and you thus lose no freedom if we distribute it, and the pain the other solutions will cause to ourselves and our users. If my DD application ever goes through, I would definitely vote against this, because the argument is completely bogus. For an similar argument, An implementation of BASIC is more akin to hardware, because it replaces IBM BASIC which used to be kept in ROM. This argument might wash if the firmware was not code at all, but in the cases I know of, the firmware is in fact code for MIPS, ARM, and other ordinary CPUs which are on the expansion card. I think everyone agrees that a) is not a possibility. Both b) and c) require a non-negligible amount of work, altough b) is less work than c), but c) is the better solution, and also to the best of my knowledge the one which upstream seems to favour, altough both may mean a long-term additional work for the kernel-team, work which the kernel team is not really prepared to make, which leaves d). Not sure if d) is politically right right now with regard to the GFDL situation, but that is another issue, which will then need to be debated. (d) is unacceptable. I have *volunteered* to work on (b) and (c) and I am happy to be the effective maintainer for any involved patches and packages. I see no reason why that would not be acceptable to the kernel team. I'm even happy to leave any individual non-free lump in 'main' while the work on making it loadable from non-free is in progress. So, Andreas, you proposed help and bug squasing parties focused on this, i guess it is now clear what needs done :), and i can only stress that this needs an additional comitment of help, since any patch which will come up will probably have to be maintained by the debian kernel team for a long time. Committment made. Will it be accepted? Also, if we go the BSP way, it has to make clear that it had to be a long standing and coordinated effort, since random patches of
Re: non-free firmware
Andreas Barth wrote: As this is a release blocker, not release until this is fixed? (And try to search for someone who can work on this issue, Ping! Dispirited volunteer here! perhaps also say something in the next release update.) -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Bastian Blank wrote: On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote: how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. This is incorrect. I know firmware[tm] blobs which only includes data. Please name them. I could likely be convinced that *those* firmware blobs do not need source code. That's different from *all* firmware blobs. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Andreas Barth wrote: * Bastian Blank ([EMAIL PROTECTED]) [060111 12:57]: On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote: how can you consider it as non-program. It is indeed composed of machine code destined to run on the controller of the device the driver is written for. This is incorrect. I know firmware[tm] blobs which only includes data. You can't decide if it is something which can be executed somewhere. Can you define what execute means? Is it execution if e.g. data is processed that defines a sound-wave for a DSP? OK, let's agree that DSP sound-wave definitions and similar transformation tables of data for sound cards are fine and free, because binary blobs probably *are* the preferred form for modification of those (if anyone actually wanted to modify them). (Of course, that's just based on my minimal knowledge; if a sound card hacker steps up and says no, those blobs are definitely not the preferred form for modification, I would have to defer to his/her superior knowledge.) -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
Sven Luther wrote: On Sun, Jan 08, 2006 at 11:52:20AM +0100, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060108 11:12]: There where two fully independent issues here : 1) some (many) of those firmware using modules had a sloppy licencing situation, which meant the compiled kernels where indeed non-distributable. 2) those firmware blurbs come without source, and are thus non-free. We where working to solve 1), since without that, it was not even possible to distribute these non-free firmwares from even non-free. I think once this is solved the plan was to : 1) either make those drivers be able to load the firmware from an external file, which we could then include in the initramfs from a non-free source. For instance, now that the tg3 firmware is under a distributable license, with my tg3 patch reinstituted the firmware for specialized tg3 cards would simply be three files which go in a specific place in the directory tree and are picked up by hotplug/udev. 2) remove those drivers entirely from the main linux-2.6, and have them distributed from the linux-nonfree-2.6 package from our non-free section. This matches with what I remember. Well, there might be cases where the binary blob is enough, but I think we agree that a) this is probably the exception and not the rule, and b) this requires a case-per-case-inspection. And how exactly can you guarantee this is the case without being the guy who wrote the code, and even so, how could we be sure to thrust such a guy claiming that it is the ultimate source code ? I'm willing to accept a claim from the guy who wrote the code. However, as a debian-legal regular, I can honestly say that that situation has not come up even *once* yet. The main problem is one of ressources, and we need a single person who can devote time and effort to follow up on all those drivers, and see if the firmware can be removed from them or not. Right now everyone is focused on other stuff. I volunteer. But I need to know that the debian-kernel team iss willing to *accept* my volunteering. That means being willing to revive the fully functional tg3 firmware loading patch which was already included in earlier driver versions. Now that the tg3 firmware is under a distributable license, I can package it for non-free, no problem. I suppose the right way to solve this (doing 1) is another matter and more of the area of upstream work than debian work, it is the better solution though, not sure if it would be ready for the etch timeframe though. The question of sloppy licenses is indeed an upstream issue - however, that doesn't mean we can shut our eyes when we come over such an issue. The DFSG-freeness is our own issue. Nope, upstream didn't care about sloppy licence, the upstream issue is to have the firmware removed from the driver and provide infrastructure to load it from initramfs. But the real problem is we are all volunteers, and if nobody has the will to work on this, what can you do ? I do have the will! And if those more likely to work on this are not convinced by the non-freeness or do not care ... Or if those who do have the will to work on it find themselves obstructed by those who don't :-( -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
[EMAIL PROTECTED] wrote: licenced modules. If we don't want to do that, the most honest way to handle it is to get another GR out the door,explaining that this is not easily possible or convenient at this time, and asking for an explicit exception for kernel firmware. I would second such a GR. I would be comfortable with a specific exception for *etch only* for drivers which *may need to load in order to mount root*. I would also be comfortable with an exception for *etch only* allowing the *installer* to contain and install such non-free material. I would not be happy with a general exception for the regular kernel packages in 'main'. Rationale for those rules follows; it is based on practical considerations. It would be dangerous to have a permanent exception, because it would just lead to more and more non-free stuff in the kernel -- because it would encourage the people who don't care to avoid fixing it and to reject patches from other people. :-P Observe the foot-dragging on the GFDL issue. It is dishonest to say that it is not easily possible or convenient to fix this issue for drivers which don't need to load early, particularly if the installer is exempted; the work for this is quite far advanced. First the issues if the installer is exempted: -- For any userspace-firmware-loading driver which does not need to be loaded in order to mount root, it requires only a deb containing the needed file for /lib/firmware (trivial). The kernel firmware loading code and udev/hotplug take care of the rest. For a non-early-loading driver which has embedded firmware, it requires a deb for the driver matching each possible installed kernel (tedious, but certainly feasible, and very straightforward). For a firmware-blob-embedding driver which needs to load before root is mounted, it requires no additions on the installed system, just the debs for the driver module for each possible installed kernel. For a userspace-firmware-loading driver which needs to load before root is mounted, it additionally requires: (1) udev and /lib/udev/firmware.agent available and in the initramfs -- I believe this is being worked on for other reasons anyway, right? (2) patches to yaird/initramfs-tools to install the files from /lib/firmware in the initramfs -- this is easy If these two steps are not ready by freeze time, I would be happy to have an exception for such drivers, as noted above. Second, the issues with the installer -- For any userspace-firmware-loading driver which does not need to be loaded in order to mount the CD or floppy drive, it requires (1) an easy facility for inserting an extra debs CD or floppy in the installer (already present) (2) an easy facility for inserting an extra udebs CD or floppy in the installer (already present, I think?) (3) a udeb (probably the same one) for each such piece of firmware, which puts the file in /lib/firmware on the installer ramdisk (almost trivial) (4) a facility to load such a udeb *before* the probing for kernel modules (shouldn't be too hard) (5) working udev/hotplug firmware.agent in the installer (this is being worked on already for other reasons, right?) The kernel firmware loading code and udev/hotplug take care of the rest. If the infrastructure for this was not ready by freeze time, an exception would be warranted, though I don't see any reason why it wouldn't be ready. For a non-early-loading driver which has embedded firmware, it requires: (1) an easy facility for inserting an extra debs CD or floppy in the installer (already present) (2) an easy facility for inserting an extra udebs CD or floppy in the installer (already present, I believe) (3) a udeb for the driver matching the kernel used in the installer (tedious, but certainly feasible) (4) a facility to load such a udeb *before* the probing for kernel modules (shouldn't be too hard) If the infrastructure for this was not ready by freeze time, an exception would be warranted, but I also don't see any reason why it wouldn't be ready. Yes, you'd have to build a bunch of drivers out of tree in non-free until they were converted to userland-firmware-loading. You already know how to do this, folks. For any driver which needs to load before the CD drive is mounted, it would appear to require (a) provisions in the installer for loading extra udebs (from where?) before mounting the CD, which are almost certainly infeasible (b) or an entire non-free installer release This is the only genuinely impractical case, and an exception *should* be made for it in the interests of installing on as much hardware as possible. This message is public domain. Please feel free to copy it to whereever you think it needs to be read. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
Sven Luther wrote: If we are going to do this, we obviously need to find out a strong framework how this is supposed to work, and all need to follow the same schema. Upstream hasn't done this. I realized this need and started asking people about an appropriate naming scheme for the files in /lib/firmware (or /usr/lib/hotplug/firmware as it was then) and attempted to keep it. I heard rumors about your patch being too disruptive, and was thus rejected by davem, we don't want that to happen. I'll be blunt: those rumors are false, and whoever started them is slandering my work. For the original patch, the reasons given for rejection were the following: (1) Either Jeff Garzik or Dave Miller (I don't remember which) wanted a transition period when the firmware loader would fall back to a built-in firmware copy. I was willing to write a patch which did that, but I thought it was a bit silly. I later asked if a patch would be accepted if it did that, but received no reply. (2) Reasonable concerns were raised about needing firmware to be available in order to mount /usr, creating a nasty chicken-and-egg problem. This has mostly been addressed by the creation of /lib/firmware. Similar problems may arise with the mounting of root, I suppose, but with the switch to initramfs-all-the-time, these can be addressed trivially by modification of the initramfs. (3) Jeff Garzik and Dave Miller didn't think that firmware loading was a good idea at all, ever. Well, if they still think that, then they'll naturally reject the patch, and there's nothing we can do about it. None of these concerns has any relevance to Debian today. Dave Miller didn't feel that the (former) non-distributable licensing of the tg3 firmware, or indeed his own failure to put correct copyright notices on it, mattered. I felt very strongly that it did, and perhaps he took a dislike to me because of my stridency on that matter. The last time I proposed a patch -- which simply separated the firmware into a separate file, so as to make life slightly easier for Debian, and on general tidiness grounds -- he accused me of trying to disguise my intentions, which I certainly was not. (Come on! I'm the poster child for strident and outspoken!) He then dropped my patch on the floor with no technical commentary at all. He did say that he didn't see the point unless it was combined with a full firmware loading patch; so I asked what technical requirements would be required of a full firmware loading patch (keeping in mind the responses earlier), and got absolute dead silence. The only technical criticism which I have ever heard of my patch was the claim that firmware loading should not be done, and that firmware blobs should be compiled into the kernel. I don't consider this to be relevant commentary. During the original period of use of the patch in Debian, I discovered that the firmware was not only non-free but also not actually legal to distribute. This led to some unfortunate problems because people were unable to get copies of the loadable firmware, and I certainly don't want to repeat the situation where the driver tries to load firmware which people can't find. I made several efforts to contact the copyright holders without sucess (no replies at all). I also asked Dave Miller, who claimed to know the authors, if he could put me in contact with someone who might be able to do something about the licensing problems, but he refused. Thankfully this has been resolved now. The patch is not very invasive at all; I actually bent over backwards to avoid interfering with the call sequence (since request_firmware can't be called in a spinlock, and nearly the whole tg3 driver is in a single spinlock). I have had several people testify that it works just fine. Again, those rumors are entirely false, so pay no attention to them. -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug 346028
I retested this and I can't reproduce it with 2.6.15-1. So it seems to be fixed. Perhaps I was confused, or perhaps there was some transitory thing going on when I had both 2.6.15-1 and 2.6.14-1 installed. :-) -- Nathanael Nerode [EMAIL PROTECTED] A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346028: moreinfo
Also, could you please give us the output of ls -lR /etc/kernel No such file or directory. -- Nathanael Nerode [EMAIL PROTECTED] This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346028: linux-2.6: Hangs while attempting to purge
Package: linux-2.6 Severity: serious Justification: Won't uninstall cleanly It hangs on this line of the postrm script: my $ret = purge(); I can get it to work by deleting this line. Perhaps this is because a debconf routine is being called after stop has been called? I don't know, but anyway it's a serious bug. This bug appears in linux-image-2.6.14-2-686 and linux-image-2.6.15-1-686, and I assume in other flavours as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325192: udev generates outrageous numbers of ttyS nodes
close 325192 thanks Marco d'Itri wrote: On Sep 22, Nathanael Nerode [EMAIL PROTECTED] wrote: Marco d'Itri wrote: Please check if this bug has been fixed by 2.6.13, on my system the four extra ttyS devices which were claimed by serial8250 are gone. I'll be sure to do this. 2.6.13 isn't in unstable yet though, is it? It's not. Also, check that ACPI support is enabled and working. Yes, fixed in 2.6.14. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325192: udev generates outrageous numbers of ttyS nodes
Marco d'Itri wrote: Please check if this bug has been fixed by 2.6.13, on my system the four extra ttyS devices which were claimed by serial8250 are gone. I'll be sure to do this. 2.6.13 isn't in unstable yet though, is it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6_2.6.12-1_i386.changes is NEW
- readdition of tg3 driver, as firmware license has been fixed It's distributable, but only in non-free. No source code for the firmware program. Sorry. :-P Ask debian-legal if you have further questions about that. If anyone's interested, I've got a patched version of the tg3 in Debian's linux-source-2.6.12 package which does firmware loading (it builds), *and* a package ready for non-free containing the firmware. (Well, it's ready except that it would need some sort of Depends: appropriate-kernel-version) Since I don't actually have a tigon 3, I need someone else to test it for me, of course. Files at http://home.twcny.rr.com/nerode/neroden/debian/ . If you're not interested in that, I suppose I could arrange for the driver to build out-of-tree. I would *like* to get the firmware loading upstream, but they have some... interesting requirements before they'll accept it, so we'll see when that happens. :-P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broadcom proposed firmware licence, please comment ...
Taking off debian-legal, since this is so not legal discussion anymore. Andres Salomon wrote: I think they said they'd accept a patch which loaded the firmware but fell back to firmware built into the kernel if it wasn't present, as a transitional requirement. Ugh squared. But I can do it; I can even do it in such a way that the tg3 patch to the kernel would consist of a single file deletion. Are they looking for a transition, or are they just looking for proof that the firmware loading will actually work? Transition code doesn't sound overly useful to me. They said they were looking for a transition. (And I agree, it doesn't sound that useful to me either.) I believe, however, that the idea was to avoid causing difficulties for people who didn't know where to find the firmware or how to install it. If the kernel installation files were changed to properly install firmware files in the right place per default, that would likely satisfy them. (I can integrate my generate-binary-firmware-file-from-hex code into the kernel patch if this sort of solution is desired.) Fixing up the installation files is just a little bit beyond what I'm personally willing to do at the moment, though, since I haven't yet figured out the kernel installation file system. So someone else would have to write that part. If anyone's volunteering to do so :-), I believe we'd decided that the right place was: /usr/lib/hotplug/firmware/tg3/5701_a0-0.0.0 /usr/lib/hotplug/firmware/tg3/tso-1.4.0 /usr/lib/hotplug/firmware/tg3/tso_5705-1.1.0 (This forms the beginnings of a namespace and conventions for loadable firmware files, and is where my existing code puts them.) Keep in mind the patch we'd have would have to simply readd the tg3 driver; the patch can't delete the file. Oh, what I was thinking was this: (1) reorganize the upstream kernel driver so that the included firmware was in a separate file (#included, for instance), as is done in most such drivers (2) include the firmware loading code upstream (3) Debian's tar.gz.orig simply omits the firmware-containing file (4) The patch simply removes the references to it in the driver file As such, it would still need to be maintained (although shouldn't be too complex, as long as it doesn't include firmware loading features and such). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broadcom proposed firmware licence, please comment ...
Andres Salomon wrote: Yes, that's what I was thinking. Vendors will be taking care of firmware file installation; kbuild should be handling it when running modules_install. Perhaps a firmware_install target that takes care of the various firmware blobs? Sounds good. I can do that, if necessary. What form was broadcom supplying firmware in in the first place? If it's a binary firmware file, there's no need to have a hex code converter; we can just throw the binary firmware file in the directory tree. Hex. I have the files from the Broadcom-released driver. :-) If anyone's volunteering to do so :-), I believe we'd decided that the right place was: /usr/lib/hotplug/firmware/tg3/5701_a0-0.0.0 /usr/lib/hotplug/firmware/tg3/tso-1.4.0 /usr/lib/hotplug/firmware/tg3/tso_5705-1.1.0 (This forms the beginnings of a namespace and conventions for loadable firmware files, and is where my existing code puts them.) I haven't bothered looking at other drivers in the tree that support firmware loading; are paths hardcoded in there, or is the firmware location simply a module/kernel arg? Hardcoded, consistently. The few present have erratically chosen names hardcoded. Indeed I have no idea where to find the firmware files to go with some of those names, which is an issue. I think the feeling was that the file in that location can be replaced rather than changing the name searched for, and that that was simpler. I'm not doctrinaire about it or anything though! Oh, what I was thinking was this: (1) reorganize the upstream kernel driver so that the included firmware was in a separate file (#included, for instance), as is done in most such drivers This alone would go a long way towards making my life easier, if upstream accepted it. Well, maybe I should do that first. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broadcom proposed firmware licence, please comment ...
Andres Salomon wrote: As I remember, upstream (jgarzik/davem) was not overly interested in such a patch to tg3. Is this still the case, or are they amenable to such changes? Upstream was not interested in legal niceties like including copyright statements, either. I suppose both are still the case. I think they said they'd accept a patch which loaded the firmware but fell back to firmware built into the kernel if it wasn't present, as a transitional requirement. Ugh squared. But I can do it; I can even do it in such a way that the tg3 patch to the kernel would consist of a single file deletion. I'd rather not maintain a tg3 patch again, if possible. I understand. :-( -- This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broadcom proposed firmware licence, please comment ...
Sven Luther wrote: The text of the new licence proposal is as follows : +/* xxx.h: Broadcom tg3 network driver. + * + * Copyright (c) 2004, 2005 Broadcom Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, except as noted below. + * + * This file contains firmware data derived from proprietary unpublished + * source code, Copyright (c) 2004, 2005 Broadcom Corporation. + * + * Permission is hereby granted for the distribution of this firmware data + * in hexadecimal or equivalent format, provided this copyright notice is + * accompanying it. + */ I would have liked a clear identification of the firmware blob, but i guess that to anyone familiar with C, it is immediately evident what is the firmware blob and what is normal code. So, before i reply to them, i would like to have feedback from debian-legal, and we can then move ahead and upload this driver to the non-free part of our archive, including a working .udeb. Great! This license is totally distributable. I'm not sure, unfortunately, what counts as equivalent to hexadecimal. I think that's the only problem. If it was just permission to distribute, unmodified, in any form, it would be clear. Before you move the whole driver to non-free, you should know that I have made a version of the driver which loads the firmware from files if it is available (many tg3 users don't *need* the firmware), and I believe that is the one currently in Debian's kernel tree. I have also designed a package containing appropriate firmware files for this version of the driver. The only reason I have not published the package yet is that it was under this legal cloud. The package generates the firmware files as arch-independent binary files (with a specified endianness) by writing out the hex in a really simple-minded way. (Each lump of hex has a length and a lump in the C file, and I just write the the length and the lump out binary, in a defined order.) If this binary form counts as equivalent, then I have a package for you :-), and I just have to fix it up to generate a udeb (and get a sponsor). If the binary form doesn't, we can rewrite the kernel driver to actually parse hex, but that seems a bit silly to me. They seem equivalent to me. I suspect they're meant to be equivalent, because the compiled version of the stock kernel contains binary rather than hex, and they want it to be possible to distribute that. Do we need clarification here? In any case, I believe we do not need to move the whole driver to non-free in this case, just the firmware. Remember that this one works for many cards without the firmware, so people will certainly appreciate that. --Nathanael Nerode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284221: Bug #284221: acenic firmware situation summary
Not really. That licence doesn't allow Debian to distribute whatever it is that's being licenced. There's only permission for personal use. Hmm. My initial reading was that you could (1) create, test and provide programs for use with ALTEON network cards (2) license the object code of such a program provided it is restricted to use with ALTEON network cards It's obviously non-free, but -- depending on who you is -- could allow distribution. Looking at it closer, it suffers from being a contract, and being inherently click-wrap, and Debian can't implement click-wrap, so it's unsuitable for non-free. :-( It does look like it's probably legal for someone to make the object code for the firmware available somewhere, under that click-wrap license, as an interim measure before independent firmware is created.
acenic firmware situation summary
Warning: long. CC'ed to debian-legal in case anyone there knows anything more. The source for the acenic driver is in fact in the source package for the kernel. The firmware is absent from Debian for *very* good reasons: the version in the Linux kernel is distributed without proper copyright notices or a license. (SCO should really have bought up firmware copyrights if it wanted to sue Linux distributors.) I do so wish people wouldn't go off ranting about anti-firmware fanatics before checking the facts. (If someone wants to try to change Debian policy so that Debian can distribute copyright-encumbered works with no clear license, go ahead. However, Debian's current policy is, I believe, to follow the law strictly in copyright matters.) -- As a point of interest, the source code for the ACENIC firmware is actually available at http://alteon.shareable.org/, but it comes without a proper license, so it's no good if you want to do things legally. The web page says: Look at the source files yourself to understand any licensing restrictions on their use. Alteon's license may be summarised like this: you may share and develop the firmware, but it is only for use with Alteon NIC products. Unfortunately, looking at the source files, I find that they are all rights reserved and I can find no license grant. The Alteon Open Firmware Agreement doesn't appear to exist any more. So his summary of the license appears to be wrong. Perhaps someone can track down the original license listed on the now-defunct web page (supposedly http://alteonwebsystems.com/) where Alteon allowed people to download the firmware? (This is a sad lesson for the developers of the Arsenic enhanced firmware: Never, ever, point to someone else's license on a web page; *always* put a verbatim copy in your distribution.) At least they have proper copyright notices; I suppose Alteon's successor might be convinced to release it under a Free license, or at least a license which grants permission to distribute. Alteon is now owned by Nortel, but apparently sold the ACENIC business to 3Com. Did that include the firmware? Who knows? Unfortunately, 3Com seems to be pretty bad about responding to licensing-related requests. If anyone knows someone on the inside, it would help. :-P (Parts are also copyright Essential Communication Corp., and I have no idea what's become of them; I think they may be the Essential Communications Corp. which was bought by ODS Networks according to http://www.bizjournals.com/dallas/stories/1998/05/04/daily7.html. Also, Alteon presumably had a license from them, and it may allow Alteon to sublicense arbitrarily; http://www.socratek.com/Agreement-Preview.asp?num=37354 may have something to do with this, or may not.) -- More usefully, the alteon.shareable.org web page features the documentation for the board, and although that's all under copyright too, it could certainly be legally used as a reference for writing your own firmware. (And if you do, you can release it under a Free license and everyone will be happy.) Jamie Lokier's tools on the same webpage, in contrast to the firmware itself, are GPL, and could certainly be used to help develop new firmware. A related page is http://www.cl.cam.ac.uk/~tjd21/alteon/, with more GPL tools which might be useful for anyone developing new firmware. In addition, if someone gets the original firmware licensed acceptably (or writes new firmware to which the changes can be applied), there's some serious improvements -- the Arsenic firmware -- released under a 4-clause BSD license from http://www.cl.cam.ac.uk/Research/SRG/netos/arsenic/. I think that sums it up. -- This space intentionally left blank.
Bug#250468: Supposed security hole in kernel patch
It would help a lot if someone could include a pointer to the appropriate thread(s) on lkml, or to something else which explained the purported security hole. I can't find a description of it anywhere.
Re: Bug#258082: missing advansys module
Nathanael Nerode wrote: Some of them already *have* provided freely-licensed source (Advansys); Thinko. Of course I meant Adaptec, with the aic7xxx driver. The keyspan_pda module by Brian Warner (USB Keyspan PDA Single Port Serial Driver, USB Xircom / Entregra Single Port Serial Driver) is another example Also the sym53c8xx_2 driver, though it is taking a rather different approach. that microcode is of course just fine to have in the kernel. -- This space intentionally left blank.
Re: Bug#258082: missing advansys module
Joshua Kwan wrote: Nathanael Nerode wrote: * Since I actually have an advansys card to test on, I should be able to convert this driver to userland firmware loading without the annoyances of a remote testing cycle. But how do you expect people to install Sarge on systems where the only mass storage controller is an advansys card? Certainly, telling people to download a bunch of firmware udebs first before they can install, or making them do so within the installer, is a huge setback in installer userfriendliness. Non-free udebs CD. (So first of all, please let me implore you to let this slide for Sarge, at the very least. I already intend to do so. On the rather straightforward grounds that it's no worse than what was in woody, and therefore it isn't a regression. But eventually, if you keep up this crusade, installing Debian will involve having megabytes of firmware files at hand. Chances are that NIC drivers will get de-blobbed at some point, and will need firmware to work. Ooops. There goes the idea of downloading the firmware from the Internet at install time. I don't want to turn Debian into a speech-free, crippled distribution. That's not what I joined the project for. I suggest that you reconsider the long term effects of all this and perhaps try to come up with a less destructive to the situation (which I do believe is a valid one, within reason.) Contact the microcode providers and ask them to provide source. That's by far the least destructive solution. Unfortunately, most of them appear to simply not be willing to talk at all, not even to say no. :-P Some of them already *have* provided freely-licensed source (Advansys); that microcode is of course just fine to have in the kernel. Alternately, propose a GR to amend the Social Contract to allow non-free programs in main (under whatever limited circumstances you like). It quite obviously and clearly doesn't as of now, but feel free to try to change it if you think it should. I strongly encourage you to do so, as a matter of fact; if I were a DD, I'd even second it just to get it to a vote, though I would oppose it. I find that the unwillingness of the pro-sourceless-microcode-in-main camp to actually try to make their views compatible with most DD's agreement to follow the Social Contract in Debian work rather undermines their argments; proposing a GR to legitimate this stuff would be a lot more honest than encouraging people to blatantly violate the SC in their Debian work. (There's still the GPL-compatilibility issue, but in the case of properly licensed material like the Advansys microcode, userland firmware loading would presumably deal with that, and if the SC were amended to allow sourceless code in main, then the microcode could just be shipped along with the kernel, in the installer, etc.)
upgrade-i386 problem: test my kernel?
So, since nobody else was dealing with populating the upgrade-i386 directory, I took a crack at it. Background is in #241497. The essence is that woody users using real i386 boxes (not 486 or higher) need a patched kernel installed before they can upgrade to woody. I have therefore made such a patched kernel, by taking the last version of the kernel in woody, hacking out all support for anything except upgrading on real-i386, hacking in the necessary patch, and building in a woody chroot. This seemed the safest option. I have therefore made the following kernel packages: kernel-image-2.4.18-i386upgrade_2.4.18-1.dsc kernel-image-2.4.18-i386upgrade_2.4.18-1.tar.gz kernel-image-2.4.18-i386upgrade_2.4.18-1_i386.changes kernel-image-2.4.18-386upgrade_2.4.18-1_i386.deb kernel-pcmcia-modules-2.4.18-386upgrade_2.4.18-1_i386.deb At the moment they sit on my home computer because I don't have a reasonable place to upload them which has enough quota. I would like someone with a real i386 to volunteer to test these packages in a woody-sarge upgrade. I can't really test them myself because I don't have a real i386. But what I would like *first* is a place to put them for now so that such volunteer testers can get them. They are nearly lintian and linda clean (there are some warnings which are unavoidable due to the unusual way kernel packages were built). If they survive testing, I'll write up a little how to upgrade from woody to sarge if you have a real i386 and propose them for the upgrade-i386 directory. -- This space intentionally left blank.
Re: Bug#258082: missing advansys module
Norbert Tretkowski wrote: * Nathanael Nerode wrote: I unflagged it and built my own kernel, and it appears to work just fine. Perhaps Debian should allow it to build; the card is rather common. Mr. binary firmware is evil, s/evil/non-free/, please. did you realize that the advansys driver contains a small firmware blob? No, in a word. Thanks for pointing it out. (Actually, it contains at least three moderately large microcode blobs.) That's one thing which makes this stuff so annoying; it's not immediate or trivial to find all the embedded binary microcode in the kernel, or even in a particular file. I certainly can't claim to have found all the contaminated files. * Since I actually have an advansys card to test on, I should be able to convert this driver to userland firmware loading without the annoyances of a remote testing cycle. * The advansys driver is licensed under a very permissive non-copyleft license which doesn't require distribution of source. This makes it the first driver I've found with binary microcode which is actually licensed correctly! Hooray for that! This means I would be entirely comfortable making a package for non-free to contain the microcode. Actually, thanks for pointing this out; I now have a new project which should be significantly less frustrating than the other firmware-separation projects. :-) -- This space intentionally left blank.
Re: Debian kernel maintainter takeover
Adam Majer wrote: Nathanael Nerode wrote: Adam Majer wrote: As to the non-free binary blobs, these are to be moved to non-free. There should be an automatic 'non-free removal patches' (not part of the actual debian source). To follow the X Strike Force model (which seems to work) I suggest a 'prune-non-free' script, which should be shipped in the debian/ directory of the source package .diff for convenience. This script would convert an upstream source tree to a 'debian-clean' source tree. I don't think we can do that. The source to the package has to be free. The patches to remove non-free things and put them in non-free need to applied to the vanilla kernel to make a Debian kernel source (orig.tar.gz) and a non-free blob source. Yes. I'm saying that the script should be included in the source package for the convenience of people who want to build their own versions of the package, and so that it is easy to find. It would not actually be run at package build time (since it would be run *before* the upload of the .orig.tar.gz), but it would be shipped in the source package so that it's easy to find. This is what XFree86 packaging does.
