Bug#489684: firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available
Package: firmware-iwlwifi Version: 0.11 Severity: important Announcment: http://sourceforge.net/mailarchive/forum.php?thread_name=1215135788.14590.598.camel%40debian.sh.intel.comforum_name=ipw3945-devel Download: http://www.intellinuxwireless.org/iwlwifi/downloads/iwlwifi-4965-ucode-228.57.1.21.tgz Bumping to important because I have reports from different people about better stability when switching ssids and improved data rates (from 50 kbit/s to 2mbyte/s!) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc6 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481346: closed by maximilian attems [EMAIL PROTECTED] (linux-image-2.6.18-6-686: kernel oops handling paging request)
Debian Bug Tracking System scrisse in data 03/07/2008 16:30: [...] that mm trouble has been fixed in newer linux images. etch + half kernel have the upstream fix. as the oops is quite rare and fix hasn't been clearly identified it is recommeded to upgrade to etch + half kernel - http://wiki.debian.org/EtchAndAHalf In effect EtchAndHalf seems to have solved the problem... Thank you very much Piviul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405810: Please provide package with vmlinuX, similar to kernel-debuginfo on redhat
The problem is that the vmlinuz file in /boot and modules in /lib/modules do not carry debug symbols. Therefor the vmlinux and unstripped modules would be needed in a linux-debug-2.6.x-x-all package carrying these would be nice. See the following discussion about systemtap for example: http://sources.redhat.com/ml/systemtap/2008-q3/msg00048.html This is not a issue for people building their own kernels, but for people tracing production systems running released debian kernels, where no debuginfo is preserved from the build. -- rm -rf only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 489684 is normal
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 severity 489684 normal Bug#489684: firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available Severity set to `normal' from `important' 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#489684: firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available
On Mon, Jul 07, 2008 at 09:07:10AM +0200, Joerg Friedrich wrote: Bumping to important because I have reports from different people about better stability when switching ssids and improved data rates (from 50 kbit/s to 2mbyte/s!) The firmware changes the ABI and is not yet referenced in Linus' tree. Bastian -- There are always alternatives. -- Spock, The Galileo Seven, stardate 2822.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489684: firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available
Bastian Blank schrieb am Montag, 07. Juli 2008 um 10:33:01 +0200: On Mon, Jul 07, 2008 at 09:07:10AM +0200, Joerg Friedrich wrote: Bumping to important because I have reports from different people about better stability when switching ssids and improved data rates (from 50 kbit/s to 2mbyte/s!) The firmware changes the ABI and is not yet referenced in Linus' tree. Bastian There are two versions of the new firmware one for ABI Ver.1 and one for ABI Ver.2 (from today) -- Jörg Friedrich There are only 10 types of people: Those who understand binary and those who don't. signature.asc Description: Digital signature
Bug#489684: firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available
Bastian Blank schrieb am Montag, 07. Juli 2008 um 10:33:01 +0200: The firmware changes the ABI and is not yet referenced in Linus' tree. Follow-up for ABI Ver.2: Both versions should be installed. the appropriate version is chosen, since there are different files: [EMAIL PROTECTED]:~# ll /lib/firmware/iwlwifi-4965-* -rw-r--r-- 1 root root 187608 7. Jul 09:15 /lib/firmware/iwlwifi-4965-1.ucode -rw-r--r-- 1 root root 187672 7. Jul 11:00 /lib/firmware/iwlwifi-4965-2.ucode -- Jörg Friedrich There are only 10 types of people: Those who understand binary and those who don't. signature.asc Description: Digital signature
Processing of firmware-nonfree_0.12_powerpc.changes
firmware-nonfree_0.12_powerpc.changes uploaded successfully to localhost along with the files: firmware-nonfree_0.12.dsc firmware-nonfree_0.12.tar.gz firmware-bnx2_0.12_all.deb firmware-iwlwifi_0.12_all.deb firmware-qlogic_0.12_all.deb firmware-ralink_0.12_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 489684
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 489684 + pending Bug#489684: firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available There were no tags set. Tags added: pending 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]
firmware-nonfree override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): firmware-iwlwifi_0.12_all.deb: package says section is non-free/admin, override says non-free/misc. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. Please INCLUDE the list of packages as seen above, or we won't be able to deal with your mail due to missing information. [NB: this is an automatically generated mail; if you replied to one like it before and have not received a response yet, please ignore this mail. Your reply needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
firmware-nonfree_0.12_powerpc.changes ACCEPTED
Accepted: firmware-bnx2_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-bnx2_0.12_all.deb firmware-iwlwifi_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-iwlwifi_0.12_all.deb firmware-nonfree_0.12.dsc to pool/non-free/f/firmware-nonfree/firmware-nonfree_0.12.dsc firmware-nonfree_0.12.tar.gz to pool/non-free/f/firmware-nonfree/firmware-nonfree_0.12.tar.gz firmware-qlogic_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-qlogic_0.12_all.deb firmware-ralink_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-ralink_0.12_all.deb Override entries for your package: firmware-bnx2_0.12_all.deb - optional non-free/admin firmware-iwlwifi_0.12_all.deb - optional non-free/misc firmware-nonfree_0.12.dsc - source non-free/admin firmware-qlogic_0.12_all.deb - optional non-free/admin firmware-ralink_0.12_all.deb - optional non-free/admin Announcing to [EMAIL PROTECTED] Closing bugs: 489684 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489684: marked as done (firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available)
Your message dated Mon, 07 Jul 2008 09:32:03 + with message-id [EMAIL PROTECTED] and subject line Bug#489684: fixed in firmware-nonfree 0.12 has caused the Debian Bug report #489684, regarding firmware-iwlwifi: new firmware iwl4965 (228.57.1.21) available 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 489684: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489684 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: firmware-iwlwifi Version: 0.11 Severity: important Announcment: http://sourceforge.net/mailarchive/forum.php?thread_name=1215135788.14590.598.camel%40debian.sh.intel.comforum_name=ipw3945-devel Download: http://www.intellinuxwireless.org/iwlwifi/downloads/iwlwifi-4965-ucode-228.57.1.21.tgz Bumping to important because I have reports from different people about better stability when switching ssids and improved data rates (from 50 kbit/s to 2mbyte/s!) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-rc6 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information ---End Message--- ---BeginMessage--- Source: firmware-nonfree Source-Version: 0.12 We believe that the bug you reported is fixed in the latest version of firmware-nonfree, which is due to be installed in the Debian FTP archive: firmware-bnx2_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-bnx2_0.12_all.deb firmware-iwlwifi_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-iwlwifi_0.12_all.deb firmware-nonfree_0.12.dsc to pool/non-free/f/firmware-nonfree/firmware-nonfree_0.12.dsc firmware-nonfree_0.12.tar.gz to pool/non-free/f/firmware-nonfree/firmware-nonfree_0.12.tar.gz firmware-qlogic_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-qlogic_0.12_all.deb firmware-ralink_0.12_all.deb to pool/non-free/f/firmware-nonfree/firmware-ralink_0.12_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Bastian Blank [EMAIL PROTECTED] (supplier of updated firmware-nonfree package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 07 Jul 2008 11:19:42 +0200 Source: firmware-nonfree Binary: firmware-bnx2 firmware-iwlwifi firmware-qlogic firmware-ralink Architecture: source all Version: 0.12 Distribution: unstable Urgency: low Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Changed-By: Bastian Blank [EMAIL PROTECTED] Description: firmware-bnx2 - Binary firmware for Broadcom NetXtremeII firmware-iwlwifi - Binary firmware for Intel Wireless 3945 and 4965 firmware-qlogic - Binary firmware for QLogic QLA2XXX firmware-ralink - Binary firmware for Ralink RT2561, RT2571, RT2661 and RT2671 wire Closes: 489684 Changes: firmware-nonfree (0.12) unstable; urgency=low . * Remove Intel Wireless 3945 (old style) firmware. * Update Intel Wireless 4965 firmware, version 228.57.1.21. (closes: #489684) * Add Intel Wireless 4965 firmware, version 228.57.2.21. Checksums-Sha1: 339c5d0d80b2d7b1b2a627de097a193fb72d4ee1 1086 firmware-nonfree_0.12.dsc 0a3e6ef78067513d33605a389fbe0bec4d3ad15c 756720 firmware-nonfree_0.12.tar.gz 7a1b23143fe1140cb637a4dd9c362bb9e8fc4967 104558 firmware-bnx2_0.12_all.deb af45a77f2b52fdc33e03c0a07dddb5b800369481 222676 firmware-iwlwifi_0.12_all.deb aa5b6f59d54954144776b4ab194e783e7e6e9453 415702 firmware-qlogic_0.12_all.deb f788a1b3e8932d4154ecb62511b6f0787e6b816a 11506 firmware-ralink_0.12_all.deb Checksums-Sha256: 4dbd0c22f8e291d979556dcd7c04656d6ac2425fcb63d0a80ec0d24de843853b 1086 firmware-nonfree_0.12.dsc 39a6627327ce221dc89988fd7d97a33231b837d7e563e02421ff8cd053e625d7 756720 firmware-nonfree_0.12.tar.gz cc74330f0c4f04415b014e96b75c4addafccff810e644cd3bff13c030cef5e46 104558 firmware-bnx2_0.12_all.deb 1ecb2618c4aa4a6dcc11151e187729df96949764373360cd5cafc47015df3c4a 222676 firmware-iwlwifi_0.12_all.deb 242643236294e164580a09889f9e1d2d0152d166864a30bc2fd29432d4b6ff7b 415702 firmware-qlogic_0.12_all.deb
Processed: Bug#471892: r8169 does not load properly in 2.6.24 kernel
Processing commands for [EMAIL PROTECTED]: clone 471892 -1 Bug#471892: r8169 does not load properly in 2.6.24 kernel Bug 471892 cloned as bug 489710. reassign -1 linux-2.6.24 Bug#489710: r8169 does not load properly in 2.6.24 kernel Bug reassigned from package `linux-image-2.6.24-1-686-bigmem' to `linux-2.6.24'. tags -1 - pending Bug#489710: r8169 does not load properly in 2.6.24 kernel Tags were: pending Tags removed: pending tags -1 patch Bug#489710: r8169 does not load properly in 2.6.24 kernel There were no tags set. Tags added: patch thanks 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#471892: r8169 does not load properly in 2.6.24 kernel
clone 471892 -1 reassign -1 linux-2.6.24 tags -1 - pending tags -1 patch thanks Cloning to 2.6.24 as it is likely affected and this may be worth fixing in an update of that kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 471892 to linux-2.6, reassign 489710 to linux-2.6, merging 471892 489710
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 reassign 471892 linux-2.6 2.6.24-1 Bug#471892: r8169 does not load properly in 2.6.24 kernel Bug reassigned from package `linux-image-2.6.24-1-686-bigmem' to `linux-2.6'. reassign 489710 linux-2.6 2.6.24-1 Bug#489710: r8169 does not load properly in 2.6.24 kernel Bug reassigned from package `linux-2.6.24' to `linux-2.6'. merge 471892 489710 Bug#471892: r8169 does not load properly in 2.6.24 kernel Bug#489710: r8169 does not load properly in 2.6.24 kernel Merged 471892 489710. 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]
Processing of initramfs-tools_0.92e_amd64.changes
initramfs-tools_0.92e_amd64.changes uploaded successfully to localhost along with the files: initramfs-tools_0.92e.dsc initramfs-tools_0.92e.tar.gz initramfs-tools_0.92e_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Kernel question
Hi. I have some question to the new kernel 2.6.25-2-686 from etch-backports. I downloaded this and try to install. After reboot my computer, i want to install a standart Nvidia driver, but the installation was aborted with errormassage that the driver don't support a Xen compiled kernel. I compare the config files from kernel 2.6.24-1-686 and the new 2.6.25-2-686 (both was downloaded from etch-backport) and in fact, the kernel 2.6.25-2-686 has activate the option for Xen support. I asked me, if this mayby a mistake of compilation, or is that option right? Mayby you can create a new vresion of this kernel, without this option. Thenks alot for the answer! -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initramfs-tools_0.92e_amd64.changes ACCEPTED
Accepted: initramfs-tools_0.92e.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.92e.dsc initramfs-tools_0.92e.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.92e.tar.gz initramfs-tools_0.92e_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.92e_all.deb Override entries for your package: initramfs-tools_0.92e.dsc - source utils initramfs-tools_0.92e_all.deb - optional utils Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405810: Please provide package with vmlinuX, similar to kernel-debuginfo on redhat
As a workaround for this if you want the kernel symbols for OProfile, you can use this script instead of opreport: http://marc.info/?l=oprofile-listm=121514749918466q=p3 It fetches kernel symbol information from /proc/kallsyms and lists them in a format identical to what opreport -l uses. //Johan 2008/7/7 Riku Voipio [EMAIL PROTECTED]: The problem is that the vmlinuz file in /boot and modules in /lib/modules do not carry debug symbols. Therefor the vmlinux and unstripped modules would be needed in a linux-debug-2.6.x-x-all package carrying these would be nice. See the following discussion about systemtap for example: http://sources.redhat.com/ml/systemtap/2008-q3/msg00048.html This is not a issue for people building their own kernels, but for people tracing production systems running released debian kernels, where no debuginfo is preserved from the build. -- rm -rf only sounds scary if you don't have backups -- To unsubscribe, send mail to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
(adding d-kernel and d-release) On Monday 07 July 2008, Otavio Salvador wrote: Frans Pop [EMAIL PROTECTED] writes: On Thursday 03 July 2008, Otavio Salvador wrote: please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, linux-modules-extra-2.6 2.6.25-5 Please wait few more days until we get it properly done on sid (d-i migrates to it). Why? We have never blocked migration of a new kernel when that wasn't needed because of a D-I release. Uploading udebs and switching to a kernel is not dependant on the migration. A new kernel can basically migrate (from a D-I PoV) as soon as a release is out. Except that kernel team wants it to upload 2.6.26 to sid when it's released (probably this week) OK, then _that_ should be discussed, not the migration to testing. The two are completely separate issues. In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. Delaying the upload of .26 to unstable could give us time, as a distribution, to stay up to date with .25, see how things are going with .26 and make a more informed decision. However, if the kernel team (together with maybe the release team) has already decided on .26 for Lenny, then it would be better to get it into unstable ASAP and for D-I to basically skip .25. and we have not yet got all architectures tested with 2.6.25 on d-i. So what? That's largely our own damned fault... Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#489758: firmware-bnx2: bnx2 module fails to load bnx2 firmware file when the root FS is encrypted
Package: firmware-bnx2 Version: 0.11~bpo40+1 Severity: important When the root filesystem is encrypted via LUKS, the init scripts wait for the passphrase, and at that time, the root filesystem is not available. The bnx2 module tries to load the firmware from the disk and fails after a long time. The module loading for any devices that may need firmware files from disk should be stalled until the passphrase is given. Alternatively, the firmware files could be added to the ramdisk. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.25-2-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
Frans Pop a écrit : Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. As the release team is Cc:ed, I just want to make sure it is aware that switching to 2.6.26 possibly means changes to userland, and thus freeze exceptions. A few examples: - The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to removed headers. Change have been needed in various packages including glibc. - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know yet which change causes the problem, I am down to a 600 lines diff. - I have recently uploaded a new version of lm-sensors needed to support 2.6.26 kernels. That said I neither opposed nor in favor of a switch to 2.6.26, I just want to emphasize that it can have a bigger impact than expected on the release planning. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489758: marked as done (firmware-bnx2: bnx2 module fails to load bnx2 firmware file when the root FS is encrypted)
Your message dated Mon, 7 Jul 2008 19:30:17 +0200 with message-id [EMAIL PROTECTED] and subject line Re: Bug#489758: firmware-bnx2: bnx2 module fails to load bnx2 firmware file when the root FS is encrypted has caused the Debian Bug report #489758, regarding firmware-bnx2: bnx2 module fails to load bnx2 firmware file when the root FS is encrypted 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 489758: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489758 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: firmware-bnx2 Version: 0.11~bpo40+1 Severity: important When the root filesystem is encrypted via LUKS, the init scripts wait for the passphrase, and at that time, the root filesystem is not available. The bnx2 module tries to load the firmware from the disk and fails after a long time. The module loading for any devices that may need firmware files from disk should be stalled until the passphrase is given. Alternatively, the firmware files could be added to the ramdisk. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.25-2-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information ---End Message--- ---BeginMessage--- On Mon, Jul 07, 2008 at 06:37:22PM +0300, Giorgos Mavrikas wrote: Version: 0.11~bpo40+1 This version is not provided by the kernel team. from disk should be stalled until the passphrase is given. Alternatively, the firmware files could be added to the ramdisk. Use the package from stable. It contains the necessary code. Bastian -- Love sometimes expresses itself in sacrifice. -- Kirk, Metamorphosis, stardate 3220.3 ---End Message---
Re: Selection of kernel for Lenny
On Mon, Jul 07, 2008 at 04:19:01PM +, Aurelien Jarno wrote: Frans Pop a écrit : Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. As the release team is Cc:ed, I just want to make sure it is aware that switching to 2.6.26 possibly means changes to userland, and thus freeze exceptions. A few examples: - The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to removed headers. Change have been needed in various packages including glibc. - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know yet which change causes the problem, I am down to a 600 lines diff. - I have recently uploaded a new version of lm-sensors needed to support 2.6.26 kernels. That said I neither opposed nor in favor of a switch to 2.6.26, I just want to emphasize that it can have a bigger impact than expected on the release planning. Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGLZAYTa17l.pgp Description: PGP signature
Re: Selection of kernel for Lenny
* Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445987: OOPS in xen domU due to unitialised pci_dma structure.
The upstream Xen tree has a patch more like the attached.
However I suspect there is no practical difference between the two so
I'd suggest applying Göran Weinholt's patch since it has actually been
tested. I will check it in shortly unless I hear screaming...
Ian.
--
Ian Campbell
The only person who always got his work done by Friday was Robinson Crusoe.
--- a/arch/i386/kernel/pci-dma-xen.c
+++ b/arch/i386/kernel/pci-dma-xen.c
@@ -70,6 +70,15 @@
{
return 1;
}
+
+static int __init pci_iommu_init(void)
+{
+ no_iommu_init();
+ return 0;
+}
+
+/* Must execute after PCI subsystem */
+fs_initcall(pci_iommu_init);
#endif
struct dma_coherent_mem {
signature.asc
Description: This is a digitally signed message part
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Mon, Jul 07, 2008 at 05:30:09PM +0200, Frans Pop wrote: (adding d-kernel and d-release) On Monday 07 July 2008, Otavio Salvador wrote: Frans Pop [EMAIL PROTECTED] writes: On Thursday 03 July 2008, Otavio Salvador wrote: please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2, linux-modules-extra-2.6 2.6.25-5 Please wait few more days until we get it properly done on sid (d-i migrates to it). Why? We have never blocked migration of a new kernel when that wasn't needed because of a D-I release. Uploading udebs and switching to a kernel is not dependant on the migration. A new kernel can basically migrate (from a D-I PoV) as soon as a release is out. Except that kernel team wants it to upload 2.6.26 to sid when it's released (probably this week) OK, then _that_ should be discussed, not the migration to testing. The two are completely separate issues. In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). disabled. Se IMO we should take a real good look at .25 and .26 and check what's new, what's important for Lenny and what's risky, and maybe check if some things we do want could be backported. Delaying the upload of .26 to unstable could give us time, as a distribution, to stay up to date with .25, see how things are going with .26 and make a more informed decision. However, if the kernel team (together with maybe the release team) has already decided on .26 for Lenny, then it would be better to get it into unstable ASAP and for D-I to basically skip .25. .26 is the release kernel. so i'm happy with push on it. .25 is a possible backup. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
* Frans Pop [EMAIL PROTECTED] [2008-07-07 17:30]: In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. FWIW, I fully agree. In the past, we never waited for all arches in d-i to move to a new kernel udebs before allowing the deb of that version to move to testing. In fact, not having 2.6.25 in testing now that some arches have updated d-i to 2.6.25 _hurts_ our testing efforts. Some Orion devices work perfectly fine in d-i now that we've moved to 2.6.25, but installations fail because no kernel is in testing... which means people cannot test it. So, please migrate the 2.6.25 debs to testing. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
maximilian attems [EMAIL PROTECTED] writes: .26 is the release kernel. so i'm happy with push on it. .25 is a possible backup. I'd like to get an official statement from RM team about that so we can move it further. -- 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: Selection of kernel for Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Michlmayr [EMAIL PROTECTED] writes: * Frans Pop [EMAIL PROTECTED] [2008-07-07 17:30]: In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. FWIW, I fully agree. In the past, we never waited for all arches in d-i to move to a new kernel udebs before allowing the deb of that version to move to testing. In fact, not having 2.6.25 in testing now that some arches have updated d-i to 2.6.25 _hurts_ our testing efforts. Some Orion devices work perfectly fine in d-i now that we've moved to 2.6.25, but installations fail because no kernel is in testing... which means people cannot test it. So, please migrate the 2.6.25 debs to testing. No objection in allowing 2.6.25 to go to testing but please hold on about uploading 2.6.26 until RM team acks on 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkhyZJAACgkQLqiZQEml+FUgZwCfUX/L+aGf7m4sk0rsAua3M3Eo 4SAAoJFrBJQgdwpJ4y+FHgUPEdAUFkTF =i8PB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Monday 07 July 2008, maximilian attems wrote: There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. Eh, how does that follow my last para which I assume you are commenting on, but which has nothing to do with testing? A side-note to your comment though... IMO testing kernel support is the weakest point in the current upload strategy by the kernel team. By uploading the next upstream release to unstable basically as soon as it's available upstream, Debian users (both unstable and testing) are frequently missing out on at least one or two upstream stable updates for the previous stable (stable -1) release. We worked around this for .24 by doing an upstream stable update through t-p-u. Upstream does seem to recognize the fact that a new release will need at least a few updates before it is actually stable and usable, and will therefore do at least a few stable updates (for both new stable and stable -1 in parallel). This basically happens in parallel to the new merge window (say the time to -rc2) and some upstream releases get longer term upstream stable support (.18, .22, .25). My personal opinion is that it would be better to delay the upload of new upstream releases to unstable until the .2 or maybe even .3 upstream stable update has become available. This would mean a bit more work for the kernel team, but I would expect that to be solvable. That would also give more time for initial arch-specific and l-m-e issues for the new upstream to be worked out (e.g. in experimental) without breaking unstable too much. IMO a new kernel version should only be uploaded to unstable if kernel meta packages can be updated at roughly the same time. It would also allow to upload a few more stable updates for stable -1 and to migrate those to testing, giving testing users on average better support and it would give D-I some more breathing space to do releases. When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. I'm having serious trouble parsing what you're trying to say here. Could you rephrase? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#484594: linux-source-2.6.25: console output?
Package: linux-source-2.6.25 Version: 2.6.25-6 Followup-For: Bug #484594 Sorry, I didn't seem to get the reply to this... Doesn't the BTS automatically respond to the submitter without a CC: needing to be set? On Thu, Jun 05, 2008 at 02:17:31PM +1000, Tim Connors wrote: 2.6.25 is very slow to boot on both my i686 (debian 2.6.25-2-686) and amd64 (debian source 2.6.25-4) machines. I suspect this may have been happening for 2.6.24 as well, but I will need to go back and check. Please show the console output, not the kernel log. The device-mapper module is loaded in the initramfs, so the machine already runs userspace code while it got stuck. I don't understand what you mean? How do I copy the console output once it scrolls past the scrollback buffer? Also, device mapper was just a hunch. Now I don't think device mapper has anything to do with it: The latest output is this on the 2.6.25-6 machine built from debian sources: ... [4.095383] Uniform CD-ROM driver Revision: 3.20 [4.105631] sda1 sda2 sda3 sda5 sda6 sda76usb 6-2: USB disconnect, address 2 [4.157337] sda8 [4.157576] sd 0:0:0:0: [sda] Attached SCSI disk [4.439143] device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised: [EMAIL PROTECTED] [4.510946] usb 7-6: new high speed USB device using ehci_hcd and address 2 [4.644381] usb 7-6: configuration #1 chosen from 1 choice [ 86.686411] PM: Starting manual resume from disk [ 86.234538] EXT3-fs: INFO: recovery required on readonly filesystem. [ 86.234542] EXT3-fs: write access will be enabled during recovery. [ 86.619607] kjournald starting. Commit interval 5 seconds ... The other machine also pauses somewhere around those USB messages. I'm wondering if its the CONFIG_USB_PERSIST I have set on both machines. It appeared about when I first came across this problem, but I'm not in a position right now to reboot either machine and test. You seems to use initramfs-tools, which should provide some output on the console during its work. Again, I'm not sure I know what you mean. initramfs-tools is just brought in by the debian linux image packages, and I haven't noticed any output it makes that is different compared to booting an upstream kernel. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25 (SMP w/2 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages linux-source-2.6.25 depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii bzip2 1.0.5-0.1high-quality block-sorting file co Versions of packages linux-source-2.6.25 recommends: ii gcc 4:4.3.1-2 The GNU C compiler ii libc6-dev [libc-dev] 2.7-12 GNU C Library: Development Librari ii make 3.81-5 The GNU version of the make util -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
Otavio Salvador wrote: Martin Michlmayr [EMAIL PROTECTED] writes: * Frans Pop [EMAIL PROTECTED] [2008-07-07 17:30]: In fact, having 2.6.25 in testing would possibly make it easier for the kernel team to do a final (?) 2.6.25 upload with latest stable updates. FWIW, I fully agree. In the past, we never waited for all arches in d-i to move to a new kernel udebs before allowing the deb of that version to move to testing. In fact, not having 2.6.25 in testing now that some arches have updated d-i to 2.6.25 _hurts_ our testing efforts. Some Orion devices work perfectly fine in d-i now that we've moved to 2.6.25, but installations fail because no kernel is in testing... which means people cannot test it. So, please migrate the 2.6.25 debs to testing. No objection in allowing 2.6.25 to go to testing but please hold on about uploading 2.6.26 until RM team acks on it. hint added. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Monday 07 July 2008, Frans Pop wrote: .26 also includes at least one change I know of that is somewhat risky: PAT support for x86 (which could be disabled). #d-uk just gave me this tidbit: ... am I missing something or will the move to .26, with libata binding before most of the IDE stuff, cause a lot of pain unless the distro manages the move from hd* to sd*? Which is basically the why don't we have persistent device naming issue (on which I won't comment). There's two things to say about this (assuming status quo otherwise): - this will probably reduce the pain on reboots for new installations as module loading order should become more predictable between different boots - this may increase the pain for people upgrading from Etch to Lenny, or not, or ... Other related issue/question. Early in lenny, when libata first stuck up its head, we made some effort to disable drivers or remove duplicate PCI IDs so that existing users using the old IDE drivers would not suddenly be confronted with a hda-sda switch. I have not really followed Debian kernels regarding this, but currently I think we basically just have both IDE and ATA drivers enabled. Correct? Are any of those early avoid duplicate PCI ID patches still active? Do we have any idea yet how this is going to be handled/documented for upgrades? signature.asc Description: This is a digitally signed message part.
