Re: Reducing number of i386 linux images
morning. On Tue, 21 Aug 2007, Bastian Blank wrote: I think its another time to reconsider the available i386 images. Currently we build: - 486 - 686 - 686-bigmem - k7 - amd64 I propose the following: - Rename 686-bigmem to 686-pae. pae is more than support for much memory, it includes things like NX. nack as already told on private channel to many pentium m out there are don't support pae - Drop k7. ack 486 image is fine for those and the hardware is no longer so wide spread. this should allow to add vserver-bigmem irc there is quite some demand. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reorganizing packages
On Tue, 21 Aug 2007, Bastian Blank wrote: * Rename linux(-[-a-z]+|)-2.6 into linux\1. * Drop the 2.6 version identifier from meta packages: cool thanks for picking that up :) -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reorganizing packages
On Tue, Aug 21, 2007 at 07:08:47PM +0200, Bastian Blank wrote:
Hi folks
* Rename linux(-[-a-z]+|)-2.6 into linux\1.
* Drop the 2.6 version identifier from meta packages:
Package: linux-image-686
Provides: linux-image, linux-latest-modules-2.6.22-1-686
Depends: linux-image-2.6.22-1-686
Package: linux-headers-686
Provides: linux-headers
Depends: linux-headers-2.6.22-1-686
Package: unionfs-modules-686
Provides: unionfs-modules
Depends: unionfs-modules-2.6.22-1-686, linux-latest-modules-2.6.22-1-686
I object; if and when there ever is a new upstream kernel branch that we
want to track separately this would have to be reverted, and in the meantime
it would cause more confusion and work because of the need to shuffle the
transition packages for users to get a smooth upgrade from etch.
The -2.6 doesn't hurt anything, I recommend leaving it as-is.
* Drop duplicated xen identifier from xen-linux-system:
Package: xen-linux-system-2.6.18-4-686
Depends: linux-image-2.6.18-4-xen-686 (= ${binary:Version}),
xen-hypervisor-3.0.3-1-i386-pae
That seems like a good improvement. It doesn't require changes to the
source package name, so is less disruptive on that front; and changes to xen
binary package names have less effect on the rest of the system (e.g., the
installer).
* Add meta packages for xen-linux-system:
Package: xen-linux-system-686
Provides: xen-linux-system
Depends: xen-linux-system-2.6.18-4-686, linux-image-686 (=
${binary:Version})
Also seems fair to me.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initramfs-tools / cryptoroot
Hello List, I'm administering several linux hosts, which are all set up to boot from a luks-encrypted partition (which partly live in LVM). I was hacked off to have to go down to the basement and enter the passwords manually on each and every reboot. So why not let this be managed by a central boot server? So I've set up the following process: - included sshd/dhclient3 in initrd by a hook - on boot time, either a static ip is assigned by a boot parameter or a dynamic one obtained by dhclient3 - sshd is started just before scripts/local-top/cryptoroot is run - while cryptsetup waits for a password to be entered, a ssh-connection can be made (thus being able to execute cryptsetup, vgchange etc remotely and automated...) - when the partition is unlocked, the cryptsetup process from cryptoroot is just killed, booting continues (especially this part is nasty (yet) as it may interfere with other hooks unexpectedly...) - dhclient3/sshd are killed - rest as usual. The remote_unlock_via_ssh.sh script is what i use for remote unlocking. The config files are stored gpg-encrypted, so i can safely boot root-encrypted machines from any trusted terminal remotely. Please let me know what you think. If you like it, I'd gladly document it further. Cheers, Daniel PS: I hope binary attachments to this list are ok, please let me know your conventions if not. initramfs-remoteunlock.tar.bz2 Description: Binary data
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote: - Drop k7. ack 486 image is fine for those and the hardware is no longer so wide spread. There are a whole lot of k7 boxes out there. I would not like to use the 486 flavour on my K7-smp servers, but I can run some benchmarks to verify performance penalities, if you point me to one suited for the task. I think if we are really going to drop k7, then we might tune some settings in the 686 flavour to support both CPU worlds equally good (or bad). But I guess In the end, it's all about cache line alignment, and the 686 flavour will perform more or less good enough on k7, allowing us to drop the other. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Reorganizing packages
Hello, On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote: I object; if and when there ever is a new upstream kernel branch that we want to track separately this would have to be reverted, and in the meantime it would cause more confusion and work because of the need to shuffle the transition packages for users to get a smooth upgrade from etch. Hmm, anyone heard of a planned 2.7 or 2.8 tree? My last infos where 2.6 is being kept for the time being. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 02:05:29PM +0200, Frederik Schueler wrote: There are a whole lot of k7 boxes out there. k6-3 and k7 are 686. Bastian -- What terrible way to die. There are no good ways. -- Sulu and Kirk, That Which Survives, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reorganizing packages
On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote: I object; if and when there ever is a new upstream kernel branch that we want to track separately this would have to be reverted, No. We never had complete support for more than one branch. And I really doubt that anyone wants the sarge-maintenance-problem back. and in the meantime it would cause more confusion and work because of the need to shuffle the transition packages for users to get a smooth upgrade from etch. The linux-image packages are already in etch. Bastian -- You can't evaluate a man by logic alone. -- McCoy, I, Mudd, stardate 4513.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reorganizing packages
On Wed, Aug 22, 2007 at 02:07:23PM +0200, Frederik Schueler wrote: On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote: I object; if and when there ever is a new upstream kernel branch that we want to track separately this would have to be reverted, and in the meantime it would cause more confusion and work because of the need to shuffle the transition packages for users to get a smooth upgrade from etch. Hmm, anyone heard of a planned 2.7 or 2.8 tree? My last infos where 2.6 is being kept for the time being. yes current upstream stated plan is that there is no need for such trees. as bonus it would separate dkt bug reports. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot
Package: linux-image-2.6.18-5-486 Version: 2.6.18.dfsg.1-13etch1 Severity: critical Justification: breaks the whole system -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The 2.6.18-5-486 kernel that was pushed over the last few days to replace 2.6.18-4 makes this system completely unbootable. I see GRUB load the kernel and then the screen goes blank; not a single boot message appears and the IDE LED on the host remains stuck at full ON, instead of flickering to indicate data transfers taking place as it would normally appear during booting. Being physically present at powerup to select the previous 2.6.18-4-486 kernel successfully boots the system, so this has to be a problem with 2.6.18-5-486. PS: I notice that a new initramfs tool was also pushed. If the break comes from there, please feel free to reassign. - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-486 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-5-486 depends on: ii coreutils 5.97-5.3 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85h tools for generating an initramfs ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo linux-image-2.6.18-5-486 recommends no packages. - -- debconf information: linux-image-2.6.18-5-486/postinst/kimage-is-a-directory: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-5-486/postinst/old-initrd-link-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/already-running-this-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/abort-install-2.6.18-5-486: linux-image-2.6.18-5-486/postinst/old-dir-initrd-link-2.6.18-5-486: true linux-image-2.6.18-5-486/postinst/old-system-map-link-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/failed-to-move-modules-2.6.18-5-486: linux-image-2.6.18-5-486/prerm/removing-running-kernel-2.6.18-5-486: true linux-image-2.6.18-5-486/prerm/would-invalidate-boot-loader-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/elilo-initrd-2.6.18-5-486: true linux-image-2.6.18-5-486/postinst/depmod-error-2.6.18-5-486: false linux-image-2.6.18-5-486/postinst/bootloader-error-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/bootloader-initrd-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/abort-overwrite-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/lilo-has-ramdisk: linux-image-2.6.18-5-486/postinst/depmod-error-initrd-2.6.18-5-486: false linux-image-2.6.18-5-486/postinst/create-kimage-link-2.6.18-5-486: true linux-image-2.6.18-5-486/postinst/bootloader-test-error-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/overwriting-modules-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/initrd-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/lilo-initrd-2.6.18-5-486: true -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGzFD0eXr56x4Muc0RAjGQAJ0WbHOVmWk8ba+73Oby+MCQyR2xLwCgsXAX 8eAggwb/dotDi1TblrQn4bY= =SCcg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot
On Wed, Aug 22, 2007 at 06:06:28PM +0300, Martin-Eric Racine wrote: Package: linux-image-2.6.18-5-486 Version: 2.6.18.dfsg.1-13etch1 Severity: critical Justification: breaks the whole system -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The 2.6.18-5-486 kernel that was pushed over the last few days to replace 2.6.18-4 makes this system completely unbootable. I see GRUB load the kernel and then the screen goes blank; not a single boot message appears and the IDE LED on the host remains stuck at full ON, instead of flickering to indicate data transfers taking place as it would normally appear during booting. Being physically present at powerup to select the previous 2.6.18-4-486 kernel successfully boots the system, so this has to be a problem with 2.6.18-5-486. PS: I notice that a new initramfs tool was also pushed. If the break comes from there, please feel free to reassign. You are the first person to report such a problem and, given there were no changes that should be in effect that early in the boot process, I suspect some other local failure. Please try re-installing this image, after possibly fscking your disk. If that doesn't work, please try 2.6.18.dfsg.1-13 and see if it works. If the latest kernel is still not working, please provide the dmesg output of the last working kernel. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439020: Please could CONFIG_TCG_TPM be set to 'm'
reassign linux-2.6 thanks On Tue, Aug 21, 2007 at 07:20:59PM +0100, Martin wrote: I was looking at trying out Trusted Grub ( http://www.prosec.rub.de/trusted_grub.html ) but found that the stock Debian kernels seem to be built without the required drivers. It appears they were disabled by in commit r3389 to the kernel-svn: http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2005-June/002083.html As far as I can see the only reason given for this was: http://lists.debian.org/debian-kernel/2005/06/msg00364.html I appreciate that this is an emotive issue for some but I dispute the assertion that these are useless. It seems there are other developers who may be interested in this as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409591 As far as I see it, the TPM chip is just a tool, whether it is used by the owner to defend their computer against tampering or whether it is used by $LARGE_CORPORATION as part of a system to take away people's freedoms is a separate human and a political issue. Thus I think it would be nice to have TPM drivers in Debian as then whoever has root on that has the choice of whether or not to use the chip. maks, looks like you disabled them. comments? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 439020 to linux-2.6
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 reassign 439020 linux-2.6 Bug#439020: Please could CONFIG_TCG_TPM be set to 'm' Bug reassigned from package `linux-image-2.6-686' to `linux-2.6'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439134: marked as done (linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot)
Your message dated Wed, 22 Aug 2007 18:47:25 +0300 with message-id [EMAIL PROTECTED] and subject line Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: linux-image-2.6.18-5-486 Version: 2.6.18.dfsg.1-13etch1 Severity: critical Justification: breaks the whole system -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The 2.6.18-5-486 kernel that was pushed over the last few days to replace 2.6.18-4 makes this system completely unbootable. I see GRUB load the kernel and then the screen goes blank; not a single boot message appears and the IDE LED on the host remains stuck at full ON, instead of flickering to indicate data transfers taking place as it would normally appear during booting. Being physically present at powerup to select the previous 2.6.18-4-486 kernel successfully boots the system, so this has to be a problem with 2.6.18-5-486. PS: I notice that a new initramfs tool was also pushed. If the break comes from there, please feel free to reassign. - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-486 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-5-486 depends on: ii coreutils 5.97-5.3 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85h tools for generating an initramfs ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo linux-image-2.6.18-5-486 recommends no packages. - -- debconf information: linux-image-2.6.18-5-486/postinst/kimage-is-a-directory: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-5-486/postinst/old-initrd-link-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/already-running-this-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/abort-install-2.6.18-5-486: linux-image-2.6.18-5-486/postinst/old-dir-initrd-link-2.6.18-5-486: true linux-image-2.6.18-5-486/postinst/old-system-map-link-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/failed-to-move-modules-2.6.18-5-486: linux-image-2.6.18-5-486/prerm/removing-running-kernel-2.6.18-5-486: true linux-image-2.6.18-5-486/prerm/would-invalidate-boot-loader-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/elilo-initrd-2.6.18-5-486: true linux-image-2.6.18-5-486/postinst/depmod-error-2.6.18-5-486: false linux-image-2.6.18-5-486/postinst/bootloader-error-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/bootloader-initrd-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/abort-overwrite-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/lilo-has-ramdisk: linux-image-2.6.18-5-486/postinst/depmod-error-initrd-2.6.18-5-486: false linux-image-2.6.18-5-486/postinst/create-kimage-link-2.6.18-5-486: true linux-image-2.6.18-5-486/postinst/bootloader-test-error-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/overwriting-modules-2.6.18-5-486: true linux-image-2.6.18-5-486/preinst/initrd-2.6.18-5-486: linux-image-2.6.18-5-486/preinst/lilo-initrd-2.6.18-5-486: true -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGzFD0eXr56x4Muc0RAjGQAJ0WbHOVmWk8ba+73Oby+MCQyR2xLwCgsXAX 8eAggwb/dotDi1TblrQn4bY= =SCcg -END PGP SIGNATURE- ---End Message--- ---BeginMessage--- On 8/22/07, dann frazier [EMAIL PROTECTED] wrote: On Wed, Aug 22, 2007 at 06:06:28PM +0300, Martin-Eric Racine wrote: Package: linux-image-2.6.18-5-486 Version: 2.6.18.dfsg.1-13etch1 Severity: critical Justification: breaks the whole system -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The 2.6.18-5-486 kernel that was pushed over the last few days to replace 2.6.18-4 makes this system completely unbootable. I see GRUB load the kernel and then the screen goes blank; not a single boot message appears and the IDE LED on the host remains stuck at full ON, instead of flickering to indicate data transfers taking place as it would normally appear during booting. Being physically present at powerup to select the previous 2.6.18-4-486 kernel successfully boots the system, so this has to be a problem with 2.6.18-5-486. PS: I notice that a new initramfs tool was also pushed. If the break comes from there, please feel free to reassign. You are the first person to report such a
problem w/ snapshot builds?
Its been over 24 hrs since I committed something to the etch branch and I haven't yet seen new builds appear in: http://kernel-archive.buildserver.net/pool/main/l/linux-2.6/ So, I checked the status page to see if there was a failure, but it looks like its currently down: http://stats.buildserver.net/packages/status.php?email=debian-kernelpackages=arches=subdist=kernel-dists Last night it said the page was last updated Jan 1, 1970 - today it has a current date, but I still don't see any logs. I assumed snapshot builds happened automatically - but maybe I need trigger one somehow? Or are snapshots just offline atm? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402770: linux-2.6: ip_conntrack module oopses
Hi, this problem occurs also on my SGI Indigo2 with 256MB RAM: BUG: warning at kernel/softirq.c:137/local_bh_enable() Call Trace: [8800f850] dump_stack+0x18/0x58 [880413dc] local_bh_enable+0x11c/0x128 [c00e5d58] $L436+0x50/0x88 [ip_conntrack] # cat /proc/cpuinfo system type : SGI Indigo2 processor : 0 cpu model : R4400SC V6.0 FPU V0.0 BogoMIPS: 124.67 wait instruction: no microsecond timers : yes tlb_entries : 48 extra interrupt vector : no hardware watchpoint : yes ASEs implemented: VCED exceptions : 1225430 VCEI exceptions : 15227 # lsmod Module Size Used by ipv6 536464 12 xt_tcpudp 5248 16 xt_state3072 4 ip_conntrack 87312 1 xt_state nfnetlink 11952 1 ip_conntrack iptable_filter 4288 1 ip_tables 40128 1 iptable_filter x_tables 27440 3 xt_tcpudp,xt_state,ip_tables dm_snapshot32352 0 dm_mirror 38224 0 dm_mod109376 2 dm_snapshot,dm_mirror # uname -a Linux archon 2.6.18-5-r4k-ip22 #1 Mon Aug 13 00:26:41 BST 2007 mips64 GNU/Linux I can provide more information if needed. Mic -- Ein Un*x mit einer falschen Zeit, ist ein Tor zur Hölle :) Stefan Huber in at.linux
Bug#439020: Please could CONFIG_TCG_TPM be set to 'm'
On Wed, Aug 22, 2007 at 09:37:47AM -0600, dann frazier wrote: Debian kernels seem to be built without the required drivers. It appears they were disabled by in commit r3389 to the kernel-svn: http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2005-June/002083.html As far as I can see the only reason given for this was: http://lists.debian.org/debian-kernel/2005/06/msg00364.html I appreciate that this is an emotive issue for some but I dispute the assertion that these are useless. It seems there are other developers who may be interested in this as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409591 As far as I see it, the TPM chip is just a tool, whether it is used by the owner to defend their computer against tampering or whether it is used by $LARGE_CORPORATION as part of a system to take away people's freedoms is a separate human and a political issue. Thus I think it would be nice to have TPM drivers in Debian as then whoever has root on that has the choice of whether or not to use the chip. maks, looks like you disabled them. comments? back in the 2005 days there was _zero_ userspace for them, thus they were useless. i'm ok to reconsider the old decision and to sync with fedora. i'll reenable them on trunk once buildserver is back. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 439134 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 severity 439134 important Bug#439134: linux-image-2.6.18-5-486: 2.6.18-5-486 fails to boot Severity set to `important' from `critical' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote: - Rename 686-bigmem to 686-pae. pae is more than support for much memory, it includes things like NX. nack as already told on private channel to many pentium m out there are don't support pae What is the problem than? They should never install them. - Drop k7. ack 486 image is fine for those and the hardware is no longer so wide spread. k7 is 686 compatible. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439149: kernel panic linux-image-2.6.18-5-xen-amd64 on xeon at starting multiple domUs
Package: linux-image-2.6-xen-amd64 Version: 2.6.18-5 When I start up multiple domUs (for example the third one) I get the following kernel panic: Aug 22 18:22:13 fourty2 kernel: --- [cut here ] - [please bite here ] - Aug 22 18:22:13 fourty2 kernel: Kernel BUG at drivers/xen/core/evtchn.c:481 Aug 22 18:22:13 fourty2 kernel: invalid opcode: [1] SMP Aug 22 18:22:13 fourty2 kernel: CPU 3 Aug 22 18:22:13 fourty2 kernel: Modules linked in: xt_tcpudp xt_physdev iptable_filter ip_tables x_tables bridge netloop ipv6 button ac battery loop psmouse serial_core pcspkr shpchp pci_hotplug serio_raw evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod ide_generic ide_cd cdrom usbhid piix sd_mod generic ide_core uhci_hcd bnx2 ehci_hcd megaraid_sas scsi_mod fan Aug 22 18:22:13 fourty2 kernel: Pid: 21, comm: xenwatch Not tainted 2.6.18-5-xen-amd64 #1 Aug 22 18:22:13 fourty2 kernel: RIP: e030:[80360f56] [80360f56] retrigger+0x26/0x3e Aug 22 18:22:13 fourty2 kernel: RSP: e02b:8800f2a9fd88 EFLAGS: 00010046 Aug 22 18:22:13 fourty2 kernel: RAX: RBX: 8e00 RCX: ff578000 Aug 22 18:22:13 fourty2 kernel: RDX: 0030 RSI: 8800f2a9fd30 RDI: 011c Aug 22 18:22:13 fourty2 kernel: RBP: 804ce280 R08: 8800f2933c70 R09: 8800ef6fb500 Aug 22 18:22:13 fourty2 kernel: R10: 8800ef6fb000 R11: 80360f30 R12: 011c Aug 22 18:22:13 fourty2 kernel: R13: 804ce2bc R14: R15: 0008 Aug 22 18:22:13 fourty2 kernel: FS: 2b19b5c046d0() GS:804c4180() knlGS: Aug 22 18:22:13 fourty2 kernel: CS: e033 DS: ES: Aug 22 18:22:13 fourty2 kernel: Process xenwatch (pid: 21, threadinfo 8800f2a9e000, task 8800f2a77080) Aug 22 18:22:13 fourty2 kernel: Stack: 802a06bc 8800ef6fb500 8800ef6fb500 Aug 22 18:22:13 fourty2 kernel: 8800f2a9fde0 020b 8036dac1 Aug 22 18:22:13 fourty2 kernel: 8036df39 8800f2a9fea4 Aug 22 18:22:13 fourty2 kernel: Call Trace: Aug 22 18:22:13 fourty2 kernel: [802a06bc] enable_irq+0x9d/0xbc Aug 22 18:22:13 fourty2 kernel: [8036dac1] __netif_up+0xc/0x15 Aug 22 18:22:13 fourty2 kernel: [8036df39] netif_map+0x2a6/0x2d8 Aug 22 18:22:13 fourty2 kernel: [8035c29a] bus_for_each_dev+0x61/0x6e Aug 22 18:22:13 fourty2 kernel: [80366743] xenwatch_thread+0x0/0x145 Aug 22 18:22:13 fourty2 kernel: [80366743] xenwatch_thread+0x0/0x145 Aug 22 18:22:13 fourty2 kernel: [80368283] frontend_changed+0x2ba/0x4f9 Aug 22 18:22:13 fourty2 kernel: [80366743] xenwatch_thread+0x0/0x145 Aug 22 18:22:13 fourty2 kernel: [8028f847] keventd_create_kthread+0x0/0x61 Aug 22 18:22:13 fourty2 kernel: [80365b51] xenwatch_handle_callback+0x15/0x48 Aug 22 18:22:13 fourty2 kernel: [80366870] xenwatch_thread+0x12d/0x145 Aug 22 18:22:13 fourty2 kernel: [8028fa0a] autoremove_wake_function+0x0/0x2e Aug 22 18:22:13 fourty2 kernel: [8028f847] keventd_create_kthread+0x0/0x61 Aug 22 18:22:13 fourty2 kernel: [80366743] xenwatch_thread+0x0/0x145 Aug 22 18:22:13 fourty2 kernel: [802334da] kthread+0xd4/0x107 Aug 22 18:22:13 fourty2 kernel: [8025c7dc] child_rip+0xa/0x12 Aug 22 18:22:13 fourty2 kernel: [8028f847] keventd_create_kthread+0x0/0x61 Aug 22 18:22:13 fourty2 kernel: [80233406] kthread+0x0/0x107 Aug 22 18:22:13 fourty2 kernel: [8025c7d2] child_rip+0x0/0x12 Aug 22 18:22:13 fourty2 kernel: Aug 22 18:22:13 fourty2 kernel: Aug 22 18:22:13 fourty2 kernel: Code: 0f 0b 68 94 db 41 80 c2 e1 01 f0 0f ab 91 00 08 00 00 b8 01 Aug 22 18:22:13 fourty2 kernel: RIP [80360f56] retrigger+0x26/0x3e Aug 22 18:22:13 fourty2 kernel: RSP 8800f2a9fd88 with version 2.6.18-4 everything works fine. here my cat /proc/cpuinfo: fourty2:/var/log# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU5120 @ 1.86GHz stepping: 6 cpu MHz : 1862.119 cache size : 4096 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips: 4656.34 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU5120 @ 1.86GHz stepping: 6 cpu MHz : 1862.119 cache size : 4096 KB physical
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 07:18:08PM +0200, Bastian Blank wrote: On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote: - Rename 686-bigmem to 686-pae. pae is more than support for much memory, it includes things like NX. nack as already told on private channel to many pentium m out there are don't support pae What is the problem than? They should never install them. waldi, It'd probably help if you listed out more specific statements about your suggested migrations. This way we can better understand the implications and what benchmarks maybe relevant. For example: Dropping 686-bigmem --- - 686-bigmem dies - 686 flavour acquires PAE support - Users with currently installed -686 systems somehow upgrade to the 486 flavour Dropping k7 --- ... -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels
Hi Adrian, On Wed, Aug 22, 2007 at 04:13:19AM +0200, Josip Rodin wrote: I'm reporting this bug that I have been seeing for a while and which is a regression from a few months/years ago - the line-in input simply doesn't work right. arecord(1) just doesn't record anything with it, it doesn't show any errors, it records silence. The recording from the same external source works just fine with the microphone input. I re-selected the old-style i810_audio driver in 2.6.21 and compiled it, unloaded the ALSA driver, loaded the old driver, and voila, everything went back to normal, I can hear the TV sound just fine. So, it might be that this is an OSS-ALSA regression that slipped through the cracks? While browsing kernel options, I noticed: Please contact Adrian Bunk [EMAIL PROTECTED] if you had to say Y here because your hardware is not properly supported by ALSA. ...in the description of CONFIG_OSS_OBSOLETE, so, here I am :) This is Debian bug #439072 (and #384933 also looks suspiciously similar, if I might add). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#434752: Kernel hangs when I echo 0 /proc/sys/vm/vdso_enabled
Processing commands for [EMAIL PROTECTED]: tags 434752 + patch Bug#434752: Kernel hangs when I echo 0 /proc/sys/vm/vdso_enabled There were no tags set. Tags added: patch stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434752: Kernel hangs when I echo 0 /proc/sys/vm/vdso_enabled
tags 434752 + patch
stop
On Thu, Jul 26, 2007, Loïc Minier wrote:
Since some months, I get unusable backtraces from gdb; I was pointed at
an OpenSuse bug at:
https://bugzilla.novell.com/show_bug.cgi?id=258433
I extracted the patch Novell/OpenSuse applied to its kernel, would be
nice to get it in Debian.
--
Loïc Minier
Subject: i386: allow debuggers to access the vsyscall page with compat vDSO
From: Jan Beulich [EMAIL PROTECTED]
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
arch/i386/kernel/sysenter.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux/arch/i386/kernel/sysenter.c
===
--- linux.orig/arch/i386/kernel/sysenter.c
+++ linux/arch/i386/kernel/sysenter.c
@@ -336,7 +336,9 @@ struct vm_area_struct *get_gate_vma(stru
int in_gate_area(struct task_struct *task, unsigned long addr)
{
- return 0;
+ const struct vm_area_struct *vma = get_gate_vma(task);
+
+ return vma addr = vma-vm_start addr vma-vm_end;
}
int in_gate_area_no_task(unsigned long addr)
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote: I propose the following: - Rename 686-bigmem to 686-pae. pae is more than support for much memory, it includes things like NX. nack as already told on private channel to many pentium m out there are don't support pae OTOH, there's little reason to ship a 486 *and* a 686 kernel, probably easiest to just drop the 686 and rename 486 to generic or something. - Drop k7. ack 486 image is fine for those and the hardware is no longer so wide spread. word. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439167: linux-2.6: forcedeth MAC correction bug in Etch
Package: linux-2.6
Version: 2.6.18.dfsg.1-13etch1
Severity: important
Hi Dann,
There's a nasty bug in NVidia onboard ethernet chipsets:
The MAC address provided by the BIOS is invalid (it's inverted); as a
consequence
the kernel creates a random MAC as a workaround. In combination with udev this
leads
to a new ethX device every time you reboot.
I've pulled the relevant fixes from git for the kernel in Univention Corporate
Server 2.0, a Debian-derived distribution based on Etch. We've updated the
Etch kernel with the attached patch and verified it to work on the system below:
http://www.asus.de/products.aspx?l1=1l2=2l3=407l4=0model=1155modelmenu=2
(It should apply to a wide range of NVidia-based systems)
So, I propose to update forcedeth in the r2 point update. This is been fixed in
linux-2.6 in 2.6.20 or 2.6.21.
Cheers,
Moritz
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core)
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
diff -Naur linux-2.6-2.6.18.dfsg.1.orig/debian/patches/features/forcedeth-mac-correction.patch linux-2.6-2.6.18.dfsg.1/debian/patches/features/forcedeth-mac-correction.patch
--- linux-2.6-2.6.18.dfsg.1.orig/debian/patches/features/forcedeth-mac-correction.patch 1970-01-01 01:00:00.0 +0100
+++ linux-2.6-2.6.18.dfsg.1/debian/patches/features/forcedeth-mac-correction.patch 2007-08-18 13:21:11.0 +0200
@@ -0,0 +1,140 @@
+--- drivers/net/forcedeth.c.orig 2007-08-13 15:59:52.0 +0200
a/drivers/net/forcedeth.c 2007-08-13 15:59:09.0 +0200
+@@ -168,6 +169,7 @@
+ #define DEV_HAS_PAUSEFRAME_TX 0x0200 /* device supports tx pause frames */
+ #define DEV_HAS_STATISTICS 0x0400 /* device supports hw statistics */
+ #define DEV_HAS_TEST_EXTENDED 0x0800 /* device supports extended diagnostic test */
++#define DEV_HAS_CORRECT_MACADDR 0x4000 /* device supports correct mac address order */
+
+ enum {
+ NvRegIrqStatus = 0x000,
+@@ -262,7 +264,8 @@
+ NvRegRingSizes = 0x108,
+ #define NVREG_RINGSZ_TXSHIFT 0
+ #define NVREG_RINGSZ_RXSHIFT 16
+- NvRegUnknownTransmitterReg = 0x10c,
++ NvRegTransmitPoll = 0x10c,
++#define NVREG_TRANSMITPOLL_MAC_ADDR_REV 0x8000
+ NvRegLinkSpeed = 0x110,
+ #define NVREG_LINKSPEED_FORCE 0x1
+ #define NVREG_LINKSPEED_10 1000
+@@ -1178,7 +1181,7 @@
+ KERN_INFO nv_stop_tx: TransmitterStatus remained busy);
+
+ udelay(NV_TXSTOP_DELAY2);
+- writel(0, base + NvRegUnknownTransmitterReg);
++ writel(readl(base + NvRegTransmitPoll) NVREG_TRANSMITPOLL_MAC_ADDR_REV, base + NvRegTransmitPoll);
+ }
+
+ static void nv_txrx_reset(struct net_device *dev)
+@@ -3918,7 +3921,7 @@
+ oom = nv_init_ring(dev);
+
+ writel(0, base + NvRegLinkSpeed);
+- writel(0, base + NvRegUnknownTransmitterReg);
++ writel(readl(base + NvRegTransmitPoll) NVREG_TRANSMITPOLL_MAC_ADDR_REV, base + NvRegTransmitPoll);
+ nv_txrx_reset(dev);
+ writel(0, base + NvRegUnknownSetupReg6);
+
+@@ -4094,7 +4097,7 @@
+ unsigned long addr;
+ u8 __iomem *base;
+ int err, i;
+- u32 powerstate;
++ u32 powerstate, txreg;
+
+ dev = alloc_etherdev(sizeof(struct fe_priv));
+ err = -ENOMEM;
+@@ -4281,12 +4284,31 @@
+ np-orig_mac[0] = readl(base + NvRegMacAddrA);
+ np-orig_mac[1] = readl(base + NvRegMacAddrB);
+
+- dev-dev_addr[0] = (np-orig_mac[1] 8) 0xff;
+- dev-dev_addr[1] = (np-orig_mac[1] 0) 0xff;
+- dev-dev_addr[2] = (np-orig_mac[0] 24) 0xff;
+- dev-dev_addr[3] = (np-orig_mac[0] 16) 0xff;
+- dev-dev_addr[4] = (np-orig_mac[0] 8) 0xff;
+- dev-dev_addr[5] = (np-orig_mac[0] 0) 0xff;
++ /* check the workaround bit for correct mac address order */
++ txreg = readl(base + NvRegTransmitPoll);
++ if ((txreg NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
++ (id-driver_data DEV_HAS_CORRECT_MACADDR)) {
++ /* mac address is already in correct order */
++ dev-dev_addr[0] = (np-orig_mac[0] 0) 0xff;
++ dev-dev_addr[1] = (np-orig_mac[0] 8) 0xff;
++ dev-dev_addr[2] = (np-orig_mac[0] 16) 0xff;
++ dev-dev_addr[3] = (np-orig_mac[0] 24) 0xff;
++ dev-dev_addr[4] = (np-orig_mac[1] 0) 0xff;
++ dev-dev_addr[5] = (np-orig_mac[1] 8) 0xff;
++ } else {
++ /* need to reverse mac address to correct order */
++ dev-dev_addr[0] = (np-orig_mac[1] 8) 0xff;
++ dev-dev_addr[1] = (np-orig_mac[1] 0) 0xff;
++ dev-dev_addr[2] = (np-orig_mac[0] 24) 0xff;
++ dev-dev_addr[3] = (np-orig_mac[0] 16) 0xff;
++ dev-dev_addr[4] = (np-orig_mac[0] 8) 0xff;
++ dev-dev_addr[5] = (np-orig_mac[0] 0) 0xff;
++ /* set permanent address to be correct aswell */
++ np-orig_mac[0] = (dev-dev_addr[0] 0) + (dev-dev_addr[1] 8) +
++ (dev-dev_addr[2] 16) + (dev-dev_addr[3] 24);
++ np-orig_mac[1] = (dev-dev_addr[4] 0) + (dev-dev_addr[5] 8);
++ writel(txreg|NVREG_TRANSMITPOLL_MAC_ADDR_REV, base + NvRegTransmitPoll);
++ }
+ memcpy(dev-perm_addr, dev-dev_addr, dev-addr_len);
+
+ if
Re: Reorganizing packages
On Wed, Aug 22, 2007 at 02:21:18PM +0200, Bastian Blank wrote: On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote: I object; if and when there ever is a new upstream kernel branch that we want to track separately this would have to be reverted, No. We never had complete support for more than one branch. And I really doubt that anyone wants the sarge-maintenance-problem back. No, I'm sure we don't want it; but if upstream ever changes its mind later about 2.6 being the one true kernel, we might still have it. and in the meantime it would cause more confusion and work because of the need to shuffle the transition packages for users to get a smooth upgrade from etch. The linux-image packages are already in etch. But they weren't *used* as the metapackages that users installed. We still need linux-image-2.6-foo packages in lenny for upgrade, if nothing else. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reorganizing packages
Steve Langasek [EMAIL PROTECTED] writes: On Wed, Aug 22, 2007 at 02:21:18PM +0200, Bastian Blank wrote: On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote: I object; if and when there ever is a new upstream kernel branch that we want to track separately this would have to be reverted, No. We never had complete support for more than one branch. And I really doubt that anyone wants the sarge-maintenance-problem back. No, I'm sure we don't want it; but if upstream ever changes its mind later about 2.6 being the one true kernel, we might still have it. I agree with you Steve and personally I don't see any good reason for dropping it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of linux-latest-2.6_6etch2_ia64.changes
linux-latest-2.6_6etch2_ia64.changes uploaded successfully to localhost along with the files: linux-latest-2.6_6etch2.dsc linux-latest-2.6_6etch2.tar.gz linux-image-itanium_2.6.18+6etch2_ia64.deb linux-image-2.6-itanium_2.6.18+6etch2_ia64.deb linux-headers-2.6-itanium_2.6.18+6etch2_ia64.deb linux-image-mckinley_2.6.18+6etch2_ia64.deb linux-image-2.6-mckinley_2.6.18+6etch2_ia64.deb linux-headers-2.6-mckinley_2.6.18+6etch2_ia64.deb kernel-image-2.6-itanium_2.6.18+6etch2_ia64.deb kernel-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb kernel-image-2.6-mckinley_2.6.18+6etch2_ia64.deb kernel-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb linux-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb linux-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-latest-2.6 update in stable incomplete
On Tue, Aug 21, 2007 at 09:10:02AM -0600, dann frazier wrote: On Tue, Aug 21, 2007 at 09:15:22AM +0200, Bastian Blank wrote: On Mon, Aug 20, 2007 at 04:10:31PM -0600, dann frazier wrote: Are security updates visible at this point in the install. I think they are (except for network-less installs). No. Bummer, but at least it fixes upgrades. luk_work 22:55:11 dannf: from SRM's POV the security update for the kernel on arm is a go! So I'm planning to proceed. Last build (hppa) just came in, so its released. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Root on LVM bug
Greetings, I recently installed etch on an amd64 box which previously had Fedora. It had a small ext2 /boot and large LVM, so I shrunk Fedora's volume and made a new one for Debian, where I installed everything. I included the LVM modules in /etc/initramfs-tools/modules . Then I added the following section to /boot/grub/menu.lst : title Debian root (hd0,0) kernel /vmlinuz-2.6.18-4-amd64 root=/dev/VolGroup00/LogVol02 initrd /initrd.img-2.6.18-4-amd64 When I booted, it sat at Begin: Waiting for root file system... but the Fedora 2.6.11 kernel started right up with otherwise identical options (except that it couldn't load the Fedora modules in Debian). After a few hours of messing around, on a whim I tried changing the root= parameter to /dev/mapper/VolGroup00-LogVol02 , which worked! So I believe something is wrong with either mount or udev used in the initramfs, such that it either doesn't create the /dev/groupname entries, or can't mount them. I did a ton of searching and couldn't find anything, so I don't think this is a known issue. Given that installed Debian and other distros can use both /dev/mapper and /dev/groupname, shouldn't this be supported in the root= parameter in grub? Where is the bug, and has it been fixed already in lenny? If not, how can I help? [Please cc me in replies] Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438458: same problem
Have the same problem with linux-image-2.6.18-5-amd64 2.6.18.dfsg.1-13etch1 after upgrading (linux-image-2.6.18-4-amd64 work fine) Motherboard P5B Display adapter ATI RADEON X1600 Series Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz MemTotal4031636 kB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438458: same problem
Have the same problem with linux-image-2.6.18-5-amd64 2.6.18.dfsg.1-13etch1 after upgrading (linux-image-2.6.18-4-amd64 work fine) Motherboard P5B Display adapter ATI RADEON X1600 Series Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz MemTotal4031636 kB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reorganizing packages
Otavio Salvador [EMAIL PROTECTED] writes: Steve Langasek [EMAIL PROTECTED] writes: On Wed, Aug 22, 2007 at 02:21:18PM +0200, Bastian Blank wrote: On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote: I object; if and when there ever is a new upstream kernel branch that we want to track separately this would have to be reverted, No. We never had complete support for more than one branch. And I really doubt that anyone wants the sarge-maintenance-problem back. No, I'm sure we don't want it; but if upstream ever changes its mind later about 2.6 being the one true kernel, we might still have it. I agree with you Steve and personally I don't see any good reason for dropping it. After talking with maks at IRC I've changed my mind and now I agree on the renaming. The only good reason that I still have to keep it is due GIT tree name but I don't think it's a requirement to us to follow it. experimental might be used if we had a linux-2.7 or something while it's not OK for sid and Maks and Bastian agree that we're not going to have more the one kernel source on the distro anymore so there's no more need to allow this diversion. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reorganizing packages
On Wed, Aug 22, 2007 at 10:49:30PM -0300, Otavio Salvador wrote: experimental might be used if we had a linux-2.7 or something while it's not OK for sid and Maks and Bastian agree that we're not going to have more the one kernel source on the distro anymore so there's no more need to allow this diversion. It's short-sighted to agree that we're not going to have more than one kernel source in the distro when the circumstances have not yet arisen where we have to consider what to do about a new upstream major version. For that matter, if someone in the project decides that they have need for a different kernel than the one the kernel team wants to ship (for a particular port, or to support older hardware, or to support a newer cutting-edge kernel design, or for some other reason), the kernel team doesn't have the authority to prohibit this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 09:39:02AM -0400, Kyle McMartin wrote: On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote: I propose the following: - Rename 686-bigmem to 686-pae. pae is more than support for much memory, it includes things like NX. nack as already told on private channel to many pentium m out there are don't support pae OTOH, there's little reason to ship a 486 *and* a 686 kernel, probably easiest to just drop the 686 and rename 486 to generic or something. Is that based on benchmarks, or on an assessment that non-PAE 686 machines are uninteresting? I would think that if the performance benefit of 686 over 486 is measurable at all, it's precisely the older systems that benefit most from having a separate kernel flavor, in terms of the hardware remaining useful. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 08:20:22PM -0700, Steve Langasek wrote: On Wed, Aug 22, 2007 at 09:39:02AM -0400, Kyle McMartin wrote: On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote: I propose the following: - Rename 686-bigmem to 686-pae. pae is more than support for much memory, it includes things like NX. nack as already told on private channel to many pentium m out there are don't support pae OTOH, there's little reason to ship a 486 *and* a 686 kernel, probably easiest to just drop the 686 and rename 486 to generic or something. Is that based on benchmarks, or on an assessment that non-PAE 686 machines are uninteresting? I would think that if the performance benefit of 686 over 486 is measurable at all, it's precisely the older systems that benefit most from having a separate kernel flavor, in terms of the hardware remaining useful. I hope it will be based on benchmarks - I see no reason to drop any flavours if there maybe a significant performance benefit for a significant part of our userbase[1]. I want as many people to run the official kernel as possible and not to regress to the woody days where any clueful admin built/ran their own. In lieu of convincing benchmarks, the default answer should be to *not* drop flavours. Without numbers, users are going to believe (rightfully or not) that running Debian's kernel reduces the power they get from their hardware. That factor is worth the slower build times and extra disk space. fwiw, a coworker is looking into the availability of a benchmark that should be good for comparing pae/non-pae. [1] whatever that means. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
