Re: failed to insert STA entry for the AP (error -2)
Hi all, adding the debian-kernel list due to issues with using debian-installer daily snapshot to install on my brand new laptop with an ath11k_pci supported wifi chip. It turns out that while d-i comes with the ath11k and ath11k_pci drivers, but misses the qrtr, qrtr-mki and michael_mic modules that are needed for the driver to actually work and not just load. On Wed, Dec 07, 2022 at 02:49:37PM +0200, Kalle Valo wrote: > Thanks. But this makes me wonder is it sensible to randomly install a > set of .ko files and drop the rest, like Debian's installer apparently > does? The dependency for drivers is pretty well documented in Kconfig > files, thanks to build testers testing with random configurations, but > if the installer omits all that there will be problems just like you are > experiencing. So for me MODULE_SOFTDEP() feels just like a band aid and > not a robust solution. I think a driver that a driver that has a runtime depedency on a certain module, but doesn't import symbols is always going to be somewhat problematic. But I also agree that the arbitrary splitting of kernel modules into separate packages for the installer, or in fact not packaging them at all for the installer is rather problematic. I'm not sure what the rationale is behind that, but I've added the debian-kernel and debian-boot lists. > Though I am happy to take your MODULE_SOFTDEP() patch, just wondering if > there is a better way to solve this. For example net/mac80211 (the > 802.11 stack) has a lot of crypto dependencies: > > select CRYPTO > select CRYPTO_LIB_ARC4 > select CRYPTO_AES > select CRYPTO_CCM > select CRYPTO_GCM > select CRYPTO_CMAC > select CRC32 > > And it's not using MODULE_SOFTDEP() at all. Yes. I'm not quite sure how the packages for d-i select which modules to include where, but given that other wifi hardware seems to work in the installer they must have figured this out somehow.
Bug#1025158: please include qrtr and qrtr-mhi in nic-wireless-modules
Source: linux Version: 6.0.0-5 Severity: wishlist Please include the qrtr and qrtr-mhi in the nic-wireless-modules binary package (or another one pulled in by DI). These modules are required by ath11k_pci to work, which is needed to install on e.g. a Thinkpad T14s Gen3 AMD.
Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported ZFS (with acltype=off) (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)
If you are violating our license please also don't spam our list when using your crappy combination.
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 03:43:10PM +0100, Lars Wirzenius wrote: > > do you think you could manage to either point the general -devel > reading population to a discussion of why using AppArmor by default is > horrible news, or write that yourself? That would seem to be more > constructive than you just showing up after months of discussion > saying it's horrible news. It's just a bad idea of a security model that implements ad-hoc and mostly path based restrictions instead of an actually verified security model. Using that by default makes it much harder to actually use a real MAC based security model, which not only is required for various security sensitive deployments but also a good idea in general. Last but not least apparmor had various issues where certain distros shipped non-upstream features that later turned out to be incompatible with what went upstream.
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 01:59:44PM +, Ben Hutchings wrote: > On Thu, 2017-11-23 at 14:58 +0100, Christoph Hellwig wrote: > > On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote: > > > AppArmor is the default LSM. > > > > There is no such thing as a default LSM in Linux. > > $ grep DEFAULT_SECURITY /boot/config-4.13.0-1-amd64 > # CONFIG_DEFAULT_SECURITY_SELINUX is not set > # CONFIG_DEFAULT_SECURITY_TOMOYO is not set > CONFIG_DEFAULT_SECURITY_APPARMOR=y > # CONFIG_DEFAULT_SECURITY_DAC is not set > CONFIG_DEFAULT_SECURITY="apparmor" That's still not an upstream default lsm. Looks like someone in Debian just decided to make apparmor the default, which is horrible news :(
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote: > AppArmor is the default LSM. There is no such thing as a default LSM in Linux. > > The changelog suggests it was done that systemd units might use it, > > but in that case those systemd units should depend on apparmor. > > They don't depend on AppArmor unless it's enabled. Which is a decision > made in the kernel configuration (potentially overriden by the kernel > comamnd line). So we should not need the recommends.
recommends for apparmor in newest linux-image-4.13
Hi all, is there any good reason for the recommends of apparmor in the latest linux packages? apparomor is just one of many security modules, and a fairly bogus one to start with. The kernel should not recommend it as it doesn't add at all to the expected kernel functionality. The changelog suggests it was done that systemd units might use it, but in that case those systemd units should depend on apparmor. And to start with there probably should be a policty that no unit file shall fail the boot for a missing security module (any of them).
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Dec 01, 2016 at 10:20:39AM -0500, Don Zickus wrote: > > - provide the memory allocation (instead of having the driver staticly > allocate) > - provide functions to retrieve various internal data (instead of having the > driver do direct referencing to deep internal elements) > - cut down on some static inlines (and use accessory functions instead), > etc. > > Those types of changes allow the OOT driver to be more ignorant of kernel > changes and struct modifications. All that is counter to what we really want to have: a well integrated kernel that moves forward together so that we can see and improve the whole situation. No need to make things worse just to help leeches. Get your damn drivers upstream ASAP and let's stop this discussion..
Bug#828826: nfs-common: move of rpc_pipefs mountpoint to /run breaks blkmapd
Package: nfs-common
Version: 1:1.2.8-9
Severity: important
Tags: patch
Dear Maintainer,
commit ba649fa4 ("Migrate the rpc_pipefs mount out of /var/lib to /run, to
better support /var on NFS.") in the Debian packaging repo completely
broke blkmapd, which still looks for rpc_pipefs in the old place.
>From looking in the BTS gssd also seems to have the same problem (#632141).
diff --git a/utils/blkmapd/device-discovery.c b/utils/blkmapd/device-discovery.c
index 69f00fa..7b00c90 100644
--- a/utils/blkmapd/device-discovery.c
+++ b/utils/blkmapd/device-discovery.c
@@ -55,9 +55,9 @@
#define EVENT_SIZE (sizeof(struct inotify_event))
#define EVENT_BUFSIZE (1024 * EVENT_SIZE)
-#define BL_PIPE_FILE "/var/lib/nfs/rpc_pipefs/nfs/blocklayout"
-#define NFSPIPE_DIR"/var/lib/nfs/rpc_pipefs/nfs"
-#define RPCPIPE_DIR"/var/lib/nfs/rpc_pipefs"
+#define BL_PIPE_FILE "/run/rpc_pipefs/nfs/blocklayout"
+#define NFSPIPE_DIR"/run/rpc_pipefs/nfs"
+#define RPCPIPE_DIR"/run/rpc_pipefs"
#define PID_FILE "/run/blkmapd.pid"
struct bl_disk *visible_disk_list;
-- Package-specific info:
-- rpcinfo --
program vers proto port service
104 tcp111 portmapper
103 tcp111 portmapper
102 tcp111 portmapper
104 udp111 portmapper
103 udp111 portmapper
102 udp111 portmapper
1000241 udp 46956 status
1000241 tcp 40643 status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nfs-common depends on:
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-59
ii libc6 2.19-18+deb8u4
ii libcap2 1:2.24-8
ii libcomerr2 1.42.12-1.1
ii libdevmapper1.02.1 2:1.02.90-2.2+deb8u1
ii libevent-2.0-5 2.0.21-stable-2
ii libgssapi-krb5-21.12.1+dfsg-19+deb8u2
ii libk5crypto31.12.1+dfsg-19+deb8u2
ii libkeyutils11.5.9-5+b1
ii libkrb5-3 1.12.1+dfsg-19+deb8u2
ii libmount1 2.25.2-6
ii libnfsidmap20.25-5
ii libtirpc1 0.2.5-1
ii libwrap07.6.q-25
ii lsb-base4.1+Debian13+nmu1
ii rpcbind 0.2.1-6+deb8u1
ii ucf 3.0030
Versions of packages nfs-common recommends:
ii python 2.7.9-1
Versions of packages nfs-common suggests:
pn open-iscsi
pn watchdog
-- debconf-show failed
Bug#738758: [PATCH] ext4: kill i_version support for Hurd-castrated file systems
On Wed, Mar 19, 2014 at 11:27:57PM -0600, Andreas Dilger wrote: Probably worthwhile to make those !EXT4_OS_HURD checks likely()? Does it make sense to support the format at all given that it's unlikely to get any testing? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140320081048.ga21...@infradead.org
Bug#696650: fsync() on read-only RAID triggers BUG
On Sat, Jan 26, 2013 at 07:44:40PM +, Ben Hutchings wrote: I applied this on top of 3.2.37 and it certainly fixes the crash. However I wonder whether fsync() should fail or should immediately succeed. I don't know whether the installer expects it to succeed. It should succeed. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130127163942.ga28...@infradead.org
Bug#569598: disk caches?
Do you have disk write caches disabled on the machine? Neither md, nor dm, nor loop pass through barrier requests. Without disabling the volatile write cache on the disks you will lose data everytime the machine is not shut down cleanly. The messages you see are typical for that kind of corruption. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216102114.ga8...@lst.de
Bug#569598: disk caches?
On Tue, Feb 16, 2010 at 10:58:06AM -0500, Philipp Weis wrote: On 2010-02-16 11:21, Christoph Hellwig h...@lst.de wrote: Do you have disk write caches disabled on the machine? Neither md, nor dm, nor loop pass through barrier requests. Without disabling the volatile write cache on the disks you will lose data everytime the machine is not shut down cleanly. The messages you see are typical for that kind of corruption. The caches are all off. Hmm, it really does look like the typical write cache corruption. Looking a bit at the loop driver as suspsect I think I know what the problem is: - loop writes data either using the address_space operations, or using -write, but it never calls does the O_SYNC processing (just -fsync in modern kernels, but a little different in 2.6.26) So when using loop data simply gets written into the page cache, but there is no guarantee it ever goes out to disk. This bug is still present in latests upstream - a patch to introduce barrier support calling -fsync went in a while ago but caused mysterious lockups and was reverted, with the patch author never coming back to try to figure it out. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216191800.ga1...@lst.de
Bug#569598: disk caches?
On Tue, Feb 16, 2010 at 03:42:25PM -0500, Philipp Weis wrote: How could it end up in the page cache for this setup? There is no filesystem layer below the loop device. Any write that reaches the loop device is passed through to lvm, then md and finally the disk. Are you saying that there is extra caching going on at the lvm or md layers? Yes, the block device node is a cached access mode, and uses the same pagecache as a filesystem uses. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216221248.ga8...@lst.de
Bug#486798: [PATCH] restore export of handle_mm_fault for Mac on Linux
On Thu, Jun 19, 2008 at 11:58:05AM +0200, Gaudenz Steinlin wrote: There is an effort underway to bring the MOL kernel modules into a mergeable form. But it's not there yet. Joseph Jezak, the MOl main developer nowdays is working on it. So MOL no longer want's to hide out of tree. It just needs some more time. It would be useful if you could send some status-updates to lkml and the kvm list. What I'm asking for is to get the export back, that as far as I can see was removed accidentialy and that was there before specially for MOL. It was removed intentionally. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486798: [PATCH] restore export of handle_mm_fault for Mac on Linux
On Wed, Jun 18, 2008 at 12:14:02PM +0200, Gaudenz Steinlin wrote: Hi The kernel modules for Mac on Linux (MOL) need handle_mm_fault. MOL is a GPL licensed virtual machine to run MacOS(X) on PPC Linux. Has been rejected a few times. An now that we actually have kvm for powerpc in tree MOL should just merge with that project and do the right things in tree instead of beeing a really hacky module subverting the VM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486798: [PATCH] restore export of handle_mm_fault for Mac on Linux
On Wed, Jun 18, 2008 at 10:45:02PM +1000, Paul Mackerras wrote: Has been rejected a few times. An now that we actually have kvm for powerpc in tree MOL should just merge with that project and do the right things in tree instead of beeing a really hacky module subverting the VM. We don't have KVM for the classic 32-bit PowerPC processors, only for the 44x family. And doing KVM for the classic 32-bit processors would probably involve just as much hackery as MOL. :) I don't think so. Doing it properly in-tree will mean that it is a) properly reviewed b) means we can do the major VM bits in the kernel without these really stupid exports Have you looked at MOL recently? It's more than disgusting. And in addition to these issue we do of course as policy not add random hooks in the kernel tree for out of tree stuff. Especially for hacks like this that don't even have the intention to get merged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping the amd64-generic flavour
On Sat, Jun 24, 2006 at 08:20:56AM +0200, Florian Weimer wrote: * Frederik Schueler: -generic is odd and too long. I am considering to change the naming scheme completely, and call the flavours 2.6.x-y-amd64 and 2.6.x-y-em64t respectively. Newer GCCs produce AMD64 code which is supposed to be closed to optimal to what GCC can produce on EM64T. Does it still make sense to distinguish between them? Or has it got something to do with the way the kernel sets up its data structures? The officially recommended way to build a distro kernel is to build the generic one. It's as fast as the specific ones because it uses some binary patching during bootup. The only thing you save with the specific options is a tiny little bit of space. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---end quoted text--- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - patch cleanup
On Tue, Feb 14, 2006 at 08:40:58PM +0100, maximilian attems wrote: * drivers-scsi-megaraid_splitup.patch Unsubmitted. misses parts of the splitup, needs an update by fabbione which is in ubuntu. this should be deal with properly in 2.6.16-rc. Better backport the megaraid drivers from latest linus' tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r5087 - in dists/trunk/linux-2.6/debian/arch: alpha amd64 hppa i386 ia64 s390
On Sun, Dec 25, 2005 at 01:31:34PM +, Frederik Sch??ler wrote: Author: fschueler-guest Date: Sun Dec 25 13:31:33 2005 New Revision: 5087 Modified: dists/trunk/linux-2.6/debian/arch/alpha/config dists/trunk/linux-2.6/debian/arch/amd64/config dists/trunk/linux-2.6/debian/arch/hppa/config dists/trunk/linux-2.6/debian/arch/i386/config dists/trunk/linux-2.6/debian/arch/ia64/config dists/trunk/linux-2.6/debian/arch/s390/config Log: Activate CONFIG_CC_OPTIMIZE_FOR_SIZE on all architectures but sparc, which is known to be broken. sparc is fixed in -rc7. the kernel build has been passing a bogus parameter to gcc which caused the problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.14-6 release, getting 2.6.15-rc into shape
On Mon, Dec 19, 2005 at 09:50:48PM +0100, Frederik Schueler wrote: - powerpc-calibrate-tau.patch - powerpc-g3-750cxe.patch Can we get them posted to linuxppc-dev again, please? - tty-locking-fixes9.patch this patch was always broken, but the underlying issue it has been papering over has been fixed now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r4992 - in dists/sid/linux-2.6/debian: . patches-debian patches-debian/series
On Thu, Dec 08, 2005 at 05:01:27PM +, Dann Frazier wrote: Author: dannf Date: Thu Dec 8 17:01:26 2005 New Revision: 4992 Added: dists/sid/linux-2.6/debian/patches-debian/drivers-scsi-buslogic-sysfs.patch Modified: dists/sid/linux-2.6/debian/changelog dists/sid/linux-2.6/debian/patches-debian/series/2.6.14-5 Log: I expect this to be re-disabled at some stage, * drivers-scsi-buslogic-sysfs.patch Adds sysfs support for buslogic. (closes #342057) The description and patch name is bullshit. It adds a pci device id table, which has absolutely nothing to do with sysfs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [kernel] r4992 - in dists/sid/linux-2.6/debian: . patches-debian patches-debian/series
On Thu, Dec 08, 2005 at 01:31:19PM -0700, dann frazier wrote: I'm not sure how this interface gets exposed to userspace, or how it helps initramfs-tools - I just inferred from the bug report that this led to this information being exposed in sysfs where initramfs-tools (via udev) could use it for device discovery. The way it's traditionally used is via the /lib/modules/$ver/modules.pcimap file that allows match drivers to PCI IDs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341522: Drivers for sbus devices are not included in initrd on sparc
On Wed, Nov 30, 2005 at 09:54:46PM -0800, Jurij Smakov wrote: Package: yaird Version: 0.0.11-12 Severity: important Hi, As I've mentioned on d-k, the sbus devices found in some early Ultras are not properly sysfs-trained. As a result, yaird currently fails to include the SCSI driver if the controller is an sbus device. As modifying the drivers may be too complicated, a possible workaround is to always force-include the esp.ko driver (I believe it is the only sbus-based SCSI controller) on sparc. If anyone volunteers to test the code I could look into converting sbus to the driver model. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 kernel udebs and d-i
16. Looked at the sun cassini nic card .. not quite sure why it's in the i386 kernel since some docs I find online seems to suggest it only works with Sun HW, but assumed the kernel team has a reason and added it to list. it's just a normal pci card, although afaik not shipped with anything but sparc hardware. as long as there's no additional work required it makes sense to support it on all architectures with PCI busses. 18. Looked at the new drivers/net/phy/ stuff, trying to decide whether to include the non-generic phy drivers (deps will pull in the generic phy support). Unsure, but left it out for now, since AFAIK nothing in d-i would load these modules. right now only plattforms for obscure ppc embedded boards use the framework. long-term all drivers with external PHYs should use this framework and we'll need to support these. I hope by that time a framework for autoloading the right PHY driver will be in place. 24. megaraid is removed (renamed to megaraid_mbox), so made kernel-wedge aware of that. Also, added megaraid_sas. actually there's two very old cards support only be megaraid and not megaraid_mbox. Where's trying to sort out the mess about this on the linux-scsi list. 26. Looked at raid_class's documentation which is in its entirity, Provides RAID. Blinked in puzzlement. Asked on irc. Went on to the next module. it's an embyonic generic raid managment framework. not useful on d-i yet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord and newer Linux kernels
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Fri, Nov 04, 2005 at 12:29:20PM +0900, Horms wrote: do I take that comment to mean that upstream can't update the drivers but Debian can? And if so, do you recommend updating Debian's kernel packages, or putting the updates elsewhere? Well, we could upstream, but so far no one is annoyed enough to overrid the driver maintainer. I'd suggest merging a more recent driver into the debian kernel package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote: So, having in mind the two levels of 'stablenesss': kernel 'stableness' and modules 'stableness' :) we should find the way to exclude discussed modules from the build, because in-kernel versions will always be, erm..., slightly (1.0.0 is mentioned only as 'stone age' in the mailing list of ipw2200 developers) outdated due to fact integration and testing gets some time in upstream kernels. I propose just to disable compilation of this drivers: everyone will be able to compile the recent version using ipw2200-source we provide. The kernel drivers aren't stable but obsolete. Because of that ever distribution that supports it's users must patch in a more recent one, which is what we should do for debian aswell. It's a pity the braindead Intel policies don't allow us to have an uptodate driver in mainline. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: realtime-lsm and Debian kernel
On Tue, Oct 11, 2005 at 06:24:20AM -0500, Geiger Guenter wrote: This means that it has to be dropped. Thats ok with me, it means less work. What was the reason again for not including the capabilities as a module ? Making Security modules actually modular means they don't have the full view of the process and generally is a bad idea. For the specific case of capabilities there even was an exploit in the past. If we want to support a given security module in debian we should compile it into the kernel statically. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: realtime-lsm and Debian kernel
On Mon, Oct 10, 2005 at 06:15:11PM +0200, Bastian Blank wrote: Can this be considered a bug and should I file a bug report ? wishlist+upstream for proper chain support. chaining was rejected upstream already. For a good reason because chanining access control decisions in multiple modules is inherently broken. The only users are totally idiotic ideas like this realtime lsm anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Observation re third parties supporting Debian kernels
On Sat, Sep 24, 2005 at 07:02:57PM +1000, Andrew Pollock wrote: Hi, I attended a product briefing at Computer Associates on Thursday, and one of the products that was discussed more than demonstrated was something called eTrust Access Control[1], which, from my interpretation, sounds like it achieves something similar to what SE Linux probably does. That's not really the point of this email though. And why should the kernel team support propritary software, especially where a better free alternative exists already? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329047: linux-image-2.6.12-1-k7: please enable CONFIG_REISERFS_FS_XATTR (and inotify)
On Mon, Sep 19, 2005 at 12:56:25PM +0800, Paul Wise wrote: Package: linux-image-2.6.12-1-k7 Version: 2.6.12-6 Severity: wishlist I would like CONFIG_REISERFS_FS_XATTR to be enabled so that the beagle desktop search and indexing daemon is faster. Also, when 2.6.13 is uploaded, be sure to enable inotify support, at least on i486. We should probably CONFIG_REISERFS_FS_XATTR , although I'd suggest you use another filesystem (ext3,jfs,xfs) if you use xattrs. The reiserfs xattr implementation is not very mature and causes problems much more often than the others. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328740: linux-source-2.6.12: xfs filesystem corruption
This looks like a typical corruption caused by not turning off the write cache on your disks. Is the write cache on your disk on or off? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328740: linux-source-2.6.12: xfs filesystem corruption
On Sat, Sep 17, 2005 at 09:33:06AM +, Jean-Luc Coulon (f5ibh) wrote: Le 17.09.2005 11:18:02, Christoph Hellwig a ?crit?: This looks like a typical corruption caused by not turning off the write cache on your disks. Is the write cache on your disk on or off? The disks are SATA disks (MAxtom Diamondmax 9, 80GB) and I've not found any way to turn ir on/off via hdparm. Because SATA is handled by the scsi layer. What does sdparm -a your disk device | grep WCE say? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acct v3 support
On Wed, Sep 07, 2005 at 02:57:47PM -0700, Ryan Lovett wrote: Are there plans to have more architectures enable the newer accounting file format via CONFIG_BSD_PROCESS_ACCT_V3 ? I'm actually only interested in amd64. $ egrep 'CONFIG_BSD_PROCESS_ACCT_V3=y|linux-2.6-2.6.12/debian/arch/' \ linux-2.6_2.6.12-5.diff The above seems to indicate that v3 is enabled for alpha and hppa. I realize enabling this feature may require changes in the user space tools, e.g. http://www.physik3.uni-rostock.de/tim/kernel/utils/acct/ Should I file a wishlist bug? This breaks the accounting format, so it's a change that needs a lot of thought. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324202: include ReiserFS ACL support in 2.6.12 kernel
Can we please stop this my filesystem is better than yours crap? As far as the debian kernel packages are concerned we should support all filesystems supported upstream unless there's a very good reason. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326730: linux-source-2.6.12: Netfilter and IPSec patches in 2.6
On Mon, Sep 05, 2005 at 12:38:21PM +0100, Antony Gelberg wrote: Package: linux-source-2.6.12 Severity: normal Hi, Please can we have the patches in 2.6 for netfilter and ipsec, and the policy match patch in iptables. See http://www.shorewall.net/IPSEC-2.6.html Dave Miller wasn't happy with those patches yet, in fact he said they are broken in rather subtile ways. Please wait until we'll have proper netfilter hooks for ipsec in mainline. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326576: linux-2.6: xfs support for user_xattr dissappeard?
On Sun, Sep 04, 2005 at 10:33:57AM +0200, Chris Searle wrote: Package: linux-2.6 Severity: normal Seen this with -1-k7 and with -1-686. Am testing beagle - so I needed to turn on user_xattr. But - when I upgraded from kernel-image-2.6.11-1-k7/-1-686 to linux-image-2.6.12-1-k7/-1-686 - suddenly the mount option of user_xattr stops working. XFS never had a user_xattr option, extended attributes are enabled by default for XFS (and JFS) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
But right now there are two problems that need to be resolved so we know where things are supposed to go. 1. Should linux-2.6 go in trunk/kernel/ or just trunk. Given that we no longer need source and per-arch directories, it seems logical to just move it up to trunk/ But thats a bit of a departure from the old model, and burns holes in some peoples brains. The old layout burned holes in my brain, so I'd surely welcome this ;-) 2. If we assume that we have two versions of linux-2.6, one based on the current upstream (and likely in sid/testing) and one based on some upstream rc releases (and likely in experimental) where should these two directories go. The main two camps seem to be: a) They are both being developled, so we may as well have them in trunk as linux-2.6 and linux-2.6-experimental, or something like that. We always had multiple versions in trunk in the past, and no one complained. This is fine with me. Just make sure -experimental is actually branched of linux-2.6 so svns primitive merging has a chance to work. b) Everything must come off trunk. Only the very leading edge can be in trunk. If the sid version isn't that then it should go under branches, and if that happens to be the version in sid, it should be branches/dists/sid/linux-2.6 (or branches/dists/sid/kernel/linux-2.6, depending on 1) above). Personally, in the context of the two questions above, I advocate trunk/linux-2.6 trunk/linux-2.6-experimental aolme too!/aol -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SVN layout
oh, and additional point, could we stop moving things around without a prior discussion on this list in the future? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: powerpc d-i daily builds reactivated, use 2.6.12 kernels, including 64bit kernels, miboot floppies dropped for now.
On Tue, Aug 23, 2005 at 02:18:07AM -0300, Rog?rio Brito wrote: Remember the debian kernel is generic for all powerpc plateforms, from old world to prep boxes, to powerbooks to the last 32bit IBM chrps and the genesi pegasos machine, so there is a bit more constraints here, but it is assuredly doable. I thought that the kernel in the miboot floppies were specific just to OldWorld machines. And you already have many flavours of it being built. I understand that the kernels have to be generic, but, say, including one specific feature of a pegasos machine in a miboot floppy isn't something that I would expect (even if it can be offloaded to a ramdisk). Sven, didn't you say a while ago a flavour more or less doesn't matter (when discussing ppc64 kernels)? I think a special oldworld kernel might be useful for these bootfloppies indeed. -- Rog?rio Brito : [EMAIL PROTECTED] : http://www.ime.usp.br/~rbrito Homepage of the algorithms package : http://algorithms.berlios.de Homepage on freshmeat: http://freshmeat.net/projects/algorithms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---end quoted text--- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: r4021 - trunk/kernel
On Mon, Aug 22, 2005 at 11:59:51AM +0200, Sven Luther wrote: Ok, this is a mess, so we probably need to hold a little flamewar about how we want the tree organized or something, before we start moving stuff back and fort. I believe that the trunk is for main development, and it is important that we keep the version we are actually using in trunk, and not the next version as the linux-2.6.13-rcsomething. Also, i am not overly convinced about the branch stuff, especially for main branches where we are going to work on, and not some obscure stuff only some will want to play with. Furthermore, now that the kernel subdir is going to be emptied of its content, in favour of the single linux-2.6 package, we could as well move linux-2.6 into the toplevel. So, my proposal was to have : /trunk/linux-2.6 - main 2.6 kernel being uploaded to sid I liked that, I always hated the enormous hierachies in the old repository. /trunk/linux-2.6-experimental - the experimental version. SVN allows branches to reside anywhere freely, including under /trunk, right? In that case this is okay, just make sure it really is a branch so merges work fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297832: [powerpc] iBook2 will not wake from sleep
On Fri, Aug 12, 2005 at 11:34:06AM +0200, Maximilian Attems wrote: any update on the matter? have you tried linux image 2.6.12? Note that I had the same problem when I still had my iBook2.2. The problem only occurs if X runs or did run. When I booted with X disabled it worked just fine, so it looks more like an X problem to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] Re: Bug#322273: [CAN-2005-2456]: XFRM array index buffer overflow
On Wed, Aug 10, 2005 at 11:47:12AM +0200, Moritz Muehlenhoff wrote: Horms wrote: As for which package to log a bug against, or cretion of duplicate bugs. To be honest it doesn't matter. If you email debian-kernel@lists.debian.org, then you should get a response, regardless of if you open a bug in the BTS or not. CCing secure-testing-team@lists.alioth.debian.org if its a bug testing and [EMAIL PROTECTED] if its a bug instable is also a good idea. When we find problems, we just fix them. The BTS is really a bit to noisy for us to use it to track bugs effectively. Obviously this is a bit of a problem, but what I am trying to say is adding a bug to the BTS just emails debian-kernel anyway, and security bugs sent there are acted on. So my my advice is tho email the addresses above, and if you want to open a bug, just open it against any of the above packages that have the vulnerability. Hi Horms, there has been a CVE assignment for an overflow in xdr.c, which can be exploited by crafted data in the nfsacl protocol: CAN-2005-2500 Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2500 for some links to patches. I suspect it is already fixed in kernel-2.6, but 2.6.8 and 2.4.27 might need backports. No, nfsacl has only been added very recently and is not present in 2.4.x or 2.6.8. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Mon, Aug 08, 2005 at 10:47:53AM +0200, Sven Luther wrote: On Wed, Aug 03, 2005 at 07:57:22PM +0200, Christoph Hellwig wrote: On Wed, Aug 03, 2005 at 07:55:12PM +0200, Bastian Blank wrote: - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. Or fix the architectures to not require them. The mips changes are fine for any other architecture, although they should be split into a few more. The m68k patch as-is isn't, but we hope to have m68k compiling from mainline sources soon after the 2.6.14 tree opens. I hope the powerpc/apus patch will be fine soon, but what about things like the (upcoming ?) powerpc/nubus patch ? Let's just work with the people to sort it out early enough. It's not like it'll be stable enough for a distro as soon as the port is mostly running anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-2.6 - subarch and patches
On Wed, Aug 03, 2005 at 07:55:12PM +0200, Bastian Blank wrote: - Each arch may specify an architectury specific patch, each image package may specify another patch, it may shared between more than one image. Or fix the architectures to not require them. The mips changes are fine for any other architecture, although they should be split into a few more. The m68k patch as-is isn't, but we hope to have m68k compiling from mainline sources soon after the 2.6.14 tree opens. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315654: devfs is being removed NOW
On Sat, Jul 30, 2005 at 08:22:31PM +1000, Russell Coker wrote: The 2.6.13 rc kernels have devfs removed. Debian won't support 2.6.13 until this problem is fixed. Debian works just fine without devfs once installed, thanks. Please reassign to whatever d-i component relies on devfs to pull in the Ubunutu changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [job] VMWare kernel development.
On Thu, Jul 14, 2005 at 11:23:20AM +0300, martin f krafft wrote: You Debian kernel guys would be whom I'd refer... please contact Michael if you are interested. Folks, do we really need to spam mailinglists with job offers? Especially for a known copyright violator on gpl'ed kernel code like vmware? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Feedback from DebConf5 Talk
On Thu, Jul 14, 2005 at 03:31:56PM +0300, dann frazier wrote: Thanks to dilinger/horms/josk/svenl for sitting up front providing the real content to backup my slides :) What all feedback did you get afterwards? One comment I heard was that users would like to have _every_ kernel-image have a different name, so that they can always have the last kernel as a fallback. The user mentioned that RedHat does something like this. rpm just allows to install multiple version of a package if their set of files doesn't overlap. Would be useful to have for dpkg aswell, that would kill all our stupid binary package versioning issues. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317288: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed
On Thu, Jul 07, 2005 at 03:14:14PM +0200, Martin Wesemann wrote: ?/lib/modules/2.6.11-1-k7/kernel/drivers/usb/input/wacom.ko? which is also in package wacom-kernel-modules-2.6.11-1-k7 dpkg-deb: Subprocess paste killed with Signal (data transfer interrupted (broken pipe)) The package wacom-kernel-modules-2.6.11-1-k7 is a self compiled kernel modul. The source is from package wacom-kernel-source. Is this modul already in the kernel-image Package now? Probably. Installing your own modules into the /lib/modules/*/kernel/ hierarchy is always wrong, they must go into /lib/modules/*/package -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or should i rely on the ubuntu toolchain, and use that to upload kernels to sid in the near future ? Together with a statically built procps naturally ? The sid procpc works just fine with ppc64 kernel, no need to mess with it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 07:36:08PM +0200, Sven Luther wrote: On Fri, Jun 10, 2005 at 07:16:02PM +0200, Christoph Hellwig wrote: On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or should i rely on the ubuntu toolchain, and use that to upload kernels to sid in the near future ? Together with a statically built procps naturally ? The sid procpc works just fine with ppc64 kernel, no need to mess with it at all. Oh, fine, so there is no risk of overflow of the process id. The process id in Linux is always 32bits, and unless you tweak /proc/sys/kernel/pid-max the actual range used is even smaller. What about the sarge procps ? It shouldn't be any different. I have been running ppc64 kernels with sarge for a long time. And if there's a bug in procps somewhere where it can't deal with some fields beeing bigger in 64bit kernels that should be fixed in procps instead of needing another set of binaries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312699: Please have hotplug rescan the scsi bus for scsi loads.
On Thu, Jun 09, 2005 at 07:14:22PM +0200, Marco d'Itri wrote: reassign 312699 kernel thanks On Jun 09, Michael Heldebrant Ph.D [EMAIL PROTECTED] wrote: For a Dell Latitude X200 laptop and docking station is is necessary to manually run scsiadd -s to enable the cdrom drive through the firewire interface. Is there a way to intelligently rescan the scsi bus when potential scsi devices may enter and leave the system or should I look into reporting a bug against the sbp2 kernel module? I'd start with the kernel. If the kernel people say that this cannot be fixed in the driver then you could write a script for /etc/hotplug.d/ieee1394/ . If you can make it run scsiadd only on this specific system then I could add it to the hotplug package. This works just fine when you use a 2.6 kernel. With the 2.4 kernel even the manual scan is extremly dangerous. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: New uniform packaging scheme
On Thu, May 19, 2005 at 02:04:33PM -0400, Jurij Smakov wrote:
Kernel packages are uniquely identified by their architecture,
subarchitecture and flavour. For most arches the kernel images are
built from the same source (upstream source with all-arch Debian
patches), using different configuration files corresponding to
different flavours. Subarch level is only required when specific
unmerged patches need to be applied to the common source to support
a particular class of hardware. As these patches potentially modify
the headers, each subarch has to have its own kernel-headers package.
I think it's a very bad idea to have different source bases and if
possible we should implement it in the packaging - that would encourage
people to use the facility instead of fixing things up properly. And
doing that is always possible. I managed to fix the big mess that ia64
was in the 2.5 series, and Al Viro managed to fix m68k easily for 2.6.12
or 2.6.13 - the fix was mostly trivial the only problem was political
unwillingness from the m68k maintainers.
Packaging scheme
To accomodate all the possibilities, the following packaging scheme
(to be implemented by the common source package) is proposed:
kernel-headers-$(version)-$(abiname)
A common headers package for an architecture without subarches.
It will contain all the common header files required to build the
3rd party modules, including the scripts subdirectory (currently
packaged as kernel-kbuild). It should contain only the includes
for this particular arch, i.e. include/{asm-generic,asm-$(arch)}
Unpacks to /usr/src/kernel-headers-$(version)-$(abiname).
kernel-headers-$(version)-$(abiname)-$(subarch)
A common headers package for an architecture with subarches.
Same purpose and contents as the one above.
kernel-headers-$(version)-$(abiname)-$(flavour)
Flavour-specific kernel headers package, containing mostly the
configuration files. It will have the same name for both cases
(subarch or no subarch). As a result there is a restriction that
all flavour names across all arches/subarches have to be unique,
but that does not seem too problematic. This package must unpack
to /usr/src/kernel-headers-$(version)-$(abiname)-$(flavour),
depend on an appropriate common kernel-headers package, set up
the symbolic links into it to provide a complete build-tree, and
supply the /lib/modules/$(version)-$(abiname)-$(flavour)/build
symlink to that tree.
I think we should only have a single kernel-headers-$(version)-$(abiname)
package. There's quite a bit of cross including of asm-arch headers,
and having the full set available makes getting this right much easier.
It's not a lot of space used anyway.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: New uniform packaging scheme
On Mon, May 23, 2005 at 05:20:06PM +0200, Christoph Hellwig wrote: On Thu, May 19, 2005 at 02:04:33PM -0400, Jurij Smakov wrote: Kernel packages are uniquely identified by their architecture, subarchitecture and flavour. For most arches the kernel images are built from the same source (upstream source with all-arch Debian patches), using different configuration files corresponding to different flavours. Subarch level is only required when specific unmerged patches need to be applied to the common source to support a particular class of hardware. As these patches potentially modify the headers, each subarch has to have its own kernel-headers package. I think it's a very bad idea to have different source bases and if possible we should implement it in the packaging - that would encourage not -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309378: kernel-image-2.6.8-2-686-smp: CONFIG_PREEMPT is set, and seems to cause oop'es with openafs.
On Mon, May 16, 2005 at 03:33:42PM -0500, Troy Benjegerdes wrote: Package: kernel-image-2.6.8-2-686-smp Version: 2.6.8-13 Severity: important I got the following oops today on a machine with openafs-modules-1.3.81: afs_put_inode: ino 6501078 (0xf68cdc00) has count 2 afs_put_inode: ino 6432306 (0xf6818400) has count 2 afs_put_inode: ino 6501042 (0xf6f0fc00) has count 2 afs_put_inode: ino 6500018 (0xf6eafc00) has count 2 [ cut here ] kernel BUG at fs/inode.c:1099! Please report such problems to the OpenAFS folks. OpenAFS is a known Piece of shunk having problems like that all the time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309378: kernel-image-2.6.8-2-686-smp: CONFIG_PREEMPT is set, and seems to cause oop'es with openafs.
On Mon, May 16, 2005 at 04:19:00PM -0500, Troy Benjegerdes wrote: Then why is CONFIG_PREEMPT disabled in 2.6.11 ? The real problem is preempt is enabled. Because it doesn't provide much benefits while letting broken code explode. That doesn't mean you should file such reports against against the kernel package unless that broken code is actually part of the mainline kernel or the debian patches. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o for amd64
On Tue, Apr 26, 2005 at 12:10:31AM +0200, Frederik Schueler wrote: Hello, I have a dpt_i2o card myself wich I had to remove from my workstation when I moved to amd64, I know your problem pretty well. Thus I am interested in this patch, I tried to contact adaptec back then but got no response. Where did you get that patch from? Was it already proposed for inclusion in the official 2.6 tree? Not sure where this thread started, but please always use the i2o_block/i2o_scsi drivers and not dpt_i2o for 2.6.x. If you see problems with that driver please report it to the very active upstream maintainer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik wrote: For tg3 a transition period shouldn't be needed as firmware loading is only needed on old/buggy hardware which is not the common case. Or to support advanced features which can be disabled. TSO firmware is commonly used these days. Because our TSO support has been totally broken for a long time? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: I don't think you did get a rejection, a few people said that _they_ weren't going to do it, but if you want to then go ahead. I think people are just fed up of people bringing up the issue and then failing to do anything about it -- so prove them wrong ;-) Actually patches to add firmware loader support to tg3 got rejected. Which is think is very unfortunately as we set the highlevel goal to move drivers over to it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 11:28:07AM +0200, Arjan van de Ven wrote: I think they will be accepted if they first introduce a transition period where tg3 will do request_firmware() and only use the built-in firmware if that fails. Fine with me. Second step is to make the built-in firmware a config option and then later on when the infrastructure matures for firmware loading/providing firmware it can be removed from the driver entirely. I think the infrasturcture is quite mature. We have a lot of drivers that require it to function. One of the sticking points will be how people get the firmware; I can see the point of a kernel-distributable-firmware project related to the kernel (say on kernel.org) which would provide a nice collection of distributable firmwares (and is appropriately licensed). Without such joint infrastructure things will always be a mess and in that context I can see the point of the driver authors not immediately wanting to switch exclusively. Simply because they'll get swamped with email about how the driver doesn't work... I agree. And that really doesn't need a lot of infrastructure, basically just a tarball that unpacks to /lib/firmware, maybe a specfile and debian/ dir in addition. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote: One of the options is to even ship the firmware in the kernel tarbal but from a separate directory with a clear license clarification text in it. I think that's what we should do. I currently don't have any firmware requiring devices, but I'd volunteer to keep such a tarball for now if no one else wants to do tiny amount of work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preempt on/off i386
On Wed, Jan 26, 2005 at 07:45:18PM +0100, maximilian attems wrote: can i turn off CONFIG_PREEMPT on the 386 arch, it's the only arch that features the costly: CONFIG_PREEMPT=y all other debian arch turn it off for good. Yes, please do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291375: initrd-tools for Debian are one big mess
On Thu, Jan 20, 2005 at 07:25:21PM +0100, Harald Dunkel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Hellwig wrote: | Complete agreement here. We're still looking for a volunteer, though | ;-) | | Come on! I had offered to take over initrd-tools several months ago. I am sure that there would be several other volunteers. Hey, it's not up to me to decide, I'm not even a DD. But I'd be happy to see initrd-tools properly maintained by you. If you want to replace initrd-tools by something else, then I would suggest to switch to the new initramfs procedure (see Gentoo). Dito for Red Hat/Fedora -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291232: kernel-source-2.6.10: Cannot burn DVD as normal user
On Wed, Jan 19, 2005 at 09:44:23AM -0500, Brian Pack wrote: Package: kernel-source-2.6.10 Version: 2.6.10-4 Severity: important Tags: patch When running as normal user with kernel 2.6.10, growisofs gives the following error when attempting to burn a DVD: Executing 'builtin_dd if=/dev/fd/0 of=/dev/hdc obs=32k seek=0' :-( unable to PREVENT MEDIA REMOVAL: Operation not permitted Running as root works fine. I found this patch on LKML, and can now burn as normal user: The patch is not correct, though. I'll put in the correct fix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284952: The USB block device should be disabled
On Mon, Jan 17, 2005 at 02:17:28PM +0900, Horms wrote: I thought it already was marked as n. Does anyone have an objection to making this so? No, please turn it off. I hadn't realized it's turned on either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281905: please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
I've put in the patch and enabled CONFIG_EFI_PARTITION for the i386 and amd64 2.6.8 and 2.6.10 kernel packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268621: Reproducable in parts
On Sun, Jan 16, 2005 at 05:14:40PM +0100, Florian Boelstler wrote: Hi, just want to mention that I can reproduce the problem with a kernel built from kernel-source-2.6.8-12 using: cdda2wav -t 1 dev=ATA:1,0,0 and cdda2wav -t 1 dev=ATAPI:0,0,0 However it does not occur when I specify the device as cdda2wav -t 1 dev=/dev/hdc At which point it's NOTABUG. You shall not use dev=ATA or dev=ATAPI. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281905: #281905 please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
On Sun, Jan 09, 2005 at 08:49:54AM -0500, Anthony DeRobertis wrote: Christoph Hellwig wrote: Best thing for 2TB disks is to use LVM anyway At least as far as d-i is concerned (AFAICT), you have to put LVM on top of an existing partition table; you can't just use the full /dev/sda or whatever. (The command-line lets you get around this). Yikes. The a stupid and quite serious bug in d-i. However, even if you do use the command line to get around d-i limitations, its still not safe to have /boot on LVM (at least according to all the documentation I've seen). with lilo it's safe if the LV is created with the continuous flag, for grub I'm not sure whether it has LVM support these days, I implemented support for LVM1 ~5 years ago but it got lost (and I don't have the patch anyore either) I believe the only way to use d-i on machines with only 2TiB disks is to rebuild the kernel to enable EFI GPT. Or any other of the partition formats that work. E.g. all the SGI Altix systems with 2TB volumes (which is probably all of them) use IRIX disk labels.
Re: Bug#281905: #281905 please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
On Sun, Jan 09, 2005 at 03:24:26PM +0100, Bastian Blank wrote: On Sun, Jan 09, 2005 at 02:53:17PM +0100, Christoph Hellwig wrote: At least as far as d-i is concerned (AFAICT), you have to put LVM on top of an existing partition table; you can't just use the full /dev/sda or whatever. (The command-line lets you get around this). Yikes. The a stupid and quite serious bug in d-i. No it is not, it is unspecified if this will work. Huh? LVM on blockdevices work. Partitions are in no way different from regular block devices from the kernel POV.
Re: r2230 - in trunk/kernel/source/kernel-source-2.6.10-2.6.10/debian: . patches patches/series
+ static int __init init_ext3_fs(void)
+ {
+ int err = init_ext3_xattr();
++
++/* fix for oops */
++printk(KERN_ERR [%d] init_ext3_fs(), err = %d\n, __LINE__, err);
urgg, this is not a fix but a hack. Should look more like:
/* ugly hack to work around compiler bug */
#ifdef __alpha__
printk(KERN_DEBUG [%d] init_ext3_fs(), err = %d\n, __LINE__, err);
#endif
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing.
Bug#281905: #281905 please enable CONFIG_EFI_PARTITION; it's needed for 2TiB
severity 281905 wishlist thanks The EFI format is unfortunately rather misdesigned and has a backup data area at the end of the devices - which won't be acciable by lots of usb devices because they have broken size reporting. This alone wouldn't be a problem if we could simply probe EFI last, but that doesn't work either as EFI partition tables also contain a fake dos partition table to trick around older windows versions. Best thing for 2TB disks is to use LVM anyway
Bug#286028: #286028 installation-reports: loading tg3 module for Broadcom NIC causes total freeze of system
please try installing with a 2.6 kernel, it has a much more uptodate tg3 driver (and various other advantages)
Bug#283241: kernel-image-2.6.8-1-k7: 2.6.8 and 2.6.9: utime(2) hangs on smbfs
On Sat, Jan 08, 2005 at 06:36:27PM +0100, S?ren Hansen wrote:
This bug does not exist in the vanilla version of 2.6.8. A patch added
somewhere in the Debian kernel-source-2.6.8 packages breaks it. I,
however, cannot seem to find any patches that should touch smbfs, so I
can't point it out. I just just rebuilt that particular module with the
sources from kernel.org and everything works just as well as before.
I believe this bug is severe enough to force a fix in Sarge! It renders
smbfs TOTALLY useless.
--
S??ren Hansen [EMAIL PROTECTED]
When merging to 2.6.10 I noticed we have a bunch of smbfs changes that
were labelled security fixes. Can you try to rebuild the kernel (or
just smbfs.ko) with the patch below reversed?
#! /bin/sh -e
## PATCHNAME.dpatch by [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Description: SMBfs overflow fixes
## DP: Patch author: unknown, stolen from -ac tree (probably Stefan Esser,
Juan Quintela, and Urban Widmark)
## DP: Upstream status: unknown
. $(dirname $0)/DPATCH
@DPATCH@
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.9/fs/smbfs/proc.c linux-2.6.9/fs/smbfs/proc.c
--- linux.vanilla-2.6.9/fs/smbfs/proc.c 2004-10-20 23:17:20.0 +0100
+++ linux-2.6.9/fs/smbfs/proc.c 2004-11-17 19:41:41.0 +
@@ -1427,9 +1427,9 @@
* So we must first calculate the amount of padding used by the server.
*/
data_off -= hdrlen;
- if (data_off SMB_READX_MAX_PAD) {
- PARANOIA(offset is larger than max pad!\n);
- PARANOIA(%d %d\n, data_off, SMB_READX_MAX_PAD);
+ if (data_off SMB_READX_MAX_PAD || data_off 0) {
+ PARANOIA(offset is larger than SMB_READX_MAX_PAD or
negative!\n);
+ PARANOIA(%d %d || %d 0\n, data_off, SMB_READX_MAX_PAD,
data_off);
req-rq_rlen = req-rq_bufsize + 1;
return;
}
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.9/fs/smbfs/request.c linux-2.6.9/fs/smbfs/request.c
--- linux.vanilla-2.6.9/fs/smbfs/request.c 2004-10-20 22:33:50.0
+0100
+++ linux-2.6.9/fs/smbfs/request.c 2004-11-17 19:41:41.0 +
@@ -588,6 +588,10 @@
data_count = WVAL(inbuf, smb_drcnt);
/* Modify offset for the split header/buffer we use */
+ if (data_offset hdrlen)
+ goto out_bad_data;
+ if (parm_offset hdrlen)
+ goto out_bad_parm;
data_offset -= hdrlen;
parm_offset -= hdrlen;
@@ -607,6 +611,10 @@
req-rq_lparm = parm_count;
req-rq_data = req-rq_buffer + data_offset;
req-rq_parm = req-rq_buffer + parm_offset;
+ if (parm_offset + parm_count req-rq_rlen)
+ goto out_bad_parm;
+ if (data_offset + data_count req-rq_rlen)
+ goto out_bad_data;
return 0;
}
@@ -643,8 +652,12 @@
if (parm_disp + parm_count req-rq_total_parm)
goto out_bad_parm;
+ if (parm_offset + parm_count req-rq_rlen)
+ goto out_bad_parm;
if (data_disp + data_count req-rq_total_data)
goto out_bad_data;
+ if (data_offset + data_count req-rq_rlen)
+ goto out_bad_data;
inbuf = req-rq_buffer;
memcpy(req-rq_parm + parm_disp, inbuf + parm_offset, parm_count);
@@ -676,13 +692,13 @@
req-rq_errno = -EIO;
goto out;
out_bad_parm:
- printk(KERN_ERR smb_trans2: invalid parms, disp=%d, cnt=%d, tot=%d\n,
- parm_disp, parm_count, parm_tot);
+ printk(KERN_ERR smb_trans2: invalid parms, disp=%d, cnt=%d, tot=%d,
ofs=%d\n,
+ parm_disp, parm_count, parm_tot, parm_offset);
req-rq_errno = -EIO;
goto out;
out_bad_data:
- printk(KERN_ERR smb_trans2: invalid data, disp=%d, cnt=%d, tot=%d\n,
- data_disp, data_count, data_tot);
+ printk(KERN_ERR smb_trans2: invalid data, disp=%d, cnt=%d, tot=%d,
ofs=%d\n,
+ data_disp, data_count, data_tot, data_offset);
req-rq_errno = -EIO;
out:
return req-rq_errno;
Re: preparing 2.6.10
On Wed, Jan 05, 2005 at 12:15:51AM -0500, Andres Salomon wrote: Alright, enough people are bothering me for 2.6.10 that we should probably get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 k-s directory (small, obvious fixes for the most part); I'm going to aim for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has objections. ia64-generic-no-smp.dpatch still needs a forward-port. drivers-scsi-generic_proc_info.dpatch should be dropped, but we need to make sure the kernelk-image packages depend on the latest initrd-tools btw, any reason your newly commited patches have leading numbersi n their patch names, unliked all the older patches?
Bug#288787: IPTables does not work with kernel 2.6.8
On Wed, Jan 05, 2005 at 06:52:26PM +0100, Kurt Huwig wrote: Package: kernel-image-2.6.8-9-amd64-k8 Version: 2.6.8-8 Fresh installation of Sarge with all updates from today: iptables doesn't work when you're running 32bit userland on 64bit kernel, and it's not fixable either. Run an i386 kernel and everything will be fine.
Re: preparing 2.6.10
On Wed, Jan 05, 2005 at 10:18:04PM +0100, Eduard Bloch wrote: #include hallo.h * Andres Salomon [Wed, Jan 05 2005, 12:15:51AM]: Alright, enough people are bothering me for 2.6.10 that we should probably get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 k-s directory (small, obvious fixes for the most part); I'm going to aim for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has objections. Wishlist on patches (laptop/power management related): http://people.ubuntu.com/~fabbione/misrouted-irq.dpatch (not enabled by default, needs kernel options, solves the extremely nasty hard kernel crash on resume from APM/ACPI suspend, thanks fabionne) Probably makes sense, but I'd personally wait for some more testing or at least until it's in -mm. The IRQ-after-swsusp-awakening patch (attached). Needed to make some hardware drivers work after resuming from swsusp (Source: Message-ID: [EMAIL PROTECTED]) The swsusp-speedup-patch (attached) - makes the swsusp in kernel a lot faster on suspending (source: Message-ID: [EMAIL PROTECTED]) We don't ship with swsusp enabled so this is just a waste of time.
Re: Status of Kernel 2.4.28 packages?
By the way, is there a guide somewhere telling how to switch an unstable system from 2.4 to 2.6? An install of the appropinquate kernel-image package should do it. At least it did for me on various ppc and an x86_64 installed as i386 system.
Re: Status of Kernel 2.4.28 packages?
On Mon, Jan 03, 2005 at 10:19:57AM +0100, Stephan Niemz wrote: Yes, converting from devfs to udev is one thing that doesn't seem to be easy. Another one is the ISDN support. Hasn't that changed significantly, too? And what's going to happen with /etc/modutils/*, how much manual tweaking would be needed there? And I'm sure there is more. I haven't used either devfs nor udev so I can't comment on that. ISDN should be fine nowdays - while there's been quite a lot of ISDN changes there's nothing that's different from the usersland POV.
Re: Status of Kernel 2.4.28 packages?
On Sun, Jan 02, 2005 at 07:37:59PM +0100, Stephan Niemz wrote: The kernel version 2.4.28 is out for almost seven weeks now. Does anybody know about the status of the corresponding Debian packages? And is there an estimation for when the kernel-patch-* packages will support the new kernel version? There's an unfinished 2.4.28 kernel-source package in the debian-kernel SVN repository. For me and several other members of the debian kernel team 2.4 packages have been a much lower priority than 2.6 packages. Given that and that sarge will release with 2.4.27 anyway I'm not sure when a 2.4.28 package will get into unstable. Any reason you're not using 2.6 kernels?
Bug#288263: initrd-tools: capability module missing from /etc/mkinitrd/modules
On Sun, Jan 02, 2005 at 07:22:28PM +, Luke Kenneth Casson Leighton wrote: Package: initrd-tools Version: 0.1.65 Severity: normal 2.6.9 and above now have capability as a module. if this module is not loaded, udev will not operate properly. and with the module loaded we'll have a local root exploit. I'll disable support for modular capabilities in the next kernel-source releases. selinux also is now a module and it too should probably be loaded, no, it's not.
Bug#288263: initrd-tools: capability module missing from /etc/mkinitrd/modules
On Sun, Jan 02, 2005 at 07:52:19PM +, Luke Kenneth Casson Leighton wrote: oh dear! ... so it'll be CONFIG_CAPABILITY=y? yes. selinux also is now a module and it too should probably be loaded, no, it's not. 2.6.9 it's CONFIG_SELINUX=y? Guess so.
Re: Status of Kernel 2.4.28 packages?
On Sun, Jan 02, 2005 at 08:16:44PM +, Tim Cutts wrote: 2.6 is still too new as far as most ISVs are concerned, and so Debian shouldn't lower the priority of work on 2.4 kernels too much just yet, in my opinion. Debian isn't lowering priority on Linux 2.4 work but individual people are.
Re: Problem with XFS and/or VM deadlock in 2.6.8
On Wed, Dec 22, 2004 at 09:16:00AM -0500, Lennart Sorensen wrote: I have been having trouble with the filesystem apparently locking up on a P4 2.8GHz HT machine (1GB ram, dual 120G SATA in raid1 with LVM on top). It locks up when I try and delete a lot of small files at once. Yesterday I tried to go delete a build dir for gcc-3.3 and while waiting for that 1.1GB to be deleted, went to delete a few other source dirs. When it got down to about 38M left for gcc-3.3 it stopped getting any further and top just showed rm in state D. A few other rm's eventually hit that state too. When I went to reboot the machine to get it back to working normally, I noticed the console had a bunch of messages from XFS and the VM. So I saved the messages in the hopes someone can figure something out to make this go away. Kernel version: 2.6.8-1-686-smp v2.6.8-10 (Debian sarge/sid build). All this should be fixed in 2.6.10-rc3. The XFS code in Debian's 2.6.8 is very much out of data and has various problems, but 2.6.8 is already really old and the various required core code changes make it hard to backport the XFS fixes.
Bug#284356: New release changed symbols thus rendering modules unloadable
On Wed, Dec 15, 2004 at 11:04:40AM +, Martin Michlmayr wrote: * Horms [EMAIL PROTECTED] [2004-12-15 13:28]: I checked 2.6 upstream and the refcount field is present. Curiously upstream 2.4 seems to neither include this field nor a fix for CAN-2004-0814 (N.B not CAN-2004-081 as I misquoted above). If anyone can correct me there I would be most grateful. Thanks for the analysis. Maybe you could contact upstream and ask why it hasn't been included and also mention this compatibility problem. It's not a problem. Linux doesn't gurantee any ABI stability.
Bug#278887: initrd-tools: Caused by megaraid2 module using /proc/scsi/megaraid
On Mon, Dec 13, 2004 at 06:38:57AM +0100, Harald Dunkel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp Niemann wrote: | | In the script /usr/sbin/mkinitrd, Line 497, is a find which seems to | search /proc/scsi for modules needed to mount the root device. If one | has the megaraid2 module loaded, there will be a directory called | megaraid in /proc/scsi. | Do you get the same misnamed module directory in /proc/scsi for kernel 2.6.x? There's no megaraid2 driver in 2.6. Megaraid 2.0.x is megaraid.ko, the newer 2.2.x driver is split into two modules, megaraid_mbox.ko and megaraid_mm.ko. In any case mkinitrd shouldn't rely on /proc/scsi at all.
Bug#284141: initrd-tools: no SCSI should not be a fatal error
On Fri, Dec 03, 2004 at 11:10:35PM +, Michael Shields wrote: Package: initrd-tools Version: 0.1.74 Severity: normal mkinitrd contains the lines: 8 | 11) if [ ! -d /proc/scsi ]; then echo $PROG: Cannot determine SCSI module 2 exit 1 fi This makes it impossible to upgrade from a custom kernel with no SCSI support to a standard Debian kernel. It would be better if mkinitrd instead left out all SCSI modules when /proc/scsi was missing. Actually no. /proc/scsi is (a) not present on all 2.6 kernels (only if legacy /proc/scsi/ support is enabled) (b) even if it is enabled on mainline kernels only drivers who actually have a -proc_info method show up there. Debian kernels have a totally broken patch that Herbert added to make mkinitrd still work. So mkinitrd simply must not rely on /proc/scsi at all when running on 2.6 kernels.
Re: Simultaneous loading of e100 and eepro100 by hotplug
On Thu, Dec 02, 2004 at 12:41:59PM +0100, Christoffer Sawicki wrote: What if the PCI ID associations in the kernel for eepro100 and e100 were changed so that a card is only associated with the module it works (best) with? The only issue I see with this approach is collecting the necesary data... There's not exact data I know of. One idea would be to remove all PCI IDs from eeproo100 and only allow assigning cards to it why the dynamic pci device ids through sysfs approach
Re: Dropping 386 support
On Sun, Oct 03, 2004 at 07:54:12PM -0400, Joey Hess wrote: Steve Langasek wrote: The d-i images really need to be built from kernel-image packages that are in the archive at the time we ship. Optimizing for 486 isn't a very good reason on its own to force another kernel build cycle. I had not even considered the impact of changing the optimisation, only of changing the package name. Steve's right, and we'd have to test the new build too. Also, doesn't optimising for 486 slow things down more than the current 386 builds on non-486 machines? The 386 build is installed whenever we cannot guess the right processor to optimise for. It's also installed all the time when the common netinst CD image is used, since we can only fit on kernel image on that CD. There's not really 486-optimized kernel as both core are so simple that gcc isn't doing any special instruction scheduling. The new instructions in the 486 are pretty important, though - e.g. bswap can optimize endian swapping quite nicely and cmpxchg is required for dri.
Bug#249510: acknowledged by developer (selinux in debian kernel)
On Wed, Sep 29, 2004 at 09:14:20PM +0100, Luke Kenneth Casson Leighton wrote: it's not a severe performance penalty. especially when it's disabled by default with selinux=0. Yes, all the indirect calls due to CONFIG_SECURITY are a performance penalty.
Bug#249510: acknowledged by developer (selinux in debian kernel)
On Wed, Sep 29, 2004 at 10:54:21PM +0100, Luke Kenneth Casson Leighton wrote: On Wed, Sep 29, 2004 at 10:33:28PM +0200, Christoph Hellwig wrote: On Wed, Sep 29, 2004 at 09:14:20PM +0100, Luke Kenneth Casson Leighton wrote: it's not a severe performance penalty. especially when it's disabled by default with selinux=0. Yes, all the indirect calls due to CONFIG_SECURITY are a performance penalty. ... of about 2%. sufficiently insignificant for both redhat _and_ suse to have started shipping, six months ago, kernels with selinux compiled in and disabled by default. It's more like 5% for the benchmarks I've seen (from HP), and yes, they complained to SuSE loudly because of that.
Re: tcp window problem in 2.6.8.1
On Sun, Sep 26, 2004 at 03:37:18PM +0200, Norbert Tretkowski wrote: * Jaakko Niemi wrote: [...] Has anyone looked at this issue? I could not find anything from list archives or from bts with quick search. A few days ago, Christoph mention that this has been fixed in svn already. I wouldn't call this a fix. It's a really bad hack to work around broken non-linux systems..
Re: aic7902 no longer works with 2.6.8-6
On Fri, Sep 24, 2004 at 12:22:39PM -0400, Avery Fay wrote: I just upgraded to the latest 2.6.8 kernel from an earlier one. I didn't change anything in the .config and now my machine no longer recognizes my scsi adapter, which is an aic7902. Reverting to and earlier kernel fixes the problem. Please send me lspci -vv output, thanks.
Bug#273191: no longer seems to support kernel command line variable values with spaces in their name
On Thu, Sep 23, 2004 at 03:40:18PM +0200, Joey Hess wrote: Package: kernel Version: 2.6.8 Severity: normal The 2.4 kernel supports parameters passed on the kernel command line of the form COUNTRY=United States; it understands the use of quotes around the value with a space in it, and sets the environment variable fine. It seems this support was dropped in the 2.6 kernel. Rusty, was this change intentional?
Bug#272983: kernel-image-2.6.8-1-686: TCP window scaling and broken router
On Thu, Sep 23, 2004 at 10:26:55AM +0200, Piotr Roszatycki wrote: Package: kernel-image-2.6.8-1-686 Version: 2.6.8-3 Severity: important Kernel 2.6.8 sets TCP window scaling to 7. It doesn't work with many broken routers including mine. It is possible to set net.ipv4.tcp_default_win_scale = 0 in sysctl.conf, but I suggest to prepare the patch which restore old behaviour, analogical to ECN bit patch. See http://lwn.net/Articles/92727/ A patch to back this out temporarily has been in SVN for a few days.
Bug#269604: Problems with some firewalls
On Thu, Sep 02, 2004 at 02:55:50PM +0200, Magnus Ekdahl wrote: Subject: Problems with some firewalls Package: kernel-image-2.6.8-1-k7 Version: 2.6.8-2 Severity: normal Somewhere after the 18th of august I got problems downloading my mail from pophost.ludd.luth.se. One of the administrators said that one possible reason for this is that Linux can't handle that their firewall won't strip TCP packages initially. As I understand him this should not be specific to ludd, but should apply to other sites too for newer 2.6 kernels. Can you check whether an echo 0 /proc/sys/net/ipv4/tcp_default_win_scale makes the problem go away?
Bug#272029: FATX filesystem support
On Sun, Sep 19, 2004 at 09:21:12AM +0200, Robert Millan wrote: On Fri, Sep 17, 2004 at 08:38:56AM +0200, Christoph Hellwig wrote: tags 272029 +upstream thanks Please get feature-patches merged upstream before bugging us, thanks. Upstream rejected them untill they're a lot more commonly used, which can also be read as supported in major distributions like Debian. Considering your opinion then the patches should go to /dev/null? Where are we going? FATX support is non-disruptive (Separate module from vfat. It won't even be loaded at all unless the user wants it). What are the problems with it? If your concern is with the release process, I can understand, and don't mind leaving this as post-sarge. That was for the Xbox hardware support. There's no reason not to push the partition and filesystem support - there's lots of foreign partitioning scheme and filesystem support in Linux.
looking for testers tg3 backport
I've backported the tg3 driver from current mainline which wasn't too easy because of our firmware removal and various interface changes in the mean time. I remember some people had problems with the IBM blades, care to test a kernel with the patch below? Testers with normal cards are also welcome of course ;-)
Bug#272082: #272082 kernel: Kernel panic 2.6.8-2 after tc qdisc add ingress, 2.6.8-3 ok.
close 272082 thanks Wonderfull, with a grave bug you _prevent_ -3 from going into testing. Closing the bug so it can be migrated.
