Bug#310982: plan to include in sarge 2.4 update
On Wed, Nov 15, 2006 at 05:54:52PM -0700, dann frazier wrote: On Mon, Nov 13, 2006 at 12:22:59PM -0800, Steve Langasek wrote: Yes, because this is a kernel security bug. The smbmount patch was entertained pre-sarge only as a stopgap due to the proximity to release; the right place to fix this is still in the kernel (upstream as appropriate). I've done some testing and verified that 2.6.18 honors uid= and 2.6.8 does not. It looks like this was fixed upstream: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/fs|src/fs/smbfs|related/fs/smbfs/inode.c So, I plan to use this patch for 2.6.8, and attempt to backport it to 2.4.27. If backporting becomes overly complicated/risky, I'll revert to using something like Horms' patch. I'll also see about getting a CVE assigned. Everyone cool with this plan? Ack -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Sun, Nov 12, 2006 at 10:28:10PM -0700, dann frazier wrote: On Mon, Nov 13, 2006 at 01:30:19PM +0900, Horms wrote: If you point me at the patch I'll be happy to rack my brains and tell you want I was thinking at the time. Thanks Horms, here's the link: http://bugs.debian.org/cgi-bin/bugreport.cgi/smbfs.no_cap_unix.patch?bug=310982;msg=101;att=1 Ahh yes, I do recall that one. I've just read through all the messages associated with the bug and my position can be best described by the text at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310982;msg=101 That is, the patch should make the kernel ignore CAP_UNIX if options which make it dangerous in Sarge are specified from user-space. At the time this seemed to Steve Langasek and myself to be the best of a poor set of available solutions. And I think that is still the case. I have not verified that the patch is correct. Although I do remember being quite confident about it at the time. If someone could test it, that would be most excellent :) -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: plan to include in sarge 2.4 update
On Sun, Nov 12, 2006 at 09:28:14PM -0700, dann frazier wrote: Moritz pointed out that this issue has been overlooked for sarge updates so far. From my reading of this report, it sounds like our best option for sarge is to incorporate Horms' patch for 2.4.27. Does anyone object to this? I'll make builds available for testing prior to uploading, in case anyone is interested in verifying this solution. If you point me at the patch I'll be happy to rack my brains and tell you want I was thinking at the time. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340108: Fwd: [Bug 5634] ALSA fails with SB16 value
- Forwarded message from [EMAIL PROTECTED] - Date: Thu, 7 Sep 2006 10:23:30 -0700 Message-Id: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 5634] ALSA fails with SB16 value http://bugzilla.kernel.org/show_bug.cgi?id=5634 [EMAIL PROTECTED] changed: What|Removed |Added Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|NEW |ASSIGNED --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - End forwarded message - - Forwarded message from [EMAIL PROTECTED] - Date: Thu, 7 Sep 2006 10:25:29 -0700 Message-Id: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 5634] ALSA fails with SB16 value http://bugzilla.kernel.org/show_bug.cgi?id=5634 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||CODE_FIX --- Additional Comments From [EMAIL PROTECTED] 2006-09-07 10:17 --- OK, original issue resolved, snd-opl3-synth-not-working is separate story and ALSA developers use their own bugzilla. Reopen there. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - End forwarded message - -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/
Bug#352152: kernel-package: latest unstable version breaks 2.4.27 image builds
Package: kernel-package Version: 10.034 Severity: important The current version of make-kpkg calls the kernel's prepare target, but this does not exist in 2.4.27. Apart from anything else, this renders all of the 2.4.27 images in etch/sid unbuildable. I'm not entirely sure what the correct fix is, as changing make-kpkg to use prepare (for 2.6) seems to have been a reasonably complex change. Here is a log of a failed build, on the off chance it helps. I've seen it for i386 and powerpc, and I believe that Norbert Tretkowski has seen it on Alpha. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-hls-2006020200 Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) (ignored: LC_ALL set to ja_JP.eucJP) Versions of packages kernel-package depends on: ii dpkg 1.13.13package maintenance system for Deb ii dpkg-dev 1.13.13package building tools for Debian ii file 4.15-2 Determines file type using magic ii gcc [c-compiler] 4:4.0.2-2 The GNU C compiler ii gcc-3.2 [c-compiler] 1:3.2.3-9 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-12 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.2-8The GNU C compiler ii gettext 0.14.5-2 GNU Internationalization utilities ii make 3.80+3.81.b4-1 The GNU version of the make util ii perl 5.8.8-1Larry Wall's Practical Extraction ii po-debconf0.9.2 manage translated Debconf template Versions of packages kernel-package recommends: ii bzip2 1.0.3-2high-quality block-sorting file co ii libc6-dev [libc-dev] 2.3.5-13 GNU C Library: Development Librari -- no debconf information [snip] fakeroot debian/rules binary dh_testdir dh_clean -k dh_clean: Compatibility levels before 4 are deprecated. dh_installdirs dh_installdirs: Compatibility levels before 4 are deprecated. dh_testdir cd kernel-source-2.4.27; \ HEADER_CLEAN_HOOK=/home/horms/tmp/debian-kernel-test/kernel-image-2.4.27-i386-trunk/kernel-image-2.4.27-i386-2.4.27/header-install.out \ make-kpkg --stem kernel --append_to_version -3 kernel-headers exec make -f /usr/share/kernel-package/ruleset/minimal.mk debian APPEND_TO_VERSION=-3 KPKG_STEM=kernel make[1]: Entering directory `/home/horms/tmp/debian-kernel-test/kernel-image-2.4.27-i386-trunk/kernel-image-2.4.27-i386-2.4.27/kernel-source-2.4.27' == making target minimal_debian [new prereqs: ]== test -d debian || mkdir debian test ! -e stamp-building || rm -f stamp-building test -f debian/control || sed -e 's/=V/2.4.27-3/g'\ -e 's/=D/2.4.27-3-10.00.Custom/g' -e 's/=A/i386/g' \ -e 's/=SA//g' -e 's/=L/ /g' \ -e 's/=I//g'\ -e 's/=CV/2.4/g' \ -e 's/=M/Unknown Kernel Package Maintainer [EMAIL PROTECTED]/g'\ -e 's/=ST/kernel/g' -e 's/=B/i386/g'\ /usr/share/kernel-package/Control debian/control test -f debian/changelog || sed -e 's/=V/2.4.27-3/g' \ -e 's/=D/2.4.27-3-10.00.Custom/g'-e 's/=A/i386/g' \ -e 's/=ST/kernel/g' -e 's/=B/i386/g' \ -e 's/=M/Unknown Kernel Package Maintainer [EMAIL PROTECTED]/g' \ /usr/share/kernel-package/changelog debian/changelog install -p -m 755 /usr/share/kernel-package/rules debian/rules for file in ChangeLog Control Control.bin86 config templates.in ; do \ cp -f /usr/share/kernel-package/$file ./debian/; \ done for dir in Config docs examples ruleset scripts pkg po; do \ cp -af /usr/share/kernel-package/$dir ./debian/; \ done test -d ./debian/stamps || mkdir debian/stamps make[1]: Leaving directory `/home/horms/tmp/debian-kernel-test/kernel-image-2.4.27-i386-trunk/kernel-image-2.4.27-i386-2.4.27/kernel-source-2.4.27' exec debian/rules DEBIAN_REVISION=2.4.27-12.hls.2006020900 APPEND_TO_VERSION=-3 KPKG_STEM=kernel kernel-headers make[1]: Entering directory `/home/horms/tmp/debian-kernel-test/kernel-image-2.4.27-i386-trunk/kernel-image-2.4.27-i386-2.4.27/kernel-source-2.4.27' == making target CONFIG-common [new prereqs: testdir]== == making target debian/stamp-conf [new prereqs: ]== # work around idiocy in recent kernel versions test ! -e scripts/package/builddeb || \ mv -f scripts/package/builddeb scripts/package
Bug#344036: Unresolved symbol ALIGN in orinoco.o module
tags 344036 +pending
thanks
I believe that the following patch, which will be included in
2.4.27-13 and 2.4.27-10sarge2 trivially resolves this problem.
--
Horms
--- a/drivers/net/wireless/hermes.c
+++ b/drivers/net/wireless/hermes.c
@@ -2312,6 +2312,8 @@ orinoco_stat_gather(struct net_device *d
}
}
+#define ALIGN(x,a) (((x)+(a)-1)~((a)-1))
+
static int
orinoco_xmit(struct sk_buff *skb, struct net_device *dev)
{
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some new 2.4.27 security patches
On Fri, Oct 14, 2005 at 04:30:10PM +0900, Horms wrote: Also this patch: http://linux.bkbits.net:8080/linux-2.4/diffs/fs/xfs/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_dinode.h|[EMAIL PROTECTED]|hist/fs/xfs/xfs_inode.c ([XFS] Handle inode creation race) should also be applied since it appears to be a security issue. Fixed in 2.4.29-pre1 Patch: http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_inode.c ChangeLog: http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.29 I'll get this into SVN for 2.4.27. It does not seem to relate to 2.6 at all. I am having trouble locating CAN numbers for these, does anyone know if there are any? I don't think there are any. Perhaps we should file for the 2nd one. I noice that hlh was involved in that patch, perhaps he can provide a slightly longer description. It turns out that this patch introduces a bug in the form of a missing symbol (#343970). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343970 The fix for this is to add an additional patch, which was also included in 2.4.29-pre1 http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|src/fs/xfs/linux-2.4|related/fs/xfs/linux-2.4/xfs_vnode.h I have added this for inclusion in Sid's (trunk) 2.4.27-13. I have removed the original patch from sarge-security's 2.4.27-10sarge2 as I believe that these patches are far to large for a security release. I don't believe they have been closely examined. And we don't even have a CVE for them. Should we add a patch-tracker entry for them and consider them for sarge3? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some new 2.4.27 security patches
On Wed, Feb 08, 2006 at 12:26:27PM +0900, Horms wrote: On Fri, Oct 14, 2005 at 04:30:10PM +0900, Horms wrote: Also this patch: http://linux.bkbits.net:8080/linux-2.4/diffs/fs/xfs/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_dinode.h|[EMAIL PROTECTED]|hist/fs/xfs/xfs_inode.c ([XFS] Handle inode creation race) should also be applied since it appears to be a security issue. Fixed in 2.4.29-pre1 Patch: http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_inode.c ChangeLog: http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.29 I'll get this into SVN for 2.4.27. It does not seem to relate to 2.6 at all. I am having trouble locating CAN numbers for these, does anyone know if there are any? I don't think there are any. Perhaps we should file for the 2nd one. I noice that hlh was involved in that patch, perhaps he can provide a slightly longer description. It turns out that this patch introduces a bug in the form of a missing symbol (#343970). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343970 Sorry, this problem should be tracked as #344036 as per the note I sent to #343970 earlier today. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344036 The fix for this is to add an additional patch, which was also included in 2.4.29-pre1 http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|src/fs/xfs/linux-2.4|related/fs/xfs/linux-2.4/xfs_vnode.h I have added this for inclusion in Sid's (trunk) 2.4.27-13. I have removed the original patch from sarge-security's 2.4.27-10sarge2 as I believe that these patches are far to large for a security release. I don't believe they have been closely examined. And we don't even have a CVE for them. Should we add a patch-tracker entry for them and consider them for sarge3? -- Horms -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343970: unresolved symbols in module xfs.o
tags 343970 +pending thanks This was caused by the inclusion of 194_xfs-bad-inodes.diff in 2.4.27-12. Otherwise known as: http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_inode.c I believe that the fix for this is 194_xfs-inode-race.diff, which I have added for inclusinon in the forthcoming 2.4.27-13 release. http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|src/|src/fs|src/fs/xfs|src/fs/xfs/linux-2.4|related/fs/xfs/linux-2.4/xfs_vnode.h -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344036: Unresolved symbol in orinoco.o module
retitle 344036 Unresolved symbol ALIGN in orinoco.o module retitle 343970 Unresolved symbol vn_mark_bad in xfs.o thanks Hi, The xfs.o/vn_mark_bad problem has also been reported as #343970 I would like to handle discussion of that problem exclsively in that bug. I also believe that I have a solution to that problem, as annotated in that bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343970 I would like to use this bug, 344036, to address the missing ACCEPT symbol in orinoco.o. I hope to post a solution to that problem shortly. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Yaird-devel] Bug#345067: ide-geenric inclusion even if it doesn't exist.
Sven Luther [EMAIL PROTECTED] wrote: On Mon, Feb 06, 2006 at 10:03:38AM +0900, Horms wrote: On Fri, Feb 03, 2006 at 10:24:51AM +0100, Sven Luther wrote: On Fri, Feb 03, 2006 at 01:51:52AM +, Horms wrote: Stephen Gran [EMAIL PROTECTED] wrote: Oh look, why are you still fighting about this? It seems to me that the real problem is that the via module doesn't declare a relation to ide-generic in situations where it actually does need it. Why not fix the kernel, so that yaird doesn't have to bend over backwards? Not that I really care either way, but it does seem to me to be cleaner to fix the underlying problem rather than adding increasingly nonsensical special case code somewhere else to work around it. Can someone cook up a patch for this and send it upstream and/or here? I guess this means someone needs to investigate it with the hardware that is broken in the first place. Nobody seemed interested in doing so, and i don't have broken via-ide x86 hardware myself. Now, can we please get the borken hack in yaird be backed out or at least disabled on powerpc as my patch proposed ? As I subsequently mentioned on IRC, I have some Via hardware, though I'm not sure if its broken or not. If someone wants me to run tests, please let me know. What we need to know is why the x86 via driver apparently needs the ide-generic module to be loaded after the via-ide one, while there doesn't seem to be a difference on powerpc who doesn't even build ide-generic. Could you try booting your via board with just viac8xx or whatever it is named, and not including the ide-generic file (means patching /usr/lib/yaird/perl/Hardware.pm, where it is hardcoded). Sure, I will try and test that out. Though it won't be toady. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Yaird-devel] Bug#345067: ide-geenric inclusion even if it doesn't exist.
On Fri, Feb 03, 2006 at 10:24:51AM +0100, Sven Luther wrote: On Fri, Feb 03, 2006 at 01:51:52AM +, Horms wrote: Stephen Gran [EMAIL PROTECTED] wrote: Oh look, why are you still fighting about this? It seems to me that the real problem is that the via module doesn't declare a relation to ide-generic in situations where it actually does need it. Why not fix the kernel, so that yaird doesn't have to bend over backwards? Not that I really care either way, but it does seem to me to be cleaner to fix the underlying problem rather than adding increasingly nonsensical special case code somewhere else to work around it. Can someone cook up a patch for this and send it upstream and/or here? I guess this means someone needs to investigate it with the hardware that is broken in the first place. Nobody seemed interested in doing so, and i don't have broken via-ide x86 hardware myself. Now, can we please get the borken hack in yaird be backed out or at least disabled on powerpc as my patch proposed ? As I subsequently mentioned on IRC, I have some Via hardware, though I'm not sure if its broken or not. If someone wants me to run tests, please let me know. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Yaird-devel] Bug#345067: ide-geenric inclusion even if it doesn't exist.
Stephen Gran [EMAIL PROTECTED] wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 59 lines --] This one time, at band camp, Sven Luther said: On Mon, Jan 30, 2006 at 01:11:44PM +0100, Jonas Smedegaard wrote: On Sun, 29 Jan 2006 15:20:34 +0100 Sven Luther [EMAIL PROTECTED] wrote: i, wearing my powerpc debian kernel maintainer hat, know that it is not needed on powerpc. This indicates that you are talking about a single kernel build - the one provided by the kernel team, not powerpc kernels in general. Jonas, can you please explain me how you can come to the conclusion that ide-generic is *NEEDED* on powerpc, if there is at least one kernel config which does not have it and works perfectly ? I think you are just arguing for the sake of arguing, and failing to even try to understand the issue at hand ? Oh look, why are you still fighting about this? It seems to me that the real problem is that the via module doesn't declare a relation to ide-generic in situations where it actually does need it. Why not fix the kernel, so that yaird doesn't have to bend over backwards? Not that I really care either way, but it does seem to me to be cleaner to fix the underlying problem rather than adding increasingly nonsensical special case code somewhere else to work around it. Can someone cook up a patch for this and send it upstream and/or here? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 for etch or not
Hi Holger, thanks for raising this important issue and sorry for being slow to reply. I think that I agree with pretty much everything you wrote, so I won't reiterate that here. However, I'd like to take the opportunity to clarify my position with regards to 2.4 in Etch. When I first became involved with debian-kernel, leading up to Sarge, my main interest was in making sure that 2.4 was in good shape. This is because at that time I felt that there was a very strong audience for it, and that it was essential for Sarge's success. As many people had already shifted their focus to 2.6 I felt there was a bit of a vacuum, and I was happy to fill it. However, leading up to Etch, as we now are, I really feel that for the various reasons you listed, the support burden of 2.4 in Etch is heavier than its benefit. So, except for architectures that absolutely must have it, we should drop 2.4. I believe 2.2 was in Sarge for some architectures, and probably will also have it for Etch. So this idea is by no means new. To be quite honest, when people like Ted T'so advise me that 2.4 isn't really viable for Etch, I tend to take notice. If, the release maintainers decide that we really must keep 2.4, then moving forward to 2.4.3X with the new unified packaging that is seen in current linux-2.6 packages is the next best option. Holger, I guess that responsibility would fall on your shoulders for now, as I unfortunately do not have the time to devote to it. Hopefully some more volunteers can be found. Failing that, keep updating 2.4.27, as we already are for Sarge security, and include that. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 for etch or not
On the topic of Security fixes and 2.4's upstream. Dann, myself, and all others involved endeavour to push any patches we find that are missing from upstream to the relevant parties. This includes 2.4 and 2.6, security and non-security patches. Marcelo has specifically asked vendors (and others) to keep doing this for 2.4. So if you have patches for critical bugs, please forward them on - he can decide to drop or keep them. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] Removal of duplicate options in debian/arch/config
Rod Whitby [EMAIL PROTECTED] wrote: As requested by fs on #debian-kernel, here is the first post in an effort to identify and remove duplicate (and sometimes inconsistent) options from the hierarchy of debian/arch/config, debian/arch/arch/config, and debian/arch/arch/config.flavour (at least for the debian/arch/arm/config.ixp4xx tree that concerns my current project of getting NSLU2 and NAS100D support into the upstream and debian kernels). I did a simple analysis on debian/arch/config (just diff the outputs of sort and sort -u on the same input file), and found a number of options duplicated in debian/arch/config. This patch removes the duplicates and should apply cleanly against current SVN. Thanks, applied. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#328707: kernel-source-2.4.27: Compile fails
[EMAIL PROTECTED] wrote: I met this problem as well lately, and the way I solved it was to momentarily downgrade binutils from 2.16.1cvs20051117-1 (current version from Debian testing) to the version in Debian stable (2.15-6) (since the error is reported by the GNU assembler 'as'). It seems that there is a problem between gcc-3.3 and binutils (at least for 'as'). Perhaps the bug should be reassigned to gcc or binutils. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please Build 2.4.27-12 for Sid
2.4.27-12 has been released into sid, this is a call to rebuild for all the different architectures. So far it is only available for i386 (which I built). I'll get powerpc rolling, I had mistakenly thought it was removed from Sid. Perhaps it should be, we can address that another day. I'm happy to do some more builds, but doing all of them is a little daunting. http://people.debian.org/~dannf/kernel-stats/kernel-avail.html Also, if an arch should not be built lets start a list. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposed Kernel Updates for Sid: Round 1
Hi, This has been a long time in the coming, but I'm happy to report that we are slowly, but very surely making progress towards being able to release a round of security updates for Sarge. These updates were actually prepared a little while ago, but it has taken us a little while to work with the Security team to get them into shape. Hopefully it won't take so long the next time around, which will likely kick off as soon as this round concludes. The reason that I am writing is to solicit help in testing. Some minor problems have been found, and mostly fixed, but the more testing the merrier. What we are looking for is problems that have been _introduced_ by the security updates. Particularly problems like, the system now fails to boot because vmlinuz is missing. The status of the architectures is: * Still needs fixing, should happen real soon now kernel-image-2.4.27-armwrong distribution, needs fix, random changes kernel-patch-2.4.27-mips needs mipsel - buildd, pending * Recently fixed, in the most need of testing kernel-image-2.4.27-ia64 kernel-image-2.4.27-alpha kernel-image-2.6.8-alpha kernel-patch-powerpc-2.6.8 * Not recently updated, already had some testing kernel-image-2.6.8-sparc kernel-image-2.4.27-sparc kernel-image-2.6.8-hppa kernel-image-2.6.8-i386 kernel-image-2.4.27-i386 kernel-image-2.6.8-m68k kernel-image-2.4.27-m68k kernel-image-2.4.27-s390 kernel-patch-2.4.27-powerpc kernel-image-2.6.8-ia64 kernel-image-2.6.8-s390 kernel-image-2.6.8-amd64 You can find the images, and corresponding source in http://kernel.debian.net/debian/pool/main/ And the archive is apt-gettable using: deb http://kernel.debian.net/debian/ sarge-proposed-security-updates main deb-src http://kernel.debian.net/debian/ sarge-proposed-security-updates main If you know of new security bugs, and they aren't in http://svn.debian.org/wsvn/kernel/patch-tracking/?rev=0sc=0 then send a note here, to the testing-security team, or open a bug in the BTS. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330081: Followup on localversion/extraversion override
In article [EMAIL PROTECTED] you wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 29 lines --] Just had a look at the 2.6.14 kernel image packages, and this is still a problem. The .extraversion file that exists is not read by anything in the kernel makefiles supplied in the linux-headers package that I can see... ln .extraversion localversion-debian makes the module install scripts from the kernel work properly, but this is not completely correct behaviour since it's an extraversion, not a localversion, but this happens to work... Perhaps localversion-00debian would be better, to be sure it's first ahead of any other patches applied, but ideally the value should be in the Makefile as EXTRAVERSION, which would mean it could no longer be shared amongst the linux-headers-2.6.14-2-* packages. Another option would be modify the upstream Makefile to read .extraversion into EXTRAVERSION at the top of the Makefile... It's Debian-specific, and probably not the best solution given that there appears to be scripts out there reading .extraversion, eg. #333842. But it otherwise seems a good solution to me that doesn't require unsharing the Makefile. Manoj, being the extraversions expert, do you have any thoughts on this. The current situation seems less than ideal. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341761: [PATCH] PCI hotplug: Be slightly quieter about shpc_cap_offset == 0
In article [EMAIL PROTECTED] you wrote:
Package: linux-2.6
Severity: minor
I'm booting using the quiet kernel option. During the synthesizing
of the initial hotplug events, I see the following messages show up:
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
I don't know what this means, but I doubt it is important enough to
break the silence I requested using quiet. I don't even have a
machine capable of PCI hotplugging.
If the issue is important enough to bother me about after all, it
should say what the problem is in plain English, so I can actually do
something about it.
I've CCed the upstream maintainer, to bring this minor issue
to his attention.
Greg, I see in the code that message is logged using err(),
perhaps dbg() would be more appropriate. Trivial patch for reference:
PCI hotplug: Be slightly quieter about shpc_cap_offset == 0
It seems that the following message, logged as err() can show
up during normal boots.
See: http://bugs.debian.org/341761
Signed-Off-By: Horms [EMAIL PROTECTED]
diff --git a/drivers/pci/hotplug/shpchp_hpc.c b/drivers/pci/hotplug/shpchp_hpc.c
index 9987a6f..69f0e5d 100644
--- a/drivers/pci/hotplug/shpchp_hpc.c
+++ b/drivers/pci/hotplug/shpchp_hpc.c
@@ -1351,7 +1351,7 @@ int shpc_init(struct controller * ctrl,
shpc_base_offset = 0; /* amd shpc driver doesn't use this;
assume 0 */
} else {
if ((shpc_cap_offset = pci_find_capability(pdev,
PCI_CAP_ID_SHPC)) == 0) {
- err(%s : shpc_cap_offset == 0\n, __FUNCTION__);
+ dbg(%s : shpc_cap_offset == 0\n, __FUNCTION__);
goto abort_free_ctlr;
}
dbg(%s: shpc_cap_offset = %x\n, __FUNCTION__,
shpc_cap_offset);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.27-12 for Sid
Hi, I know this thread kind of miandered off into how to move beyond 2.4.27, but as progress there is likely to be slow I am going ahead and uploading 2.4.27-12. Holger took a bit of a look over it and couldn't find anything drasticaly wrong. And it does have some bug fixes, so hopefully we are moving forward. I have tagged and uploaded source and i386 accordingly. There is no powerpc for 2.4.27, so I shan't upload that. Interested parties, please build for other architectures. Though if we could get some autobuild-foo happening using the experimental buildds at some stage, that would be awsome. It should be in incoming shortly, and I'll keep it at the following links for a little while: http://packages.vergenet.net/testing/kernel-source-2.4.27_2.4.27-12/ http://packages.vergenet.net/testing/kernel-image-2.4.27-i386_2.4.27-12/ Lastly, its signed with my new key, as the last one was on a lost laoptop and revoked. I belive that the new key is in the keyring. If you want to drop by Tokyo and sign it, feel free. Alternatively, I'll be at LCA2006 in Dunedin next month. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.15 - i386: drop M386 support in favour of M486?
Frederik Schueler [EMAIL PROTECTED] wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 42 lines --] Hi all, we should start making 2.6.15-rc ready in experimental, so we can again upload the final version the same day upstream releases, and maybe do it in time through the NEW queue this time. But before that, every arch maintainer needs to check their configs and maybe rediff some (now commented out) patches. For the start, the orig tarball for 2.6.15-rc4 is at http://people.debian.org/~fs/linux-2.6_2.6.14+2.6.15-rc4.orig.tar.gz I have the amd64 configs in sync, and would like to upload a first try to experimental. Unfortunately, I cannot upload amd64 binaries to the archive yet, so I worked on the i386 parts too. This leads us to the following problem: The 386 flavour used to have CONFIG_M386 set, wich currently fails to build due to missing CONFIG_X86_CMPXCHG (which is !M386), which in turn is needed for example by ACPI. Currently the 386 flavour breaks after some warnings about this. I wonder why we don't drop M386 support at all, and switch to M486? The alternative would be investigate the changes and fix all concerned code, which I sincerely don't have the time to do. Current post-sarge kernels won't work on real i386 systems anyway, since we dropped x86-i486_emu.dpatch. M486 sounds reasonable to me. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
In article [EMAIL PROTECTED] you wrote: On Tue, 8 Nov 2005 15:34:48 +0100, Sven Luther wrote [typo corrected]: You can now, just need to add Recommends: blah to the arch/arch/defines entry. Now the capability has been added, any chance you could pop this extra line in? I'd be happy to do it myself, but of course I can't. Richard. I will put the follwing into svn which should effect the change. -- Horms Index: debian/arch/i386/defines === --- debian/arch/i386/defines(revision 4929) +++ debian/arch/i386/defines(working copy) @@ -12,16 +12,20 @@ [686] class: PPro/Celeron/PII/PIII/P4 longclass: Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4 +recommends: libc6-i686 [686-smp] class: PPro/Celeron/PII/PIII/P4 SMP longclass: multi-processor Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4 +recommends: libc6-i686 [k7] class: AMD K7 longclass: 32bit AMD Duron/Athlon/AthlonXP +recommends: libc6-i686 [k7-smp] class: AMD K7 SMP longclass: 32-bit multi-processor AMD Duron/Athlon/AthlonXP +recommends: libc6-i686 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340774: udev: unable to register OSS PCM device 0:0 for snd-intel8x0 with dxr3 card installed
In article [EMAIL PROTECTED] you wrote: reassign 340774 linux-2.6 thanks On Nov 25, AdamW [EMAIL PROTECTED] wrote: I've got a problem with oss emulation from alsa with dxr3 card installed in my system. Udev loads drivers for dxr3 first and then is unable to register OSS PCM device 0:0 When I remove dxr3 drivers (em8300, bt865) everything is ok. It would be grateful if you could fix this problem. I think that it would be enough if udev could load sound drivers first, however, I do not know how t do it. udev does not and will not enforce this kind of drivers ordering. This looks like a kernel bug. I understand, but with hotplug there is no problem with alsa oss emulation even if drivers for sound card are loaded first. It happens only when I use udev istead of hotplug I believe that what Marco is saying is that, while the ordering of loading the modules may be important, as does indeed seem to be the case here, its not up to udev to set that ordering, it is handled entirely by the kernel. So it seems that Alsa needs to be enhanced so either the ordering isn't required, or it has some way to load oss pcm first. With this in mind, could you please log a bug against ALSA and report any bugs back here (unfortunately bugzilla doesn't play well with the debian BTS). James Courtier-Dutton recently posted (to another bug) about how he would like ALSA bugs handled. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338606;msg=15 Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340836: linux-image-2.6.14-2-686: module ieee80211_crypt_tkip and ieee80211_crypt_ccmp are broken
In article [EMAIL PROTECTED] you wrote: Package: linux-image-2.6.14-2-686 Version: 2.6.14-3 Severity: important Hi, When ieee80211_crypt_tkip is loaded I have this in kern.log and TKIP auth doesn't work: Nov 26 10:41:36 localhost vmunix: ieee80211_crypt: registered algorithm 'NULL' Latest ieee80211-source give the same result. There is a known problem with the ieee80211 in Linus' tree being out of date. Its slowly being discussed on debian-kernel. http://lists.debian.org/debian-kernel/2005/11/msg01215.html -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
Mikhail Gusarov [EMAIL PROTECTED] wrote: You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. The complete list of changes needed to turn off ieee80211 seems to be: # CONFIG_HOSTAP is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IEEE80211_CRYPT_TKIP is not set # CONFIG_IEEE80211_CRYPT_WEP is not set # CONFIG_IEEE80211_CRYPT_CCMP is not set # CONFIG_IEEE80211 is not set Or in other words HOSTAP and IPW2100, IPW2200 and HOSTAP (Prism) also needs to be disabled. Is the latter acceptable collateral dammage? I was under the impression that upstream had recently updated ieee80211. Is it still out of date in 2.6.14 ? Below is a patch that effects the change in the current 2.6.14 tree. Note that it probably will not apply cleanly as soon as any other changes are made to the configs due to some quirks in the way that split config. Note also that it consolodates some spurious arm and m68k configs for these options into the global config. Index: a/debian/arch/arm/config.s3c2410 === --- a/debian/arch/arm/config.s3c2410(revision 4929) +++ a/debian/arch/arm/config.s3c2410(working copy) @@ -279,11 +279,7 @@ # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers Index: a/debian/arch/arm/config.footbridge === --- a/debian/arch/arm/config.footbridge (revision 4929) +++ a/debian/arch/arm/config.footbridge (working copy) @@ -305,11 +305,7 @@ # CONFIG_VLSI_FIR is not set # CONFIG_VIA_FIR is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers @@ -687,7 +683,6 @@ # # CONFIG_NET_RADIO is not set # CONFIG_IPW_DEBUG is not set -CONFIG_IPW2200=m # # Wan interfaces Index: a/debian/arch/arm/config.ixp4xx === --- a/debian/arch/arm/config.ixp4xx (revision 4929) +++ a/debian/arch/arm/config.ixp4xx (working copy) @@ -437,11 +437,7 @@ # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers @@ -856,10 +852,8 @@ # # Wireless 802.11b ISA/PCI cards support # -CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW_DEBUG is not set -CONFIG_IPW2200=m CONFIG_HERMES=y # CONFIG_PLX_HERMES is not set # CONFIG_TMD_HERMES is not set @@ -871,7 +865,6 @@ # Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support # # CONFIG_PRISM54 is not set -CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_PCI=m Index: a/debian/arch/arm/config.rpc === --- a/debian/arch/arm/config.rpc(revision 4929) +++ a/debian/arch/arm/config.rpc(working copy) @@ -251,11 +251,7 @@ # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set -CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set -CONFIG_IEEE80211_CRYPT_WEP=m -CONFIG_IEEE80211_CRYPT_CCMP=m -CONFIG_IEEE80211_CRYPT_TKIP=m # # Device Drivers Index: a/debian/arch/m68k/config === --- a/debian/arch/m68k/config (revision 4929) +++ a/debian/arch/m68k/config (working copy) @@ -344,7 +344,3 @@ CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m -CONFIG_IEEE80211_CRYPT_CCMP=n -CONFIG_IEEE80211_CRYPT_TKIP=n -CONFIG_IEEE80211_CRYPT_WEP=n -CONFIG_IEEE80211=n Index: a/debian/arch/config === --- a/debian/arch/config(revision 4929) +++ a/debian/arch/config(working copy) @@ -585,7 +585,6 @@ CONFIG_USB_NET_AX8817X=m CONFIG_USB_YEALINK=m CONFIG_FUSE_FS=m -CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_PHYCONTROL=y # CONFIG_IPW_DEBUG is not set # CONFIG_EV64360 is not set @@ -601,7 +600,6 @@ CONFIG_INET_TCP_DIAG=m CONFIG_RAID_ATTRS=m CONFIG_USB_NET_CDCETHER=m -CONFIG_IPW2100=m CONFIG_DVB_USB_VP702X=m CONFIG_VIDEO_SAA6588=m CONFIG_CHELSIO_T1=m @@ -631,7 +629,6 @@ CONFIG_DRM_SAVAGE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_PHYLIB=m -CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_MARVELL_PHY=m CONFIG_SCSI_SATA_MV=m CONFIG_SND_GENERIC_DRIVER=y @@ -645,7 +642,6 @@ CONFIG_IP6_NF_TARGET_REJECT=m #
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 30, 2005 at 10:09:54AM +0100, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:51:44AM +, Horms wrote: Mikhail Gusarov [EMAIL PROTECTED] wrote: You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. The complete list of changes needed to turn off ieee80211 seems to be: # CONFIG_HOSTAP is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set # CONFIG_IEEE80211_CRYPT_TKIP is not set # CONFIG_IEEE80211_CRYPT_WEP is not set # CONFIG_IEEE80211_CRYPT_CCMP is not set # CONFIG_IEEE80211 is not set Or in other words HOSTAP and IPW2100, IPW2200 and HOSTAP (Prism) also needs to be disabled. Is the latter acceptable collateral dammage? I was under the impression that upstream had recently updated ieee80211. Is it still out of date in 2.6.14 ? yes. 2.6.15 ipw2XXX are fine and with up2date ieee80211 stack. there we should really enable those. Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.27-12 for Sid
Joey Hess [EMAIL PROTECTED] wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 15 lines --] Horms wrote: Holger kindly reminded me on IRC yesterday that its been a long time since a new 2.4.27 was uploaded into Sarge. He pointed out that there are a number of valuable fixes in SVN. Is there any reason why you're sticking with 2.4.27+patches rather than following the 2.4 series upstream? Seems to this uninformed observer like it might be less work to follow upstream since it's limited to security fixes, serious bug fixes, and driver backports, assuming merging with it isn't too much work. Well, the main reasons are: 1) The patches are actually coming in at a very slow rate so keeping 2.4.27 up to date hasn't proved to be a great burden (though the same would be true of 2.4.32) 2) The merge takes time. 3) Currently maintaining 2.4.27 for sid also maintains it for sarge, two birds, one stone. Thats not to say that they are good reasons. But they are the reasons. To be quite honest, I would be very happy if someone would take over looking after 2.4. And update it to 2.4.32 and the new packaging infastructure that is now used for linux-2.6 in sid/etch. At the time that I started working on 2.4 packaging, 2.4 was slated as a viable kernel for a significant userbase for sarge. Looking forward, it is my belif that by the time we hit etch, 2.4 will only be for niche users, older hardware and arches that don't have 2.6. I think those users are very worthy reasons to keep 2.4, at least on arches that need it. But I'm finding it hard to get excited about doing it myself. Holger mentioned he would be interested in looking into it. He also mentioned that his coding skills are a little weak. Personally I don't think that is mich of a problem. What is needed is someone who is patient, can work with people to find answers, can do simple merging of patches and in short, manage package releases. In my time working on the kernel team I have spend much, much, much more time doing those things than the occasional like of code I write as a bugfix. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341035: kernel-source-2.6.8: [PATCH] CH Products USB yoke and pedals recognized but frozen by SET_IDLE
Vassilii Khachaturov [EMAIL PROTECTED] wrote: Package: kernel-source-2.6.8 Version: 2.6.8-16 Severity: normal Tags: patch The devices Bus 004 Device 003: ID 068e:00ff CH Products, Inc. Flight Sim Yoke Bus 004 Device 002: ID 068e:00f2 CH Products, Inc. Flight Sim Pedals on my machine get recognized but they don't work. cat'ting the relevant /dev/input/js* devices reports some initial data, but no axis or button input on any of them produces any change. flightgear/fgjs/js_demo don't show any input either. Following the tip at http://www.qbik.ch/usb/devices/showdev.php?id=587 by Alex Perry, I made the following patch that works perfectly on my system. A better approach would probably be a configure option if somebody does need that extra SET_IDLE call. I'm not x-posting to lkml since 2.6.8 is an ancient source (2.6.14 exists today), but since we only have 2.6.8 in debian archive as of today, I want it available for other Debian users that might want to solve the same problem. Just a slight clarification, 2.6.8 and 2.4.27 are the kernels for Sarge. More recent kernels are available in Sid (unstable) and Etch (currently testing), and occasionally experimental. There is also a backport of 2.4.12 for Sarge floating about: http://packages.vergenet.net/sarge-backports/ --- drivers/usb/input/hid-core.c.orig 2005-11-27 23:53:11.838499336 +0200 +++ drivers/usb/input/hid-core.c2005-11-27 23:53:05.533457848 +0200 @@ -1309,9 +1309,14 @@ void hid_init_reports(struct hid_device * bugfree devices and will cause a worst-case extra delay of * 1ms for buggy ones. */ +#if 0 /* vassilii: disabled tipped by Alex Perry's report for an equivalent + * change of older (2001) source. This allows the USB CH Products + * yoke and pedals to work correctly. + */ usb_control_msg(hid-dev, usb_sndctrlpipe(hid-dev, 0), HID_REQ_SET_IDLE, USB_TYPE_CLASS | USB_RECIP_INTERFACE, (1 8), hid-ifnum, NULL, 0, HZ * USB_CTRL_SET_TIMEOUT); +#endif report_enum = hid-report_enum + HID_INPUT_REPORT; list = report_enum-report_list.next; That seems fine enough to me. Do you know of any side effects of using this patch. Or do you considere it a candidate for inclusion in a Sarge update. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#332381: This problem has broader implications
Micah Anderson [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Although the original report says, After 250 days, the jiffies overflow and ipt_recent do not work anymore and is for 2.4, I've actually found that the code included in 2.6.8 (and probably any kernel version that includes ipt_recent) causes unexpected issues related to the jiffies as well, other than the 250 days issue. If you have rules that block based on ipt_recent you will find that they will block much too early at odd times. For example, I have a rule that will DROP ssh connections if there have been more than 6 seen in the last 60 seconds, but (seemingly) randomly I will get DROPped on the first connection. Lets be quite clear, the ip_recent code is in dire need of a rewrite. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
In gmane.linux.debian.devel.kernel Maximilian Attems [EMAIL PROTECTED] wrote: On Wed, Nov 30, 2005 at 12:49:28PM +0100, Frans Pop wrote: On Wednesday 30 November 2005 11:44, Maximilian Attems wrote: On Wed, Nov 30, 2005 at 06:22:17PM +0900, Horms wrote: Ok, so I should just go ahead and put my patch into the 2.6.14 branch? Or should we leave it as 2.6.15 probably isn't that far away... maybe depends if d-i will base itself on 2.6.14 for next beta than it's maybe nicer to have those ancient than nothing. We will use whatever is in testing at the time of the release. So it depends very much on when 2.6.15 will be uploaded (and even if 2.6.14 will have moved to testing before then). Are there major changes from .14 to .15? If not, we should be able to change over to .15 relatively fast. Ok, in this case I am inclided to leave things as is in .14, and make changes as required, if any, to .15. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341329: kernel-image-2.6.8-2-386: usb 2.0 pci card with ali 5273 chip not working
On Wed, Nov 30, 2005 at 12:44:29PM -0800, Dan Aronson wrote: Horms, I don't know why I didn't see it yesterday when I looked, but this seems to be the same bug as 316848. Sorry for making you reply again. I'll be even more careful next time. No problem. Just to clarify. You still see the same bug in 2.6.12? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341329: kernel-image-2.6.8-2-386: usb 2.0 pci card with ali 5273 chip not working
On Wed, Nov 30, 2005 at 06:37:57PM -0800, Dan Aronson wrote: As I wrote, the in 2.6.12 the driver now reports that there is a BIOS bug, but then recovers and finishes loading, I haven't yet tried a device on it, but it does show up correctly in /proc/bus/usb/devices. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] hfs, hfsplus: don't leak s_fs_info and fix an oops
On Fri, Oct 07, 2005 at 09:10:05AM +0200, Colin Leroy wrote: On 07 Oct 2005 at 13h10, Horms wrote: Hi, I took a look at making a backport, and it seems that some of the problems are there, but without a deeper inspection of the code its difficult to tell if the problems manifest or not. That was easy to get the oops: $ dd if=/dev/zero of=im_not_hfsplus count=10 #for example $ mkdir test_dir $ sudo mount -o loop -t hfsplus ./im_not_hfsplus ./testdir $ dmesg After an extended delay I have been able to confirm that the above commands do not cause 2.4 (Debian's 2.4.27) to do anything unusal. Mount just reports: mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too many mounted file systems And there is nothing exciting in dmsg: loop: loaded (max 8 devices) HFS+-fs: unable to find HFS+ superblock HFS+-fs: unable to find HFS+ superblock HFS+-fs: unable to find HFS+ superblock Thus it seems that 2.4 does not suffer from this bug. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.4.27-12 for Sid
Hi, Holger kindly reminded me on IRC yesterday that its been a long time since a new 2.4.27 was uploaded into Sarge. He pointed out that there are a number of valuable fixes in SVN. http://svn.debian.org/wsvn/kernel/dists/trunk/kernel-2.4/source/kernel-source-2.4.27-2.4.27/?rev=0sc=0 I'll also add that the rate of 2.4 security and other bugs is fairly slow, so there seems to be no good reason not to release 2.4.27-12. However, if you have a pet bug you want fixed, now would be an excellent time to bring them here, hopefully with patches. In the mean time, here is what I have, source and i386 packages. This is not a call to build, though if you have another arch handy, now would be an excellent time to check for FTBFS. This is a call for testing, weather that be installing and booting, testing rebuilds, or examining the changelog / patches. Feedback, please! http://packages.vergenet.net/testing/kernel-image-2.4.27-i386_2.4.27-11.hls.2005112400/ http://packages.vergenet.net/testing/kernel-source-2.4.27_2.4.27-11.hls.2005112400/ Q: Hey, those packages are 2.4.27-11.hls.2005112400 and you are talking about 2.4.27-12, what gives? A: Its a snapshot built from SVN of what would be 2.4.27-12 if it was released yesterday (or today as there have been no changes). I changed the version number to signify that it isn't an official release. I also changed some dependancies accordingly. They are the only changes. Q: Didn't you revoke your key after an incident involving a laptop and a restuarant? A: Yes. Hopefully my new key will make it into the keyring soon. I signed the snapshot packages with my new key, and if anyone is kicking around Tokyo and wants to sign it drop me a line. In the mean time, I need someone to sponsor my uploads. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340108: linux-image-2.6.14-2-386: ALSA fails with SB16 value
Ralf Neubauer [EMAIL PROTECTED] wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 15 lines --] On Mon, Nov 21, 2005 at 12:25:11PM +0900, Horms wrote: tag 340108 +upstream [...] As this is almost certainly an ALSA bug, could you take a few moments to log your report with the ALSA maintainers, as per the instructions on: http://www.mailarchives.org/list/debian-kernel/msg/2005/09177 http://bugzilla.kernel.org/show_bug.cgi?id=5634 Thanks, I've added myself as a CC. I was going to add [EMAIL PROTECTED], but that would require reginstering that address as a user, which seems like an abuse of bugzilla to me. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340215: linux-image-2.6.14-2-686-smp: missing mkiss module
Hamish Moffatt [EMAIL PROTECTED] wrote: Package: linux-image-2.6.14-2-686-smp Version: 2.6.14-3 Severity: normal The mkiss module (in drivers/net/hamradio) is missing in this SMP kernel (and -k7-smp) but present in the uniprocessor kernels. It is SMP-safe as of 2.6.14 (according to Ralf Baechle who signed off the patches to upstream) and hence should be enabled in the packages. It's in the amd64-k8-smp kernel already. That seems fine to me, I've enabled MKISS globally the head in the sid (2.6.14) and trunk (2.6.15-preN) trees in SVN. A summary of the change follows. Interested parties, please comment/revert as needed. -- Horms -CONFIG_MKISS=m Index: debian/arch/powerpc/config Index: debian/arch/ia64/config Index: debian/arch/alpha/config.alpha-generic Index: debian/arch/alpha/config.alpha-smp Index: debian/arch/i386/config.386 Index: debian/arch/i386/config.k7 Index: debian/arch/i386/config.686 Index: debian/arch/amd64/config.amd64-k8 Index: debian/arch/amd64/config.em64t-p4-smp Index: debian/arch/amd64/config.em64t-p4 Index: debian/arch/amd64/config.amd64-generic Index: debian/arch/amd64/config.amd64-k8-smp -# CONFIG_MKISS is not set Index: debian/arch/i386/config.k7-smp Index: debian/arch/i386/config.686-smp +CONFIG_MKISS=m Index: debian/arch/config -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340228: kernel-image-2.6.8-2-k7: IDE DMA error recovery doesn't work anymore
versions, its probably best to just report it against one and ask if it should be clonned in the bug report. Its pretty easy to duplicate the bug and reassign it if needed. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340228: [PATCH, IDE] Blacklist CD-912E/ATK
URL: http://bugs.debian.org/340228
From: Karol Lewandowski [EMAIL PROTECTED]
Package: kernel-image-2.6.8-2-k7
Version: 2.6.8-16
Severity: important
Linux kernel 2.6.(everything) panics when mounting cdrom when DMA
transfers are enabled (default). It works fine if DMA is disabled.
The drive is clearly broken. Adding blacklist to drivers/ide/ide-dma.c
for this model (CD-912E/ATK) fixes this problem.
Messages gathered on panic condition:
--- Begin kernel messages ---
ide-cd: cmd 0x28 timed out
hdc: DMA interrupt recovery
hdc: lost interrupt
hdc: cdrom_decode_status: status=0xd0 { Busy }
ide: failed opcode was: unknown
hdc: DMA disabled
[ cut here ]
kernel BUG at drivers/ide/ide-iops.c:949!
invalid operand: [#1]
Modules linked in:
CPU:0
EIP:0060:[c01ece82]Not tainted VLI
EFLAGS: 00010086 (2.6.14-eve1)
EIP is at ide_execute_command+0x22/0x90
eax: c01ecef0 ebx: c02fed38 ecx: 8000 edx: c3f81580
esi: c02feca8 edi: 0286 ebp: c01f9000 esp: c02c7e50
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c02c6000 task=c028eba0)
Stack: 0082 00808000 c01179e5 a00ce600 c10ce600 c02fed38 c02feca8
c01f8869
c02fed38 00a0 c01f9000 1770 c01f86e0 c10d8ec4 c02fed38 c10d8ec4
c10ce600 0004 c01f938a c02fed38 8000 c01f9000 c02fed38 c10d8ec4
Call Trace:
[c01179e5] update_process_times+0x85/0x130
[c01f8869] cdrom_start_packet_command+0x119/0x1a0
[c01f9000] cdrom_start_read_continuation+0x0/0xb0
[c01f86e0] cdrom_timer_expiry+0x0/0x70
[c01f938a] cdrom_start_read+0xca/0xd0
[c01f9000] cdrom_start_read_continuation+0x0/0xb0
[c01fa075] ide_do_rw_cdrom+0x95/0x1b0
[c01eb1b6] start_request+0x156/0x240
[c01eb4fa] ide_do_request+0x22a/0x380
[c01eb867] ide_timer_expiry+0xd7/0x1c0
[c01eb790] ide_timer_expiry+0x0/0x1c0
[c0117b66] run_timer_softirq+0xb6/0x1b0
[c0113deb] __do_softirq+0x7b/0x90
[c0113e26] do_softirq+0x26/0x30
[c010415e] do_IRQ+0x1e/0x30
[c0102a46] common_interrupt+0x1a/0x20
[c0100920] default_idle+0x0/0x30
[c0100943] default_idle+0x23/0x30
[c01009e0] cpu_idle+0x50/0x60
[c02c87f6] start_kernel+0x146/0x170
[c02c8380] unknown_bootoption+0x0/0x1e0
Code: c3 90 8d b4 26 00 00 00 00 57 56 53 83 ec 10 8b 5c 24 20 0f b6 44 24
24 88 44 24 0f 8b 73 6c 8b 56 08 9c 5f fa 8b 02 85 c0 74 08 0f 0b b5 03 9c 08
27 c0 8b 44 24 28 89 02 8b 44 24 30 89 82 dc
0Kernel panic - not syncing: Fatal exception in interrupt
--- End ---
Thanks, I'm forwarding the patch you suggest to the IDE maintainers for
consideration. It seems to apply to current 2.6 head as well
as the somewhat ancient 2.6.8.
Signed-off-by: Horms [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index 1e15313..e430717 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -126,6 +126,7 @@ static const struct drive_list_entry dri
{ HITACHI CDR-8435, ALL },
{ Toshiba CD-ROM XM-6202B , ALL },
{ CD-532E-A , ALL },
+ { CD-912E/ATK , ALL },
{ E-IDE CD-ROM CR-840,ALL },
{ CD-ROM Drive/F5A, ALL },
{ WPI CDD-820,ALL },
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#339058: linux-image-2.6.14-1-686: 2.6.14 frame buffer no longer enabled in binary package
Curt Howland [EMAIL PROTECTED] wrote: Package: linux-image-2.6.14-1-686 Version: 2.6.14-2 Severity: wishlist First, thank you for all your astounding work keeping Debian the best distribution bar none. Until 2.6.14, I was able to use vga=791 for framebuffer in lilo.conf, and found the substantially larger console very useful. vga=791 no longer functions, in fact it causes the console to fail entirely. I looked in the /etc/yaird/Default.cfg and it says OPTIONAL MODULE fbcon so maybe the framebuffer has to be compiled in. Sorry I cannot be more help, I tried compiling my own 2.6.14, and got hopelessly lost even though compiling in the frame buffer did work. Could you see if this problem still exists in 2.6.14-3? As of 2.6.14 VESA_FB is no longer modular, however this turned out to mean that FRAMEBUFFER_CONSOLE needed to be manually loaded on systems that were previously using vga=... This can be fixed by telling the initrd generator to load FRAMEBUFFER_CONSOLE on boot, however as of -3 it is built into the kernel to avoid this problem. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#339719: with new udev in etch kernel hangs during boot time when loading usb in a sis motherboard
giorgiove [EMAIL PROTECTED] wrote: on a sis chipset computer, the new udev hangs during boot time giving errors regarding usb . No way to boot and with acpi=off option on I get to boot but both usb devices and ps3 port are unusable. I can command only via a ps2 keyboard. I contacted udev team but they say it's a driver-kernel problem. The only way to use computer is deinstall the new udev anfd use old hotplug. everything goes ok then. I use etch but I tried even the new kernel in sid.same results but now even hotplug gives problems. Hi, Most likely you are seeing #333052/#333522 which I believe is fixed by installing module-init-tools 3.2-pre9-4 If pain persists could you please report which version of the kernel, udev and module-init-tools you are using. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334843: Oops suddenly appearing after a video card change
In article [EMAIL PROTECTED] you wrote: Horms and Maximilian Attems, how does your discussion relate to the bugs reports you are including in CC? I thought that Considering my previous comment, this does not seems to be really relevant. was a polite, but clear enough, way to ask you to stop cross-posting your apparently off-topic discussion (if it is not off-topic, make it clear). I was confused by your initial bug report, thought that it was related to the loading of ide modules, and was offering a work around. If you feel that was off-topic, please ignore it. To get back to the subject, apparently a bugfix in hddtemp should avoid this bug to occur http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335571 Thanks, I wasn't aware that you had duplicated the bug, nor that progress had been made. It is still unclear to me if it is acceptable or not that a simple bug in a software like hddtemp can cause the kernel to segfault, especially not while it occurs since a video card change. If the kernel segfaults, its a kernel bug. Aurelien, could you elaborate a little on what the fix for #335571 was, it seems that whatever kernel code that is tickling wants fixing. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339485:
merge 339487 339485 thanks In article [EMAIL PROTECTED] you wrote: This should be merged with 339487 (typed --body option rather than --body-file) Merging as requested. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340108: linux-image-2.6.14-2-386: ALSA fails with SB16 value
tag 340108 +upstream In article [EMAIL PROTECTED] you wrote: Package: linux-image-2.6.14-2-386 Version: 2.6.14-3 Severity: normal My SB16 value cards (ISA, afaik no PNP) don't work with ALSA. The words SB16 value are litererally printed on the card. As I found out, these seem to be SB16's without a MIDI interface (but with OPL3). Hi, As this is almost certainly an ALSA bug, could you take a few moments to log your report with the ALSA maintainers, as per the instructions on: http://www.mailarchives.org/list/debian-kernel/msg/2005/09177 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#252289: general: system clock goes chaoticly causing system breakdown
tag 252289 +wontfix tag 252289 +upstream thanks Is this bug reproducable with 2.4.27-11 and 2.6.14-3 (or whatever is the latest in sid when you read this). I'm taging this as wontfix, as its assigned to 2.4.27 and the chance of a fix not requiring a significant backport seems remote. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338347: psmouse driver keeps losing synchronization
David Hugh-Jones [EMAIL PROTECTED] wrote: The only way I seem to be able to fix is: stop apmd; modprobe -r psmouse; unplug mouse; plug mouse back in; modprobe psmouse. That works some of the time. (Stopping apmd may not be necessary, I am not sure.) Hi David, this problem seems completely different to the problem that I had. Could you please post report to the upstream maintainers, Vojtech Pavlik [EMAIL PROTECTED], [EMAIL PROTECTED], CCing [EMAIL PROTECTED] Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New kernel-package 10.009 heading for experimental
Sven Luther [EMAIL PROTECTED] wrote: On Thu, Nov 10, 2005 at 03:58:54PM -0600, Manoj Srivastava wrote: On Thu, 10 Nov 2005 08:43:07 +0100, Sven Luther [EMAIL PROTECTED] said: As discussed on irc, we still need to find out why the new k-p break (or whatever you want to call it) the linux-2.6 control file mechanism, and thus we end up with missing dependencies on the linux-image packages, which break the ramdisk-tool upgrade path. Please don't upload the package to unstable until we know what is going on, and fix it, but i guess that was always your intentions. Well, as it turns out, it was not kernel-package breaking the dependency mechanism, it was the linux-2.6 control file not playing nice with dpkg-gencontrol, so the only thing holding kernel-package back is a request from the kernel team to wait until the -3 release. Indeed, and all the issues i was aware of have been solved now, so as far as i am concerned the 10.00x k-p can go in unstable, not sure if we should use it for -3 directly or not. Sorry for the confusion about this, i seriously believed you where uploading to unstable. I've been away from my desk for a few days, well other than occasionaly popping in on IRC. If I'm not deeply mistaken 2.6.14-3 is now out there, and was released using k-p 9.008.4. 10.00x seems to be in pretty good shape now, unless something nasty is lurking deeper in my INBOX. Manoj, please upload at will. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Mon, Nov 14, 2005 at 07:45:20PM -0500, Graham Knap wrote: James Bottomley [EMAIL PROTECTED] wrote: Can you try with the attached patch, which will force DV to ignore the echo buffer write tests? I'll certainly try. The kernel I was using was a prebuilt Debian kernel. I'm not sure how to rebuild it from source. Horms, if you could point me in the right direction, I'll give it a try. That depends exactly what you want to build. To just make an image for testing, upacking the tarball supplied by linux-source-2.6.14, using the config that came with linux-image-XYZ in /boot, and optionally using make-kpkg, should work. Though I think you have most of that happening. For now, I've built a kernel using the linux-source-2.6.14 package (version 2.6.14-2). It's massively stripped down so that it compiles in a semi-reasonable amount of time on this very slow PC. There isn't a great deal I can suggest in order to speed up builds, except perhaps using ccache, or trimming the config as you have done. If you need me to build stuff for you, I'm happy to oblige, though obviously there are extra email round-trips involved. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord and newer Linux kernels
In article [EMAIL PROTECTED] you wrote: [-- text/plain, encoding quoted-printable, charset: us-ascii, 33 lines --] [ Bugger, got the cdrtools-devel address wrong on the first mail. Now fixed. ] On Fri, Nov 11, 2005 at 12:53:00AM +0100, Christoph Hellwig wrote: On Thu, Nov 10, 2005 at 11:47:29PM +, Steve McIntyre wrote: In kernel 2.6.8 and later, SCSI generic commands are verified for safety. This may be a reasonable measure in some respects, but it makes effective non-root CD/DVD burning rather difficult. For best performance cdrecord, growisofs and friends may often need to send SCSI commands to drives that the kernel may neither know about nor understand. And (to add to the pain) these commands are very often vendor- or device-specific, so simply allowing those commands in the kernel will defeat the point of the verification in the first place. The whole point of the verification is to allow safe access to a selected set of raw commands for normal users. root (or rather a process that has CAP_SYS_RAWIO) can send any command. if you need unknown commands just make sure to burn as root, as everything else would be unsafe anyway. That does make it rather difficult to have any safe CD/DVD writing software - do you think it's a good idea to have end users run apps as root to burn CDs? I've read too much of the cdrecord source to be happy running that as root! :-) My thought is that it might be better to allow specific commands on specific drives, and let the local admin configure that for themselves... The whole problem is that some IOCTLS are not safe. And there is no definitive list of IOCTLs, so safe ones are added as they are known. And the others are disabled. If you have discovered ioctls which are indeed safe, then they should be added to the whitelist. As for allowing root to have a mechanism to allow users to access arbitary (unsafe) ioctls, that sounds like a can of worms to me. I have CCed the SCSI maintainers for comment. For their reference, your original post and patch, allong with the rest of this thread is at: http://lists.debian.org/debian-kernel/2005/11/msg00748.html -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338431: linux-2.6: [infrastrucutre] gencontrol.py should know how to exclude stuff from deps, add INITRD_CMD setting.
In article [EMAIL PROTECTED] you wrote: Package: linux-2.6 Severity: normal Well, this is something that came up with the desire of not using the (currently broken) initramfs-tools on alpha. We need two implementations to fix this, or at least one of them but the other seems useful too. 1) gencontrol.py should know how to handle an 'excludes' field, which will be used to remove any reference to the entries in it when generating the depends and such fields, this would be used as : arch/alpha/defines: ... excludes: initramfs-tools and the line : Depends: yaird | initramfs-tools | linux-initramfs-tool, module-init-tools (= 0.9.13) would be rewritten to : Depends: yaird | linux-initramfs-tool, module-init-tools (= 0.9.13) 2) We need support for setting INITRD_CMD prior to the make-kpkg command which creates the postinst (i thinkg the kernel-image one not sure though). This would allow to do : arch/defines : ... ramdisks: mkinitrd.yaird mkinitramfs arch/alpha/defines : ... ramdisks: mkinitrd.yaird The first one would be nice to have, we currently keep the full depend and add a conflict on alpha, but i believe the second solution is better, altough it needs k-p 10.000x. The reason why the second fix is better, is that there is really no reason to stop alpha from installing initramfs-tools, just we have to make sure not to use it by default. Agreed. I'm somewhat dubious about the need for 1) as we do have a mechanism, albeit a little tedious, to effect these kind of dependancies. And in this case at least 2) shows us that there is actually a slightly deeper problem that needs to be addresses. I'd be surprised if we really end up needing 1). -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338606: Kernel 2.6.14 break midi play in SB Live
In article [EMAIL PROTECTED] you wrote: Package: linux-image-2.6.14-1-k7 Version: 2.6.14-1 Severity: Normal In this kernel version I am unable to play midi (no sound) files with pmidi program in a SB Live Value. With the same settings, pmidi works perfectly in kernel version 2.6.12. Taking a wild guess, I'd say that this is related to the following patch, which seems to be have been added to shortly after the release of 2.6.12. http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b6b22f3815b2937f272d3666bd18665d3f7f5a8 I've CCed James Courtier-Dutton, the EMU10K1 maintainer, he can probably help rather than just stabbing in the dark as I have done. PCI report :00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] :00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) :00:13.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) :00:13.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a) :01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) Modules snd_rtctimer3152 0 snd_seq_midi9312 0 snd_emu10k1_synth 7424 0 snd_emux_synth 37632 1 snd_emu10k1_synth snd_seq_virmidi 7232 1 snd_emux_synth snd_seq_midi_emul 7424 1 snd_emux_synth snd_seq_oss35328 0 snd_seq_midi_event 7168 3 snd_seq_midi,snd_seq_virmidi,snd_seq_oss snd_seq52624 8 snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_oss,snd_seq_midi_event snd_emu10k1 123492 1 snd_emu10k1_synth snd_rawmidi25440 3 snd_seq_midi,snd_seq_virmidi,snd_emu10k1 snd_seq_device 8780 7 snd_seq_midi,snd_emu10k1_synth,snd_emux_synth,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi snd_ac97_codec 97276 1 snd_emu10k1 snd_pcm_oss54688 0 snd_mixer_oss 19776 1 snd_pcm_oss snd_pcm92168 3 snd_emu10k1,snd_ac97_codec,snd_pcm_oss snd_timer 24772 4 snd_rtctimer,snd_seq,snd_emu10k1,snd_pcm snd_ac97_bus2176 1 snd_ac97_codec snd_page_alloc 10952 2 snd_emu10k1,snd_pcm snd_util_mem4544 2 snd_emux_synth,snd_emu10k1 snd_hwdep 9184 2 snd_emux_synth,snd_emu10k1 snd55652 13 snd_emux_synth,snd_seq_virmidi,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep soundcore 9696 1 snd rtc12472 1 snd_rtctimer Thanks Waldo Cancino -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338615: psmouse should be loaded after usb-stuff
Hi, According to http://bugs.debian.org/338615 and before it http://www.ussg.iu.edu/hypermail/linux/kernel/0407.1/0862.html The psmouse driver needs to be loaded after usb (if it is going to be loaded). I'm posting this to linux-input and linux-hotplug-devel as I have no idea how this should be done. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: kernel 2.4
-sparc64-smp' Bug reassigned from package `kernel-image-2.4.26-sparc64-smp' to `kernel-image-2.4.27-2-sparc64-smp'. reassign 281511 kernel-image-2.4.27-2-sparc32 Bug#281511: kernel-image-2.4.26-sparc32: kernel paging request oops Warning: Unknown package 'kernel-image-2.4.26-sparc32' Bug reassigned from package `kernel-image-2.4.26-sparc32' to `kernel-image-2.4.27-2-sparc32'. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ABI changes on specific architectures only
Bastian Blank [EMAIL PROTECTED] wrote: [-- text/plain, encoding quoted-printable, charset: utf-8, 17 lines --] On Tue, Nov 08, 2005 at 02:28:23PM +0100, Norbert Tretkowski wrote: I switched the alpha build from gcc-3.3 to gcc-4.0 in the not yet uploaded 2.6.14-3, and Jurij said he'll also switch sparc from gcc-3.3 to gcc-4.0. 2.6.14.1 seems to need an ABI bump anyway, so go ahead. How to handle these ABI changes for specific architectures? We can't, and we never want to support that. Agreed. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: version/infrastructure separation test ...
Sven Luther [EMAIL PROTECTED] wrote: On Wed, Nov 09, 2005 at 11:07:24AM +0900, Horms wrote: Yes and no. The problem is that basically we have two different things, the first one is the build infrastructure, which should really not be all that different for each version, and which there is really no need to have a branch per version from. On the other hand, the per version configs and patches cannot be done without, and thus should be hold in a different branch each. This indeed adds some complexity (rather minimal though if done right), but on the other hand it will keep the branching to the absolute minimum, and weren't you the one complaining about too many branches ? Yes, though it doesn't decrease the number of branches, the number of non-infastructure branches remains the same, and additionally, we have a (sometimes branched) set of infastruture somewhere else. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14.1
Bastian Blank [EMAIL PROTECTED] wrote: [-- text/plain, encoding quoted-printable, charset: utf-8, 11 lines --] Hi folks 2.6.14.1 is released. It changes the ABI of procfs. Thanks, I'll work on getting the change into 2.6.8 and 2.4.27 as neccessary. There is already an entry for this in dannf's patchdir I assume someone has bumped the ABI for 2.6.14. Now, who will be the first to tell us that about CVE-2005-2709 that we already know about? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CVE-2005-2709 - Another local DoS in the kernel
Moritz Muehlenhoff [EMAIL PROTECTED] wrote: Hi Horms and the rest of debian-kernel, Al Viro has found another local DoS vulnerability in the kernel; one can trigger an oops in sysctl. The fix is the only code change in 2.6.14.1 and has been assigned CVE-2005-2709. Thanks, we're already on the case. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CVE-2005-2709 - Another local DoS in the kernel
Sven Luther [EMAIL PROTECTED] wrote: On Wed, Nov 09, 2005 at 03:22:59PM +0100, Sven Luther wrote: On Wed, Nov 09, 2005 at 02:48:10PM +0100, Moritz Muehlenhoff wrote: Hi Horms and the rest of debian-kernel, Al Viro has found another local DoS vulnerability in the kernel; one can trigger an oops in sysctl. The fix is the only code change in 2.6.14.1 and has been assigned CVE-2005-2709. Sadly, Manoj uploaded an untried kernel-package version to unstable, which broke kernel builds, this is currently being worked on, but at this time there has not been a confirmed fix yet, so it is not possible to upload packages containign 2.6.14.1 which fix this CVE and was mentioned here a coupe of hours ago. The patches are already in our SVN repo though, so you could try building them yourself with the older kernel-package, or wait a bit. Well, i was wrong Manoj uploaded k-p 10.008 to experimental, i was confunded by the fact that he told us on irc that he was uploading to unstable, which was probably a typo on his part, so forget anything about the above. I guess we can upload at will then. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#336471: still appears broken.
Jonas Smedegaard [EMAIL PROTECTED] wrote: CONFIG_FRAMEBUFFER_CONSOLE=y --- CONFIG_FRAMEBUFFER_CONSOLE=m Well - not sure either if it's the same bug, but whatever. If happening that late in the game it seems to be kernel related - not ramdisk-related, so reassigning... The abouve FRAMEBUFFER change should appear in 2.6.13-3. Perhaps it will help. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new kernel-package breaks official linux-2.6 kernel builds, should not propagate to testing.
Manoj Srivastava [EMAIL PROTECTED] wrote: 1. the missing config caues manuals not to build ,[ Manual page make-kpkg(1) ] | DESCRIPTION | This manual page explains the Debian make-kpkg utility, which is | used to create the kernel related Debian packages. This utility | needs to be run from a top level Linux kernel source directory, | which has been previously configured (unless you are using the | configure target). ` Previously been configured == has a .config file. This problem has been resolved by adding --config defconfig to the make-kpkg invocation that was failing. Its in SVN, and should appear in 2.6.14-3. However, as some targets, which don't need a .config, have worked in the past, I'm not sure that I see compliance with the above description as a good justification for making invocations that worked (flawlessly) in the past fail. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build while creating kernel-headers package
Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, It was remarked on IRC that a build with the new kernel-package does a full build even when compiling kernel-headers, and this behaviour was different from the kernel-package in Sid. Now, since make-kpkg only calls the top level makefile with a very limited set of targets, namely, one of the configure targets, a build, or an install target, one can figure (without delving into code or looking at logs, like I did) that all we used to do before was call make oldconfig or similar before creating a kernel headers package. So, I did a build with a modified new kernel package, and did a debdiff on a kernel headers package created after a full build, with another with just a make oldconfig; and I discovered that not doing a build creates a kernel header package missing things like include/linux/compile.h and Module.symvers. So, while it is true that the behaviour has changed, it is not a regression in kernel-package, as has been stated, it is a bug fix. Full debdiff below. I wonder, if this deficiency was know, and the official headers packages had work arounds, why was this not brought to the attention of the kernel-package maintainer? This deficiency has left the users of kernel-package down, and I am sorry about that. I would have thought caring for end users would have been more important than turf wars. Firstly, its not about turf wars. If you wish to attack it from that angle, then I shall not participate in the discussion any further. The finger pointing situation is, frankly, rediculous. The headers package has often been broken, so it wouldn't surprise me if things are missing. The method that is used to create them involves a combination of kernel-package and a postinst, which basically uses find. This is available in SVN. And the results are examinable in the packages available on debian.org. I would certainly welcome anyone looking into the headers packages and finding deficiencies, and better still solutions. As I said earlier in the week, though perhaps not on this channel, I am more than happy for the common/flavour headers splitting that the the kernel-team's packaging does moved into kernel-package. As I said above, its long been a source of pain and frustration. I encourage you to play with the linux-2.6 packages and explore what in there is broken, how we could be using kernel-package better, and what logic might be best moved into kernel-package. I particularly encourage this in the area of the headers packages. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298766: gnome-applets: battstat don't show correct values at startup on some hardware
On Wed, Mar 09, 2005 at 09:21:19PM +0100, Marco Innocenti wrote:
Battstat on my laptop (Toshiba P20-311) don't show the correct value
of the charge of the battery at startup. I have to wait several
minutes to get it. I've made some test and discoveded that cat
/proc/acpi/battery/BAT1/* give the wrong value the first few time.
So I patched battstat_applet.c to get acpiinfo 10 times at startup.
It works for me and don't think would harm others.
[snip]
Hi Marco,
As discussed breifly on http://bugs.debian.org/298766, this is probably
a problem better solved in the kernel than in user-space. I have CCed
the ACPI maintainers on this message for their consideration, including
your patch, which is below.
--
Horms
diff -r -u gnome-applets-2.8.2.orig/battstat/battstat_applet.c
gnome-applets-2.8.2/battstat/battstat_applet.c
--- gnome-applets-2.8.2.orig/battstat/battstat_applet.c 2005-03-09
20:58:00.302510520 +0100
+++ gnome-applets-2.8.2/battstat/battstat_applet.c 2005-03-09
17:24:47.0 +0100
@@ -232,7 +232,7 @@
#ifdef __linux__
struct acpi_info acpiinfo;
-gboolean using_acpi;
+gboolean using_acpi, started_now=TRUE;
int acpi_count;
#endif
@@ -310,6 +310,14 @@
* Updated by David Moore [EMAIL PROTECTED] 5/29/2003 to poll less and
* use ACPI events. */
if (using_acpi acpiinfo.event_fd = 0) {
+/* By Marco Innocenti [EMAIL PROTECTED] 09/03/2005
+ * Some hardware need several requests to warm up and give correct
results. */
+if (started_now) {
+ started_now=FALSE;
+ for (acpi_count=1; acpi_count 10; acpi_count++) {
+ acpi_linux_read(apminfo, acpiinfo);
+ }
+}
if (acpi_count = 0) {
/* Only call this one out of 30 calls to apm_readinfo() (every 30
seconds)
* since reading the ACPI system takes CPU cycles. */
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.6.14-3 Release [includes 2.6.14.1/CVE-2005-2709]
Hi, I'd like to get people's opinion on releasing 2.6.14-3. Here are some factors: * There are a number of changes in SVN, including 2.6.14.1/CVE-2005-2709 * The zero length udp problem has not been solved in 2.6.14.1, and this might mean that 2.6.14.2 comes out soon. Or we could just crab the patch, IIRC its a one or two-liner. http://permalink.gmane.org/gmane.linux.kernel/346872 * Jurij tells me there are some sparc problems he is working on, but they should be sorted shortly. * Manoj is keen to get kernel-package 10.00X (X probably = 9) into unstable. Right now 9.008.4, which we have used before is there. If we are going to release in the next few days, I'd rather Manoj hold off. But if its going to be longer, then we probably have enoughy scope to debug any 10.00X and get kernel-package re-released before we make our relese. Comments, please. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new kernel-package breaks official linux-2.6 kernel builds, should not propagate to testing.
Manoj Srivastava [EMAIL PROTECTED] wrote: With the new, streamlined, internal dependency mechanisms, it is actually going to be a big kludge not to require the configure target in the dependency path (since the dependency path has been separated from actual make commands for targets). Thats fine, now we know that we must provide a .config to call make-kpkg, whereas previously we were occasionally getting away without it isn't a bit deal. Thanks for clarifying why maintaining the old (not to specficiation) behaviour is a pain. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: patch tracking dir in svn
dann frazier [EMAIL PROTECTED] wrote: hey, We've been tracking patches (mostly security) across kernel streams under people/ dirs in svn. Since this procedure isn't really specific to an individual, I'd like to move this out of people. My current plan is to move it to /patch-tracking - unless anyone has a better suggestion? Fine by me. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, Nov 08, 2005 at 11:36:13AM +0100, Sven Luther wrote: On Tue, Nov 08, 2005 at 11:19:36AM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 8 Nov 2005 11:31:10 +0900 Horms [EMAIL PROTECTED] wrote: Waldi, can you coment on how to add a recommends to images on a per-flavour basis? Isn't per-flavour control hints one of the new features of the soon-to-be-in-sid kernel-package? If so, I suggest using that instead of bloating linux-2.6 packaging unnecessarily. linux-2.6 packaging already has quite nice per-flavour dependency handling, thank you. Either way, is it possible to add recommends on a per-flavour basis, and if so, how? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ABI changes on specific architectures only
On Tue, Nov 08, 2005 at 02:52:15PM +0100, Sven Luther wrote: On Tue, Nov 08, 2005 at 02:28:23PM +0100, Norbert Tretkowski wrote: Hi, I switched the alpha build from gcc-3.3 to gcc-4.0 in the not yet uploaded 2.6.14-3, and Jurij said he'll also switch sparc from gcc-3.3 to gcc-4.0. How to handle these ABI changes for specific architectures? I think if you do it together, the easiest way is probably to do a ABI++ for everyone. I think that as it stands ABI++ for everyone is the only sane solution. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
On Tue, Nov 08, 2005 at 09:01:24AM -0600, Manoj Srivastava wrote: On Tue, 8 Nov 2005 14:26:17 +0100, Sven Luther [EMAIL PROTECTED] said: On Tue, Nov 08, 2005 at 08:30:53PM +0900, Horms wrote: On Tue, Nov 08, 2005 at 11:36:13AM +0100, Sven Luther wrote: On Tue, Nov 08, 2005 at 11:19:36AM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 8 Nov 2005 11:31:10 +0900 Horms [EMAIL PROTECTED] wrote: Waldi, can you coment on how to add a recommends to images on a per-flavour basis? Isn't per-flavour control hints one of the new features of the soon-to-be-in-sid kernel-package? If so, I suggest using that instead of bloating linux-2.6 packaging unnecessarily. linux-2.6 packaging already has quite nice per-flavour dependency handling, thank you. Would it not be nice to push it down into the underlying tool, so that even endusers get a nicely hinted per flavour images, as appropriate? I mean, we cater to all users, not just those that use official Debian kernels. Don't we need to handle the control file ourselves because we make multiple make-kpkg invocations which all come together to form a single source package? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: version/infrastructure separation test ...
On Tue, Nov 08, 2005 at 04:48:04PM +0100, Sven Luther wrote: Hi all, As you may have noticed, i did some tests to illustrate my proposal to split the infrastructure out of the real packaging, which you can find at : svn://svn.debian.org/svn/kernel/dists/test The layout is as follows : linux/infrastructure/debian - contains the common stuff. linux/versions/version/debian - contains : arch, patches-debian, patches-arch I have added symlinks from each version to the infrastructure stuff, but ideally we would have a way to handle this better. I am thinking of an export debian/control rules, which would do the right thing and prepare an uploadable directory, doing svn export, unpacking the upstream tarball and pruning it or using the debian dir and so on. The one problem which needs a bit more though would be the changelog field, which i didn't know where to put, as there are the per-version changes and the infrastructure changes, maybe we need a Changelog.infrastructure or something like this, and that we should also pull in the k-p changelog at built time. Comments on this are welcome. Another idea would be to have the following layout : linux/debian - all the common stuff. linux/debian/2.6.12 - the 2.6.12 stuff. linux/debian/2.6.14 - the 2.6.14 stuff. All in a single place, and we can just exclude the not-needed directories from being included in the debian/rules export target. Hi Sven, While I think keeping common code common is important, isn't this something our version control system should be doing for us with branches and merges? I'm concerned that your approach adds extra complexity to achive much the same goal. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
Sven Luther [EMAIL PROTECTED] wrote: On Tue, Nov 08, 2005 at 12:53:47PM -0600, Manoj Srivastava wrote: On Wed, 9 Nov 2005 00:22:23 +0900, Horms [EMAIL PROTECTED] said: Don't we need to handle the control file ourselves because we make multiple make-kpkg invocations which all come together to form a single source package? I am planning on constructing the control file from bits even in the default install so that the uml and xen images do not show up in the control file but are never built, and we get all the package exists in control file but not in changes warnings. Perhaps there can be a set of mini-control files concatenated together into a control file before it is read by Make? I'm still not entirely sure that I understand how this would fit into what linux-2.6 is doing. Perhaps if I breifly explain what it does you can fill in the gaps. First up there are templates in templates/ and defitions the architectures, sub-architectures and flavours there are in arch/. These definitions are growing to include information about dependancies, kernel header directories and stuff like that. arch/ also includes configure fragments. Before dpkg-buildpackage is run, a script is run which produces a control file that contains all the packages for all architectures, this is built using the information in templates/ and arch/. Simiarly, rules.gen, which rules drives to produce the packages on each architecture is produced. Its combination of rules.gen and control which allows architectures, sub architectures and flavours to be added and removed in a flexible manner, just by manipulating arch/ At run time, some additional mangling occurs to produce the .config files based on the fragments in arch/ In a nuthsell kernel trees are unpacked, the appropriate .config is produced and placed in the tree and make-kpkg is called. I should note, that I didn't actually write the system, and I'm still learning how to drive it. Waldi and Dilinger know a lot more about it, perhaps they can fill in some of my gaps. Manoj, we already do this, see the templates dir and bin/gencontrol.py. I told you that earlier already. Is there really any need to be so aggressive? Yes there is logic in there, and yes its coming along quite nicely. But to be honest, the more logic we can push back to kernel-package, the less we have to worry about. And I'm all about worrying less. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337914: linux-2.6: SOFTWARE_SUSPEND needs PM on ppc
Package: linux-2.6 Severity: normal Tags: patch As a work around I am going to disable SOFTWARE_SUSPEND on effected flavours, so far powerpc/miboot: It seems that CONFIG_PM needs to be set for CONFIT_SOFFTWARE_SUSPEND to compile cleanly. For startes, swsusp_arch_suspend needs swsusp_save. Sould SOFTWARE_SUSPEND required PM, or should i add some strategic #ifdef CONFIG_PM to the code. This is 2.6.14, but i think its present in linus' current git. arch/ppc/kernel/built-in.o: In function `swsusp_arch_suspend': : undefined reference to `swsusp_save' arch/ppc/kernel/built-in.o: In function `swsusp_arch_resume': : undefined reference to `pagedir_nosave' arch/ppc/kernel/built-in.o: In function `swsusp_arch_resume': : undefined reference to `pagedir_nosave' arch/ppc/platforms/built-in.o: In function `pmac_late_init': : undefined reference to `pm_set_ops' -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686-smp Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) (ignored: LC_ALL set to ja_JP.eucJP) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337713: [PATCH] Null pointer access in nf_queue()
On Sun, Nov 06, 2005 at 12:02:37AM +0200, Torok Edwin wrote:
Package: linux-image-2.6.14-1-k7
Version: 2.6.14-1
Severity: important
I have got a kernel panic, here it is: (I hand-copied it, since it wasn't
saved to disk)
EIP: 0060: [c02b2516] Not tainted VLI
EFLAGS: 00010286 (2.6.14-1-k7)
EIP is at nf_queue+0x16/0x240
eax: ebx: 0001 ecx: edx: 0002
esi: dece0920 edi: c03a3aa8 ebp: c0277e70 esp: cf165e78
ds: 007b es: 007b ss: 0068
Process sh (pid:5278, threadinfo=cf164000 task=dc5b4ab0)
Stack: cf165f00 dae29000 c0277e70 0001 cf165f00 c03a3aa8
c0277e70
c02b1f7c cf165f00 dece0920 0002 0001 dae29000 c0277e70
dece0920 da641b40 da54bcde cc318abc c0277c10 0002
Call Trace:
[c0277e70] ip_local_deliver_finish+0x0/0x230
[c0277e70] ip_local_deliver_finish+0x0/0x230
[c02b1f7c] nf_hook_slow+0x0c/0x110
[c0277e70] ip_local_deliver_finish+0x0/0x230
[c0277c10] ip_local_deliver+0x60/0x2c0
[c02783f7] ip_rcv+0x357/0x540
[c0258ed8] netif_receive_skb+0x238/0x2e0
[c0258fec] process_backlog+0x6e/0xf0
[c02590f7] net_rx_action+0x87/0x140
[c0120a33] __do_softirqq+0x43/0x90
[c012caa6] do_softirq+0x26/0x30
[c010528e] do_IRQ+0x1e/0x30
[c0103ada] common_interrupt+0x1a/0x20
Code: c0 75 ec e9 bd e5 e6 ff 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 57 56
53
83 ec 10 8b 54 24 2c 8b 74 24 28 8b 04 9b c0 42 3a c0 8b 38 85 ff 0f 84 96
01
00 00 86 44 24 2c 8b 7c 24 2c c7 44 24
0Kernel panic - not syncing: Fatal exception in interrupt
Bug reproducible: always.
Steps to reproduce: Start fireflierd
Result: kernel panic
What fireflierd does is try to communicate with the ip_queue module, that
isn't loaded.
If I load the module everything is ok.
On kernel version 2.6.12 I got an error message from fireflierd, but the
kernel didn't panic.
If you need further info, tell please tell me how to provide it.
If you need the program fireflierd, just tell me, I can upload it somewhere
(binary/source), it is a GPL program,
that's going to be released soon.
Thanks,
I did some disasembling fun and games, and I'm pretty sure the patch
below will fix your problem. I'll fire of a build, I'd be greateful if
you could test it.
According to the trace above, pf (%edx) is 2, however, it seems that
queue_handler[pf] is NULL. I would guess that it has been unbound using
netlink (nfqnl_recv_config(), case NFQNL_CFG_CMD_PF_UNBIND:)
Or in other words, queue_handler[pf] can be set to NULL from userspace,
but it is accessed without checking to see if it is NULL.
I'm taking a few leaps of faith here, so my logic could be out.
Here is the a portion of the disasembled code if anyone cares:
0xc02b2500: push %ebp
0xc02b2501: push %edi
0xc02b2502: push %esi
0xc02b2503: push %ebx
0xc02b2504: sub$0x10,%esp
0xc02b2507: mov0x2c(%esp),%edx
0xc02b250b: mov0x28(%esp),%esi
0xc02b250f: mov0xc03a42c0(,%edx,4),%eax
0xc02b2516: mov(%eax),%edi
0xc02b2518: test %edi,%edi
0xc02b251a: je 0x412b26b6
Signed-off-by: Horms [EMAIL PROTECTED]
diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index d10d552..d3a4f30 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -117,7 +117,7 @@ int nf_queue(struct sk_buff **skb,
/* QUEUE == DROP if noone is waiting, to be safe. */
read_lock(queue_handler_lock);
- if (!queue_handler[pf]-outfn) {
+ if (!queue_handler[pf] || !queue_handler[pf]-outfn) {
read_unlock(queue_handler_lock);
kfree_skb(*skb);
return 1;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Care to comment on plan for module building?
On Mon, Nov 07, 2005 at 03:08:30PM +0100, Sven Luther wrote: On Mon, Nov 07, 2005 at 02:29:52PM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Eduard (and cc kernel list), I have put together a draft for future kernel module handling, based on a discussion at the kernel list and spiced up with a few thoughts of my own. It is available here: http://wiki.debian.org/KernelModulesPackaging Could you please have a look and tell me what you think (or perhaps simply edit that wiki page directly)? Notice that you again sided with Manoj, depite him never providing any arguments in favour of not using the standard upstream mandated build symlink, and since both of you prefered resulting to insults instead of reasoned argumentations, i want to have no plan with any such plans as you have, so go ahead, and break everything for all i care. I'm reluctantly entering this discussion, as it seems to be at an impass to say the least. I must say that I really stuggle to understand why everyone is so up-tight about this issue. I know there have been words said in this thread and on IRC that might have been better not said, but really, what is the issue? As far as I can see, the issue is that we need to have a better framwork for out-of-tree module support. There is the problem of the build/ link, which has historical behaviour that dates back quite a number of years. Its current behaviour is not entirely ideal from the point of view of users who only install kernel-header packages. But it is quite useful for users who roll their own kernel packages. And due to certain packaging limitations, it is somewhat tedious to make it both have the historical behaviour that many users might expect, and reach the expections of users with only kernel-header packages installed. To be honest, its probably best to stear clear of that link as much as possible when defining how modules are packaged. As for the wiki entry. I take it to be a work-in-progress document, rather than doctrine. I personally don't find much at fault with what it says. But I haven't been looking into the module build problem much. I really think we should focus our energies on finding a module build framework that works for packagers and uers. Rather firing harsh words at each other. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging of modules which are in official kernel
On Mon, Nov 07, 2005 at 12:32:23PM +0100, Sebastian Ley wrote: Hi, I am the maintainer of the ipw2100 module package. That module is now included in the kernel as of version 2.6.14. For the time being I want to keep the package and decide later whether to drop it. The question is however, where to put the modules such that they do not conflict with the modules from the kernel. The related bugreport is #337920. I just want to verify that the submitter's solution is the right way to go. Please CC me on replies, as I am not subscribed to this list. That seems reasonable to me. Can others comment? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: I can't build Modules.debs with linuxheaders 2.6.12-1-k7
On Mon, Nov 07, 2005 at 02:23:41PM +0100, Sébastien Platel wrote: I'm trying to compile nvidia kernel driver by getting source from debian repository, decompressing it using tar -zxvf XXX and then using cd /usr/src/linux-headers-2.6.12-1686 make-kpkg modules_image since then I found another way to compile this module following this document http://www.coagul.org/article.php3?id_article=346 (as you can't read french I can describe it quickly saying that after a few environnement variables setup and cd into the module source the line debian/rules binary_modules compiles the debian package I think that it is fair to say that the problem is not that the modules don't compile, but that its not entirely obvious how to make them compile. The kernel-team is currently working on making this situation better, however as you might note if you scan debian-kernel, we are far from consensus on the issue. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-package (10.005) heading to experimental
On Mon, Nov 07, 2005 at 06:51:09PM +0100, Sven Luther wrote: On Mon, Nov 07, 2005 at 10:47:12AM -0600, Manoj Srivastava wrote: Hi, I think this fixes all issues that had been reported to me. 10.006 should head out to Sid tonight, or tomorrow. Which will probably break the kernel builds, no thanks. Please refrain from uploading to unstable until at least there is a decision taken on the build symlink issue. Sven, I don't believe that 10.006 changes the build symlink behaviour from what is currently in sid. So that really is an othogonal issue. Manoj, as I mentioned just now on IRC, I am seeing an issue with ppc builds from trunk/experimental using 10.004. I'd like a chance to look through that more throrougly before you upload. Its probably not a kernel-package problem, but if it is, it could put the kernel-team in a bit of a pickle with regards to and releases in the near future. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should
reassign 278729 linux-2.6 retitle 278729 some i386 images should recommend libc6-i686 thanks On Mon, Nov 07, 2005 at 04:58:36PM +, Richard Burton wrote: 2.6.8 is frozen solid for sarge. IF there is interest in having this added for the etch kernels, can you please reasign it to linux-2.6 I think it should become a permanent addition to all 686 class kernels going forward, but I don't mind what point that starts at - unstable would be fine for me, but etch would be useful more widely. I wouldn't expect anything to change in sarge at this stage in it's release. I think Etch would be an appropriate place for this. Though as I mentioned earlier, it requires some slight reengineering of the build scripts, if I'm not mistaken. Waldi, can you coment on how to add a recommends to images on a per-flavour basis? I'm afraid I don't know how to reassign a bug in BTS though, so I can't do that. IF your are interested, that is covered on http://bugs.debian.org, but breifly, CC [EMAIL PROTECTED] and start the message as I have above. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330583: Problem solved
On Mon, Nov 07, 2005 at 10:59:50AM +0100, Boris Kleibl wrote: Uff, I solved the problem, but what happened? Lots of things changed between 2.6.12 and 2.6.14. If you are really interested you could hunt through the changelogs, patches and git-commits. But its probably enough just to know if it is fixed in 2.6.14-2. Is that the case? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337713: [netfilter-core] [PATCH] Null pointer access in nf_queue()
On Mon, Nov 07, 2005 at 09:55:56AM +0100, Harald Welte wrote: On Mon, Nov 07, 2005 at 05:39:53PM +0900, Horms wrote: I did some disasembling fun and games, and I'm pretty sure the patch below will fix your problem. I'll fire of a build, I'd be greateful if you could test it. Sorry, Horms, you must have missed my previos fix (that does exactly the same). I've already posted it to netdev, and IIRC, Arnaldo has merged it for net-2.6.15. Sorry for not Cc'ing you with the fix, it seems like I only reported back to bugzilla :( No problem, it would have saved me some hunting, but actually it was quite fun. Glad to hear the problem is fixed. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
code = 0x1 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 sd 0:0:0:0: SCSI error: return code = 0x1 end_request: I/O error, dev sda, sector 0 Buffer I/O error on device sda, logical block 0 unable to read partition table Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 /bin/cat: /sys/block/sda/sda2/dev: No such file or directory Waiting 1 seconds for /sys/block/sda/sda2/dev to show up /bin/cat: /sys/block/sda/sda2/dev: No such file or directory Waiting 2 seconds for /sys/block/sda/sda2/dev to show up /bin/cat: /sys/block/sda/sda2/dev: No such file or directory Waiting 4 seconds for /sys/block/sda/sda2/dev to show up /bin/cat: /sys/block/sda/sda2/dev: No such file or directory Waiting 8 seconds for /sys/block/sda/sda2/dev to show up /bin/cat: /sys/block/sda/sda2/dev: No such file or directory Waiting 16 seconds for /sys/block/sda/sda2/dev to show up /bin/cat: /sys/block/sda/sda2/dev: No such file or directory Device /sys/block/sda/sda2/dev seems to be down. Debugging opportunity, type ^D to continue. /bin/dash: can't access tty; job control turned off # -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337045: linux-image-2.6.14-1-686: I hate to me too, but me too
On Thu, Nov 03, 2005 at 08:28:47AM -0500, Christian Weeks wrote: I didn't think the module build was the problem either. You're right though- my laptop is a Dell D600 latitude, with a 1.6 GHz Centrino chipset. One thing I did notice is that it's using the generic ide chipset module, rather than one for my laptop. I will verify that this is the same with the 2.6.12 fallback kernel, but I wonder if maybe it's that it tries a different module for the ide chipset? Mind you, I was also reading bug #333052, and I wonder if this problem is related to that problem- they both seem like race problems to me. I stronly suspect so. A proposed fix has been incoporated into module-init-tools 3.2-pre9-4, could interested parties please test this problem against that release? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333522#msg132 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337089: linux-image-2.6.14-1-powerpc: add CONFIG_TCP_CONG_BIC=y
On Sat, Nov 05, 2005 at 07:24:41AM +1300, Ian McDonald wrote: But Debian .config has CONFIG_TCP_CONG_BIC=m (CONFIG_TCP_CONG_*=m) which makes NewReno default. So this is like a regression. I'd like debian kernel to have CONFIG_TCP_CONG_BIC=y provided that one can easily switch to another algorithm (using /proc/sys/net/ipv4/tcp_congestion_control). could someone please comment on what a good default congestion algorithm setup for distribution kernels is? If you want BIC as default then do as suggested here. My personal opinion is that is the correct thing to do for a standard distribution. Thanks, the suggestion above will be incporated into the next release. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Fri, Nov 04, 2005 at 01:51:24AM -0500, Joey Hess wrote: Horms wrote: I don't have a particular problem with disabling those drivers from the build. But the d-i guys might. I've CCed them for comment (and dropped the netdev CC). No d-i udebs contain ipw2200 or ieee80211. The system does allow building udebs containing externally packages kernel modules, although we've not done that yet, partly because externally packages kernel modules rately seem to be built in time to keep up with new releases of the debian kernels.. Thanks for the clarification. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
[dropping debian-boot from CC, they've indicated this isn't a packaging issue for them at this time] Hi, Sorry for the confusion surround this, I was not at all aware of the somewhat special state of ieee80211/ipw2200 upstream. Let me answer some questions, now I have done a little bit or research. Note these are the answers to the best of my knowledge, which is limited. If you know more, please add your knowledge below. 1. Why is ipw2200 so out of date in Debian's 2.6.14? ipw2200 is out of date in Debian's 2.6.14 because it is out of date in Linus' 2.6.14. I have been told by several sources that this is because of Intel not pushing the driver into the upstream tree untill it has gone through some certification process. Or at the very least, its fair to say that Intel are not pushing changes upstream as fast as a lot of people might like. So in short, there are newer versions of the driver floating around than what is in 2.6.14. 2. Why is ipw2200 in Debian's 2.6.14 source but not compiled. As I undestand it, the ipw2200 driver requires some non-free firmware to run. The firmware is not embeded in the code, so there is no problem with distributing it. But the driver isn't particularly useful (perhaps dosn't work at all?), so it isn't compiled. 3. Can you disable the ieee80211/ipw2200 drivers in 2.6.14 Unless I am very much mistaken, they are disabled. 4. Can you mangles the headers to make compilation of ieee80211-source and/or ipw2200-source easier? Given the unusual standing of these drivers, that is, they really are out of date in Linus' tree because the developers aren't pushing updates, I think we can consider a departure from the usual policy of only accepting upstream (that is Linus') changes. My prefered option would be a minimal patch to allow ieee80211-source and ipw2200-source to compile sensibly. However, if someone wants to maintain a backport of ipw2200/ieee80211 as a patch included in linux-2.6, then I think we should consider that. My main reservation there is that it might hold up releases. For insance, are we confident that updates to ipw2200/ieee80211 will be ready the day Linus releases 2.6.15? Also, someone needs to take responsibility for this task. Without that its going to end up a s broken patch in the tree. Ultimately the best option is to get newer versions of these drivers into Linus' tree. If there is any way that Debian can help with that, then thats help that should be given IMHO. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote: You ([EMAIL PROTECTED]) wrote: I've encountered the problem with 2.6.14 kernels: they are shipped with ancient version of ipw2200 drivers (1.0.0 while current version is 1.0.7) and ancient version of ieee80211 subsystem (copyrighted as 2004, so also outdated). This breaks compilation of module from ipw2200-source package (because it links against in-kernel ieee80211). H I assume the problem you are seeing is a headers problem. Ah, yes. The other problem is two copies ipw2200.ko ieee80211*.ko modules being installed: the ones included in kernel and others compiled as external modules. I suppose this may lead to the problems with depmod. Is there way to modularize builds to exclude ieee80211 or just disable it (along with ipw2200) because it is outdated and current vesion is shipped in ieee80211-source package? H Probably the best place to start is to ping netdev to find out if H there are any plans to update IPW2200 in Linus's tree. I've CCed H that list, hopefully someone can shed some light on this. So, having in mind the two levels of 'stablenesss': kernel 'stableness' and modules 'stableness' :) we should find the way to exclude discussed modules from the build, because in-kernel versions will always be, erm..., slightly (1.0.0 is mentioned only as 'stone age' in the mailing list of ipw2200 developers) outdated due to fact integration and testing gets some time in upstream kernels. I propose just to disable compilation of this drivers: everyone will be able to compile the recent version using ipw2200-source we provide. I don't have a particular problem with disabling those drivers from the build. But the d-i guys might. I've CCed them for comment (and dropped the netdev CC). -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 02, 2005 at 04:26:21PM +, Christoph Hellwig wrote: On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote: So, having in mind the two levels of 'stablenesss': kernel 'stableness' and modules 'stableness' :) we should find the way to exclude discussed modules from the build, because in-kernel versions will always be, erm..., slightly (1.0.0 is mentioned only as 'stone age' in the mailing list of ipw2200 developers) outdated due to fact integration and testing gets some time in upstream kernels. I propose just to disable compilation of this drivers: everyone will be able to compile the recent version using ipw2200-source we provide. The kernel drivers aren't stable but obsolete. Because of that ever distribution that supports it's users must patch in a more recent one, which is what we should do for debian aswell. It's a pity the braindead Intel policies don't allow us to have an uptodate driver in mainline. Christoph, do I take that comment to mean that upstream can't update the drivers but Debian can? And if so, do you recommend updating Debian's kernel packages, or putting the updates elsewhere? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sid linux-2.6 in SVN (Was: linux-2.6_2.6.14-2_hppa.changes ACCEPTED)
On Thu, Nov 03, 2005 at 09:34:46PM +0100, Christian T. Steigies wrote: What is this email address? Christian T. Steigies [EMAIL PROTECTED] I have never used that, I don't even know that machine... Sven, you should fix your mail client. On Thu, Nov 03, 2005 at 08:32:14AM +0100, Sven Luther wrote: On Wed, Nov 02, 2005 at 03:35:02PM -0800, Debian Installer wrote: Accepted: linux-headers-2.6-32-smp_2.6.14-2_hppa.deb Cool, this means we are only missing m68k and the two mips/mipsels. Christian, can you give a fast status update of the m68k problem ? Did Roman start the merge ? I did not see any commit to the apus tree also, so i have some doubts. Yes, there were some commits, I haven't tried building a kernel with those fixes yet. But the weekend is approaching... Christian, just a heads up. The linux-2.6 in sid is, as of yesterday, in sid/linux-2.6. This is what was up until yesterday trunk/linux-2.6. Don't shoot the messanger :) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333522: linux-image-2.6.14-1-686-smp: even manual modprobes now fail
On Wed, Nov 02, 2005 at 03:16:46PM -0800, Paul Traina wrote: Please ignore/delete the comments about snd_intel8x0, that is a totally unrelated bug. I tried Rusty's proposed fix for modprobe.c (in bug 333052) and it solves the problem reported in 522 and 333052 for me (running on a stock linux-image-2.6.14-2 with initramfs made by initramfs-tools). I believe that the problem still remains at boot time because root is read-only, and modprobe's locks require write access. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337089: linux-image-2.6.14-1-powerpc: add CONFIG_TCP_CONG_BIC=y
On Wed, Nov 02, 2005 at 05:24:50PM +0100, Benoît Dejean wrote: Package: linux-image-2.6.14-1-powerpc Version: 2.6.14-1 Severity: normal Hi, Linux 2.6.14 used to have every TCP congestion algorithms as builtins but NewReno + BIC was default. Linux 2.6.14 has splitted these features into modules. But default remains NewReno + BIC accordint to CONFIG_TCP_CONG_ADVANCED help message : Nearly all users can safely say no here, and a safe default selection will be made (BIC-TCP with new Reno as a fallback). And indeed NewReno+BIC is a good and safe default. Much better than NewReno But Debian .config has CONFIG_TCP_CONG_BIC=m (CONFIG_TCP_CONG_*=m) which makes NewReno default. So this is like a regression. I'd like debian kernel to have CONFIG_TCP_CONG_BIC=y provided that one can easily switch to another algorithm (using /proc/sys/net/ipv4/tcp_congestion_control). Hi Netdev, could someone please comment on what a good default congestion algorithm setup for distribution kernels is? Thanks -- Horms
Re: udev issue
On Tue, Nov 01, 2005 at 12:36:18PM +0100, Sven Luther wrote: On Tue, Nov 01, 2005 at 11:05:51AM +0100, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: There are some missing symbols in some modules (usb ones here, but maybe others), and running depmod fixes it, No, it does not. Please read the full #333052 and #333522 bugs. Well, it did for me (the usb stuff on powerpc), but then this is maybe another issue ? Sven, I think the problem Marco is talking about is a real bug. He and Rusty are trying to figure out a solution. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updated Howto needed: How to compile a kernel like etch's.
On Tue, Nov 01, 2005 at 09:47:44AM +, Nick Hill wrote: I have tried and failed to find a howto which will fill my need: I need a howto which gives the steps, package names and repositories to 1) Build a kernel just like the binary distribution in testing/unstable. apt-get source linux-2.6 cd linux-2.6-X.Y.Z-N dpkg-buildpackage [-B] [-us] [-uc] [-frakeroot] ... Thats eactly how I make kernels for uploading, If I already have the source. 2) Build as 1) above but be able to apply/remove patches during the build process The patches are automatically applied and unapplied. If you want to add or remove patches, I would recommend doing the following between the cd and dpkg-buildpackage commands above. 1. Editing the debian/changelog to create your own version. Say, 2.6.14-2nh0 If you run dch -i it will do most of the work for you. I believe it is in the devscripts package 2. Put any new patches in debian/patches-debain Please note that the filename of patches must end in .patch e.g. cp /tmp/blah.diff debian/patches-debain/blah.patch 3. Create a series file that matches the name of your version in debian/patches-debain/series. Inside, list one per line each patch you want to add or remove. e.g. echo + blah.patch debian/patches-debain/series/2.6.14-2nh0 echo - a-bad.patch debian/patches-debain/series/2.6.14-2nh0 All lines that start in + are patches to be added. All lines that start in - are patches to be removed. All lines that start in # are comments So lets say that a-bad.patch was added in 2.6.14-2 and released, and you don't like it. The above will add your patch, and then unapply a-bad.patch. Note that applying is done in the order listed in the file. Latter, the patches may be unapplied, this will be done in reverse order. This can be important if multiple patches touch the same part of the file. 3) As 1) But using the latest svn patch sets from debian kernel development tree. Assuming that the kernel has been released, run the follwing betwen the apt-get and cd from question 1) rm -rf debian svn export svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian \ ./debain/ Note that trunk above is just that, what is being worked on. Somtimes there is a sid branch, which reflects what is in sid. Right now there is an etch branch which reflects what is in etch. Its best to jump onto #debian-kernel on oftc.net and ask if you're unsure, which to use. ./debian/rules debian/rules.gen debian/contol I had an un-published howto which applied pre-sarge, but many things have changed. I have not found a howto or a method to achieve any of the above. There are plenty of howtos which say along the lines of: download debian source package or from kernel.org, make menuconfig, make-kpkg etc. But that is not what I am looking for as I will end up with something other than a current Debian kernel. If I wanted to create a patch for submission, I can't be sure it will work without having a build process for a patched debian kernel. Understood, consistency is important, the current docs don't reflect that. For the record. 1. Download original tar.bz2 of kernel from from kernel.org wget http://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.tar.bz2 2. Get prune-non-free from svn svn export svn://svn.debian.org/svn/kernel/dists/trunk/scripts/prune-non-free 3. Run this to create the orig tarballs Note for now you need ruby installed for this to run, also, it takes a while. ./prune-non-free linux-2.6.14.tar.bz2 2.6.14 4. Remove the non-free tree, rm -rf linux-nonfree-2.6-2.6.14/ 3. Enter kernel tree cd linux-2.6-2.6.14/ 4. Export the debian directory from svn, as in question 3) above svn export svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian \ ./debain/ 5. Genearate the control file, as in question 3) above ./debian/rules debian/rules.gen debian/contol 6. Mangle at will, as per question 2) above 7. Run dpkg-buildpackage -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335538: kernel-image-2.6.8-2-386: Hard drive locks up - DMA or Power Management problem?
On Tue, Nov 01, 2005 at 09:24:16AM +, George B. wrote: P.S. I could try unloading the ide-generic module etc. if you think that's a good idea. I think its certainly worth a try, though its probably not going to make much difference. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
On Mon, Oct 31, 2005 at 07:57:18AM +0100, Sven Luther wrote: On Mon, Oct 31, 2005 at 10:57:54AM +0900, Horms wrote: Vesafb is no more modular now, and should either have been dropped fully or builtin, please check the config file. As the driver is no longer modular it is now built into the kernel on all i386 and amd64 architectures. It is not included in any other achitecture, but I believe this was the case when it was modular. # grep -r VESA debian/arch/ | grep -v .svn debian/arch/i386/config:CONFIG_FB_VESA=y debian/arch/amd64/config:CONFIG_FB_VESA=y The reason that it has been changed from modular to builtin, is that making it modular was a somewhat problematic patch. I hope we can find a solution that doesn't lead us back to that code. Still, i don't think its modular vs builtin nature should change things, except if some stuff noz use vesafb, while vga16fb was used previously. I wouldn't have thought so either, but the problems seem to have appeared at about the same time that the change was made (2.6.13), so I suspect a link. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336424: linux-headers-2.6.12-1-686: missing Makefile in scripts/basic directory
On Sun, Oct 30, 2005 at 12:03:09PM +0300, Sergey Safonov wrote: Package: linux-headers-2.6.12-1-686 Version: 2.6.12-10 Severity: normal Modules for linux 2.6.12 are unable to build with make-kpkg. The command cd /usr/src/linux-headers-2.6.12-1-686 make-kpkg modules_image fails with the following message : /usr/bin/make\ ARCH=i386 oldconfig make[1]: Entering directory `/usr/src/linux-headers-2.6.12-1-686' scripts/Makefile.build:15: /usr/src/linux-headers-2.6.12-1-686/scripts/basic/Makefile: No such file or directory make[2]: *** No rule to make target `/usr/src/linux-headers-2.6.12-1-686/scripts/basic/Makefile'. Stop. make[1]: *** [scripts_basic] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.12-1-686' make: *** [stamp-kernel-configure] Error 2 It happens when i use linux-headers-2.6.12-1-686 2.6.12-10, but with linux-headers-2.6.12-1-686 2.6.12-1 everything is ok. The contents of linux-headers-2.6.12-1-686 2.6.12-1 scripts/basic directory : .docproc.cmd .fixdep.cmd .split-include.cmd Makefile docproc docproc.c fixdep ficdep.c fixinclude fixinclude.c and scripts/basic directory of linux-headers 2.6.12-1-686 2.6.12-10 : docproc fixdep fininclude Makefile is missing. Is it right? or is it a bug in kernel-package? Manoj, I took a look and it seems that something bad is going on in the scripts/basic direcory. I've prodded away at this a bit, and I think this is a make-kpkg problem. Unfortunately I have no more time to prod today, could you take a look into it? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336431: linux-source-2.6.14: pptp connection tracking fails to compile
On Mon, Oct 31, 2005 at 10:01:05PM +0100, Vincent L??nngren wrote: Here it is, but with pptp connection tracking turned off since I needed the kernel. Thanks. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x86 kernel flavours was: 2.6.14-1 in incoming, status and future
On Tue, Nov 01, 2005 at 02:03:46AM +1100, Anand Kumria wrote: On Sun, 30 Oct 2005 02:31:01 -0800, Steve Langasek wrote: On Sun, Oct 30, 2005 at 07:57:34PM +1100, Anand Kumria wrote: Speaking of kernel flavours (we weren't, but what the hey); is the plan still to reduce all of the x86 flavours down to two: generic x86 and generic x86-smp? Still? When was this ever the plan? It was a discussion I observed at various times and places during debconf in Helsinki, so I was under the impression that reducing the burden on the kernel team was one of their goals. There was some discussion of cutting down on the number of flavours. It all centred around, is there any real benifit. For instance, it is conventional wisdom that 686 will run faster on a UP box than 686-smp, but for a typical workload, is it really enough to warrant an extra flavour. To be honest, most of the reason for extra flavours, especially in i386, comes down to performance. A 686-smp kernel will run faster on a P4 than a 386 kernel (n.b 386 and 686 are just the flavour names). In that case its almost certainly worth it. But its not entirely clear there is enough benifit to warrant all the flavours in between. However, as its a performance issue, what is needed is numbers. I heard that Ubuntu were looking into it, but haven't heard anything of late. And the reason for wanting to cut down? Shorter build times, less confusing package versions... simplicity. Its not a particularly strong motive, especially as we have been getting better on the packaging side. And there really hasn't been any discussion of it since Helsinki. Its probably well enough to let it go back to sleep for now. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336295: linux-headers-2.6.14-1: arch specific include/asm-$(ARCH)/ headers are not included in linux-headers-2.6.14-1 packages
On Sun, Oct 30, 2005 at 08:56:51PM +0100, Frederik Schueler wrote: Hello, Looks like this change was introduced with commit r4606 and not documented nor propagated to all arch maintainers properly. Waldi: can you please elaborate? should we add kernel-header-dirs: kernel arch name to every debian/arch/$arch/defines file or are you working on an alternative fix? I think 2.6.14-2 should wait until this is fixed, otherwise the kernel images will be useless for most users relying on external modules. To all concerned, this was indeed fallout from some packaging changes. The missing line should now be in the tree for each architecture - though I had to do a bit of guess, so if you are an arch maintainer, please take a peek. The fix should appear in 2.6.14-2, and that should be released shortly. There seems to be an unrelated headers problem, #336424, which has been around since 2.6.12-X, but only noticed recently. I'd like to get that fixed, but it seems much less severe than this problem. http://bugs.debian.org/336424 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: linux-image-2.6.14-1-686: 2.6.14-1-686 doesn't support vga=795 o
On Mon, Oct 31, 2005 at 07:44:42AM +, Richard Burton wrote: As Sven said vesafb isn't a module at 2.6.14. So for =2.6.14 you need both, for 2.6.14 you only need to add fbcon to the conf file. I'm sure you all spotted it - there is a slight error in the above statement, so for the record it should read: As Sven said vesafb isn't a module at 2.6.14. So for 2.6.14 you need both, for =2.6.14 you only need to add fbcon to the conf file. And with that combination your console is alive? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333522: linux-image-2.6.14-1-686-smp: occurs in stock linux-image as well
On Mon, Oct 31, 2005 at 03:10:29PM -0800, Paul Traina wrote: Package: linux-image-2.6.14-1-686-smp Version: 2.6.14-1 Followup-For: Bug #333522 udev/unstable uptodate 0.071-1 Just to cover the blanks, it is occuring as well with stock 2.6.14 debian kernels. This is a straight kernel built with an up to date initramfs tools. initramfs-tools rebuilt the initramfs several times (I've beend debugging evms) while running 2.6.14 and depmod -a's have occured. Let me know if I can test/help/hack. I'm 99.9% certain its due to modprobe being called in parallel by the new udev code. Don't understand why m-i-t isn't serializing the right bits. Yes, that seems to be the current school of thought. Rusty has been thinking it over with Marco, but we are yet to find the solution. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
