Bug#411294: linux-2.6: capi_{cmsg,message}2str not thread-safe; vulnerable to buffer overflow
tags 411294 patch thanks There's a patch upstream: http://bugzilla.kernel.org/attachment.cgi?id=10526action=view It applies cleanly to version 2.6.18.dfsg.1-10 with a small offset in some files, but I haven't checked whether any other changes might be needed for 2.6.18. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: This is a digitally signed message part
Bug#415709: linux-image-2.6.18-4-686: dv1394 oops on device removal
Package: linux-image-2.6.18-4-686 Version: 2.6.18.dfsg.1-11 Severity: normal Tags: patch, upstream I plugged in a CardBus 1394/USB card and used it to capture video from a DV camera. When I unplugged the card this resulted in an oops, though I didn't notice that immediately. When I plugged the card in again the system hung, apparently due to deadlock in the kernel. This is a known upstream bug in the dv1394 module and the upstream patch fixed it for me (it applies to 2.6.18 at a small offset). http://bugzilla.kernel.org/show_bug.cgi?id=7121 -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-4-686 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy linux-image-2.6.18-4-686 recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
On Thu, 2007-10-11 at 09:42 +0200, Per Olofsson wrote: Hi, Robert Edmonds wrote: The only rationale for removing the *firmware* is compliance with GR 2006-004... Am I missing something here? Didn't that GR fail? http://www.debian.org/vote/2006/vote_004 There's no need for a resolution to decide that executable machine code - whether or not you call it firmware[1] - is software. The relevant GR is 2006-007, which decided against making a permanent exception for firmware in the kernel. [1] The term firmware should apply only to software that is installed in non-volatile memory such as ROM or flash, which Debian does not need to distribute. What we're talking about here is software for peripheral processors. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Bug#405232: include rt2400/rt2500/rt2570/rt2x00
These packages are probably technically ready to be included in linux-modules-extra. However, rt2x00 was merged into Linux 2.6.24-rc1, and the legacy drivers are not actively maintained upstream, so I don't know think this is really a good idea. Ben. -- Ben Hutchings It is impossible to make anything foolproof because fools are so ingenious. signature.asc Description: This is a digitally signed message part
Re: rt2x00-modules-2.6.18-5-k7: should depend on the linux-image version used to build it
Luca Capello [EMAIL PROTECTED] wrote: since rt2x00-modules-* doesn't depend on the linux-image used to build it, it's not automatically removed with that linux-image. I agree that it might be desirable for module packages to be removed along with the kernel they can be used with. However, if the modules are built against an unpackaged kernel, this would then introduce an incorrect dependency. Is there a policy on whether this use case should be supported? BTW, I don't know anything technical about the module, but shouldn't depend on wireless-tools as well, instead of simply recommending it? No, you could configure it with network-manager instead. Ben. -- Ben Hutchings Everything should be made as simple as possible, but not simpler. - Albert Einstein signature.asc Description: This is a digitally signed message part
Bug#426561: modpost wrapper fails if given no filenames
Package: linux-kbuild-2.6.18 Version: 2.6.18-1 If a module source directory does not provide source for any complete modules, stage 2 of the build runs modpost with no filenames. The upstream version of modpost silently does nothing in this case (so far as I can see). Debian's wrapper unconditionally uses the first non-option argument as a filename, but if there are no such arguments it uses a null pointer and fails. This prevents some of our drivers from building on etch, though we can work around it. I think the wrapper should be compatible and do nothing if given no non-option arguments. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434135: linux-image-2.6.21-2-686: NFS client buffers writes then hangs
Package: linux-image-2.6.21-2-686 Version: 2.6.21-6 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have been using Kino to edit DV files on an NFS-mounted filesystem. When I export an edited sequence to a single file, Kino starts to write frames and then eventually hangs. Sometimes it recovers from the hang after a few seconds or minutes. In other cases I have given up on it after about 10 minutes. While Kino is hung, attempts to list the directory containing the file it was writing (ls -l) hang, but listing of other directories on the NFS-mount do not (I suspect that the stat call on this specific file is hanging). One thing I have noticed when listing the directory on the client and server *during* an export is that before the hang the client begins to show a much larger file size (up to 400 MB larger) than the server. In some cases I have been able to kill Kino, which sometimes unblocks ls as well. After this, the file sizes become consistent again. This does not happen with linux-image-2.6.18-4-686. - -- Package-specific info: - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (100, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.21-2-686 depends on: ii initramfs-tools [linux-initra 0.85g tools for generating an initramfs ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo Versions of packages linux-image-2.6.21-2-686 recommends: ii libc6-i686 2.3.6.ds1-13 GNU C Library: Shared libraries [i - -- debconf information excluded -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGomUr79ZNCRIGYgcRAhDuAKDhM6gg5Cci61SL1zazYkD1ciZGowCgmAdq 76xuTiVWl8X3f9+fj0eIfSc= =ewq1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471461: linux-modules-extra-2.6: Please add sfc modules
Package: linux-modules-extra-2.6 Version: 2.6.24-4 Severity: wishlist Please add the sfc modules (sfc-source). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468343: Page fault in nfs_complete_unlink
These oops messages seem incomplete but I'm assuming a page fault. The
traceback shows the fault at offset 0x10 in nfs_complete_unlink. The
top of this function is:
void
nfs_complete_unlink(struct dentry *dentry)
{
struct nfs_unlinkdata *data;
for(data = nfs_deletes; data != NULL; data = data-next) {
if (dentry == data-dentry)
break;
}
Offset 0x10 in the compiled code corresponds to the line if (dentry ==
data-dentry) with data in register rbx. In the register dump we see
rbx is 0x00050006, so the nfs_deletes list is corrupt.
The first comment in fs/nfs/unlink.c says:
* NOTE: we rely on holding the BKL for list manipulation protection.
So I looked at which functions manipulate the nfs_deletes list and
found:
- nfs_async_unlink
- called by nfs_sillyrename
- called by nfs_unlink, holding BKL
- called by nfs_rename, holding BKL
- nfs_complete_unlink
- called by nfs_dentry_iput, holding BKL
- nfs_detach_unlinkdata
- called by nfs_put_unlinkdata
- called by nfs_complete_unlink
- called by nfs_dentry_iput, holding BKL
- called by nfs_async_unlink_release
- called through rpc_call_ops::rpc_release
- NOT called with BKL!
The locking was revised and probably fixed by patch
e4eff1a622edd6ab7b73acd5d8763aa2fa3fee49 which went into Linux 2.6.23.
It looks like this will apply to 2.6.18 with a tiny bit of fudging, but
it changes ABI.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
signature.asc
Description: This is a digitally signed message part
Bug#471461: linux-modules-extra-2.6: Please add sfc modules
Daniel Baumann wrote: Hi Ben, sfc currently doesn't work, here is the build-log. Nevertheless, I've added the meta files for sfc in lme, but did not enable it yet. As soon as you've uploaded a fixed version of sfc to unstable, I'll enable it. The extraversion.h and config.h headers are built by the Makefile when it's not included by kbuild. You should not invoke kbuild directly on the module source directory. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471461: linux-modules-extra-2.6: Please add sfc modules
Bastian Blank wrote: On Fri, Mar 28, 2008 at 04:31:11PM +, Ben Hutchings wrote: You should not invoke kbuild directly on the module source directory. This is the prequisite to build it as part of linux-modules-*. OK. Why doesn't it do what module-assistant does? I could add a static config.h and extraversion.h to the package as we don't need to worry about versions with backported changes in Debian, unlike some other distributions I could mention. However we're switching to a more autoconf-like way of detecting kernel features, which will mean that in future it's essential to run a script before compiling any source files. I'll try using the filechk rules in kbuild to do this. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471461: linux-modules-extra-2.6: Please add sfc modules
Ben Hutchings wrote: Bastian Blank wrote: On Fri, Mar 28, 2008 at 04:31:11PM +, Ben Hutchings wrote: You should not invoke kbuild directly on the module source directory. This is the prequisite to build it as part of linux-modules-*. OK. Why doesn't it do what module-assistant does? I could add a static config.h and extraversion.h to the package as we don't need to worry about versions with backported changes in Debian, unlike some other distributions I could mention. I have done this in package version 2.2.0063-2. However we're switching to a more autoconf-like way of detecting kernel features, which will mean that in future it's essential to run a script before compiling any source files. I'll try using the filechk rules in kbuild to do this. I have successfully done this in the development tree, so unless it turns out to cause problems for other build configurations this should work without patching in future. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479721: FTBFS with 2.6.25-1
Upstream commit e80c1ff7cfb63e247a4479c4a20f65d373d99b62 should fix this: http://sources.redhat.com/git/?p=cluster.git;a=commitdiff;h=e80c1ff7cfb63e247a4479c4a20f65d373d99b62 (This doesn't make the sysfs code do the right thing, as it will free a superblock on unmount even if an open sysfs file still refers to it. That's not a regression though.) Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Fixing linux-modules-extra-2.6
Daniel, I had a look at the various build failures for linux-modules-extra-2.6, filed bugs on those module-source packages that didn't have them, and have suggested fixes for some. I then made the module-source bugs block #478314 as appropriate. sourceftbfs on? bug fixed atl2 mips, s390 453016 no (can be disabled) aufs - btrfs - drbd8 mips, mipsel453077 no (disabled) et131xs390480733 no (patch) gspca - iscsitarget alpha, hppa, mips, mipsel 480734 no (patch) kqemu - loop-aes - lzma - r6040 amd64 475705 no (patch) redhat-clusterall 479721 no (fixed-upstream) squashfs m68k431409 no (not release arch) sfc arm, armel, powerpc, sparc 475467 yes tp-smapi - unionfs - virtualbox-ose- virtualbox-ose-guest all 478333 no (patch) Unfortunately I haven't yet been able to test my suggested fixes for arch-dependent failures, and I don't know how we might disable some modules on some configurations (suggested for atl2). Also we don't know that there won't be other build failures once these are fixed. :-( Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: Fixing linux-modules-extra-2.6
On Mon, 2008-05-12 at 10:58 +0200, maximilian attems wrote: On Sun, 11 May 2008, Ben Hutchings wrote: sfc arm, armel, powerpc, sparc 475467 yes merged for 2.6.26 so can be dropped soon. Yes, I'm rather pleased about this one. :-) Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Bug#481561: linux-latest-2.6: Must be updated to depend on Linux 2.6.25
Package: linux-latest-2.6 Version: 13 Severity: serious Justification: Policy 2.2.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The linux-image-2.6-* packages still depend on linux-image-2.6.24-*, which are no longer in unstable. Obviously this needs to be updated. (Is there any reason why this can't be combined with linux-2.6 so they stay in sync?) Ben. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILjbE79ZNCRIGYgcRAuk+AKCuGfS+1BAY7d0EnUazQ/iKQuUrnQCgjgDx cAGZPpFzTGFwzXgqhL+NMiQ= =80aI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reassign 401035 to linux-2.6, found 401035 in 2.6.17-9, found 401035 in 2.6.18-6 ...
# Automatically generated email from bts, devscripts version 2.10.27 reassign 401035 linux-2.6 found 401035 2.6.17-9 found 401035 2.6.18-6 found 401035 2.6.22-6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fixing linux-modules-extra-2.6
New status: sourceftbfs on? bug fixed atl2 mips, s390 453016 disabled these aufs - btrfs many? disabled these drbd8 alpha, mips, mipsel, s390 453077 disabled these eeepc-acpi- et131xs390480733 no (should disable) gspca - iscsitarget alpha, mips, mipsel 480734 yes (but disabled) kqemu - loop-aes - lzma - nilfs2ia64481847 disabled ia64 r6040 amd64 475705 disabled (but should patch) redhat-clusterall 479721 disabled (but fixed-upstream) squashfs hppa, m68k 431409 disabled hppa; m68k not release arch sfc s390- no (should disable s390) tp-smapi - virtualbox-ose- virtualbox-ose-guest all 478333 no (patch) All the PCI drivers (atl2, et131x, r6040, sfc) should be disabled on s390 and any other configuration that excludes PCI. sfc is still enabled. I just uploaded a fix for #480734, and will try to work through the other bugs with patches available. Ben. -- Ben Hutchings Gates has joked that everything goes on and off unexepectedly in the house, which is run by a high-end PC network built on Windows NT. - Seattle Times signature.asc Description: This is a digitally signed message part
Bug#479721: FTBFS with 2.6.25-1
I made an NMU with the upstream patch. Here's the debdiff:
diff -u redhat-cluster-2.20080229/debian/changelog
redhat-cluster-2.20080229/debian/changelog
--- redhat-cluster-2.20080229/debian/changelog
+++ redhat-cluster-2.20080229/debian/changelog
@@ -1,3 +1,11 @@
+redhat-cluster (2.20080229-1.1) unstable; urgency=low
+
+ * Non-maintainer upload
+ * Added upstream patch for compatibility with Linux 2.6.25.
+Closes: #479721.
+
+ -- Ben Hutchings [EMAIL PROTECTED] Mon, 19 May 2008 23:46:03 +0100
+
redhat-cluster (2.20080229-1) unstable; urgency=low
[ Christian Perrier ]
only in patch2:
unchanged:
--- redhat-cluster-2.20080229.orig/debian/patches/00list
+++ redhat-cluster-2.20080229/debian/patches/00list
@@ -0,0 +1 @@
+2.6.25
only in patch2:
unchanged:
--- redhat-cluster-2.20080229.orig/debian/patches/2.6.25.dpatch
+++ redhat-cluster-2.20080229/debian/patches/2.6.25.dpatch
@@ -0,0 +1,149 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Upstream changes for compatibility with Linux 2.6.25
+## DP: (git commit e80c1ff7cfb63e247a4479c4a20f65d373d99b62):
+## DP: [KERNEL] Update modules to build with 2.6.25
+## DP: Update clean target to cope with a new file that Kbuild creates at
build time.
+## DP: Bump minimum kernel requirements to 2.6.25.
+## DP: Port modules to new kobj api.
+## DP: Signed-off-by: Fabio M. Di Nitto [EMAIL PROTECTED]
+
[EMAIL PROTECTED]@
+diff --git a/configure b/configure
+index 13ed3e6..2501059 100755
+--- a/configure
b/configure
+@@ -28,7 +28,7 @@ my $ret = 0;
+
+ # this should be only the major version without the extra version
+ # eg. only the first 3 digits
+-my $required_kernelversion = '2.6.24';
++my $required_kernelversion = '2.6.25';
+
+ my %options = (
+ help = \$help,
+diff --git a/gfs-kernel/src/gfs/sys.c b/gfs-kernel/src/gfs/sys.c
+index de64a3f..8afbebd 100644
+--- a/gfs-kernel/src/gfs/sys.c
b/gfs-kernel/src/gfs/sys.c
+@@ -85,24 +85,20 @@ static struct kobj_type gfs_ktype = {
+ .sysfs_ops = gfs_attr_ops,
+ };
+
+-static struct kset gfs_kset = {
+- .ktype = gfs_ktype,
+-};
++static struct kset *gfs_kset;
+
+ int gfs_sys_fs_add(struct gfs_sbd *sdp)
+ {
+ int error;
+
+- sdp-sd_kobj.kset = gfs_kset;
+- sdp-sd_kobj.ktype = gfs_ktype;
++ sdp-sd_kobj.kset = gfs_kset;
+
+- error = kobject_set_name(sdp-sd_kobj, %s, sdp-sd_table_name);
++ error = kobject_init_and_add(sdp-sd_kobj, gfs_ktype, NULL,
++ %s, sdp-sd_table_name);
+ if (error)
+ goto fail;
+
+- error = kobject_register(sdp-sd_kobj);
+- if (error)
+- goto fail;
++ kobject_uevent(sdp-sd_kobj, KOBJ_ADD);
+
+ return 0;
+
+@@ -112,20 +108,21 @@ int gfs_sys_fs_add(struct gfs_sbd *sdp)
+
+ void gfs_sys_fs_del(struct gfs_sbd *sdp)
+ {
+- kobject_unregister(sdp-sd_kobj);
++ kobject_put(sdp-sd_kobj);
+ }
+
+ int gfs_sys_init(void)
+ {
+ gfs_sys_margs = NULL;
+ spin_lock_init(gfs_sys_margs_lock);
+- kobject_set_name(gfs_kset.kobj, gfs);
+- kobj_set_kset_s(gfs_kset, fs_subsys);
+- return kset_register(gfs_kset);
++ gfs_kset = kset_create_and_add(gfs, NULL, fs_kobj);
++ if (!gfs_kset)
++ return -ENOMEM;
++ return 0;
+ }
+
+ void gfs_sys_uninit(void)
+ {
+ kfree(gfs_sys_margs);
+- kset_unregister(gfs_kset);
++ kset_unregister(gfs_kset);
+ }
+diff --git a/gnbd-kernel/src/gnbd.c b/gnbd-kernel/src/gnbd.c
+index 1be2eee..9a6abe3 100644
+--- a/gnbd-kernel/src/gnbd.c
b/gnbd-kernel/src/gnbd.c
+@@ -266,21 +266,19 @@ static const char *gnbdcmd_to_ascii(int cmd)
+
+ static void gnbd_end_request(struct request *req)
+ {
+- int uptodate = (req-errors == 0) ? 1 : 0;
++ int error = req-errors ? -EIO : 0;
+ struct request_queue *q = req-q;
+ unsigned long flags;
+
+ dprintk(DBG_BLKDEV, %s: request %p: %s\n, req-rq_disk-disk_name,
+- req, uptodate? done: failed);
++ req, error ? failed : done);
+
+- if (!uptodate)
++ if (error)
+ printk(%s %d called gnbd_end_request with an error\n,
+ current-comm, current-pid);
+
+ spin_lock_irqsave(q-queue_lock, flags);
+- if (!end_that_request_first(req, uptodate, req-nr_sectors)) {
+- end_that_request_last(req, uptodate);
+- }
++ __blk_end_request(req, error, req-nr_sectors 9);
+ spin_unlock_irqrestore(q-queue_lock, flags);
+ }
+
+@@ -879,10 +877,8 @@ static int __init gnbd_init(void)
+ struct timeval tv;
+ int i;
+
+- if (sizeof(struct gnbd_request) != 28) {
+- printk(KERN_CRIT gnbd: sizeof gnbd_request needs to be 28 in
order to work!\n );
+- return -EIO;
+- }
++ BUILD_BUG_ON(sizeof(struct gnbd_request) != 28);
++
+ shutdown_req.cmd_type = REQ_TYPE_SPECIAL
Bug#480733: Should not attempt to build et131x on s390
A similar problem applies to sfc, and to any other PCI driver (though the others are already excluded from being built for s390). Ben. -- Ben Hutchings One of the nice things about standards is that there are so many of them. signature.asc Description: This is a digitally signed message part
Re: Fixing linux-modules-extra-2.6
Today's status: sourceftbfs on? bug fixed atl2 mips, s390 453016 disabled these (but could patch for mips?) aufs - btrfs many? disabled these drbd8 alpha, mips, mipsel, s390 453077 disabled these eeepc-acpi- et131xs390480733 no (should disable s390) gspca - iscsitarget alpha, hppa, mips, mipsel 480734 yes (but disabled) kqemu - loop-aes - lzma - nilfs2ia64481847 disabled ia64 r6040 amd64 475705 disabled all (looks very buggy) redhat-clusterall 479721 yes (but disabled) squashfs hppa, m68k 431409 disabled hppa; m68k not release arch sfc s390480733 no (should disable s390) tp-smapi - virtualbox-ose- virtualbox-ose-guest all 478333 yes It looks like all architectures will build now if the remaining two PCI drivers are disabled on s390. iscsitarget and redhat-cluster could probably be re-enabled back now, but maybe it's best to leave them to a later upload for safety. I'm still working through the other build failures. Ben. -- Ben Hutchings One of the nice things about standards is that there are so many of them. signature.asc Description: This is a digitally signed message part
Bug#487721: linux-2.6: ipw2200 wrongly claims it can scan for hidden ESSIDs
Package: linux-2.6 Version: 2.6.25-5 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since I upgraded from Linux 2.6.24, NetworkManager cannot associate my Intel wireless card, handled by the ipw2200 driver, with my AP, which has a hidden SSID. NetworkManager thinks that wpa_supplicant should be able to scan for specific hidden SSIDs if the underlying driver advertises IW_SCAN_CAPA_ESSID, which ipw2200 does since 2.6.25. However, this doesn't work. I have confirmed that NetworkManager is interpreting this capability flag correctly and checked that wpa_supplicant has the patch that I was referred to - see the thread on linux-wireless http://thread.gmane.org/gmane.linux.kernel.wireless.general/15560. Therefore I believe the driver is at fault. This should be fixable by removing the capability flag: diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c index 6e70460..457c078 100644 - --- a/drivers/net/wireless/ipw2200.c +++ b/drivers/net/wireless/ipw2200.c @@ -8973,7 +8973,7 @@ static int ipw_wx_get_range(struct net_device *dev, range-enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 | IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP; - - range-scan_capa = IW_SCAN_CAPA_ESSID | IW_SCAN_CAPA_TYPE; + range-scan_capa = IW_SCAN_CAPA_TYPE; IPW_DEBUG_WX(GET Range\n); return 0; - --- END --- Ben. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFIX/n079ZNCRIGYgcRAtTDAJ0QJkA9bMRF6l9AEr5X6TukLEyq9ACfW+YL rCQutbYqXk8u8vZP8Zawka0= =pip+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: finalizing 2.6.28 config options
On Fri, 2009-02-06 at 14:42 +0100, maximilian attems wrote: [...] * FIRMWARE_IN_KERNEL default enabled we probably don't ship right yet relevant firmware separetly? FIRMWARE_IN_KERNEL enables inclusion of firmware along with drivers in the main kernel image, and has no effect on driver modules. Driver modules that use request_firmware() will always need separate firmware. [...] * USB_SERIAL_KEYSPAN_MPR USB_SERIAL_KEYSPAN_USA28 USB_SERIAL_KEYSPAN_USA28X USB_SERIAL_KEYSPAN_USA28XA USB_SERIAL_KEYSPAN_USA28XB USB_SERIAL_KEYSPAN_USA19 USB_SERIAL_KEYSPAN_USA18X USB_SERIAL_KEYSPAN_USA19W USB_SERIAL_KEYSPAN_USA19QW USB_SERIAL_KEYSPAN_USA19QI USB_SERIAL_KEYSPAN_USA49W USB_SERIAL_KEYSPAN_USA49WLC bunch of new firmware for some option style serial dev not looked at their licences yet nor request_firmware() usage This driver uses request_firmware(). * STAGING pile of crap drivers disabled in fedora, users might request it, but currently seems not really supportable. so i'd be for unsetting, but want opinons? We already distribute some of these, e.g. rt2860. I would favour enabling at least the ones that we currently distribute separately. [...] * STRICT_DEVMEM is userspace ready for that!? probably should da a testboot and see if lenny xorg comes up with it enabled. This has no effect on the X server, or at least that's the theory. * X86_VERBOSE_BOOTUP default yes and guess debian users like it!? [...] This can easily be overridden with quiet, in any case. Ben. signature.asc Description: This is a digitally signed message part
Bug#514288: stock debian kernels map heap, data, and other sections as rwx
On Thu, 2009-02-05 at 15:44 -0800, tgo wrote: Package: linux-image-2.6.24-e Version: 2.6.24-6~etchnhalf.7 On both vmlinuz-2.6.18-5-686 and vmlinuz-2.6.24-etchnhalf.1-686 kernels, the debian system maps the heap, binary data, and other data sections as rwx, instead of the normal and sensible rw-. This is a hardware limitation of i386 page tables - these permissions cannot be set independently. To overcome this limitation, you need a kernel that uses PAE page tables (-686-bigmem or -amd64 flavour) and a processor that supports the NX flag (look for nx on the flags line in /proc/cpuinfo). Ben. signature.asc Description: This is a digitally signed message part
Re: Problem with CIFS on Lenny?
On Thu, 2009-02-12 at 19:30 +0100, Harald Krammer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Harald Krammer schrieb: Hello! Exists any problems with CIFS on Lenny? Today I installed a Lenny on a machine (i386 based with i686-kernel) and all looks fine, but on shutdown the CIFS unmount process kills my machine (CIFS mount points were added in /etc/fstab). The magic key was also not working to find out the issue. Tomorrow I will try smbfs instead of CIFS... Any hints? Nice greetings, Harald Today I made a screen shot in case of a hang: http://hkr.at/uOyDFw3oTbfyT/problem.jpg - - before I start a shut down a manual remount of cifs shares solves the problem - - I can not reproduce the problem on Etch I notice that NetworkManager is mentioned. Do you allow it to manage the interface which was used to contact the file server? Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: Problem with CIFS on Lenny?
On Fri, 2009-02-13 at 14:12 +0100, Harald Krammer wrote: [...] Hello Ben, I did my network configuration with the Debian installer, selected DHCP and nothing more. h...@hkpc:~$ ps axu | grep -i network root 3073 0.0 0.0 12972 2084 ?Ssl 07:45 0:00 /usr/sbin/NetworkManager --pid-file /var/run/NetworkManager/NetworkManager.pid root 3081 0.0 0.0 3504 1324 ?Ss 07:45 0:00 /usr/sbin/NetworkManagerDispatcher --pid-file /var/run/NetworkManager/NetworkManagerDispatcher.pid Here is my /etc/network/interfaces : # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp That means that eth0 is managed by NetworkManager and not ifupdown. You should change allow-hotplug eth0 to auto eth0. See /usr/share/doc/network-manager/README.Debian for more details. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Bug#515073: linux-image-2.6.26-1-vserver-686: realtek r8139.ko shows erattic packets dropped (changes fast, always) from ifconfig
On Fri, 2009-02-13 at 01:57 -0700, supaplex wrote:
Package: linux-image-2.6.26-1-vserver-686
Version: 2.6.26-13
Severity: minor
netbook:~# for a in {0..9} ; do ifconfig eth0|grep 'RX packets';sleep
0.01;done
RX packets:10923 errors:0 dropped:1666757496 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1669188652 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1671339578 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1673867025 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1678176522 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1680628018 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1682748257 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1685294521 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1689635655 overruns:0 frame:0
RX packets:10923 errors:0 dropped:1691597286 overruns:0 frame:0
This segment of the network is pretty quiet, but dropped packets are
constantly counting. Clearly a cosmetic bug imo, but someone using
network monitoring might be unsetteled by what they think is a trend.
[...]
r8169 23684 0
[...]
You have r8169 not r8139 (which actually isn't the name of an existing
module, though there are 8139cp and 8139too).
This bug was previously reported
http://bugzilla.kernel.org/show_bug.cgi?id=10180 and fixed upstream
(commit 523a609496dbc3897e530db2a2f27650d125ea00). It will probably be
possible to apply this fix in a stable update.
Ben.
--
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou
signature.asc
Description: This is a digitally signed message part
Bug#515982: linux-image-2.6-486: Cannot boot on i486
On Wed, Feb 18, 2009 at 08:06:05PM +0100, Bas Wijnen wrote: On Wed, Feb 18, 2009 at 05:58:13PM +0100, maximilian attems wrote: Code: 00 89 c2 fa 90 8d b4 26 00 00 00 00 90 89 c8 89 ef c1 e8 02 89 c1 f3 a5 89 d9 83 e1 03 74 02 f3 a4 89 d0 50 9d 90 8d b4 26 00 00 00 00 b8 01 00 00 00 0f a2 5a 89 e8 5b 5e 5f 5d c3 55 31 c9 57 EIP: [c010797d] text_poke_early+0x41/0x52 SS:ESP 0068:c0363eb0 ---[ end trace 4eaa2a86a8e2da22 ]--- Kernel panic - not syncing: Attempted to kill the idle task! can you check if 2.6.28 trunk buildserver images are fine inbetween? They give the same panic, with almost the same output (now it's at text_poke_early+0x3e/0x4e, but the Code is the same). text_poke_early() is patching code sequences that need to be changed dynamically. The problem seems to be that it itself contains such a code sequence! The bytes 8d b4 26 00 00 00 00 match GENERIC_NOP7 and the instruction pointer in this crash points into the middle of those, which suggests that they've just been changed. I think this is something to do with the tracing added by CONFIG_TRACE_IRQFLAGS_SUPPORT. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFC: Firmware removal
Now that lenny is out, it's time for an update on this. I wrote: No word from Sun re Cassini. Still no word, I've tried contacting Simon Phipps now. There is a FreeBSD driver for the Kawasaki USB network chips (kaweth driver) under 4-clause BSD but the stated copyright holder for the firmware is the driver author, which is not correct. I will try contacting him. Bill Paul wrote: First, look here: http://www.freebsd.org/~wpaul/KLSI These are all of the files that I originally received from Kawasaki LSI when I first contacted them about writing a driver, as I originally received them. This includes the file containing the firmwre image. I was never given any firmware source. You will note that there are no copyright headers at all, and when I spoke to the Kawasaki representative on the phone the subject of copyright on the firmware image never came up. I wrote: No news from Tehuti, but I found firmware in OpenBSD under 4-clause BSD. Pinchas Ziv (CEO of Tehuti) wrote: We are satisfied with the last statement: Permission is hereby granted for the distribution of this firmware data in hexadecimal or equivalent format, provided this copyright notice is accompanying it. I wrote: WhiteHEAT hardware is still avalable so there may be some mileage in contacting the manufacturer. I talked back and forth with them and they seemed to be happy to fix the license text but I never got a final statement of what exactly it would be. I think we should move ahead with removal of sourceless firmware, but include everything we have clear permission to distribute in the non-free section. This would exclude the 3 blobs mentioned above and several others that are already stripped from Debian kernels. I propose that future versions of firmware-nonfree, or a second firmware source package, should be based on the firmware directory of Linux releases, using a script to exclude the files with unclear license status. The contents of the firmware directory should be excluded from the linux-2.6 package except where source is available. Of the 13 sourceless firmware blobs I was aware of in the lenny kernel, several have subsequently been moved to the firmware directory: - 2.6.27: dabusb, dsp56k (with source), kaweth, whiteheat - 2.6.28: cassini - 2.6.29: e100, starfire - linux-next: qla1280 The remaining firmware - found in mga, r128, radeon, tehuti, typhoon - is at least clearly redistributable. Before I spend (and possibly waste) time in preparing packages, I'd like to get people's opinions on this proposal. Ben. signature.asc Description: This is a digitally signed message part
[PATCH] Firmware removal
Here's a patch against svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6. Still largely untested, I'm afraid. Ben. Index: debian/patches/debian/dfsg/files-1 === --- debian/patches/debian/dfsg/files-1 (revision 12898) +++ debian/patches/debian/dfsg/files-1 (working copy) @@ -23,6 +23,12 @@ rm firmware/vicam rm firmware/yamaha +rm drivers/gpu/drm/mga/mga_ucode.h + +unifdef drivers/gpu/drm/r128/r128_cce.c -UREMOVE_DFSG + +rm drivers/gpu/drm/radeon/radeon_microcode.h + rm drivers/net/appletalk/cops.c rm drivers/net/appletalk/cops.h rm drivers/net/appletalk/cops_ffdrv.h @@ -38,10 +44,18 @@ rm drivers/net/myri_code.h +rm drivers/net/tehuti_fw.h + rm drivers/net/tokenring/3c359.c rm drivers/net/tokenring/3c359.h rm drivers/net/tokenring/3c359_microcode.h +rm drivers/net/typhoon-firmware.h + +rm drivers/scsi/ql1040_fw.h +rm drivers/scsi/ql12160_fw.h +rm drivers/scsi/ql1280_fw.h + rm drivers/scsi/qlogicpti_asm.c rm sound/pci/cs46xx/cs46xx_image.h Index: debian/patches/series/1~experimental.1 === --- debian/patches/series/1~experimental.1 (revision 12898) +++ debian/patches/series/1~experimental.1 (working copy) @@ -8,6 +8,12 @@ #+ debian/dfsg/drivers-net-bnx2-request_firmware-1.patch #+ features/all/drivers-net-acenic-firmwar_request.patch ++ features/all/drivers-gpu-drm-mga-request_firmware.patch ++ features/all/drivers-gpu-drm-r128-request_firmware.patch ++ features/all/drivers-gpu-drm-radeon-request_firmware.patch ++ features/all/drivers-net-tehuti-request_firmware.patch ++ features/all/drivers-net-typhoon-request_firmware.patch ++ features/all/drivers-scsi-qla1280-request_firmware.patch + features/all/export-gfs2-locking-symbols.patch + features/all/export-unionfs-symbols.patch Index: debian/patches/series/orig-0 === --- debian/patches/series/orig-0(revision 12898) +++ debian/patches/series/orig-0(working copy) @@ -1,10 +1,16 @@ -X debian/dfsg/files-1 ++ debian/dfsg/drivers-gpu-drm-mga-disable.patch ++ debian/dfsg/drivers-gpu-drm-r128-disable.patch ++ debian/dfsg/drivers-gpu-drm-radeon-disable.patch + debian/dfsg/drivers-net-bnx2-disable.patch + debian/dfsg/drivers-net-bnx2x-disable.patch + debian/dfsg/drivers-net-appletalk-cops.patch + debian/dfsg/drivers-net-hamradio-yam.patch + debian/dfsg/drivers-net-myri.patch ++ debian/dfsg/drivers-net-tehuti-disable.patch + debian/dfsg/drivers-net-tokenring-3c359-smctr.patch ++ debian/dfsg/drivers-net-typhoon-disable.patch ++ debian/dfsg/drivers-scsi-qla1280-disable.patch + debian/dfsg/drivers-scsi-qlogicpti.patch + debian/dfsg/firmware-cleanup.patch + debian/dfsg/sound-pci.patch +X debian/dfsg/files-1 Index: debian/patches/features/all/drivers-net-typhoon-request_firmware.patch === --- debian/patches/features/all/drivers-net-typhoon-request_firmware.patch (revision 0) +++ debian/patches/features/all/drivers-net-typhoon-request_firmware.patch (revision 0) @@ -0,0 +1,167 @@ +From 06fdc64b4d38bde05d41dfa9dfef78473ffae8cd Mon Sep 17 00:00:00 2001 +From: Ben Hutchings b...@decadent.org.uk +Date: Sat, 18 Oct 2008 16:04:33 +0100 +Subject: [PATCH 21/24] typhoon: use request_firmware + +Based on patch by Jaswinder Singh jaswin...@infradead.org, +with additional validation of the firmware size. + +made following const as we treat firmware data as const: +struct typhoon_file_header *fHdr +struct typhoon_section_header *sHdr +u8 *image_data +--- + drivers/net/Kconfig |2 +- + drivers/net/typhoon.c | 74 + + 2 files changed, 63 insertions(+), 13 deletions(-) + +diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig +index 4bddcbd..29dfc1d 100644 +--- a/drivers/net/Kconfig b/drivers/net/Kconfig +@@ -732,7 +732,7 @@ config VORTEX + config TYPHOON + tristate 3cr990 series \Typhoon\ support + depends on NET_VENDOR_3COM PCI +- depends on BROKEN ++ select FW_LOADER + select CRC32 + ---help--- + This option enables driver support for the 3cr990 series of cards: +diff --git a/drivers/net/typhoon.c b/drivers/net/typhoon.c +index 734ce09..4cacb62 100644 +--- a/drivers/net/typhoon.c b/drivers/net/typhoon.c +@@ -129,16 +129,18 @@ static const int multicast_filter_limit = 32; + #include asm/uaccess.h + #include linux/in6.h + #include linux/dma-mapping.h ++#include linux/firmware.h + + #include typhoon.h +-#include typhoon-firmware.h + + static char version[] __devinitdata = + typhoon.c: version DRV_MODULE_VERSION ( DRV_MODULE_RELDATE )\n; + ++#define FIRMWARE_NAME 3com/typhoon.bin + MODULE_AUTHOR(David Dillow d...@thedillows.org); + MODULE_VERSION(DRV_MODULE_VERSION); + MODULE_LICENSE(GPL); ++MODULE_FIRMWARE
Re: [PATCH] Firmware removal
On Sun, 2009-02-22 at 10:58 +0100, maximilian attems wrote: On Sun, Feb 22, 2009 at 03:53:22AM +, Ben Hutchings wrote: Here's a patch against svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6. Still largely untested, I'm afraid. Ben. looks good to me. anyway now is a good time to eventually break something. do you send in the drm patches to airlied, so that they land for 2.6.20 ? Yes, but they haven't been merged. I'll try again. Ben. signature.asc Description: This is a digitally signed message part
Re: [PATCH] Firmware removal
On Sun, 2009-02-22 at 11:37 +0100, Bastian Blank wrote:
On Sun, Feb 22, 2009 at 03:53:22AM +, Ben Hutchings wrote:
--- debian/patches/series/orig-0(revision 12898)
+++ debian/patches/series/orig-0(working copy)
@@ -1,10 +1,16 @@
-X debian/dfsg/files-1
There is a reason why this was at the beginning. See the old tg3 patches
for details.
It needs to be placed after any patches that insert markers for unifdef.
++static const struct firmware *typhoon_fw;
const is already static.
What are you talking about? There is no connection whatsoever between
the two.
Why is that a global variable?
This was written by Jaswinder Singh; ask him. ;-)
++ pdev = platform_device_register_simple(r128_cce, 0, NULL, 0);
++ if (IS_ERR(pdev)) {
++ printk(KERN_ERR r128_cce: Failed to register firmware\n);
++ return PTR_ERR(pdev);
++ }
++ rc = request_firmware(fw, FIRMWARE_NAME, pdev-dev);
++ platform_device_unregister(pdev);
The drm modules don't register proper devices already?
Apparently not, though there are PCI devices associated with this. I
based this on what Jaswinder did for radeon.
++/* Firmware section */
++#define FIRMWARE_BDX tehuti/bdx.bin
++static const struct firmware *bdx_fw;
Again, why global?
+index efaf84d..dec67e0 100644
+--- a/drivers/net/tehuti.h
b/drivers/net/tehuti.h
+@@ -29,6 +29,7 @@
+ #include linux/if_vlan.h
+ #include linux/interrupt.h
+ #include linux/vmalloc.h
++#include linux/firmware.h
+ #include asm/byteorder.h
This looks wrong. Nothing from firmware.h is used in this header.
Right, this seems to be a holdover from an earlier version of the patch
which kept referenes to the firmware in struct bdx_priv.
+ [ Ben Hutchings ]
+ * Remove firmware from drivers and make them use request_firmware():
+- mga (closes: #502666)
+- qla1280 (closes: #502667)
+- r128 (closes: #494007)
+- radeon (closes: #494009)
+- tehuti (closes: #501153)
+- typhoon (closes: #502669)
The patches still needs to be accepted upstream.
The patch for qla1280 has been. The others, I'll try to push again.
But this hasn't been a requirement for e.g. the tg3 patch so I don't see
why it should be for others.
Ben.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Firmware removal
On Sun, 2009-02-22 at 15:10 +, Ben Hutchings wrote:
On Sun, 2009-02-22 at 11:37 +0100, Bastian Blank wrote:
[...]
Why is that a global variable?
This was written by Jaswinder Singh; ask him. ;-)
This was clearly wrong given that firmware was loaded in the probe
function, not the module init function. Given that firmware is not
needed outside of the probe function, I have removed the static firmware
variable from this and the tehuti driver patches.
+index efaf84d..dec67e0 100644
+--- a/drivers/net/tehuti.h
b/drivers/net/tehuti.h
+@@ -29,6 +29,7 @@
+ #include linux/if_vlan.h
+ #include linux/interrupt.h
+ #include linux/vmalloc.h
++#include linux/firmware.h
+ #include asm/byteorder.h
This looks wrong. Nothing from firmware.h is used in this header.
Right, this seems to be a holdover from an earlier version of the patch
which kept referenes to the firmware in struct bdx_priv.
In fact the #include is here because tehuti.c only #includes tehuti.h.
This is strange but I don't see any point in changing this.
+ [ Ben Hutchings ]
+ * Remove firmware from drivers and make them use request_firmware():
+- mga (closes: #502666)
+- qla1280 (closes: #502667)
+- r128 (closes: #494007)
+- radeon (closes: #494009)
+- tehuti (closes: #501153)
+- typhoon (closes: #502669)
The patches still needs to be accepted upstream.
The patch for qla1280 has been. The others, I'll try to push again.
I have now submitted the other patches to drm and net maintainers and
lists.
Ben.
signature.asc
Description: This is a digitally signed message part
Re: dmesg timestamps vs uptime
On Wed, 2009-02-25 at 20:47 -0500, Yaroslav Halchenko wrote: My today reported (and reassigned to linux2.6) bug #517122 doesn't gimme rest. One of the problem of analysis of traces is that some times are recorded since epoch, some are the kernel's uptime. what puzzles me is: * Difference between dmesg timestamp and /proc/uptime $ tcpdump -i bond0 -tt -vvv -n (dst host raider or src host raider) -s 192 | head -3; dmesg | tail -1; echo /proc/uptime; cat /proc/uptime ... [250851.259481] device eth1 left promiscuous mode /proc/uptime 241764.70 224706.33 so I have timestamp in kernel messages bigger than uptime I wonder why is that? different clock source? any other drift? Different clock source. or may be 'kernel time' in dmesg is some kind of tick, not time per se? It's a scheduler timestamp, which is an approximation to real time but due to internal requirements of the scheduler may run slightly fast. Timestamps in the kernel log help to show how close together events occurred, but nothing more. * Is there an easy way to convert (reliably ;)) timestamp in dmesg to time since epoch (with mksec precision of cause), so I could easily compare with output in strace and alike. Not really, but you can get a scheduler timestamp from /proc/sched_debug which may help in correlating them. Ben. signature.asc Description: This is a digitally signed message part
Re: Re: dmesg timestamps vs uptime
On Wed, 2009-02-25 at 23:06 -0500, Yaroslav Halchenko wrote: Hi Ben, Thanks -- that is a nice pointer (i.e. /proc/sched_debug), but I still can't match everything up in my mind... could you gimme a little hint? I guess the .clock (in sched_debug) is the interesting one, but it doesn't match up to the time reported by the kernel... $ sudo tcpdump -i bond0 -tt -vvv -n (dst host raider or src host raider) -s 192 | head -3; dmesg | tail -1; grep -e 'now' -e '\.clock' /proc/sched_debug ; echo -n date :; date +'%s.%N'; echo -n uptime:; cat /proc/uptime 1235620965.207560 IP (tos 0x0, . ... [259941.257724] device eth1 left promiscuous mode now at 250362660.852703 msecs .clock : 250362660.973307 .clock : 250362661.008877 date :1235620965.387909070 uptime:250362.67 232514.99 so indeed /proc/uptime is close (or is) what is in .clock in sched_debug, but how could I get those 259941.257724? I am sorry if that is something obvious and RTFM Sorry, I thought the clocks shown in sched_debug matched the log timestamps, but I was wrong. I think the divergence is a result of cross-processor interactions, and my machine only has a single processor. Grepping the kernel source suggests that there is currently no way to read the current value of the clock used by printk from user-space. If you are prepared to write a kernel module then you can get the value in nanoseconds for a particular CPU using cpu_clock(cpu_id). Ben. signature.asc Description: This is a digitally signed message part
Bug#517181: linux-image-2.6.28-1-amd64: bnx2 driver not shipped
On Thu, 2009-02-26 at 14:20 +0530, Ritesh Raj Sarraf wrote: Package: linux-image-2.6.28-1-amd64 Version: 2.6.28-1 Severity: important *** Please type your report below this line *** The bnx2 driver is not available in 2.6.28. The same is available in 2.6.26 We have been patching bnx2 to use a separate firmware file. However it seems that this patch was accidentally dropped for 2.6.28 and the driver was left broken (so not built at all). This should be fixed in the first package of 2.6.29. Ben. signature.asc Description: This is a digitally signed message part
Bug#517627: linux-image-2.6.26-1-parisc64-smp: Acenic driver without firmware triggers HPMC
On Sun, 2009-03-01 at 01:48 +0100, Thibaut VARENE wrote: Package: linux-image-2.6.26-1-parisc64-smp Version: 2.6.26-13 Severity: important Acenic driver is provided without firmware. When it's being loaded at boot time, it starts complaining that it can't find a firmware to load. Boot progreses for a little while and eventually when setting up networking, the box goes kaboom. Yay. Can you be more specific? Meanwhile, I should see about adding the firmware to firmware-nonfree. Ben. signature.asc Description: This is a digitally signed message part
Bug#517193: linux-image-2.6.28-1-amd64 fails to boot on amd64
Can you confirm whether this boot failure matches the bug filed upstream as http://bugzilla.kernel.org/show_bug.cgi?id=12520? That bug has not yet been fixed in a stable release but is believed to be fixed in Linux 2.6.29. Ben. -- Ben Hutchings Life is like a sewer: what you get out of it depends on what you put into it. signature.asc Description: This is a digitally signed message part
Bug#494009: linux-2.6: are the ATI firmware-nonfree files available?
On Fri, 2009-03-06 at 01:56 +1030, Arthur Marsh wrote: Package: linux-2.6 Followup-For: Bug #494009 I couldn't find any files containing ATI firmware at http://ftp.debian.org/debian/pool/non-free/f/firmware-nonfree/ Are these files available anywhere? They're in the Subversion repository for this package and will be in the next release. Note that the change to remove them from kernel images is also unreleased. Ben. signature.asc Description: This is a digitally signed message part
Re: future proofing linux-2.6 config, disabling deprecated interfaces
maximilian attems m...@stro.at wrote: for 2.6.29 following interfaces will be unset: - SCSI_PROC_FS should only be needed by legacy apps, sysfs equiv exists - PCMCIA_IOCTL pcmciautils is even already shipped in etch - ACPI_PROCFS - ACPI_PROCFS_POWER - ACPI_PROC_EVENT scheduled to be removed soon they should only be needed by legacy applications and it is the right time in the release now to either have those kicked out as nobody uses them anyway or to have userland fixed. [...] Most of /proc/acpi is redundant but at least some files don't yet have alternatives: 13:53 bwh # CONFIG_ACPI_PROCFS is not set 13:54 mjg59 bwh: Given that not all of the proc functionality has been ported elsewhere yet, I'd say that's aggressive 13:54 bwh What's missing? 13:56 mjg59 bwh: Device wakeup control 13:57 mjg59 Setting things like DOS 14:00 bwh DOS? 14:00 mjg59 bwh: Display Output Switch Ben. -- Ben Hutchings The world is coming to an end. Please log off. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509646: bnx2x firmware licensing
On Thu, 2009-03-19 at 13:05 -0600, John Wright wrote: Hi Eilon, In bnx2x_init_values.h, there appear to be several sourceless firmware blobs (init_data_*, *_int_table_data_*, and arguably init_ops). [...] init_ops looks like a plausible preferred form for modification to me. It's not very meaningful without reference to the Programmers' Reference Manual, but then neither is most of the other hardware setup code in the driver. Regarding the other tables, I'll reiterate John's request. Unless you can make a good case that these really are the preferred form for modification, or apply a licence that does not require source, then Debian can't distribute them at all. Ben. signature.asc Description: This is a digitally signed message part
Bug#414287: eth0 to eth0_rename_ren
On Mon, 2009-03-23 at 09:06 +, Nigel Horne wrote: I just had to change my motherboard and when I did I lost eth0 and it was called eth0_rename with no networking. I manually changed everything in /etc/network/interfaces from eth0 to eth0_rename along with firewall/routing/blah blah settings. This morning I booted up and guess what? The same problem, only this time I had to change eth0_rename to eth0_rename_ren in all my files and settings. What gives? Why doesn't Linux just call it eth0, it's not rocket science! Ethernet interfaces are initially named eth0, eth1, etc. as they are detected by drivers. The order in which they are detected and numbered may vary between boots and particularly if you install, remove or relocate expansion cards. If you have udev installed (you probably do) it will record the name of each new physical interface (identified by MAC address) in /etc/udev/rules.d/70-persistent-net.rules. On subsequent boots these rules ensure that interfaces get the same name again. However, sometimes the rules may be written wrongly such that two interfaces are supposed to be given the same name (eth0 in this case). In this case udev will give up and one of them will be left with the _rename suffix. You will need to edit this file to fix it. Ben. signature.asc Description: Digital signature
Bug#520891: general: Data coruption on my /dev/sda - /dev/sdd sata_siil siil 3114 chip
On Mon, 2009-03-23 at 16:55 +0100, Bengt Samuelsson wrote: I will be verry happy to ansver every question you may have. It is an old problem I am not able to solve myself. There is an old bug report on the kernel Bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=6845. Unfortunately several different problems seem to have been conflated in this one report, but it does provide a list of things to try: 1. Change the RAM 2. Use the disks individually (assume they're not all broken...) 3. Change the motherboard if it has an nforce chipset (Nvidia really should stick to graphics) 4. Apply the patch http://bugzilla.kernel.org/attachment.cgi?id=12200 to the kernel So far as I can see, no changes have been made to the driver since 2.6.18 to address this bug. Ben. signature.asc Description: Digital signature
Bug#521553: rt2860 driver contains non-free firmware
On Sat, 2009-03-28 at 15:03 +0200, Damyan Ivanov wrote: Package: linux-2.6 Version: 2.6.29 Severity: serious [cc-ed to debian-eeepc-devel as the affected network controller is uused in several eeepc models] Hi, The file drivers/staging/rt2860/common/firmware.h contains the following text: [...] There was me thinking we'd finally got rid of the firmware, and more of it pops up in drivers/staging. Another reason to hate that directory. A quick search finds the following additional firmware files: drivers/staging/me4000/me4000_firmware.h drivers/staging/me4000/me4610_firmware.h drivers/staging/otus/hal/hp*fw*.c drivers/staging/rt2870/common/firmware.h drivers/staging/slicoss/gbrcvucode.h drivers/staging/slicoss/oasisrcvucode.h Of these, only rt2860 and rt2870 are enabled in Debian. Ben. On Sat, 2009-03-28 at 15:03 +0200, Damyan Ivanov wrote: Package: linux-2.6 Version: 2.6.29 Severity: serious [cc-ed to debian-eeepc-devel as the affected network controller is uused in several eeepc models] Hi, The file drivers/staging/rt2860/common/firmware.h contains the following text: [...] There was me thinking we'd finally got rid of the firmware, and more of it pops up in drivers/staging. Another reason to hate that directory. A quick search finds the following additional firmware files: drivers/staging/me4000/me4000_firmware.h drivers/staging/me4000/me4610_firmware.h drivers/staging/otus/hal/hp*fw*.c drivers/staging/rt2870/common/firmware.h drivers/staging/slicoss/gbrcvucode.h drivers/staging/slicoss/oasisrcvucode.h Of these, only rt2860 and rt2870 are enabled in Debian. Ben. signature.asc Description: Digital signature
Bug#521553: rt2860 driver contains non-free firmware
On Sat, Mar 28, 2009 at 02:34:14PM +, Ben Hutchings wrote: On Sat, 2009-03-28 at 15:03 +0200, Damyan Ivanov wrote: Package: linux-2.6 Version: 2.6.29 Severity: serious [cc-ed to debian-eeepc-devel as the affected network controller is uused in several eeepc models] Hi, The file drivers/staging/rt2860/common/firmware.h contains the following text: [...] There was me thinking we'd finally got rid of the firmware, and more of it pops up in drivers/staging. Another reason to hate that directory. A quick search finds the following additional firmware files: drivers/staging/me4000/me4000_firmware.h drivers/staging/me4000/me4610_firmware.h drivers/staging/otus/hal/hp*fw*.c drivers/staging/rt2870/common/firmware.h drivers/staging/slicoss/gbrcvucode.h drivers/staging/slicoss/oasisrcvucode.h Of these, only rt2860 and rt2870 are enabled in Debian. I'd like to commit the following change. Obviously this disables the drivers and they will have to be modified to work with external firmware. But I don't see why we should wait for that. Ben. Index: debian/changelog === --- debian/changelog(revision 13283) +++ debian/changelog(working copy) @@ -1,4 +1,4 @@ -linux-2.6 (2.6.29-2) UNRELEASED; urgency=low +linux-2.6 (2.6.29.dfsg.1-2) UNRELEASED; urgency=low [ Martin Michlmayr ] * [arm/ixp4xx] Build in LEDS_TRIGGER_TIMER (closes: #521141). @@ -6,8 +6,12 @@ [ maximilian attems ] * linux-libc-dev: Bump versioned replaces libdrm-dev. - -- Martin Michlmayr t...@cyrius.com Wed, 25 Mar 2009 08:57:14 +0100 + [ Ben Hutchings ] + * Remove firmware from driver/staging (closes: #521553) +- Disable affected drivers: rt2860, rt2870 + -- Ben Hutchings b...@decadent.org.uk Sat, 28 Mar 2009 10:42:00 -0500 + linux-2.6 (2.6.29-1) unstable; urgency=low * New upstream release Index: debian/patches/debian/dfsg/drivers-staging-slicoss-disable.patch === --- debian/patches/debian/dfsg/drivers-staging-slicoss-disable.patch (revision 0) +++ debian/patches/debian/dfsg/drivers-staging-slicoss-disable.patch (revision 0) @@ -0,0 +1,11 @@ +diff --git a/drivers/staging/slicoss/Kconfig b/drivers/staging/slicoss/Kconfig +index d2993d3..2b510e0 100644 +--- a/drivers/staging/slicoss/Kconfig b/drivers/staging/slicoss/Kconfig +@@ -1,5 +1,6 @@ + config SLICOSS + tristate Alacritech Gigabit IS-NIC support ++ depends on BROKEN + depends on PCI X86 NETDEV_1000 + default n + help Index: debian/patches/debian/dfsg/drivers-staging-otus-disable.patch === --- debian/patches/debian/dfsg/drivers-staging-otus-disable.patch (revision 0) +++ debian/patches/debian/dfsg/drivers-staging-otus-disable.patch (revision 0) @@ -0,0 +1,11 @@ +diff --git a/drivers/staging/otus/Kconfig b/drivers/staging/otus/Kconfig +index d549d08..fef9785 100644 +--- a/drivers/staging/otus/Kconfig b/drivers/staging/otus/Kconfig +@@ -1,5 +1,6 @@ + config OTUS + tristate Atheros OTUS 802.11n USB wireless support ++ depends on BROKEN + depends on USB WLAN_80211 MAC80211 + default N + ---help--- Index: debian/patches/debian/dfsg/files-1 === --- debian/patches/debian/dfsg/files-1 (revision 13283) +++ debian/patches/debian/dfsg/files-1 (working copy) @@ -57,5 +57,15 @@ rm drivers/scsi/qlogicpti_asm.c +rm drivers/staging/me4000/me*_firmware.h + +rm drivers/staging/otus/hal/hp*fw*.c + +rm drivers/staging/rt2860/common/firmware.h + +rm drivers/staging/rt2870/common/firmware.h + +rm drivers/staging/slicoss/*ucode.h + rm sound/pci/cs46xx/cs46xx_image.h rm sound/pci/cs46xx/imgs Index: debian/patches/debian/dfsg/drivers-staging-me4000-disable.patch === --- debian/patches/debian/dfsg/drivers-staging-me4000-disable.patch (revision 0) +++ debian/patches/debian/dfsg/drivers-staging-me4000-disable.patch (revision 0) @@ -0,0 +1,12 @@ +diff --git a/drivers/staging/me4000/Kconfig b/drivers/staging/me4000/Kconfig +index 5e6c9de..45d2ea9 100644 +--- a/drivers/staging/me4000/Kconfig b/drivers/staging/me4000/Kconfig +@@ -1,6 +1,7 @@ + config ME4000 + tristate Meilhaus ME-4000 support + default n ++ depends on BROKEN + depends on PCI + help + This driver supports the Meilhaus ME-4000 family of boards Index: debian/patches/debian/dfsg/drivers-staging-rt2860-disable.patch === --- debian/patches/debian/dfsg/drivers-staging-rt2860-disable.patch (revision 0) +++ debian/patches/debian/dfsg/drivers-staging-rt2860-disable.patch (revision 0) @@ -0,0 +1,11 @@ +diff --git a/drivers/staging/rt2860/Kconfig b
Re: Comments regarding firmware-nonfree_0.15_amd64.changes
On Sat, 2009-03-28 at 23:06 +, Frank Lichtenheld wrote: Hi. debian/copyright for firmware-linux says The binary firmwares are downloaded from http://ftp.debian.org/debian/pool/non-free/f/firmware-nonfree; which is probably not true. Shouldn't that be kernel.org or something? This new package contains some firmware that is distributed in binary-equivalent form by kernel.org. We should probably change both the upstream URL and the template for the package description. Ben. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#485034: linux-image-2.6.25-2-686: ath5k associates but no network
On Sun, 2009-03-29 at 10:38 -0700, Bill Wohler wrote: maximilian attems m...@stro.at wrote: I did, however, try WEP with 2.6.26. My box still did not associate. could you please try a more recent kernel like 2.6.29. ath5k saw a lot of work since. Thanks. There are a couple of issues which will get in my way: 1. The new kernels have really, really large /lib/modules directories and are too big for my / partition. [...] This was true of 2.6.28 but the problem was fixed in 2.6.29. Ben. signature.asc Description: This is a digitally signed message part
Re: HP netbook ethernet problem.
On Wed, 2009-04-08 at 11:15 -0700, jscottkas...@yahoo.com wrote: Hi guys, I'm not subscribed, so please CC. I'm trying to use Debian on a brand new HP Mini 1030NR netbook. The internal wired ethernet adaptor is supported by the Sky2 driver. The problem that I have is that the device is rarely ever detected by the kernel, so no driver is, or can, be loaded to activate the device. [...] When the ethernet adapter is not detected, is it visible using lspci? If not, this is probably a hardware fault. If it does appear but the driver fails to initialise it, please report a bug including the kernel log messages. Ben. signature.asc Description: This is a digitally signed message part
Bug#522956: firmware-matrox: g200-warp firmware from firmware-linux kills system on 3d-acceleration
On Tue, 2009-04-07 at 19:21 +0300, David Baron wrote: Package: firmware-linux Version: 0.16? Severity: critical Justification: breaks the whole system As of 2.6.29 kernels, this (nonfree?) code is broken out of the kernel's driver and loaded from this package. The mga driver for Matrox g200 mila card worked before when this separate firmware was not necessary. Sorry about this. No-one has previously reported the results of the patch to separate Matrox firmware so it may not have been tested before it was included in the 2.6.29 package. Now, any attempt to start a 3d-accelerated app (i.e. games like chromium or ppracer) will freeze the entire system. Only logged error will be x existed suddenly or such. If you have another computer on the local network, can you try enabling netconsole and capturing kernel messages up to the crash? What happens if you uninstall the firmware? The result should be a fallback to software rendering. Ben. signature.asc Description: This is a digitally signed message part
Bug#522956: firmware-matrox: g200-warp firmware from firmware-linux kills system on 3d-acceleration
On Sat, 2009-04-11 at 21:58 +0300, David Baron wrote: [...] What happens if you uninstall the firmware? The result should be a fallback to software rendering. This is what happens. Your bug report is for firmware-linux. If you have not installed it, clearly you have not found a bug in the repackaging of the firmware but in the code added to the mga DRM driver for the missing-firmware case. Please confirm whether or not you have installed firmware-linux. If not, please install it and report whether 3D acceleration works again. Ben. signature.asc Description: This is a digitally signed message part
New position statement on firmware
The current text at http://wiki.debian.org/KernelFirmwareLicensing is: 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 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. 2. Sourceless binary blobs distributed under GPL. This situation has been interpreted as a violation of the terms of GPL, which requires the distribution to be accompanied by the source code. Removal of firmware in this category will cause effective removal of a large number of important drivers, resulting in a severe negative impact on our users. 3. Binary blobs violating DFSG for other reasons. This category includes firmware which contains obfuscated source, or is not allowed to be modified. While less numerous than category 2, removal of drivers in this category will also have a significant negative impact on our users. 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. While we continuosly strive to improve the situation with DFSG-compliance of kernel packages, and there has been progress on it since Sarge release, we recognize that fixing all the problems with drivers falling into categories 2 and 3 is not feasible in the etch release time frame. Alternative solutions, like removal of the affected drivers would have a severe negative impact on our users, and would be detrimentary to the Debian's goal of advancement of free software. Therefore, we propose to accept the drivers from categories 2 and 3 in the kernel packages for etch, given that an agreement can be achieved with release and ftp-master teams, or the issue is resolved by way of General Resolution. This is clearly outdated in its reference to etch and lack of reference to the current approach using firmware loader and firmware-nonfree. I propose a new statement along these lines: The 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 emi62, keyspan, smctr, cops, emi26, and 3c359 drivers. Removal of these drivers will have minimal impact on users, as they are believed to be unpopular and not likely to be required during installation. 2. Sourceless binary blobs distributed under GPL. This situation has been interpreted as a violation of the terms of GPL, which requires the distribution to be accompanied by the source code. This affects several important drivers. 3. Binary blobs violating DFSG for other reasons. This category includes firmware which contains obfuscated source, or is not allowed to be modified. It is the intention of the kernel team to: a. Request relicensing of blobs in category 2 b. Patch drivers in categories 2 and 3 to load separate firmware c. Prune the blobs from the upstream tarball d. Disable affected drivers in category 1, and in category 2 where relicensing is impossible Ben. signature.asc Description: This is a digitally signed message part
Re: New position statement on firmware
On Mon, 2009-04-13 at 11:31 -0600, dann frazier wrote: [...] It is the intention of the kernel team to: This sounds more like a plan instead of a position statement. imo, a position statement should be more along the lines of what we will permit and what we won't, as opposed to what we are currently planning to work on. That's true, but the original had this too. Let's change the title to Kernel team plan for handling sourceless firmware. [...] d. Disable affected drivers in category 1, and in category 2 where relicensing is impossible This is the one part where I have a different view - I don't see any problem with enabling these drivers and adding request_firmware support. I don't think our views differ significantly. We can't redistribute them, but users are free to way their own legal risks and install these files from other sources. And to me, that's no reason to force them to compile their own kernel. Of course, I'm not saying that we should consider that work a priority but, if provided with a patch (or one is inherited from upstream), I don't see why we should reject it. I agree there's no reason to reject patches. In cases where a driver depends on non-free firmware and cannot load it from a separate file at run-time then we disable it. It makes sense to prioritise any work we do based largely on popularity of the hardware and availability of the firmware to our users. I compressed that into the sloppy wording in (d) above. I agree with all your other proposed clarifications. Ben. signature.asc Description: This is a digitally signed message part
Re: So just how are out of tree kernel modules supposed to work now?
On Mon, 2009-04-13 at 14:52 -0400, Lennart Sorensen wrote: I am starting to think that debian has completely broken support for compiling out of tree kernel modules as of 2.6.29 now. It used to be, that if you needed to know if a certain function used one style or another, then you could do a compile test against the kernel headers and see if it worked or not, and try until you found the style that worked with the given kernel version. With the removal of the symlinks in 2.6.29, this is no longer possible. [...] You need to use kbuild for the compile test. Ben. signature.asc Description: This is a digitally signed message part
Re: So just how are out of tree kernel modules supposed to work now?
On Mon, 2009-04-13 at 17:55 -0400, Lennart Sorensen wrote: On Mon, Apr 13, 2009 at 09:13:50PM +0100, Ben Hutchings wrote: On Mon, 2009-04-13 at 14:52 -0400, Lennart Sorensen wrote: I am starting to think that debian has completely broken support for compiling out of tree kernel modules as of 2.6.29 now. It used to be, that if you needed to know if a certain function used one style or another, then you could do a compile test against the kernel headers and see if it worked or not, and try until you found the style that worked with the given kernel version. With the removal of the symlinks in 2.6.29, this is no longer possible. [...] You need to use kbuild for the compile test. Hmm. I wonder how one could do that without creating hundreds of directories and makefiles. Are there any examples of projects doing things that way yet? Can you call kbuild for a single module or actually just a single file to see if the .o would be created? Make a temporary directory, generate a trivial makefile and source file, test-compile those, then remove the temporary directory. Wrap that up in a function which you call for each of your compatibility tests. This has been used successfully in version 2.3 of the sfc network driver (though we do also have file tests which I'll need to change). Unfortunately that hasn't been publicly released yet so I can't point to it. Ben. signature.asc Description: This is a digitally signed message part
Bug#524699: e1000e: random kernel oopses
On Sun, 2009-04-19 at 12:29 +0200, F. Stoyan wrote: Package: linux-image-2.6.29-1-686 Version: 2.6.29-3 Severity: normal Dear Kernel Maintainers, When I disconnect the ethernet cable, the kernel randomly oopses on my IBM/Lenovo Thinkpad T500. This doesn't happens with 2.6.28. This is a debugging message added by the e1000e developers and shouldn't really be a warning at all. It does not indicate a serious problem. Ben. signature.asc Description: This is a digitally signed message part
Bug#524699: e1000e NVM mutex contention warnings
David, What's your plan for collecting information about NVM mutex contention and when do you intend to remove the warnings? I have to say I find this way of testing very user-unfriendly and would like to see it gone as soon as possible. Ben. signature.asc Description: This is a digitally signed message part
Bug#524699: e1000e NVM mutex contention warnings
On Thu, 2009-04-23 at 15:15 -0700, Brandeburg, Jesse wrote: Ben Hutchings wrote: What's your plan for collecting information about NVM mutex contention and when do you intend to remove the warnings? I have to say I find this way of testing very user-unfriendly and would like to see it gone as soon as possible. Hi Ben, checking linus' tree and davem's current net-2.6 tree shows that the code was removed as of commit: 0a834a36ac92375cd82d9e4fe4f571e257997d6a it was put in 2/14/2009, and was included in 2.6.30-rc1 by linus. Thanks. I had a look but somehow missed that this was already on the way out in 2.6.30. are you suggesting that we maybe try to push to -stable too? If you now have the information you need about contention, then it seems to me that it would be worthwhile to remove the unnecessary warnings. If you don't want to submit a stable update then I can patch it out in the Debian kernel package. Ben. signature.asc Description: This is a digitally signed message part
Bug#525296: Cannot set tg3 interface to full duplex
On Thu, 2009-04-23 at 10:23 -0400, Greg Wooledge wrote: Package: linux-image-2.6.26-1-686 Version: 2.6.26-13lenny2 Neither mii-tool nor ethtool can set my network interface to full duplex. This is a huge problem here. Do you also expect to get a gigabit link or only 100 megabit? img2:/usr/bin# mii-tool eth0 eth0: no autonegotiation, 100baseTx-HD, link ok img2:/usr/bin# mii-tool -F 100baseTx-FD eth0 img2:/usr/bin# mii-tool eth0: no autonegotiation, 100baseTx-HD, link ok Please run mii-tool -v eth0. mg2:/usr/bin# ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Half Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: g Current message level: 0x00ff (255) Link detected: yes img2:/usr/bin# ethtool -s eth0 duplex full img2:/usr/bin# ethtool eth0 | grep -i duplex Duplex: Half Is autonegotiation enabled at the other end of the link? Ben. signature.asc Description: This is a digitally signed message part
Bug#525296: Cannot set tg3 interface to full duplex
On Fri, 2009-04-24 at 09:33 -0400, Greg Wooledge wrote: On Fri, Apr 24, 2009 at 12:29:23AM +0100, Ben Hutchings wrote: Do you also expect to get a gigabit link or only 100 megabit? The other end is set to 100/full. That is what I want to set the NIC to. Please run mii-tool -v eth0. img2:~# uptime 08:37:59 up 1 min, 1 user, load average: 0.28, 0.12, 0.04 img2:~# uname -a Linux img2 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux img2:~# mii-tool -v eth0 eth0: no autonegotiation, 100baseTx-HD, link ok product info: vendor 00:08:18, model 24 rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD As you can see, the other end only advertised 100BASE-T half-duplex, so that was the only possible result of autonegotiation. Is autonegotiation enabled at the other end of the link? No. The networking department here has a Policy of not using autonegotiation, ever. My commiserations. Do they know that 1000BASE-T does not work without autonegotiation? [...] I have been Googling intermittently for things like Debian tg3 force full duplex for years and I have NEVER found a straight answer to the relatively simple question of How do you force a NIC to 100/full? I am not explicitly setting autonegotiation. The driver module is probably doing so when it's loaded by udev or discover or magical leprechauns or whatever it is that Linux/Debian are using this year. Which is absolutely the correct default for a multi-speed NIC. [...] So, now, the REALLY final test: img2:~# tail /etc/network/interfaces # The primary network interface allow-hotplug eth0 #iface eth0 inet dhcp iface eth0 inet static address 139.137.100.23 netmask 255.255.255.0 gateway 139.137.100.100 up ethtool -s eth0 autoneg off speed 100 duplex full # up sleep 5; mii-tool -F 100baseTx-FD eth0 This is the sensible approach now. In the current (unstable) package of ethtool I have added an ifupdown hook so these settings can be specified in interfaces without explicitly running ethtool. [...] (Not that this will answer every question. I'm sure it will still fail for lots of other people, because the correct answer seems to be something along the lines of It depends on which driver your NIC uses. You're probably screwed. Try some other operating system and pray, or buy a different NIC and pray, or both.) The ethtool command above should work for just about any Ethernet NIC under Linux, though obviously some drivers have bugs. Ben. signature.asc Description: This is a digitally signed message part
Bug#526805: firmware-iwlwifi: wlan0 needs extra poke to come up
On Sun, 2009-05-03 at 13:00 -0400, Mark T.B. Carroll wrote: Package: firmware-iwlwifi Version: 0.16 Severity: normal My /etc/network/interfaces has, iface wlan0 inet dhcp wireless_mode Managed wireless_essid mtbc at home I'm doing these tests without encryption, to make it simpler. If I do an ifup wlan0 then it says, ADDRCONF(NETDEV_UP): wlan0: link is not ready This is normal. and the DHCP goes ahead and doesn't get any response. [...] What does iwconfig wlan0 say in this case? Ben. -- Ben Hutchings No political challenge can be met by shopping. - George Monbiot signature.asc Description: This is a digitally signed message part
Bug#464197: Any update on this issue?
)) {
+ snd_printk(KERN_ERR cs46xx: firmware hunk out of
range\n);
+ return -EINVAL;
+ }
+ offset += size;
+ }
+
+ if (firmware-size != offset) {
+ snd_printk(KERN_ERR cs46xx: firmware size mismatch\n);
+ return -EINVAL;
+ }
+
return 0;
}
+
+static int snd_cs46xx_download_image(struct snd_cs46xx *chip)
+{
+ int idx, err;
+ const struct firmware *firmware = NULL;
+ const struct cs46xx_old_image *image;
+ const __le32 *data;
+
+ err = request_firmware(firmware, cs46xx/cs46xx-old.fw,
+ chip-pci-dev);
+ if (err 0) {
+ snd_printk(KERN_ERR cs46xx: no firmware\n);
+ return err;
+ }
+
+ err = snd_cs46xx_check_image_size(firmware);
+ if (err 0)
+ goto end;
+ image = (const struct cs46xx_old_image *)firmware-data;
+ data = image-data;
+
+ for (idx = 0; idx BA1_MEMORY_COUNT; idx++) {
+ size_t size = le32_to_cpu(image-size[idx]);
+
+ err = snd_cs46xx_download(chip, data, idx 16, size);
+ if (err 0)
+ goto end;
+ data += size / sizeof(u32);
+ }
+end:
+ release_firmware(firmware);
+ return err;
+}
#endif /* CONFIG_SND_CS46XX_NEW_DSP */
/*
@@ -3874,3 +3929,5 @@ int __devinit snd_cs46xx_create(struct snd_card *card,
*rchip = chip;
return 0;
}
+
+MODULE_FIRMWARE(cs46xx/cs46xx-old.fw);
diff --git a/sound/pci/cs46xx/cs46xx_lib.h b/sound/pci/cs46xx/cs46xx_lib.h
index 4eb55aa..85babb5 100644
--- a/sound/pci/cs46xx/cs46xx_lib.h
+++ b/sound/pci/cs46xx/cs46xx_lib.h
@@ -103,8 +103,8 @@ int cs46xx_dsp_proc_done (struct snd_cs46xx *chip);
#define cs46xx_dsp_proc_done(chip)
#endif
int cs46xx_dsp_scb_and_task_init (struct snd_cs46xx *chip);
-int snd_cs46xx_download (struct snd_cs46xx *chip, u32 *src, unsigned long
offset,
-unsigned long len);
+int snd_cs46xx_download(struct snd_cs46xx *chip, const __le32 *src, unsigned
long offset,
+ unsigned long len);
int snd_cs46xx_clear_BA1(struct snd_cs46xx *chip, unsigned long offset,
unsigned long len);
int cs46xx_dsp_enable_spdif_out (struct snd_cs46xx *chip);
int cs46xx_dsp_enable_spdif_hw (struct snd_cs46xx *chip);
--- END ---
--
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot
signature.asc
Description: This is a digitally signed message part
Bug#464197: Any update on this issue?
On Mon, 2009-05-04 at 01:35 +0200, Antonio Ospite wrote:
On Mon, 04 May 2009 00:17:03 +0100
Ben Hutchings b...@decadent.org.uk wrote:
On Mon, 2009-04-20 at 21:45 -0600, dann frazier wrote:
Kalle: would you mind submitting your patch upstream, if you haven't
already? A lot of similar patches for other drives have been accepted
in recent months.
Kalle's patch has a serious problem in that it attempts to byte-swap the
firmware in place. On a big-endian system where the firmware is built
into the kernel, or if a cache is implemented, this will corrupt the
image or cause an oops.
I saw also that some drivers provide blobs as ihex files, a textual
representation of the binary data, and convert it to a binary image at
build time. Could this be useful in this case?
In the upstream repository, all firmware extracted from drivers is
stored in some variant of Intel hex format. But this is still
byte-oriented and does not help to avoid byte-swapping.
Furthermore, I think any patch sent upstream will need to handle the
new DSP code as well.
Indeed.
Anyway, here's my proposed patch for unstable (against 2.6.30-rc4) that
deals with the first problem. I'll have a go at handling the new DSP
code as well, but as I don't have the hardware for this driver this will
need testing by others.
I will test this patch soon; wrt the NEW DSP feature, I don't know if I
can test everything, because I have a Thinkpad T20, only stereo output.
BTW, what binary image to use? Is the one extracted with the tool in
this thread, to be run on a little-endian host, ok?
You would need to apply this patch to cs46xx_image.h before running that
program:
--- a/sound/pci/cs46xx/cs46xx_image.h
+++ b/sound/pci/cs46xx/cs46xx_image.h
@@ -1,14 +1,13 @@
struct BA1struct {
struct {
- unsigned long offset;
- unsigned long size;
+ u32 size;
} memory[BA1_MEMORY_COUNT];
u32 map[BA1_DWORD_SIZE];
};
static struct BA1struct BA1Struct = {
-{{ 0x, 0x3000 },{ 0x0001, 0x3800 },{ 0x0002,
0x7000 }},
+{{ 0x3000 },{ 0x3800 },{ 0x7000 }},
{0x,0x,0x,0x,
0x,0x,0x,0x,
0x,0x,0x0163,0x,
--- END ---
Also note the change of filename (partly because of the format change).
Ben.
--
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot
signature.asc
Description: This is a digitally signed message part
Bug#464197: Any update on this issue?
On Mon, 2009-05-04 at 08:21 +0300, Kalle Olavi Niemitalo wrote: Ben Hutchings b...@decadent.org.uk writes: - Remove Modified on... lines; that's what the commit message is for Those were the prominent notices mentioned in GPLv2 2. a). Right, I see. I believe the Debian patch system makes our changes prominent enough, and such notices are certainly not expected in patches submitted upstream (see Documentation/SubmittingPatches). Ben. -- Ben Hutchings No political challenge can be met by shopping. - George Monbiot signature.asc Description: This is a digitally signed message part
Bug#529850: Please include firmware for broadcom WLAN bcm43xx
On Thu, 2009-05-21 at 21:19 +0200, Bernhard wrote: Package: firmware-nonfree Severity: wishlist Version: 0.16 Please add the firmware for the broadcom WLAN bcm43xx series. The firmware can be found on: http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2 The firmware has to be extracted with the firmware cutter. What? How? You'll have to be a bit more explicit. I don't see anything looking like a firmware blob in the C sources or any licence text applying to the object files. Ben. On my notebook with bcm4318, this firmware works fine. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else. signature.asc Description: This is a digitally signed message part
Bug#494010: Source for dsp56k firmware
Here is the assembly-language source for the firmware, licenced under GPLv2. Adding this to the kernel source package should fix this bug. Ben. ; Author: Frederik Noring [EMAIL PROTECTED] ; ; This file is subject to the terms and conditions of the GNU General Public ; License. See the file COPYING in the main directory of this archive ; for more details. ; DSP56k loader ; Host Interface M_BCR EQU $FFFE ; Port A Bus Control Register M_PBC EQU $FFE0 ; Port B Control Register M_PBDDR EQU $FFE2 ; Port B Data Direction Register M_PBD EQU $FFE4 ; Port B Data Register M_PCC EQU $FFE1 ; Port C Control Register M_PCDDR EQU $FFE3 ; Port C Data Direction Register M_PCD EQU $FFE5 ; Port C Data Register M_HCR EQU $FFE8 ; Host Control Register M_HSR EQU $FFE9 ; Host Status Register M_HRX EQU $FFEB ; Host Receive Data Register M_HTX EQU $FFEB ; Host Transmit Data Register ; SSI, Synchronous Serial Interface M_RXEQU $FFEF ; Serial Receive Data Register M_TXEQU $FFEF ; Serial Transmit Data Register M_CRA EQU $FFEC ; SSI Control Register A M_CRB EQU $FFED ; SSI Control Register B M_SREQU $FFEE ; SSI Status Register M_TSR EQU $FFEE ; SSI Time Slot Register ; Exception Processing M_IPR EQU $ ; Interrupt Priority Register org P:$0 start jmp $40 org P:$40 ; ; Zero 16384 DSP X and Y words ; clr A #0,r0 ; clr B #0,r4 ; do #64,_block1 ; rep #256 ; moveA,X:(r0)+ B,Y:(r4)+ ;_block1; Zero (32768-512) Program words ; clr A #512,r0 ; do #126,_block2 ; rep #256 ; moveA,P:(r0)+ ;_block2 ; Copy DSP program control move#real,r0 move#upload,r1 do #upload_end-upload,_copy moveP:(r0)+,x0 movex0,P:(r1)+ _copy movep #4,X:M_HCR movep #$c00,X:M_IPR and #$fe,mr jmp upload real org P:$7ea9 upload movep #1,X:M_PBC movep #0,X:M_BCR nextjclr#0,X:M_HSR,* movep X:M_HRX,A move#3,x0 cmp x0,A #1,x0 jeq $0 _get_address jclr#0,X:M_HSR,_get_address movep X:M_HRX,r0 _get_length jclr#0,X:M_HSR,_get_length movep X:M_HRX,y0 cmp x0,A #2,x0 jeq load_X cmp x0,A jeq load_Y load_P do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,P:(r0)+ _load jmp next load_X do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,X:(r0)+ _load jmp next load_Y do y0,_load jclr#0,X:M_HSR,* movep X:M_HRX,Y:(r0)+ _load jmp next upload_end end signature.asc Description: This is a digitally signed message part
Bug#494007: binary firmware in drivers/char/drm/r128_cce.c
Here's a patch to make r128 use request_firmware. This is
compile-tested only as I don't have appropriate hardware. The firmware
file can be produced by writing the array as 32-bit little-endian
values. However, there is still a problem with its licence.
Ben.
diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig
index 610d6fd..ea26dfd 100644
--- a/drivers/char/drm/Kconfig
+++ b/drivers/char/drm/Kconfig
@@ -26,6 +26,7 @@ config DRM_TDFX
config DRM_R128
tristate ATI Rage 128
depends on DRM PCI
+ select FW_LOADER
help
Choose this option if you have an ATI Rage 128 graphics card. If M
is selected, the module will be called r128. AGP support for
diff --git a/drivers/char/drm/r128_cce.c b/drivers/char/drm/r128_cce.c
index c31afbd..e29c082 100644
--- a/drivers/char/drm/r128_cce.c
+++ b/drivers/char/drm/r128_cce.c
@@ -29,6 +29,8 @@
*Gareth Hughes [EMAIL PROTECTED]
*/
+#include linux/firmware.h
+
#include drmP.h
#include drm.h
#include r128_drm.h
@@ -36,51 +38,6 @@
#define R128_FIFO_DEBUG0
-/* CCE microcode (from ATI) */
-static u32 r128_cce_microcode[] = {
- 0, 276838400, 0, 268449792, 2, 142, 2, 145, 0, 1076765731, 0,
- 1617039951, 0, 774592877, 0, 1987540286, 0, 2307490946U, 0,
- 599558925, 0, 589505315, 0, 596487092, 0, 589505315, 1,
- 11544576, 1, 206848, 1, 311296, 1, 198656, 2, 912273422, 11,
- 262144, 0, 0, 1, 33559837, 1, 7438, 1, 14809, 1, 6615, 12, 28,
- 1, 6614, 12, 28, 2, 23, 11, 18874368, 0, 16790922, 1, 409600, 9,
- 30, 1, 147854772, 16, 420483072, 3, 8192, 0, 10240, 1, 198656,
- 1, 15630, 1, 51200, 10, 34858, 9, 42, 1, 33559823, 2, 10276, 1,
- 15717, 1, 15718, 2, 43, 1, 15936948, 1, 570480831, 1, 14715071,
- 12, 322123831, 1, 33953125, 12, 55, 1, 33559908, 1, 15718, 2,
- 46, 4, 2099258, 1, 526336, 1, 442623, 4, 4194365, 1, 509952, 1,
- 459007, 3, 0, 12, 92, 2, 46, 12, 176, 1, 15734, 1, 206848, 1,
- 18432, 1, 133120, 1, 100670734, 1, 149504, 1, 165888, 1,
- 15975928, 1, 1048576, 6, 3145806, 1, 15715, 16, 2150645232U, 2,
- 268449859, 2, 10307, 12, 176, 1, 15734, 1, 15735, 1, 15630, 1,
- 15631, 1, 5253120, 6, 3145810, 16, 2150645232U, 1, 15864, 2, 82,
- 1, 343310, 1, 1064207, 2, 3145813, 1, 15728, 1, 7817, 1, 15729,
- 3, 15730, 12, 92, 2, 98, 1, 16168, 1, 16167, 1, 16002, 1, 16008,
- 1, 15974, 1, 15975, 1, 15990, 1, 15976, 1, 15977, 1, 15980, 0,
- 15981, 1, 10240, 1, 5253120, 1, 15720, 1, 198656, 6, 110, 1,
- 180224, 1, 103824738, 2, 112, 2, 3145839, 0, 536885440, 1,
- 114880, 14, 125, 12, 206975, 1, 33559995, 12, 198784, 0,
- 33570236, 1, 15803, 0, 15804, 3, 294912, 1, 294912, 3, 442370,
- 1, 11544576, 0, 811612160, 1, 12593152, 1, 11536384, 1,
- 14024704, 7, 310382726, 0, 10240, 1, 14796, 1, 14797, 1, 14793,
- 1, 14794, 0, 14795, 1, 268679168, 1, 9437184, 1, 268449792, 1,
- 198656, 1, 9452827, 1, 1075854602, 1, 1075854603, 1, 557056, 1,
- 114880, 14, 159, 12, 198784, 1, 1109409213, 12, 198783, 1,
- 1107312059, 12, 198784, 1, 1109409212, 2, 162, 1, 1075854781, 1,
- 1073757627, 1, 1075854780, 1, 540672, 1, 10485760, 6, 3145894,
- 16, 274741248, 9, 168, 3, 4194304, 3, 4209949, 0, 0, 0, 256, 14,
- 174, 1, 114857, 1, 33560007, 12, 176, 0, 10240, 1, 114858, 1,
- 33560018, 1, 114857, 3, 33560007, 1, 16008, 1, 114874, 1,
- 33560360, 1, 114875, 1, 33560154, 0, 15963, 0, 256, 0, 4096, 1,
- 409611, 9, 188, 0, 10240, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
-};
-
static int R128_READ_PLL(struct drm_device * dev, int addr)
{
drm_r128_private_t *dev_priv = dev-dev_private;
@@ -176,20 +133,36 @@ static int r128_do_wait_for_idle(drm_r128_private_t *
dev_priv)
*/
/* Load the microcode for the CCE */
-static void r128_cce_load_microcode(drm_r128_private_t * dev_priv)
+static int
+r128_cce_load_microcode(struct drm_device *dev, drm_r128_private_t *dev_priv)
{
- int i;
+ const struct firmware *fw;
+ const __le32 *microcode;
+ int rc, i;
#
DRM_DEBUG(\n);
+ rc = request_firmware(fw, r128/cce_ucode.bin, dev-pdev-dev);
+ if (rc)
+ return rc;
+ if (fw-size != 256 * 8) {
+ release_firmware(fw);
+ return -EINVAL;
+ }
+ microcode = (const __le32 *)fw-data;
+
r128_do_wait_for_idle(dev_priv);
R128_WRITE(R128_PM4_MICROCODE_ADDR, 0);
for (i = 0; i 256; i++) {
-
Bug#494009: binary firmware in drivers/char/drm/radeon_microcode.h
Here's a patch to radeon to make it use request_firmware. This is
compile-tested only, but I have hardware I can test on shortly. The
firmware files can be produced by writing the arrays as 32-bit
little-endian values. They should be suitable for inclusion in
firmware-nonfree, so I am including a patch for that as well.
Ben.
diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig
index ea26dfd..17edd8a 100644
--- a/drivers/char/drm/Kconfig
+++ b/drivers/char/drm/Kconfig
@@ -35,6 +35,7 @@ config DRM_R128
config DRM_RADEON
tristate ATI Radeon
depends on DRM PCI
+ select FW_LOADER
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/char/drm/radeon_cp.c b/drivers/char/drm/radeon_cp.c
index e53158f..8408e34 100644
--- a/drivers/char/drm/radeon_cp.c
+++ b/drivers/char/drm/radeon_cp.c
@@ -29,14 +29,14 @@
*Gareth Hughes [EMAIL PROTECTED]
*/
+#include linux/firmware.h
+
#include drmP.h
#include drm.h
#include radeon_drm.h
#include radeon_drv.h
#include r300_reg.h
-#include radeon_microcode.h
-
#define RADEON_FIFO_DEBUG 0
static int radeon_do_cleanup_cp(struct drm_device * dev);
@@ -319,83 +319,71 @@ static void radeon_init_pipes(drm_radeon_private_t
*dev_priv)
* CP control, initialization
*/
+static const char *radeon_cp_family_name(drm_radeon_private_t * dev_priv)
+{
+ switch (dev_priv-flags RADEON_FAMILY_MASK) {
+ case CHIP_R100: case CHIP_RV100: case CHIP_RV200: case CHIP_RS100:
+ case CHIP_RS200:
+ return R100;
+ case CHIP_R200: case CHIP_RV250: case CHIP_RV280: case CHIP_RS300:
+ return R200;
+ case CHIP_R300: case CHIP_R350: case CHIP_RV350: case CHIP_RV380:
+ case CHIP_RS480:
+ return R300;
+ case CHIP_R420: case CHIP_RV410:
+ return R400;
+ case CHIP_RS690:
+ return RS690;
+ case CHIP_RV515: case CHIP_R520: case CHIP_RV530: case CHIP_R580:
+ case CHIP_RV560: case CHIP_RV570:
+ return R500;
+ default:
+ WARN_ON(1); /* new chip needs a name */
+ return ;
+ }
+}
+
/* Load the microcode for the CP */
static void radeon_cp_load_microcode(drm_radeon_private_t * dev_priv)
{
+ const __le32 *microcode;
int i;
DRM_DEBUG(\n);
radeon_do_wait_for_idle(dev_priv);
+ DRM_INFO(Loading %s Microcode\n, radeon_cp_family_name(dev_priv));
+ microcode = (const __le32 *)dev_priv-microcode-data;
RADEON_WRITE(RADEON_CP_ME_RAM_ADDR, 0);
- if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R100) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV100) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV200) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS100) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS200)) {
- DRM_INFO(Loading R100 Microcode\n);
- for (i = 0; i 256; i++) {
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAH,
-R100_cp_microcode[i][1]);
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAL,
-R100_cp_microcode[i][0]);
- }
- } else if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R200) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV250) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV280) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS300)) {
- DRM_INFO(Loading R200 Microcode\n);
- for (i = 0; i 256; i++) {
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAH,
-R200_cp_microcode[i][1]);
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAL,
-R200_cp_microcode[i][0]);
- }
- } else if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R300) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R350) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV350) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV380) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RS480)) {
- DRM_INFO(Loading R300 Microcode\n);
- for (i = 0; i 256; i++) {
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAH,
-R300_cp_microcode[i][1]);
- RADEON_WRITE(RADEON_CP_ME_RAM_DATAL,
-R300_cp_microcode[i][0]);
- }
- } else if (((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_R420) ||
- ((dev_priv-flags RADEON_FAMILY_MASK) == CHIP_RV410)) {
- DRM_INFO(Loading R400 Microcode\n);
-
Bug#501153: binary firmware in drivers/net/tehuti_fw.h
Here's a patch for tehuti to make it use request_firmware. This is
compile-tested only. The firmware file can be produced by writing out
the array s_loadFirm as 32-bit little-endian values. However, the
licence remains a problem.
Ben.
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 3e433cb..9e1a73c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2569,6 +2569,7 @@ config MLX4_DEBUG
config TEHUTI
tristate Tehuti Networks 10G Ethernet
depends on PCI
+ select FW_LOADER
help
Tehuti Networks 10G Ethernet NIC
diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c
index 432e837..3f732eb 100644
--- a/drivers/net/tehuti.c
+++ b/drivers/net/tehuti.c
@@ -63,7 +63,6 @@
*/
#include tehuti.h
-#include tehuti_fw.h
static struct pci_device_id __devinitdata bdx_pci_tbl[] = {
{0x1FC9, 0x3009, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
@@ -319,28 +318,41 @@ static int bdx_poll(struct napi_struct *napi, int budget)
static int bdx_fw_load(struct bdx_priv *priv)
{
+ const struct firmware *fw = NULL;
int master, i;
+ int rc;
ENTER;
master = READ_REG(priv, regINIT_SEMAPHORE);
if (!READ_REG(priv, regINIT_STATUS) master) {
- bdx_tx_push_desc_safe(priv, s_firmLoad, sizeof(s_firmLoad));
+ rc = request_firmware(fw, tehuti/firmware.bin,
priv-pdev-dev);
+ if (rc)
+ goto out;
+ bdx_tx_push_desc_safe(priv, fw-data, fw-size);
mdelay(100);
}
for (i = 0; i 200; i++) {
- if (READ_REG(priv, regINIT_STATUS))
- break;
+ if (READ_REG(priv, regINIT_STATUS)) {
+ rc = 0;
+ goto out;
+ }
mdelay(2);
}
+ rc = -EIO;
+out:
+ if (fw)
+ release_firmware(fw);
if (master)
WRITE_REG(priv, regINIT_SEMAPHORE, 1);
- if (i == 200) {
+ if (rc) {
ERR(%s: firmware loading failed\n, priv-ndev-name);
- DBG(VPC = 0x%x VIC = 0x%x INIT_STATUS = 0x%x i=%d\n,
- READ_REG(priv, regVPC),
- READ_REG(priv, regVIC), READ_REG(priv, regINIT_STATUS), i);
- RET(-EIO);
+ if (rc == -EIO)
+ DBG(VPC = 0x%x VIC = 0x%x INIT_STATUS = 0x%x i=%d\n,
+ READ_REG(priv, regVPC),
+ READ_REG(priv, regVIC),
+ READ_REG(priv, regINIT_STATUS), i);
+ RET(rc);
} else {
DBG(%s: firmware loading success\n, priv-ndev-name);
RET(0);
@@ -618,13 +630,6 @@ err:
RET(rc);
}
-static void __init bdx_firmware_endianess(void)
-{
- int i;
- for (i = 0; i ARRAY_SIZE(s_firmLoad); i++)
- s_firmLoad[i] = CPU_CHIP_SWAP32(s_firmLoad[i]);
-}
-
static int bdx_range_check(struct bdx_priv *priv, u32 offset)
{
return (offset (u32) (BDX_REGS_SIZE / priv-nic-port_num)) ?
@@ -2498,7 +2503,6 @@ static void __init print_driver_id(void)
static int __init bdx_module_init(void)
{
ENTER;
- bdx_firmware_endianess();
init_txd_sizes();
print_driver_id();
RET(pci_register_driver(bdx_pci_driver));
@@ -2518,3 +2522,4 @@ module_exit(bdx_module_exit);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(BDX_DRV_DESC);
+MODULE_FIRMWARE(tehuti/firmware.bin);
diff --git a/drivers/net/tehuti.h b/drivers/net/tehuti.h
index efd170f..b9acb3f 100644
--- a/drivers/net/tehuti.h
+++ b/drivers/net/tehuti.h
@@ -30,6 +30,7 @@
#include linux/version.h
#include linux/interrupt.h
#include linux/vmalloc.h
+#include linux/firmware.h
#include asm/byteorder.h
/* Compile Time Switches */
--- END ---
signature.asc
Description: This is a digitally signed message part
Bug#501152: binary firmware in drivers/net/starfire_firmware.h
Here's a patch for starfire to make it use request_firmware. This is compile-tested only. The firmware files can be produced by writing out the firmware_rx and firmware_tx arrays as 32-bit little-endian values. However, the licence remains a problem. Ben. diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 4a12477..3e433cb 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1306,6 +1306,7 @@ config ADAPTEC_STARFIRE depends on NET_PCI PCI select CRC32 select MII + select FW_LOADER help Say Y here if you have an Adaptec Starfire (or DuraLAN) PCI network adapter. The DuraLAN chip is used on the 64 bit PCI boards from diff --git a/drivers/net/starfire.c b/drivers/net/starfire.c index 7b7b171..73394d9 100644 --- a/drivers/net/starfire.c +++ b/drivers/net/starfire.c @@ -42,11 +42,11 @@ #include linux/mii.h #include linux/if_vlan.h #include linux/mm.h +#include linux/firmware.h #include asm/processor.h /* Processor type for cache alignment. */ #include asm/uaccess.h #include asm/io.h -#include starfire_firmware.h /* * The current frame processor firmware fails to checksum a fragment * of length 1. If and when this is fixed, the #define below can be removed. @@ -224,6 +224,8 @@ MODULE_AUTHOR(Donald Becker [EMAIL PROTECTED]); MODULE_DESCRIPTION(Adaptec Starfire Ethernet driver); MODULE_LICENSE(GPL); MODULE_VERSION(DRV_VERSION); +MODULE_FIRMWARE(starfire/gfp_rx.bin); +MODULE_FIRMWARE(starfire/gfp_tx.bin); module_param(max_interrupt_work, int, 0); module_param(mtu, int, 0); @@ -948,12 +950,21 @@ static int netdev_open(struct net_device *dev) void __iomem *ioaddr = np-base; int i, retval; size_t tx_done_q_size, rx_done_q_size, tx_ring_size, rx_ring_size; + const struct firmware *fw_rx, *fw_tx; + const __le32 *fw_data; /* Do we ever need to reset the chip??? */ - retval = request_irq(dev-irq, intr_handler, IRQF_SHARED, dev-name, dev); + retval = request_firmware(fw_rx, starfire/gfp_rx.bin, np-pci_dev-dev); if (retval) return retval; + retval = request_firmware(fw_tx, starfire/gfp_tx.bin, np-pci_dev-dev); + if (retval) + goto out_release_fw_rx; + + retval = request_irq(dev-irq, intr_handler, IRQF_SHARED, dev-name, dev); + if (retval) + goto out_release_fw_tx; /* Disable the Rx and Tx, and reset the chip. */ writel(0, ioaddr + GenCtrl); @@ -1084,10 +1095,12 @@ static int netdev_open(struct net_device *dev) #endif /* VLAN_SUPPORT */ /* Load Rx/Tx firmware into the frame processors */ - for (i = 0; i FIRMWARE_RX_SIZE * 2; i++) - writel(firmware_rx[i], ioaddr + RxGfpMem + i * 4); - for (i = 0; i FIRMWARE_TX_SIZE * 2; i++) - writel(firmware_tx[i], ioaddr + TxGfpMem + i * 4); + fw_data = (const __le32 *)fw_rx-data; + for (i = 0; i fw_rx-size / 4; i++) + writel(le32_to_cpu(fw_data[i]), ioaddr + RxGfpMem + i * 4); + fw_data = (const __le32 *)fw_tx-data; + for (i = 0; i fw_tx-size / 4; i++) + writel(le32_to_cpu(fw_data[i]), ioaddr + TxGfpMem + i * 4); if (enable_hw_cksum) /* Enable the Rx and Tx units, and the Rx/Tx frame processors. */ writel(TxEnable|TxGFPEnable|RxEnable|RxGFPEnable, ioaddr + GenCtrl); @@ -1099,7 +1112,11 @@ static int netdev_open(struct net_device *dev) printk(KERN_DEBUG %s: Done netdev_open().\n, dev-name); - return 0; +out_release_fw_tx: + release_firmware(fw_tx); +out_release_fw_rx: + release_firmware(fw_rx); + return retval; } --- END --- signature.asc Description: This is a digitally signed message part
Bug#494009: binary firmware in drivers/char/drm/radeon_microcode.h
However, you should probably use this patch and firmware format instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=3a911a216742e4ab998f3281409d46a62f252716 Ben. signature.asc Description: This is a digitally signed message part
Bug#501153: binary firmware in drivers/net/tehuti_fw.h
You could use this similar patch instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=e41f3e5f8c5110871e376a2566b8eea2932b813b Ben. signature.asc Description: This is a digitally signed message part
Bug#498631: binary firmware in drivers/net/cassini.h
You could use this patch and firmware format instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=5263b94d83666854240d254852dd44309c436e25 Ben. signature.asc Description: This is a digitally signed message part
Bug#501152: binary firmware in drivers/net/starfire_firmware.h
You could use this patch and firmware format instead: http://git.infradead.org/users/jaswinder/firm-jsr-2.6.git?a=commitdiff;h=6963b36bfb1f171ae8ea4884e239bdccc5f47266 Ben. signature.asc Description: This is a digitally signed message part
Bug#501153: Tehuti driver and firmware distribution for Linux
I am writing as a member of the Debian project, which distributes a version of Linux. The project is attempting to resolve the licencing of firmware used with Linux. The following may require attention by your legal department. Linux includes a driver and firmware which are listed as copyright of Tehuti Networks and licenced under the GNU General Public Licence (GPL). Thank you for supporting Linux and free software. Unfortunately, applying the GPL to the firmware is problematic, because you distribute it in binary (or equivalent) form, and not the source code that your programmers used to create it. The GPL states that anyone redistributing a work that it covers must also offer to distribute the source code. This means that strictly speaking no-one outside Tehuti Networks is allowed to distribute the firmware, which I assume was not your intent. Please can you clarify the licence for the firmware, and preferably issue a new licence that clearly allows Debian and others to distribute the firmware. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498631: Sun GigaSwift driver and firmware distribution for Linux
I am writing as a member of the Debian project, which distributes a version of Linux. The project is attempting to resolve the licencing of firmware used with Linux. Linux includes a driver (cassini) and firmware for GigaSwift NICs which are listed as copyright of Sun Microsystems and licenced under the GNU General Public Licence (GPL). Thank you for supporting Linux and free software. Unfortunately, applying the GPL to the firmware is problematic, because you distribute it in binary (or equivalent) form, and not the source code that your programmers used to create it. The GPL states that anyone redistributing a work that it covers must also offer to distribute the source code. This means that strictly speaking no-one outside Sun Microsystems is allowed to distribute the firmware, which I assume was not your intent. Please can you clarify the licence for the firmware, and preferably issue a new licence that clearly allows Debian and others to distribute the firmware. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494007: binary firmware in drivers/char/drm/r128_cce.c
I asked Dave Airlie about this: 23:36 bwh airlied: Do you know who might be a good person to write to at ATI/AMD about the licence for firmware in r128? 23:48 airlied bwh: what license you want it under? its already MIT licensed. 23:50 bwh airlied: Is it? Thing is, r128_cce.c doesn't have any ATI copyright notice on it. 23:51 airlied bwh: fail.. it probably should have, its still MIT licensed though. 23:52 bwh So would someone at ATI be able to confirm that? 23:53 airlied well the r128_cce.c has the MIT license on top 23:53 airlied I'm just looking to see if I have the original DDK release. 23:55 bwh airlied: cheers 23:56 airlied so the original table was just released under NDA, with permission to reuse in open source. 23:58 bwh Funny sort of NDA ;-) Do you have some legally meaningful statement of the permission that you could forward? 23:58 airlied bwh: why funny? 23:58 airlied I get lots of NDAs like that. 23:59 airlied nope I've gotten nothing real, I doubt anyone in AMD has either, this is like a 10 year old part. I don't know if this is sufficient assurance of its licence. Ben. signature.asc Description: This is a digitally signed message part
Bug#501152: binary firmware in drivers/net/starfire_firmware.h
FreeBSD appears to have copied the proper copyright notices into their versions of the firmware: http://fxr.watson.org/fxr/source/dev/sf/starfire_rx.h http://fxr.watson.org/fxr/source/dev/sf/starfire_tx.h (c)2001 Adaptec, Inc. By using this software you agree that it is licensed to you AS IS and that Adaptec makes no warranties, express or implied, regarding the Software. Any redistribution of this Software must include this disclaimer and copyright notice. So this ought to be OK for firmware-nonfree. Ben. signature.asc Description: This is a digitally signed message part
Bug#501153: Tehuti driver and firmware distribution for Linux
I am writing as a member of the Debian project, which distributes a version of Linux. The project is attempting to resolve the licencing of firmware used with Linux. The following may require attention by your legal department. Linux includes a driver and firmware which are listed as copyright of Tehuti Networks and licenced under the GNU General Public Licence (GPL). Thank you for supporting Linux and free software. Unfortunately, applying the GPL to the firmware is problematic, because you distribute it in binary (or equivalent) form, and not the source code that your programmers used to create it. The GPL states that anyone redistributing a work that it covers must also offer to distribute the source code. This means that strictly speaking no-one outside Tehuti Networks is allowed to distribute the firmware, which I assume was not your intent. Please can you clarify the licence for the firmware, and preferably issue a new licence that clearly allows Debian and others to distribute the firmware. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501153: Tehuti driver and firmware distribution for Linux
On Mon, Oct 13, 2008 at 10:52:31AM +0200, Pinchas wrote: Dear Ben This subject was discussed and clarified in the past and it was agreed that the firmware part of the Driver will be distributed in Binary. This Firmware is actually an integral part of our H/W and should be viewed as such, thus it is supplied as a Binary code. I accept that you are treating this as a part of the hardware and I am not asking you to release its source code. I am asking for a licence that clearly allows Debian and others to redistribute the firmware in binary format. The GPL does not do this, because it says we must also distribute source code, and we cannot. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494010: Source for dsp56k firmware
You wrote: On Sun, Oct 12, 2008 at 08:10:53PM +0100, Ben Hutchings wrote: Here is the assembly-language source for the firmware, licenced under GPLv2. Very nice! Where did you find it? It was added to the upstream tree recently as part of the firmware separation effort. Adding this to the kernel source package should fix this bug. Actually, it should be assembled and used. AFAICT this is for an m68k processor. I suppose we have a command to assemble this code in binutils-multiarch or so? It's for a Motorola 56000 (aka DSP56000 or DSP56K) processor, which is a different architecture but maybe with some similarities. I doubt we have any of the necessary tools but the code is short enough to hand- assemble. However, as I understand it, this source was written by the same person as the driver and the binary that is embedded in it, and should assemble to exactly the same bits. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: Digital signature
Bug#494010: Source for dsp56k firmware
On Wed, Oct 15, 2008 at 07:49:19PM +0200, Robert Millan wrote: On Wed, Oct 15, 2008 at 06:12:23PM +0200, Robert Millan wrote: On Wed, Oct 15, 2008 at 03:16:56AM +0100, Ben Hutchings wrote: It's for a Motorola 56000 (aka DSP56000 or DSP56K) processor, which is a different architecture but maybe with some similarities. I doubt we have any of the necessary tools but the code is short enough to hand- assemble. I found an assembler, a56 (see http://www.zdomain.com/a56.html), which seems to be DFSG-free (BSD-style license). I'll see about packaging it. Gah, there's a bit more to this: - First I had to run frodos on bootstrap.asm to cleanup the CRLF. I think that's introduced by the BTS. - Attached patch fixes a few errors spit by a56. I think my other two fixes are correct, but I have no idea what the '' / '' candy is supposed to do (hints?). According to the assembler reference manual http://www.freescale.com/files/dsp/doc/ref_manual/DSPASMRM.pdf they mean: - I/O short addressing mode force operator - Short addressing mode force operator - Long addressing mode force operator - Resulting offsets doen't match with the blob. I still haven't figured out how are program code offsets mapped to the output file, but some parts don't match. For example, the blob has a jump (0C 00 40) to 0x40 (and so does a56 output, at offset 0x0 in both cases), but then code from the blob continues at 0xc0, unlike code from a56 which continues at 0x40. Is there some trick to this? It's a 24-bit processor and uses word-addressing, not byte-addressing. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: Digital signature
Re: [PATCH] Firmware removal
Next, a patch for firmware-nonfree that allows firmware to be read from
and installed to subdirectories as expected by some drivers.
Ben.
Index: firmware-nonfree/debian/bin/gencontrol.py
===
--- firmware-nonfree/debian/bin/gencontrol.py (revision 12301)
+++ firmware-nonfree/debian/bin/gencontrol.py (working copy)
@@ -97,9 +97,14 @@
files_real = {}
for root, dirs, files in os.walk(package):
-del dirs[:]
+try:
+dirs.remove('.svn')
+except ValueError:
+pass
for f in files:
f1 = f.rsplit('-', 1)
+if root != package:
+f = root[len(package) + 1 : ] + '/' + f
if f in files_orig:
files_real[f] = f, f, None
elif len(f1) 1:
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] Firmware removal
, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE +LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION +OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION +WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Index: firmware-nonfree/ati/defines === --- firmware-nonfree/ati/defines(revision 0) +++ firmware-nonfree/ati/defines(revision 0) @@ -0,0 +1,34 @@ +[base] +desc: ATI Rage 128 and Radeon graphics cards +files: + r128/r128_cce.bin + radeon/R100_cp.bin + radeon/R200_cp.bin + radeon/R300_cp.bin + radeon/R420_cp.bin + radeon/R520_cp.bin + radeon/RS690_cp.bin +longdesc: ATI Rage 128 and Radeon graphics cards supported by the r128 and + radeon drivers +uri: http://ftp.debian.org/debian/pool/non-free/f/firmware-nonfree + +[r128_cce.bin_base] +desc: Rage 128 CCE microcode + +[R100_cp.bin_base] +desc: Radeon R100-family CP microcode + +[R200_cp.bin_base] +desc: Radeon R200-family CP microcode + +[R300_cp.bin_base] +desc: Radeon R300-family CP microcode + +[R420_cp.bin_base] +desc: Radeon R400-family CP microcode + +[R520_cp.bin_base] +desc: Radeon R500-family CP microcode + +[RS690_cp.bin_base] +desc: Radeon RS690 CP microcode Index: firmware-nonfree/debian/changelog === --- firmware-nonfree/debian/changelog (revision 12301) +++ firmware-nonfree/debian/changelog (working copy) @@ -1,3 +1,12 @@ +firmware-nonfree (0.14) unstable; urgency=low + + * Add ATI Rage 128 and Radeon firmware used by r128 and radeon drivers +(firmware-ati) + * Add Adaptec DuraLAN firmware used by starfire driver (firmware-adaptec) + * Add Intel PRO/100 firmware used by e100 driver (firmware-e100) + + -- Ben Hutchings [EMAIL PROTECTED] Sun, 12 Oct 2008 21:00:37 +0100 + firmware-nonfree (0.13) unstable; urgency=low * Make firmware-bnx2 trigger update-initramfs (closes: #494936) signature.asc Description: This is a digitally signed message part
Firmware removal progress
On Fri, 2008-10-17 at 00:34 +0100, Ben Hutchings wrote: I'm going to post a series of patches that aim to fix the RC bugs relating to sourceless firmware. Unfortunately, a quick search suggests that there is still more left: file licence distributable -- drivers/char/drm/mga_ucode.h GPLv2 no drivers/media/video/dabfirmware.h BSDishyes drivers/net/typhoon-firmware.h BSD 3-clause yes drivers/net/usb/kawethfw.h GPLv2 no drivers/scsi/ql12160_fw.h GPLv2 no drivers/scsi/ql1040_fw.h GPLv2 no drivers/scsi/ql1280_fw.h GPLv2 no drivers/usb/serial/whiteheat_fw.h GPLv2 no Is there any reason why these shouldn't also be treated as bugs? Ben. signature.asc Description: This is a digitally signed message part
Bug#501153: Tehuti driver and firmware distribution for Linux
On Mon, Oct 13, 2008 at 12:04:35PM +0100, Ben Hutchings wrote: On Mon, Oct 13, 2008 at 10:52:31AM +0200, Pinchas wrote: Dear Ben This subject was discussed and clarified in the past and it was agreed that the firmware part of the Driver will be distributed in Binary. This Firmware is actually an integral part of our H/W and should be viewed as such, thus it is supplied as a Binary code. I accept that you are treating this as a part of the hardware and I am not asking you to release its source code. I am asking for a licence that clearly allows Debian and others to redistribute the firmware in binary format. The GPL does not do this, because it says we must also distribute source code, and we cannot. As examples, other hardware vendors have used the licence text: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of [company] nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. or: 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 be very grateful if you could state your intent formally. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] Firmware removal
On Fri, 2008-10-17 at 00:39 +0100, Ben Hutchings wrote: Finally, the metadata for sourceless firmware that can be moved to firmware-nonfree. A source package including the added firmware is available at http://womble.decadent.org.uk/tmp/firmware-nonfree_0.14.dsc. Ben. signature.asc Description: This is a digitally signed message part
Re: Firmware removal progress
On Sat, 2008-10-18 at 17:10 +0200, Julien Cristau wrote: On Fri, Oct 17, 2008 at 00:44:45 +0100, Ben Hutchings wrote: On Fri, 2008-10-17 at 00:34 +0100, Ben Hutchings wrote: I'm going to post a series of patches that aim to fix the RC bugs relating to sourceless firmware. Unfortunately, a quick search suggests that there is still more left: file licence distributable -- drivers/char/drm/mga_ucode.h GPLv2 no * Copyright 1999 Matrox Graphics Inc. * All Rights Reserved. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the Software), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included * in all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL * MATROX GRAPHICS INC., OR ANY OTHER CONTRIBUTORS BE LIABLE FOR ANY CLAIM, * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE * OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. That's not GPLv2, and is distributable. Yup, I noticed that myself since then. I now have patches (mostly by David Woodhouse and Jaswinder Singh) to remove all of these as well. Again, I'm lacking the hardware to test them. Ben. signature.asc Description: This is a digitally signed message part
Bug#502663: linux-2.6: Binary firmware in dabusb driver
Package: linux-2.6 Version: 2.6.26-9 Severity: serious Justification: Policy 2.2.1 The file drivers/media/video/dabfirmware.h contains machine code written as C structures/arrays, for which the source code is not provided. A patch is available to make this driver use the request_firmware() API, and I will provide patches for linux-2.6 and firmware-nonfree shortly. Ben. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502665: Binary firmware in kaweth driver
Package: linux-2.6 Version: 2.6.26-9 Severity: serious Justification: Policy 2.2.1 The file drivers/net/usb/kawethfw.h contains machine code written as C structures/arrays, for which the source code is not provided. Further, the licence for the firmware is stated to be GPLv2 which does not allow distribution without source code also available. A patch is available to make this driver use the request_firmware() API, and I will provide a patch for linux-2.6. Ben. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502667: Binary firmware in qla1280 driver
Package: linux-2.6
Version: 2.6.26-9
Severity: serious
Justification: Policy 2.2.1
The files drivers/scsi/ql1{2160,040,280}_fw.h contain machine code
written as C structures/arrays, for which the source code is not
provided. Further, the licence for the firmware is stated to be GPLv2
which does not allow distribution without source code also available.
A patch is available to make this driver use the request_firmware()
API, and I will provide a patch for linux-2.6 shortly.
Ben.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502668: Binary firmware in whiteheat driver
Package: linux-2.6 Version: 2.6.26-9 Severity: serious Justification: Policy 2.2.1 The file drivers/usb/serial/whiteheat_fw.h contains machine code written as C structures/arrays, for which the source code is not provided. Further, the licence for the firmware is stated to be GPLv2 which does not allow distribution without source code also available. A patch is available to make this driver use the request_firmware() API, and I will provide a patch for linux-2.6 shortly. Ben. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502666: Binary firmware in mga driver
Package: linux-2.6 Version: 2.6.26-9 Severity: serious Justification: Policy 2.2.1 The file drivers/char/drm/mga_ucode.h contains machine code written as C structures/arrays, for which the source code is not provided. I have written a patch to make this driver use the request_firmware() API, and I will provide patches for linux-2.6 and firmware-nonfree shortly. Ben. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502669: Binary firmware in typhoon driver
Package: linux-2.6 Version: 2.6.26-9 Severity: serious Justification: Policy 2.2.1 The file drivers/net/typhoon-firmware.h contains machine code written as C structures/arrays, for which the source code is not provided. There is a patch available to make this driver use the request_firmware() API, and I will provide patches for linux-2.6 and firmware-nonfree shortly. Ben. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware removal progress
Here's an updated overview; I think this now covers all sourceless
firmware/microcode left in linux-2.6:
driver bug source file(s) licenceaction
-
cassini498631 net/cassini.hGPLv2 remove
dabusb 502663 media/video/dabfirmware.hBSDish move (dabusb)
dsp56k 494010 char/dsp56k.cGPLv2 add source
e100 494308 net/e100.c BSDish move (e100)
kaweth 502665 net/usb/kawethfw.h GPLv2 remove
mga502666 char/drm/mga_ucode.h MITmove (matrox)
qla1280502667 scsi/ql1{2160,040,280}_fw.h GPLv2 remove
r128 494007 char/drm/r128_cce.c MITmove (ati)
radeon 494009 char/drm/radeon_microcode.h MITmove (ati)
starfire 501152 net/starfire_firmware.h unmodified redist move
(adaptec)
tehuti 501153 net/tehuti_fw.h GPLv2 remove
typhoon502669 net/typhoon-firmware.h unmodified redist move (3com)
whiteheat 502668 usb/serial/whiteheat_fw.hGPLv2 remove
Action is what my changes would do. If the licence requires source
distribution, remove. If the licence allows binary-only distribution,
move to firmware-nonfree (the names given are the package names minus
the leading firmware-. In the case of dsp56k we can provide the
source.
My modified firmware-nonfree is at http://womble.decadent.org.uk/tmp/.
I'll post a new patch for linux-2.6 tomorrow.
Ben.
signature.asc
Description: This is a digitally signed message part
Re: Firmware removal progress
Today's status:
driver bug source file(s) licenceaction
-
cassini498631 net/cassini.hGPLv2 remove
dabusb 502663 media/video/dabfirmware.hBSDish move (dabusb)
dsp56k 494010 char/dsp56k.cGPLv2 add source
e100 494308 net/e100.c BSDish move (e100)
kaweth 502665 net/usb/kawethfw.h GPLv2 remove
mga502666 char/drm/mga_ucode.h MITmove (matrox)
qla1280502667 scsi/ql1{2160,040,280}_fw.h 3-clause BSD move (qlogic)
r128 494007 char/drm/r128_cce.c MITmove (ati)
radeon 494009 char/drm/radeon_microcode.h MITmove (ati)
starfire 501152 net/starfire_firmware.h unmodified redist move
(adaptec)
tehuti 501153 net/tehuti_fw.h 4-clause BSD move (tehuti)
typhoon502669 net/typhoon-firmware.h unmodified redist move (3com)
whiteheat 502668 usb/serial/whiteheat_fw.hGPLv2 remove
No word from Sun re Cassini.
There is a FreeBSD driver for the Kawasaki USB network chips (kaweth
driver) under 4-clause BSD but the stated copyright holder for the
firmware is the driver author, which is not correct. I will try
contacting him.
I found QLogic QLA1XXX firmware in OpenBSD under 3-clause BSD.
No news from Tehuti, but I found firmware in OpenBSD under 4-clause BSD.
WhiteHEAT hardware is still avalable so there may be some mileage in
contacting the manufacturer.
I renumbered the previous firmware-nonfree as 0.13.1 and uploaded
today's updates as 0.13.2.
Ben.
signature.asc
Description: This is a digitally signed message part
Bug#502668: WhiteHEAT driver and firmware distribution for Linux
I am writing as a member of the Debian project, which distributes a version of Linux. The project is attempting to resolve the licencing of firmware used with Linux. The following may require attention by your legal department. Linux includes a driver and firmware for WhiteHEAT which are listed as copyright of ConnectTech Inc and licenced under the GNU General Public Licence (GPL). Thank you for supporting Linux and free software. Unfortunately, applying the GPL to the firmware is problematic, because you distribute it in binary (or equivalent) form, and not the source code that your programmers used to create it. The GPL states that anyone redistributing a work that it covers must also offer to distribute the source code. This means that strictly speaking no-one outside ConnectTech Inc is allowed to distribute the firmware, which I assume was not your intent. Please can you clarify the licence for the firmware, and preferably issue a new licence that clearly allows Debian and others to distribute the firmware. Other hardware vendors have used text such as: Permission is hereby granted for the distribution of this firmware data in hexadecimal or equivalent format, provided this copyright notice is accompanying it. or: Redistribution and use in source and binary forms are permitted provided that the following conditions are met: 1. Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502668: WhiteHEAT driver and firmware distribution for Linux
On Fri, Mar 21, 2031 at 04:17:18AM -0400, David Worthen wrote: Hi Ben, We would be most pleased to clarify license as suggested below. Where do you suggest we place the text captioned below? Regards, david Your chosen licence text should appear at the top of whiteheat_fw.h in place of the current GPLv2 text. Please send the new version of whiteheat_fw.h by way of confirmation. Thanks a lot! Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501153: Tehuti driver and firmware distribution for Linux
On Wed, Oct 22, 2008 at 11:27:42AM +0200, Pinchas wrote: Dear Ben We are satisfied with the last statement: Permission is hereby granted for the distribution of this firmware data in hexadecimal or equivalent format, provided this copyright notice is accompanying it. Thank you very much. Ben. -- Ben Hutchings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494308: e100 firmware testing
On Wed, 2008-10-22 at 17:05 -0600, dann frazier wrote: hey Ben, I got around to testing a build from the source you reference in your blog[1] today - but it appears that the e100 patch in place simply removes the firmware and marks the driver broken. I see in #494308 that there were a couple of different approaches being considered for e100, so perhaps e100 is still a work in progress. My changes to e100 in linux-2.6 are actually divided across 3 files under debian/patches, following what has been done for several other instances of sourceless firmware: 1. debian/dfsg/e100-disable.patch inserts #ifdef REMOVE_DFSG...#endif around the microcode and marks the driver as BROKEN in Kconfig. 2. debian/dfsg/files-1 uses unifdef to remove the microcode. 3. features/all/e100-request_firmware.patch removes the BROKEN mark and adds firmware loading using request_firmware. Each of the 11 other drivers is dealt with similarly, except that for most of them we can use rm instead of unifdef. The orig tarball has steps 1 and 2 already applied and step 3 is part of the normal build process. If you decide to move forward w/ a request_firmware() approach, you might want to take note that the e100 driver will be included in the initramfs by default. This means that the firmware should be included in the initramfs as well. You should be able to enable an initramfs hook in the firmware-nonfree source package - see bnx2/defines for an example. I know this works for fw blobs that live in /lib/firmware, but I don't know how well it would deal with files in other subdirectories (e.g. /lib/firmware/e100/). Right, I hadn't got that far yet. Ben. signature.asc Description: This is a digitally signed message part
Bug#503216: initramfs-tools: Network drivers missing from netboot and most sets
Package: initramfs-tools Version: 0.92l Severity: important I noticed that the sfc driver is not included in an initramfs by default. On further investigation I found that neither are cxgb, ixgb, ixgbe, s2io, netxen_nic, mlx4_core or tehuti. Also the typhoon driver is not included due to a typo (typhon). Maybe auto_add_modules() should handle the net class by including everything under kernel/drivers/net with specific exclusions (wan, wireless, irda, hamradio, ...)? Ben. -- Package-specific info: -- /proc/cmdline root=LABEL=sid-root ro -- /proc/filesystems ext3 -- lsmod Module Size Used by binfmt_misc 7528 1 ppdev 6468 0 parport_pc 22500 0 lp 8164 0 parport30988 3 ppdev,parport_pc,lp ipv6 235300 12 video 16400 0 output 2912 1 video ac 4196 0 battery10180 0 dm_snapshot14340 0 dm_mirror 15104 0 dm_log 8452 1 dm_mirror dm_mod 46184 3 dm_snapshot,dm_mirror,dm_log loop 12748 0 sd_mod 22200 0 arc41824 2 ecb 2624 2 crypto_blkcipher 15236 1 ecb pcspkr 2432 0 rt2500pci 17152 0 rt2x00pci 7648 1 rt2500pci rt2x00lib 22592 2 rt2500pci,rt2x00pci firmware_class 6816 1 rt2x00lib rfkill 5652 1 rt2x00lib led_class 3908 1 rt2x00lib button 6064 0 snd_intel8x0 26268 3 input_polldev 3752 1 rt2x00lib mac80211 139680 2 rt2x00pci,rt2x00lib snd_ac97_codec 88484 1 snd_intel8x0 cfg80211 21576 2 rt2x00lib,mac80211 ac97_bus1728 1 snd_ac97_codec snd_pcm62628 3 snd_intel8x0,snd_ac97_codec snd_seq41456 0 snd_timer 17800 3 snd_pcm,snd_seq snd_seq_device 6380 1 snd_seq eeprom_93cx62144 1 rt2500pci snd45604 10 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_seq,snd_timer,snd_seq_device soundcore 6368 1 snd snd_page_alloc 7816 2 snd_intel8x0,snd_pcm sis_agp 6752 1 i2c_sis96x 4132 0 i2c_sis630 5644 0 agpgart28776 1 sis_agp shpchp 25528 0 pci_hotplug23460 1 shpchp i2c_core 19828 2 i2c_sis96x,i2c_sis630 evdev 8000 3 ext3 105256 2 jbd39444 1 ext3 mbcache 7108 1 ext3 ide_cd_mod 27652 0 cdrom 30176 1 ide_cd_mod ide_disk 10496 4 ide_pci_generic 3908 0 [permanent] usbhid 35904 0 hid33184 1 usbhid ff_memless 4392 1 usbhid usb_storage75936 0 floppy 47716 0 sis5513 6788 0 [permanent] ide_core 96168 4 ide_cd_mod,ide_disk,ide_pci_generic,sis5513 ata_generic 4676 0 via_rhine 18664 0 mii 4896 1 via_rhine libata140416 1 ata_generic scsi_mod 129356 3 sd_mod,usb_storage,libata dock8272 1 libata ohci_hcd 18500 0 usbcore 118160 4 usbhid,usb_storage,ohci_hcd thermal15228 0 processor 32576 1 thermal fan 4164 0 thermal_sys10856 4 video,thermal,processor,fan -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = no postinst_hook = update-grub postrm_hook = update-grub -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initramfs-tools depends on: ii cpio 2.9-14 GNU cpio -- a program to manage ar ii findutils 4.4.0-2utilities for finding files--find, ii klibc-utils 1.5.12-2 small utilities built with klibc f ii module-init-tools 3.4-1 tools for managing Linux kernel mo ii udev 0.125-7/dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: ii busybox 1:1.10.2-2 Tiny utilities for small and embed initramfs-tools suggests no packages. -- no debconf information -- To
