Bug#602418: Debian Squeeze Xen with Nouveau or Radeon: Test packages
On Mon, 2011-01-03 at 15:51 +0100, Lionel Elie Mamane wrote: This combination works for me: [snip] Excellent. Thanks for testing. Ian. -- Ian Campbell Current Noise: Hypocrisy - Compulsive Psychosis phosflink: To flick a bulb on and off when it burns out (as if, somehow, that will bring it back to life). -- Sniglets, Rich Hall Friends -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294131813.3831.1.ca...@zakaz.uk.xensource.com
Bug#558740: marked as done (firmware-linux-nonfree: Add Atheros AR9170 one stage firmware (ar9170.fw))
Your message dated Tue, 04 Jan 2011 10:05:02 + with message-id e1pa3lg-0002y6...@franck.debian.org and subject line Bug#558740: fixed in firmware-nonfree 0.28 has caused the Debian Bug report #558740, regarding firmware-linux-nonfree: Add Atheros AR9170 one stage firmware (ar9170.fw) 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 ow...@bugs.debian.org immediately.) -- 558740: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-linux-nonfree Version: 0.21 Severity: wishlist Tags: patch Hi, Please consider including the one stage firmware [1] for the ar9170usb driver in firmware-linux-nonfree, for support of Atheros AR9170-based USB wireless LAN devices. Patch (based on [2]) attached. Geoff [1] http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw [2] http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/LICENSE -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.31-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash firmware-linux-nonfree depends on no packages. firmware-linux-nonfree recommends no packages. Versions of packages firmware-linux-nonfree suggests: ii initramfs-to 0.93.4 tools for generating an initramfs ii linux-image- 2.6.31-2Linux 2.6.31 for modern PCs ii linux-image- 2.6.32~rc8-1~experimental.1 Linux 2.6.32-rc8 for modern PCs -- no debconf information Index: linux-nonfree/LICENSE === --- linux-nonfree/LICENSE (revision 14703) +++ linux-nonfree/LICENSE (working copy) @@ -89,6 +89,49 @@ OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +* ar9170.fw + +Copyright (c) 2008, Atheros Communications, Inc. +All rights reserved. + +Redistribution. Redistribution and use in binary form, without +modification, are permitted provided that the following conditions are +met: + +* Redistributions must reproduce the above copyright notice and the + following disclaimer in the documentation and/or other materials + provided with the distribution. + +* Neither the name of Atheros Communications, Inc. nor the names of + its suppliers may be used to endorse or promote products derived + from this software without specific prior written permission. + +* No reverse engineering, decompilation, or disassembly of this + software is permitted. + +Limited patent license. Atheros Communications, Inc. grants a +world-wide, royalty-free, non-exclusive license under patents it +now or hereafter owns or controls to make, have made, use, import, +offer to sell and sell (Utilize) this software, but solely to +the extent that any such patent is necessary to Utilize the software +alone, or in combination with an operating system licensed under an +approved Open Source license as listed by the Open Source Initiative +at http://opensource.org/licenses. The patent license shall not +apply to any other combinations which include this software. No +hardware per se is licensed hereunder. + +DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND +CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, +BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND +FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL +THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, +BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS +OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR +TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE +USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * cxgb3/ael2005_opt_edc.bin * cxgb3/ael2005_twx_edc.bin * cxgb3/ael2020_twx_edc.bin Index: linux-nonfree/defines === --- linux-nonfree/defines (revision 14703) +++ linux-nonfree/defines (working copy) @@ -13,6 +13,7 @@ advansys/mcode.bin agere_ap_fw.bin agere_sta_fw.bin + ar9170.fw cxgb3/ael2005_opt_edc.bin cxgb3/ael2005_twx_edc.bin cxgb3/ael2020_twx_edc.bin @@ -91,6 +92,9 @@ desc: Agere/Prism/Symbol Orinoco firmware (STA mode) version: 9.48 Hermes I +[ar9170.fw_base] +desc: Atheros
Bug#564628: marked as done (Add Realtek RTL8168D firmware)
Your message dated Tue, 04 Jan 2011 10:05:02 + with message-id e1pa3lg-0002ya...@franck.debian.org and subject line Bug#564628: fixed in firmware-nonfree 0.28 has caused the Debian Bug report #564628, regarding Add Realtek RTL8168D firmware 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 ow...@bugs.debian.org immediately.) -- 564628: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564628 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-linux-nonfree Version: 0.22 Severity: wishlist I need to request a suitable licence to redistribute the RTL8168D firmware patches which are removed from Linux kernel packages. Currently the only licence for drivers/net/r8169.c is GPLv2, which is not suitable for sourceless firmware. Ben. -- System Information: Debian Release: squeeze/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash firmware-linux-nonfree depends on no packages. firmware-linux-nonfree recommends no packages. Versions of packages firmware-linux-nonfree suggests: ii initramfs-tools 0.93.4 tools for generating an initramfs ii linux-image-2.6.26-2-686 [lin 2.6.26-20 Linux 2.6.26 image on PPro/Celeron ii linux-image-2.6.32-trunk-686 2.6.32-5 Linux 2.6.32 for modern PCs ii linux-image-2.6.32-trunk-amd6 2.6.32-5 Linux 2.6.32 for 64-bit PCs -- no debconf information ---End Message--- ---BeginMessage--- Source: firmware-nonfree Source-Version: 0.28 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-atheros_0.28_all.deb to non-free/f/firmware-nonfree/firmware-atheros_0.28_all.deb firmware-bnx2_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2_0.28_all.deb firmware-bnx2x_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2x_0.28_all.deb firmware-brcm80211_0.28_all.deb to non-free/f/firmware-nonfree/firmware-brcm80211_0.28_all.deb firmware-intelwimax_0.28_all.deb to non-free/f/firmware-nonfree/firmware-intelwimax_0.28_all.deb firmware-ipw2x00_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ipw2x00_0.28_all.deb firmware-ivtv_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ivtv_0.28_all.deb firmware-iwlwifi_0.28_all.deb to non-free/f/firmware-nonfree/firmware-iwlwifi_0.28_all.deb firmware-linux-nonfree_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux-nonfree_0.28_all.deb firmware-linux_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux_0.28_all.deb firmware-netxen_0.28_all.deb to non-free/f/firmware-nonfree/firmware-netxen_0.28_all.deb firmware-nonfree_0.28.dsc to non-free/f/firmware-nonfree/firmware-nonfree_0.28.dsc firmware-nonfree_0.28.tar.gz to non-free/f/firmware-nonfree/firmware-nonfree_0.28.tar.gz firmware-qlogic_0.28_all.deb to non-free/f/firmware-nonfree/firmware-qlogic_0.28_all.deb firmware-ralink_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ralink_0.28_all.deb firmware-realtek_0.28_all.deb to non-free/f/firmware-nonfree/firmware-realtek_0.28_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 564...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings b...@decadent.org.uk (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 ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 04 Jan 2011 02:40:16 + Source: firmware-nonfree Binary: firmware-linux firmware-atheros firmware-bnx2 firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-ipw2x00 firmware-ivtv firmware-iwlwifi firmware-linux-nonfree firmware-netxen firmware-qlogic firmware-ralink firmware-realtek Architecture: source all Version: 0.28 Distribution: unstable Urgency: low Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Changed-By: Ben Hutchings b...@decadent.org.uk Description: firmware-atheros - Binary firmware for Atheros wireless cards firmware-bnx2 - Binary firmware for Broadcom NetXtremeII firmware-bnx2x -
Bug#587960: marked as done ([Debian] Where can I find rtl81638d-2.fw firmware for Realtek 8168D NIC?)
Your message dated Tue, 04 Jan 2011 10:05:02 + with message-id e1pa3lg-0002ya...@franck.debian.org and subject line Bug#564628: fixed in firmware-nonfree 0.28 has caused the Debian Bug report #564628, regarding [Debian] Where can I find rtl81638d-2.fw firmware for Realtek 8168D NIC? 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 ow...@bugs.debian.org immediately.) -- 564628: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564628 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-nonfree On Fri, Jul 2, 2010 at 22:13, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2010-07-02 at 09:48 +0200, Sandro Tosi wrote: Hello Ben, sorry to disturb you with this, but you might be my salvation :) Well, don't just ask me. You should use the debian-kernel list or the BTS for firmware-nonfree. ah indeed, sorry: I wrote to you personally since I saw several replies from you on the topic. Submitting the request on BTS with this email. I recently bought a laptop (HP dv6-2193el) which has an unfortunate NIC: Realtek 8168D. That's the nic that requires the firmware rtl81638d-2.fw to work. Does it actually require that? I think that that image is a patch that fixes a bug in the original firmware. Currently the driver will still allow you to use the NIC if the firmware image is not available. well, the NIC leds blink, but I can't connect to the other host, nor doing any other network operation. Ehm, what image are you referring to? squeeze alpha1 installer? Now, I saw some request for inclusion in firmware-linux-nonfree, but you said it's not possible since we still don't have a clear licence that allows for redistribution. What I'm actually asking you is: where can I get that firmware? I googled a lot without success, and also trying with some different net-installers (lenny, testing dailies @ 2010-06-26, squeeze alpha 1) none of them was able to correctly detect and enable the NIC, and without that, I can't go on with Debian installation. You would need to convert the array that was removed from rtl8168d_2_hw_phy_config() here to a binary: http://git.debian.org/?p=kernel/linux-2.6.git;a=commitdiff;h=c8d71d6cd4746c075387b689506adb7256b3221a#patch10 if only I know how :) Thanks in advance, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ---End Message--- ---BeginMessage--- Source: firmware-nonfree Source-Version: 0.28 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-atheros_0.28_all.deb to non-free/f/firmware-nonfree/firmware-atheros_0.28_all.deb firmware-bnx2_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2_0.28_all.deb firmware-bnx2x_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2x_0.28_all.deb firmware-brcm80211_0.28_all.deb to non-free/f/firmware-nonfree/firmware-brcm80211_0.28_all.deb firmware-intelwimax_0.28_all.deb to non-free/f/firmware-nonfree/firmware-intelwimax_0.28_all.deb firmware-ipw2x00_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ipw2x00_0.28_all.deb firmware-ivtv_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ivtv_0.28_all.deb firmware-iwlwifi_0.28_all.deb to non-free/f/firmware-nonfree/firmware-iwlwifi_0.28_all.deb firmware-linux-nonfree_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux-nonfree_0.28_all.deb firmware-linux_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux_0.28_all.deb firmware-netxen_0.28_all.deb to non-free/f/firmware-nonfree/firmware-netxen_0.28_all.deb firmware-nonfree_0.28.dsc to non-free/f/firmware-nonfree/firmware-nonfree_0.28.dsc firmware-nonfree_0.28.tar.gz to non-free/f/firmware-nonfree/firmware-nonfree_0.28.tar.gz firmware-qlogic_0.28_all.deb to non-free/f/firmware-nonfree/firmware-qlogic_0.28_all.deb firmware-ralink_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ralink_0.28_all.deb firmware-realtek_0.28_all.deb to non-free/f/firmware-nonfree/firmware-realtek_0.28_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 564...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings b...@decadent.org.uk (supplier of updated firmware-nonfree package) (This message was generated automatically at their request; if you believe that
Bug#602450: marked as done (firmware-nonfree: Please add rtlwifi/rtl8712u.bin, needed by r8712u = 2.6.37, to firmware-realtek)
Your message dated Tue, 04 Jan 2011 10:05:02 +
with message-id e1pa3lg-0002yi...@franck.debian.org
and subject line Bug#602450: fixed in firmware-nonfree 0.28
has caused the Debian Bug report #602450,
regarding firmware-nonfree: Please add rtlwifi/rtl8712u.bin, needed by r8712u
= 2.6.37, to firmware-realtek
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 ow...@bugs.debian.org
immediately.)
--
602450: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602450
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: firmware-nonfree
Version: 0.27
Severity: wishlist
Hi
Starting with kernel 2.6.37, rtl8192su/ r8192s_usb will be replaced by
the new staging driver rtl8712/ r8712u. It would be nice if its firmware,
which has been added to firmware-linux.git this week, could be added to
the firmware-realtek package.
http://lkml.indiana.edu/hypermail/linux/kernel/1011.0/00610.html
Message-ID: 4cd014ec.e0ho4xdm0+tov1xt%larry.fin...@lwfinger.net
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi
The firmware license appears to be acceptable for firmware-nonfree
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.rtlwifi_firmware.txt
--
Hints for linux-2.6 2.6.37~
r8712u as merged mainline for 2.6.37 does not use this external firmware
yet, but still compiles it into the r8712u kernel module through
drivers/staging/rtl8712/farray.h (rm)
Patches to employ request_firmware() are pending
http://www.spinics.net/lists/linux-wireless/msg58214.html
Message-ID: 4cc9f4be.7070...@lwfinger.net
and a minor (updated in this attachment) fixup attached
http://www.spinics.net/lists/linux-wireless/msg58240.html
Message-Id: 201010292203.39953.s@gmx.de
I can confirm that rtl8712/ r8712u with split out firmware using
request_firmware() is working with RealTek RTL8188S and RTL8191S
devices and a decent replacement/ update for rtl8192su/ r8192s_usb.
http://www.spinics.net/lists/linux-wireless/msg58239.html
Message-Id: 201010292202.25486.s@gmx.de
Regards
Stefan Lippers-Hollmann
staging: r8712u: Fix external firmware loading
* select FW_LOADER
* declare MODULE_FIRMWARE for r8712u
* change firmware location to represent published linux-fimware.git
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
drivers/staging/rtl8712/Kconfig|1 +
drivers/staging/rtl8712/hal_init.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/rtl8712/Kconfig
+++ b/drivers/staging/rtl8712/Kconfig
@@ -3,6 +3,7 @@ config R8712U
depends on WLAN USB
select WIRELESS_EXT
select WEXT_PRIV
+ select FW_LOADER
default N
---help---
This option adds the Realtek RTL8712 USB device such as the D-Link DWA-130.
--- a/drivers/staging/rtl8712/hal_init.c
+++ b/drivers/staging/rtl8712/hal_init.c
@@ -40,7 +40,7 @@ static u32 rtl871x_open_fw(struct _adapt
const u8 **ppmappedfw)
{
int rc;
- const char firmware_file[] = rtl8712u/rtl8712u.bin;
+ const char firmware_file[] = rtlwifi/rtl8712u.bin;
const struct firmware **praw = (const struct firmware **)
(pphfwfile_hdl);
struct dvobj_priv *pdvobjpriv = (struct dvobj_priv *)
@@ -58,6 +58,7 @@ static u32 rtl871x_open_fw(struct _adapt
*ppmappedfw = (u8 *)((*praw)-data);
return (*praw)-size;
}
+MODULE_FIRMWARE(rtlwifi/rtl8712u.bin);
static void fill_fwpriv(struct _adapter *padapter, struct fw_priv *pfwpriv)
{
signature.asc
Description: This is a digitally signed message part.
---End Message---
---BeginMessage---
Source: firmware-nonfree
Source-Version: 0.28
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-atheros_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-atheros_0.28_all.deb
firmware-bnx2_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-bnx2_0.28_all.deb
firmware-bnx2x_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-bnx2x_0.28_all.deb
firmware-brcm80211_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-brcm80211_0.28_all.deb
firmware-intelwimax_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-intelwimax_0.28_all.deb
firmware-ipw2x00_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-ipw2x00_0.28_all.deb
firmware-ivtv_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-ivtv_0.28_all.deb
firmware-iwlwifi_0.28_all.deb
to non-free/f/firmware-nonfree/firmware-iwlwifi_0.28_all.deb
firmware-linux-nonfree_0.28_all.deb
to
Bug#598470: marked as done (bnx2-mips-06-5.0.0.j6.fw file not included in firmware-bnx2)
Your message dated Tue, 04 Jan 2011 10:05:02 + with message-id e1pa3lg-0002ye...@franck.debian.org and subject line Bug#598470: fixed in firmware-nonfree 0.28 has caused the Debian Bug report #598470, regarding bnx2-mips-06-5.0.0.j6.fw file not included in firmware-bnx2 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 ow...@bugs.debian.org immediately.) -- 598470: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598470 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-bnx2 Version: 0.26 Severity: wishlist Newer Linux kernel versions try to load BNX2 firmware from file bnx2-mips-06-5.0.0.j6.fw, which isn't included in the firmware-bnx2 package. Thanks! Alex -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash firmware-bnx2 depends on no packages. firmware-bnx2 recommends no packages. Versions of packages firmware-bnx2 suggests: ii initramfs-tools 0.92o tools for generating an initramfs ii linux-image-2.6. 2.6.33-1~experimental.4 Linux 2.6.33 for 64-bit PCs ii linux-image-2.6. 2.6.35-1~experimental.3 Linux 2.6.35 for 64-bit PCs -- no debconf information ---End Message--- ---BeginMessage--- Source: firmware-nonfree Source-Version: 0.28 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-atheros_0.28_all.deb to non-free/f/firmware-nonfree/firmware-atheros_0.28_all.deb firmware-bnx2_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2_0.28_all.deb firmware-bnx2x_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2x_0.28_all.deb firmware-brcm80211_0.28_all.deb to non-free/f/firmware-nonfree/firmware-brcm80211_0.28_all.deb firmware-intelwimax_0.28_all.deb to non-free/f/firmware-nonfree/firmware-intelwimax_0.28_all.deb firmware-ipw2x00_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ipw2x00_0.28_all.deb firmware-ivtv_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ivtv_0.28_all.deb firmware-iwlwifi_0.28_all.deb to non-free/f/firmware-nonfree/firmware-iwlwifi_0.28_all.deb firmware-linux-nonfree_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux-nonfree_0.28_all.deb firmware-linux_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux_0.28_all.deb firmware-netxen_0.28_all.deb to non-free/f/firmware-nonfree/firmware-netxen_0.28_all.deb firmware-nonfree_0.28.dsc to non-free/f/firmware-nonfree/firmware-nonfree_0.28.dsc firmware-nonfree_0.28.tar.gz to non-free/f/firmware-nonfree/firmware-nonfree_0.28.tar.gz firmware-qlogic_0.28_all.deb to non-free/f/firmware-nonfree/firmware-qlogic_0.28_all.deb firmware-ralink_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ralink_0.28_all.deb firmware-realtek_0.28_all.deb to non-free/f/firmware-nonfree/firmware-realtek_0.28_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 598...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings b...@decadent.org.uk (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 ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 04 Jan 2011 02:40:16 + Source: firmware-nonfree Binary: firmware-linux firmware-atheros firmware-bnx2 firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-ipw2x00 firmware-ivtv firmware-iwlwifi firmware-linux-nonfree firmware-netxen firmware-qlogic firmware-ralink firmware-realtek Architecture: source all Version: 0.28 Distribution: unstable Urgency: low Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Changed-By: Ben Hutchings b...@decadent.org.uk Description: firmware-atheros - Binary firmware for Atheros wireless cards firmware-bnx2 - Binary firmware for Broadcom NetXtremeII firmware-bnx2x - Binary firmware for Broadcom NetXtreme II 10Gb firmware-brcm80211 - Binary firmware for Broadcom 802.11 wireless cards firmware-intelwimax - Binary firmware for Intel WiMAX Connection firmware-ipw2x00 - Binary firmware for Intel Pro Wireless 2100, 2200 and
Bug#606289: marked as done (4.0.517 firmware crashes frequently on HP NC522SFP)
Your message dated Tue, 04 Jan 2011 10:05:02 + with message-id e1pa3lg-0002ym...@franck.debian.org and subject line Bug#606289: fixed in firmware-nonfree 0.28 has caused the Debian Bug report #606289, regarding 4.0.517 firmware crashes frequently on HP NC522SFP 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 ow...@bugs.debian.org immediately.) -- 606289: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606289 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: firmware-netxen Version: 0.27 Severity: important A user reported that the 4.0.517 crashes within seconds on this netxen-based NIC - this is the firmware version we currently ship in 0.27. The user confirmed that 4.0.534 fixes the issue. This version was recently accepted into the linux-firmware tree. ---End Message--- ---BeginMessage--- Source: firmware-nonfree Source-Version: 0.28 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-atheros_0.28_all.deb to non-free/f/firmware-nonfree/firmware-atheros_0.28_all.deb firmware-bnx2_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2_0.28_all.deb firmware-bnx2x_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2x_0.28_all.deb firmware-brcm80211_0.28_all.deb to non-free/f/firmware-nonfree/firmware-brcm80211_0.28_all.deb firmware-intelwimax_0.28_all.deb to non-free/f/firmware-nonfree/firmware-intelwimax_0.28_all.deb firmware-ipw2x00_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ipw2x00_0.28_all.deb firmware-ivtv_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ivtv_0.28_all.deb firmware-iwlwifi_0.28_all.deb to non-free/f/firmware-nonfree/firmware-iwlwifi_0.28_all.deb firmware-linux-nonfree_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux-nonfree_0.28_all.deb firmware-linux_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux_0.28_all.deb firmware-netxen_0.28_all.deb to non-free/f/firmware-nonfree/firmware-netxen_0.28_all.deb firmware-nonfree_0.28.dsc to non-free/f/firmware-nonfree/firmware-nonfree_0.28.dsc firmware-nonfree_0.28.tar.gz to non-free/f/firmware-nonfree/firmware-nonfree_0.28.tar.gz firmware-qlogic_0.28_all.deb to non-free/f/firmware-nonfree/firmware-qlogic_0.28_all.deb firmware-ralink_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ralink_0.28_all.deb firmware-realtek_0.28_all.deb to non-free/f/firmware-nonfree/firmware-realtek_0.28_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 606...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings b...@decadent.org.uk (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 ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 04 Jan 2011 02:40:16 + Source: firmware-nonfree Binary: firmware-linux firmware-atheros firmware-bnx2 firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-ipw2x00 firmware-ivtv firmware-iwlwifi firmware-linux-nonfree firmware-netxen firmware-qlogic firmware-ralink firmware-realtek Architecture: source all Version: 0.28 Distribution: unstable Urgency: low Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Changed-By: Ben Hutchings b...@decadent.org.uk Description: firmware-atheros - Binary firmware for Atheros wireless cards firmware-bnx2 - Binary firmware for Broadcom NetXtremeII firmware-bnx2x - Binary firmware for Broadcom NetXtreme II 10Gb firmware-brcm80211 - Binary firmware for Broadcom 802.11 wireless cards firmware-intelwimax - Binary firmware for Intel WiMAX Connection firmware-ipw2x00 - Binary firmware for Intel Pro Wireless 2100, 2200 and 2915 firmware-ivtv - Binary firmware for iTVC15-family MPEG codecs (ivtv and pvrusb2 d firmware-iwlwifi - Binary firmware for Intel Wireless 3945, 4965 and 5000-series car firmware-linux - Binary firmware for various drivers in the Linux kernel (meta-pac firmware-linux-nonfree - Binary firmware for various drivers in the Linux kernel firmware-netxen - Binary firmware for QLogic Intelligent Ethernet (3000 and 3100 Se firmware-qlogic - Binary firmware for QLogic IBA7220, QLA1xxx, ISP2xxx and SP2x2 firmware-ralink - Binary firmware for Ralink
firmware-nonfree_0.28_i386.changes ACCEPTED into unstable
Accepted: firmware-atheros_0.28_all.deb to non-free/f/firmware-nonfree/firmware-atheros_0.28_all.deb firmware-bnx2_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2_0.28_all.deb firmware-bnx2x_0.28_all.deb to non-free/f/firmware-nonfree/firmware-bnx2x_0.28_all.deb firmware-brcm80211_0.28_all.deb to non-free/f/firmware-nonfree/firmware-brcm80211_0.28_all.deb firmware-intelwimax_0.28_all.deb to non-free/f/firmware-nonfree/firmware-intelwimax_0.28_all.deb firmware-ipw2x00_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ipw2x00_0.28_all.deb firmware-ivtv_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ivtv_0.28_all.deb firmware-iwlwifi_0.28_all.deb to non-free/f/firmware-nonfree/firmware-iwlwifi_0.28_all.deb firmware-linux-nonfree_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux-nonfree_0.28_all.deb firmware-linux_0.28_all.deb to non-free/f/firmware-nonfree/firmware-linux_0.28_all.deb firmware-netxen_0.28_all.deb to non-free/f/firmware-nonfree/firmware-netxen_0.28_all.deb firmware-nonfree_0.28.dsc to non-free/f/firmware-nonfree/firmware-nonfree_0.28.dsc firmware-nonfree_0.28.tar.gz to non-free/f/firmware-nonfree/firmware-nonfree_0.28.tar.gz firmware-qlogic_0.28_all.deb to non-free/f/firmware-nonfree/firmware-qlogic_0.28_all.deb firmware-ralink_0.28_all.deb to non-free/f/firmware-nonfree/firmware-ralink_0.28_all.deb firmware-realtek_0.28_all.deb to non-free/f/firmware-nonfree/firmware-realtek_0.28_all.deb Override entries for your package: firmware-atheros_0.28_all.deb - optional non-free/kernel firmware-bnx2_0.28_all.deb - optional non-free/kernel firmware-bnx2x_0.28_all.deb - optional non-free/kernel firmware-brcm80211_0.28_all.deb - optional non-free/kernel firmware-intelwimax_0.28_all.deb - optional non-free/kernel firmware-ipw2x00_0.28_all.deb - optional non-free/kernel firmware-ivtv_0.28_all.deb - optional non-free/kernel firmware-iwlwifi_0.28_all.deb - optional non-free/kernel firmware-linux-nonfree_0.28_all.deb - optional non-free/kernel firmware-linux_0.28_all.deb - optional non-free/kernel firmware-netxen_0.28_all.deb - optional non-free/kernel firmware-nonfree_0.28.dsc - source non-free/kernel firmware-qlogic_0.28_all.deb - optional non-free/kernel firmware-ralink_0.28_all.deb - optional non-free/kernel firmware-realtek_0.28_all.deb - optional non-free/kernel Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 558740 564628 598470 602450 606289 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1pa3lf-0002xv...@franck.debian.org
Bug#608144: linux-image-2.6.32-5-xen-amd64: Kernel oops: net/core/dev.c:1582 skb_gso_segment+0x109/0x263() (Bug #596802 reappeared)
On Mon, 2011-01-03 at 08:45 +0100, Stephan Austermühle wrote: Am 02.01.2011 20:27, schrieb Ian Campbell: Did -28 work OK? Otherwise what was the last known good kernel? The -29 kernel was the one that was installed when I've setup Squeeze. So, there was never a different kernel on that system. Anyway... I can try -28 and see what happens. If it's not too much trouble then yes please. Ian. -- Ian Campbell Current Noise: Annihilator - Never, Neverland We don't have to protect the environment -- the Second Coming is at hand. -- James Watt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294137528.3831.93.ca...@zakaz.uk.xensource.com
Bug#608804: linux-image-amd64: /sys/class/power_supply/ACAD/online is 1 without power cable plugged in
On Mon, Jan 03, 2011 at 08:30:21PM +, Ben Hutchings wrote: Please report this upstream at https://bugzilla.kernel.org under product ACPI, component Power-Battery. Let us know the bug number or URL so we can track it. I've just tried kernel image 2.6.37~rc7-1~experimental.1 from experimental and the problem is gone. /sys/class/power_supply/ACAD/online returns the correct information. Since it's fixed in a newer version the problem remains with 2.6.32 for squeeze. The change that fixed this must have come somewhere between 2.6.37-rc5 and 2.6.37-rc7 since 2.6.37-rc5 still displayed the wrong information. mk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104104623.ga3...@finrod
Bug#605090: Updated patch
I've put updated patches on
http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/ (kernel is
built but not uploaded to packages/ since it's quite huge, will do that
at one point. Patches are attached to that mail too.
The first one (add-grsecurity-featureset) is against the debian kernel
svn tree and add the featureset, while the second (debian-grsecurity) is
against the grsecurity upstream patch and adapts it to the current
debian kernel sources (removes the stuff already backported by the
kernel team etc.).
I expect it to be really smaller for 2.6.37.
Patch and build procedure is:
mkdir kernel-grsec
cd kernel-grsec
svn co svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6
cd linux-2.6
curl
http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/add-grsecurity-featureset.patch
|patch
cd debian/patches/features/all/grsec
wget
http://grsecurity.net/stable/grsecurity-2.2.1-2.6.32.27-201101021130.patch
cp grsecurity-2.2.1-2.6.32.27-201101021130{,+debian}.patch
curl
http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/debian-grsecurity.patch
|patch grsecurity-2.2.1-2.6.32.27-201101021130+debian.patch
cd ../../../../../..
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.tar.bz2
cd linux-2.6
python debian/bin/genorig.py ../linux-2.6.32.tar.bz2
debian/rules debian/control-real
dpkg-buildpackage -us -uc (or fakeroot make -f debian/rules.gen
binary-arch_amd64_grsec_amd64 or the variant you need)
See the kernel handbook (http://kernel-handbook.alioth.debian.org/) for
more info, and remember to check the various stuff you download,
sha1sums for the patches are:
e0a7d38f93a7857f2caceb13cac56eebb4b79530 add-grsecurity-featureset.patch
20c7c213f36f1a99a381d5fca563d9c22236e172 debian-grsecurity.patch
Comments welcome.
Regards,
--
Yves-Alexis Perez
ANSSI/ACE/LAM
Index: debian/patches/series/30-extra
===
--- debian/patches/series/30-extra (revision 16770)
+++ debian/patches/series/30-extra (working copy)
@@ -22,3 +22,5 @@
+ features/all/xen/radeon-ttm-PCIe-Use-dma_addr-if-TTM-has-set-it.patch featureset=xen
+ features/all/xen/nouveau-ttm-PCIe-Use-dma_addr-if-TTM-has-set-it.patch featureset=xen
+ features/all/xen/radeon-PCIe-Use-the-correct-index-field.patch featureset=xen
+
++ features/all/grsec/grsecurity-2.2.1-2.6.32.27-201101021130+debian.patch featureset=grsec
Index: debian/changelog
===
--- debian/changelog (revision 16770)
+++ debian/changelog (working copy)
@@ -22,6 +22,9 @@
* r8169: Change RTL8111D/RTL8168D initialisation and firmware loading to
match upstream version (for #564628)
+ [ Yves-Alexis Perez ]
+ * Add a grsecurity featureset.
+
[ maximilian attems ]
* [openvz] Reenable NF_CONNTRACK_IPV6. (closes: #580507)
* cifs: fix another memleak, in cifs_root_iget.
Index: debian/config/i386/grsec/defines
===
--- debian/config/i386/grsec/defines (revision 0)
+++ debian/config/i386/grsec/defines (revision 0)
@@ -0,0 +1,9 @@
+[base]
+flavours:
+ 686
+ amd64
+
+[grsec]
+flavours:
+ i386
+ amd64
Index: debian/config/i386/defines
===
--- debian/config/i386/defines (revision 16770)
+++ debian/config/i386/defines (working copy)
@@ -7,6 +7,7 @@
openvz
vserver
xen
+ grsec
flavours:
486
686
Index: debian/config/featureset-grsec/config
===
--- debian/config/featureset-grsec/config (revision 0)
+++ debian/config/featureset-grsec/config (revision 0)
@@ -0,0 +1,144 @@
+#
+# Grsecurity
+#
+CONFIG_GRKERNSEC=y
+# CONFIG_GRKERNSEC_LOW is not set
+# CONFIG_GRKERNSEC_MEDIUM is not set
+CONFIG_GRKERNSEC_HIGH=y
+# CONFIG_GRKERNSEC_CUSTOM is not set
+
+#
+# Address Space Protection
+#
+CONFIG_GRKERNSEC_KMEM=y
+CONFIG_GRKERNSEC_IO=y
+CONFIG_GRKERNSEC_PROC_MEMMAP=y
+CONFIG_GRKERNSEC_BRUTE=y
+CONFIG_GRKERNSEC_MODHARDEN=y
+CONFIG_GRKERNSEC_HIDESYM=y
+
+#
+# Role Based Access Control Options
+#
+# CONFIG_GRKERNSEC_NO_RBAC is not set
+CONFIG_GRKERNSEC_ACL_HIDEKERN=y
+CONFIG_GRKERNSEC_ACL_MAXTRIES=3
+CONFIG_GRKERNSEC_ACL_TIMEOUT=30
+
+#
+# Filesystem Protections
+#
+CONFIG_GRKERNSEC_PROC=y
+CONFIG_GRKERNSEC_PROC_USER=y
+CONFIG_GRKERNSEC_PROC_USERGROUP=y
+CONFIG_GRKERNSEC_PROC_GID=64044
+CONFIG_GRKERNSEC_PROC_ADD=y
+CONFIG_GRKERNSEC_LINK=y
+CONFIG_GRKERNSEC_FIFO=y
+CONFIG_GRKERNSEC_ROFS=y
+CONFIG_GRKERNSEC_CHROOT=y
+CONFIG_GRKERNSEC_CHROOT_MOUNT=y
+CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
+CONFIG_GRKERNSEC_CHROOT_PIVOT=y
+CONFIG_GRKERNSEC_CHROOT_CHDIR=y
+CONFIG_GRKERNSEC_CHROOT_CHMOD=y
+CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
+CONFIG_GRKERNSEC_CHROOT_MKNOD=y
+CONFIG_GRKERNSEC_CHROOT_SHMAT=y
+CONFIG_GRKERNSEC_CHROOT_UNIX=y
+CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
+CONFIG_GRKERNSEC_CHROOT_NICE=y
+CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
Processed: reassign
Processing commands for cont...@bugs.debian.org: reassign 603767 linux-2.6,xorg Bug #603767 [general] gdm: starts on v8 instead of vt7 Bug reassigned from package 'general' to 'linux-2.6,xorg'. reassign 596700 linux-2.6,xorg Bug #596700 [xorg] The X server does not deallocate its vt upon shutdown. Restarting the X server results in the use of a higher-numbered vt. Bug reassigned from package 'xorg' to 'linux-2.6,xorg'. Bug No longer marked as found in versions xorg/1:7.5+6. forcemerge 603767 596700 Bug#603767: gdm: starts on v8 instead of vt7 Bug#596700: The X server does not deallocate its vt upon shutdown. Restarting the X server results in the use of a higher-numbered vt. Forcibly Merged 596700 603767. thanks Stopping processing here. Please contact me if you need assistance. -- 596700: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596700 603767: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603767 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129414041426363.transcr...@bugs.debian.org
Re: Bug#607368: Please decide how kernel ABI should be managed
Don Armstrong d...@debian.org wrote: Hi, Ok. For some reason, I hadn't originally noticed that this was concerning an OOT module which Debian itself didn't actually distribute. [Julien: I'm correct in that, right?] But that's probably fine. You are correct. Julien: Are you currently shipping a kernel in production which would be affected by this change if we don't change the ABI number? Or does this only affect cases where you are testing squeeze? Could it be I have 30 beta-testers that are affected by this issue on the workstations they have started using for their everyday work. Although it's still a beta phase, at this point, these workstations are to be considered in production given the users have basically made the switch now. Full deployment involves over a thousand workstations. worked around by using DKMS or similar with prebuilt binaries and requiring exact kernel version dependencies? DKMS is useless if the ABI number doesn't change, in its current form. If DKMS was changed to rebuild all modules when the kernel package is upgraded, we'd still have issues with on-disk modules not matching the running kernel ABI until the machine is rebooted. This can sometimes take two or three weeks if a long-running computation is running on the machine. We switched to DKMS to reduce the maintenance cost associated with prebuilt binaries. We'd rather not come back to that if we can help it. It also adds a delay to kernel updates that we'd rather avoid. As to using strict dependencies... it makes all of the above even worse. And I'll ask again: what's the point of the kernel ABI number if we have to use strict dependencies? Seriously? We need a kernel ABI numbering we can rely on. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc7wgb6x@sonic.technologeek.org
Bug#607709: XEN kernel crash (this time with a shorter trace)
On Thu, 2010-12-30 at 16:02 +0100, Giuseppe Sacco wrote:
A new crash on that machine, after upgrading kernel, is shown here:
Dec 29 22:21:28 atf-124 kernel: [49041.588528] [ cut here
]
Dec 29 22:21:28 atf-124 kernel: [49041.591269] kernel BUG at
/build/buildd-linux-2.6_2.6.32-29-i386-Of6Yt1/linux-2.6-2.6
.32/debian/build/source_i386_xen/arch/x86/xen/enlighten.c:309!
This seems to be this BUG():
static void set_aliased_prot(void *v, pgprot_t prot)
{
[...]
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
I would expect some log on the hypervisor console (xm dmesg) which
corresponds with this hypercall failure, which would be very useful to
see..
Ian.
--
Ian Campbell
Current Noise: Soilwork - Distortion Sleep
You need tender loving care once a week - so that I can slap you into shape.
-- Ellyn Mustard
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1294141998.3831.189.ca...@zakaz.uk.xensource.com
Bug#607709: XEN kernel crash (this time with a shorter trace)
Hi Ian,
thanks for working on this report.
Il giorno mar, 04/01/2011 alle 11.53 +, Ian Campbell ha scritto:
On Thu, 2010-12-30 at 16:02 +0100, Giuseppe Sacco wrote:
A new crash on that machine, after upgrading kernel, is shown here:
Dec 29 22:21:28 atf-124 kernel: [49041.588528] [ cut here
]
Dec 29 22:21:28 atf-124 kernel: [49041.591269] kernel BUG at
/build/buildd-linux-2.6_2.6.32-29-i386-Of6Yt1/linux-2.6-2.6
.32/debian/build/source_i386_xen/arch/x86/xen/enlighten.c:309!
This seems to be this BUG():
static void set_aliased_prot(void *v, pgprot_t prot)
{
[...]
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
I would expect some log on the hypervisor console (xm dmesg) which
corresponds with this hypercall failure, which would be very useful to
see..
Currently I cannot access that machine because of public holidays. The
problem about this request is that during last test the machine crashed
and automatically rebooted. We will try again one ot these days,
hopefully before tomorrow.
Bye,
Giuseppe
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1294146331.11730.8.ca...@scarafaggio
Bug#607709: XEN kernel crash (this time with a shorter trace)
Hi Ian, Il giorno mar, 04/01/2011 alle 11.53 +, Ian Campbell ha scritto: On Thu, 2010-12-30 at 16:02 +0100, Giuseppe Sacco wrote: [...] I would expect some log on the hypervisor console (xm dmesg) which corresponds with this hypercall failure, which would be very useful to see.. I just received the attached log for yesterday crash. It includes output from dmesg and from xm dmesg. Bye, Giuseppe bug#607709.tbz Description: application/bzip-compressed-tar
Bug#607709: XEN kernel crash (this time with a shorter trace)
On Tue, 2011-01-04 at 14:48 +0100, Giuseppe Sacco wrote: Hi Ian, Il giorno mar, 04/01/2011 alle 11.53 +, Ian Campbell ha scritto: On Thu, 2010-12-30 at 16:02 +0100, Giuseppe Sacco wrote: [...] I would expect some log on the hypervisor console (xm dmesg) which corresponds with this hypercall failure, which would be very useful to see.. I just received the attached log for yesterday crash. It includes output from dmesg and from xm dmesg. Thanks. Unfortunately there doesn't seem to be anything of interest in the xm dmesg output. It's possible that you need to add loglvl=all guest_loglvl=all to the hypervisor command line in order to get the messages. Are you able to try that? Ian. -- Ian Campbell Current Noise: The Hidden Hand - Black Ribbon More software projects have gone awry for lack of calendar time than for all other causes combined. -- Fred Brooks, Jr., _The Mythical Man Month_ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294149206.3831.219.ca...@zakaz.uk.xensource.com
Bug#606964: linux-image-2.6.32-5-xen-amd64: Xen fails to boot dom0 kernel on system with, lots of RAM
On Mon, 2011-01-03 at 09:59 +0100, Rik Theys wrote: Hi, On 12/22/2010 10:34 AM, Ian Campbell wrote: I was wondering about clamping something in the kernel to correspond to CONFIG_XEN_MAX_DOMAIN_MEMORY and avoid the issue but you say the crash is after x VCPUS and before Scrubbing Free RAM so I'm surprised the dom0 kernel has run at this point and hence changing it would not help. The hypervisor doesn't know about this guest configuration item so there isn't much which can be done there. To try and confirm what is going on is there any chance you could you collect a serial console log with verbose debugging enabled by using the command line parameters described in Are there more debugging options I could enable to troubleshoot booting problems? of http://wiki.xensource.com/xenwiki/XenParavirtOps (without the recommended dom0_mem). The console log is attached. Thanks. Did you use earlyprintk=xen on the kernel command line as well as the loglvl=all stuff on the hypervisor command line? Now I think of it can you also collect a similar log with the dom0_mem workaround in place, for comparisons sake. Assuming that shows that the domain 0 kernel did actually get a chance to run and crash I'll take a look at what else needs to be clamped to have it just work. From what I can see in the log, the dom0 kernel doesn't seem to get started. It does rather look that way. If you press Ctrl-A three times on the hypervisor serial console then you might be able to inject some hypervisor debug keys. Such as 'q' which should dump a dump of interesting state about dom0. '0' and 'd' might also print something of interest. Press 'h' for a list of available keys. Ian. -- Ian Campbell Current Noise: The Hidden Hand - Magdalene Never get into fights with ugly people because they have nothing to lose. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294150116.3831.248.ca...@zakaz.uk.xensource.com
Bug#606964: linux-image-2.6.32-5-xen-amd64: Xen fails to boot dom0 kernel on system with, lots of RAM
On Tue, 2011-01-04 at 14:08 +, Ian Campbell wrote: Now I think of it can you also collect a similar log with the dom0_mem workaround in place, for comparisons sake. Are you able to rebuild the kernel with CONFIG_XEN_MAX_DOMAIN_MEMORY=128? If so then a log of that boot for comparison would be very interesting. If you don't know how let me know and I'll build one for you. Ian. -- Ian Campbell Current Noise: The Hidden Hand - Sons Of Kings If you are too busy to read, then you are too busy. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294150698.3831.264.ca...@zakaz.uk.xensource.com
Bug#608144: linux-image-2.6.32-5-xen-amd64: Kernel oops: net/core/dev.c:1582 skb_gso_segment+0x109/0x263() (Bug #596802 reappeared)
Hi Ian, I've tried with 2.6.32-28 but problem persists. So we have a problem with symptoms similar to #596802. I'll attach the oops details. Regards, Stephan Jan 4 17:46:33 n0020 kernel: [ 82.100424] device vif1.0 entered promiscuous mode Jan 4 17:46:33 n0020 kernel: [ 82.103545] br0: port 2(vif1.0) entering learning state Jan 4 17:46:33 n0020 kernel: [ 82.269708] ip_tables: (C) 2000-2006 Netfilter Core Team Jan 4 17:46:34 n0020 kernel: [ 82.900774] nf_conntrack version 0.5.0 (4062 buckets, 16248 max) Jan 4 17:46:34 n0020 kernel: [ 82.901499] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use Jan 4 17:46:34 n0020 kernel: [ 82.901773] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or Jan 4 17:46:34 n0020 kernel: [ 82.902035] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. Jan 4 17:46:34 n0020 kernel: [ 83.335139] tun: Universal TUN/TAP device driver, 1.6 Jan 4 17:46:34 n0020 kernel: [ 83.335428] tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com Jan 4 17:46:34 n0020 kernel: [ 83.492992] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. Jan 4 17:46:34 n0020 kernel: [ 83.507857] device tap1.0 entered promiscuous mode Jan 4 17:46:34 n0020 kernel: [ 83.508180] br0: port 3(tap1.0) entering learning state Jan 4 17:46:44 n0020 kernel: [ 92.692116] hrtimer: interrupt took 150037247 ns Jan 4 17:46:48 n0020 kernel: [ 97.101015] br0: port 2(vif1.0) entering forwarding state Jan 4 17:46:49 n0020 kernel: [ 98.508020] br0: port 3(tap1.0) entering forwarding state Jan 4 17:46:52 n0020 kernel: [ 100.992120] br0: port 3(tap1.0) entering disabled state Jan 4 17:46:52 n0020 kernel: [ 101.008073] device tap1.0 left promiscuous mode Jan 4 17:46:52 n0020 kernel: [ 101.008263] br0: port 3(tap1.0) entering disabled state Jan 4 17:46:56 n0020 kernel: [ 105.285534] blkback: ring-ref 1536, event-channel 6, protocol 2 (x86_32-abi) Jan 4 17:47:04 n0020 kernel: [ 113.061493] frontend_changed: backend/vif/1/0: prepare for reconnect Jan 4 17:47:55 n0020 kernel: [ 164.315756] [ cut here ] Jan 4 17:47:55 n0020 kernel: [ 164.316079] WARNING: at /build/buildd-linux-2.6_2.6.32-28-amd64-EUJiNq/linux-2.6-2.6.32/debian/build/source_amd64_xen/net/core/dev.c:1582 skb_gso_segment+0x109/0x263() Jan 4 17:47:55 n0020 kernel: [ 164.316689] Hardware name: Jan 4 17:47:55 n0020 kernel: [ 164.316991] e1000e: caps=(0x110ba9, 0x0) len=5453 data_len=5395 ip_summed=1 Jan 4 17:47:55 n0020 kernel: [ 164.317001] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 tun xt_state nf_conntrack xt_physdev iptable_filter ip_tables x_tables nfsd lockd nfs_acl auth_rpcgss sunrpc xen_evtchn exportfs xenfs bridge stp ext3 jbd mbcache loop firewire_sbp2 nouveau ttm drm_kms_helper snd_hda_codec_idt drm i2c_algo_bit i2c_i801 parport_pc i2c_core parport snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd pcspkr evdev button processor soundcore snd_page_alloc acpi_processor dm_mod btrfs zlib_deflate crc32c libcrc32c sg sd_mod crc_t10dif sr_mod cdrom uhci_hcd firewire_ohci ata_generic ahci pata_marvell firewire_core libata floppy ehci_hcd scsi_mod thermal thermal_sys crc_itu_t e1000e usbcore nls_base [last unloaded: scsi_wait_scan] Jan 4 17:47:55 n0020 kernel: [ 164.319704] Pid: 0, comm: swapper Not tainted 2.6.32-5-xen-amd64 #1 Jan 4 17:47:55 n0020 kernel: [ 164.319704] Call Trace: Jan 4 17:47:55 n0020 kernel: [ 164.319704] IRQ [8125eeb6] ? skb_gso_segment+0x109/0x263 Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8125eeb6] ? skb_gso_segment+0x109/0x263 Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8104ed8c] ? warn_slowpath_common+0x77/0xa3 Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8104ee14] ? warn_slowpath_fmt+0x51/0x59 Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8100e5bd] ? xen_force_evtchn_callback+0x9/0xa Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8100ec72] ? check_events+0x12/0x20 Jan 4 17:47:55 n0020 kernel: [ 164.319704] [a003f739] ? e1000_get_drvinfo+0xac/0xe3 [e1000e] Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8125eeb6] ? skb_gso_segment+0x109/0x263 Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8125f1c0] ? dev_hard_start_xmit+0x1b0/0x2b8 Jan 4 17:47:55 n0020 kernel: [ 164.319704] [81272550] ? sch_direct_xmit+0x58/0x14c Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8125f61b] ? dev_queue_xmit+0x252/0x38d Jan 4 17:47:55 n0020 kernel: [ 164.319704] [a02c7c51] ? br_dev_queue_push_xmit+0x75/0x79 [bridge] Jan 4 17:47:55 n0020 kernel: [ 164.319704] [a02cc050] ? br_nf_post_routing+0x1b1/0x1c8 [bridge] Jan 4 17:47:55 n0020 kernel: [ 164.319704] [8127c16a] ? nf_iterate+0x41/0x7d Jan 4 17:47:55 n0020 kernel: [ 164.319704] [a02c7bdc] ?
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
Hi, No, unfortunately not. I just suffered it again aswell over the Christmas break. Let me know if you find any fix. Regards, Mark On Sun, Dec 26, 2010 at 12:50:26PM +0100, Moritz Muehlenhoff wrote: On Wed, Oct 06, 2010 at 12:05:18PM +0100, Mark Adams wrote: As this is when the clock went from 18:00 to 18:50 and started the chain of events (restarted the 2008 domU). Any ideas why this log occurred? The TSC appeared to go backwards by a fairly significant amount, which has upset the kernel. The behaviour of the virtual TSC as seen by an HVM guest is controlled by a combination of the tsc_mode setting in your domain configuration and, I think, by the features of your specific hardware (some have constant rate TSC, others advertise varying levels of synchronisation between cores etc). It's then up to the guest kernel whether it even uses TSC as a timesource at all and how it handles instability etc and how it derives other time sources (such as the wallclock time) from it. Sorry this isn't more helpful, but as I say you will probably get better answers on one of the Xen mailing lists. Hi Ian, Thanks for your notes. I've already tried the xen-users list so I will try xen-devel to see if I can glean any more information about my issue. I will update the report here when I get any more information. Did you contact them? From what I read from the bug report so far, running an NTP client in the HVM host should suffice. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104165600.ga19...@campbell-lange.net
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
In addition, I received the below from James Song but when I queried what it changed he did not respond, so I haven't tried it.. added timer_mode =2 and tsc_mode = 1 and viridian=1 into your configure file. On Tue, Jan 04, 2011 at 04:56:00PM +, Mark Adams wrote: Hi, No, unfortunately not. I just suffered it again aswell over the Christmas break. Let me know if you find any fix. Regards, Mark On Sun, Dec 26, 2010 at 12:50:26PM +0100, Moritz Muehlenhoff wrote: On Wed, Oct 06, 2010 at 12:05:18PM +0100, Mark Adams wrote: As this is when the clock went from 18:00 to 18:50 and started the chain of events (restarted the 2008 domU). Any ideas why this log occurred? The TSC appeared to go backwards by a fairly significant amount, which has upset the kernel. The behaviour of the virtual TSC as seen by an HVM guest is controlled by a combination of the tsc_mode setting in your domain configuration and, I think, by the features of your specific hardware (some have constant rate TSC, others advertise varying levels of synchronisation between cores etc). It's then up to the guest kernel whether it even uses TSC as a timesource at all and how it handles instability etc and how it derives other time sources (such as the wallclock time) from it. Sorry this isn't more helpful, but as I say you will probably get better answers on one of the Xen mailing lists. Hi Ian, Thanks for your notes. I've already tried the xen-users list so I will try xen-devel to see if I can glean any more information about my issue. I will update the report here when I get any more information. Did you contact them? From what I read from the bug report so far, running an NTP client in the HVM host should suffice. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104165834.ga19...@campbell-lange.net
Bug#608144: linux-image-2.6.32-5-xen-amd64: Kernel oops: net/core/dev.c:1582 skb_gso_segment+0x109/0x263() (Bug #596802 reappeared)
On Tue, 2011-01-04 at 17:54 +0100, Stephan Austermühle wrote: Hi Ian, I've tried with 2.6.32-28 but problem persists. So we have a problem with symptoms similar to #596802. I'll attach the oops details. Thanks. I don't suppose you feel inclined to bisect between -23 and -28 to find the first broken version, do you? (http://snapshot.debian.org/ is your friend here) If not (I wouldn't blame you) then are you at least able to verify that 2.6.32-23 worked for you, to rule out the possibility that this is a similar but different issue to #596802. Ian. -- Ian Campbell Current Noise: Turbonegro - High On The Crime Delta: The kids will love our inflatable slides.-- David Letterman -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294162391.3831.680.ca...@zakaz.uk.xensource.com
Bug#608865: initramfs-tools: postinst fails if /tmp is mounted noexec
On Tue, Jan 04, 2011 at 08:30:27AM +0100, Martin Gerdes wrote: Installing initramfs-tools version 0.98.7 on squeeze (=debian testing) I get the following error messages: /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-top/all_generic_ide: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-top/blacklist: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-top/keymap: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-top/udev: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-bottom/udev: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/local-premount/resume: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/local-bottom/cryptopensc: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/local-top/cryptopensc: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/local-top/cryptroot: Permission denied /usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/local-top/lvm2: Permission denied aboves does not give much info, but doesn't look pretty indeed. is that the full log? -the postinst fails because /tmp is mounted noexec, and the script can't set the executable bit for the listed files Found this thread which indicates that m...@sro.at fixed the problem: http://lists.debian.org/debian-kernel/2010/04/msg00481.html I can work around this for now given the hints in the thread (I'll just point $TMPDIR to another director for the install), but would like to know if this will get fixed for final sqeeze? I'll definitely run into problems otherwise, as /tmp is set to noexec on all servers... Many thanks in advance, and a happy new year hmm please follow on with reportbug on an affected box, as this report misses vital info that reportbug does gather directly: reportbug -N bugnr also needed is the output of the following commands: mount sh -x /usr/sbin/mkinitramfs -o /tmp/foo thank you -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104203531.gu20...@vostochny.stro.at
Bug#606964: linux-image-2.6.32-5-xen-amd64: Xen fails to boot dom0 kernel on system with, lots of RAM
Iann Now I think of it can you also collect a similar log with the dom0_mem workaround in place, for comparisons sake. Are you able to rebuild the kernel with CONFIG_XEN_MAX_DOMAIN_MEMORY=128? If so then a log of that boot for comparison would be very interesting. If you don't know how let me know and I'll build one for you. If you find the time, please build one. I hope to be able to test it soon. -- Rik -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1101042142500.20...@helium.esat.kuleuven.be
Bug#608144: linux-image-2.6.32-5-xen-amd64: Kernel oops: net/core/dev.c:1582 skb_gso_segment+0x109/0x263() (Bug #596802 reappeared)
Hello, Am 04.01.2011 18:33, schrieb Ian Campbell: I don't suppose you feel inclined to bisect between -23 and -28 to find the first broken version, do you? (http://snapshot.debian.org/ is your friend here) I've checked... -23: oops -24: oops -25: oops -26: oops -27: oops -28: oops -29: oops So the problem was already present in -23 and it just seems to have the same symptoms like #596802. Regards, Stephan smime.p7s Description: S/MIME Cryptographic Signature
Bug#608144: linux-image-2.6.32-5-xen-amd64: Kernel oops: net/core/dev.c:1582 skb_gso_segment+0x109/0x263() (Bug #596802 reappeared)
On Tue, 2011-01-04 at 21:44 +0100, Stephan Austermühle wrote: So the problem was already present in -23 and it just seems to have the same symptoms like #596802. OK, thanks for testing that. I wonder if you could play with ethtool to enable/disable various features on the physical NIC. In particular I think it might be worth fiddling with the LRO and GRO settings, via the -k/-K options. The reason for this is that the warning you are seeing is because the skb in question has skb-gso_size != 0 (i.e. it is apparently a GSO skb) but it is not skb-ip_summed == CHECKSUM_PARTIAL, which is necessary in order to do GSO, (i.e. to send the SKB). I think one way that such skbs can be injected into the system is via LRO on the physical NIC (LRO is a bit like, but not exactly identical to, the opposite of GSO, AIUI). When an NIC which supports LRO is bridged then these SKBs are passed across the bridge and end up getting treated as GSO on the outgoing path (i.e. the VIF) even though they aren't quite GSO frames, and this triggers the warning in skb_gso_segment. GRO is a generalisation of LRO, I'm not sure if it is supposed to fix this forwarding issue or not. Ian. -- Ian Campbell Reactor error - core dumped! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294178912.13733.25.ca...@localhost.localdomain
Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file
package linux-2.6 retitle 608858 copying large file with smbd on raid causes BUG at fs/jbd/transaction.c:1156 thanks [resending via smtp.academica.fi since smtp.netsonic.fi does not seem to be delivering my emails any time soon...] Gregg gkn...@tampabay.rr.com writes: [1393760.788377] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid block bitmap - block_group = 1229, block = 40271874 [1393760.788779] [ cut here ] [1393760.788835] kernel BUG at /build/buildd-linux-2.6_2.6.32-28~bpo50+1-i386-VgAojN/linux-2.6-2.6.32/debian/build/source_i386_none/fs/jbd/transaction.c:1156! Sounds like an ext3 bug. Either ext3 corrupted its data structures or something else (HDD, RAM) did and ext3 didn't cope with it. Googling for BUG jbd/transaction.c:1156 finds other cases: I installed Debian Squeeze from a net install to a raid 1 array. I have been having a lot of troubles related to being able to write to one or more of the mounted drives - even touch gives me errors. The most interesting line from dmesg is: [15174.549931] kernel BUG at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/fs/jbd/transaction.c:1156! Here is the full output from dmesg: -- http://forums.debian.net/viewtopic.php?f=5t=56527 1) Are you using aacraid on this dm-5 device too? 2) Can you make the bug occur again? 3) If yes, can you temporarily try it without raid at all? (Just make backups before test) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8462u4ibfp@sauna.l.org
Processed: Re: Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file
Processing commands for cont...@bugs.debian.org: package linux-2.6 Limiting to bugs with field 'package' containing at least one of 'linux-2.6' Limit currently set to 'package':'linux-2.6' retitle 608858 copying large file with smbd on raid causes BUG at fs/jbd/transaction.c:1156 Bug #608858 [linux-2.6] linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file Changed Bug title to 'copying large file with smbd on raid causes BUG at fs/jbd/transaction.c:1156' from 'linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file' thanks Stopping processing here. Please contact me if you need assistance. -- 608858: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608858 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12941794501239.transcr...@bugs.debian.org
Re: Bug#607368: Please decide how kernel ABI should be managed
On Tue, Jan 04, 2011 at 12:28:22PM +0100, Julien BLACHE wrote: Don Armstrong d...@debian.org wrote: [...] worked around by using DKMS or similar with prebuilt binaries and requiring exact kernel version dependencies? DKMS is useless if the ABI number doesn't change, in its current form. If DKMS was changed to rebuild all modules when the kernel package is upgraded, we'd still have issues with on-disk modules not matching the running kernel ABI until the machine is rebooted. This can sometimes take two or three weeks if a long-running computation is running on the machine. We switched to DKMS to reduce the maintenance cost associated with prebuilt binaries. We'd rather not come back to that if we can help it. It also adds a delay to kernel updates that we'd rather avoid. As to using strict dependencies... it makes all of the above even worse. And I'll ask again: what's the point of the kernel ABI number if we have to use strict dependencies? Seriously? [...] Do pay attention. We were discussing the implications of changing our current practice of trying to avoid ABI bumps during freeze and stable updates. We would then probably change the uname release (the ABI identifier) in each version of the package. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104223042.gh3...@decadent.org.uk
Re: Bug#607368: Please decide how kernel ABI should be managed
On Tue, 04 Jan 2011, Julien BLACHE wrote: Don Armstrong d...@debian.org wrote: Julien: Are you currently shipping a kernel in production which would be affected by this change if we don't change the ABI number? Or does this only affect cases where you are testing squeeze? Could it be I have 30 beta-testers that are affected by this issue on the workstations they have started using for their everyday work. Although it's still a beta phase, at this point, these workstations are to be considered in production given the users have basically made the switch now. Ok. My main concern here is what exactly would happen if we were to ignore the ABI change for this particular issue, and then put in place some kind of a process where the kernel team could be informed of downstream users of the ABI. From my current understanding, the ABI number is only meant to cover some of the symbols which can be used externally, not all of them. [Specifically, those that the kernel team are aware of being used externally.] Full deployment involves over a thousand workstations. But presumably they're not running a testing version affected by this. worked around by using DKMS or similar with prebuilt binaries and requiring exact kernel version dependencies? DKMS is useless if the ABI number doesn't change, in its current form. If DKMS was changed to rebuild all modules when the kernel package is upgraded, we'd still have issues with on-disk modules not matching the running kernel ABI until the machine is rebooted. This can sometimes take two or three weeks if a long-running computation is running on the machine. Presumably this wouldn't be much of an issue, unless users are going to be newly loading these modules. [Which I would hope wouldn't be the case if you were running a long-running computation.] As to using strict dependencies... it makes all of the above even worse. Certainly; there's a cost to be born on both sides. The most important thing to avoid from my perspective is a kernel which when booted has modules that cannot be loaded. And I'll ask again: what's the point of the kernel ABI number if we have to use strict dependencies? Some modules may need strict dependencies if they are using symbols not covered by the ABI; this is one possible way that we can resolve this issue. Seriously? Lets restrict ourselves to discussing the technical issues and possible solutions instead of rhetorical flourishes. Don Armstrong -- The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104230510.gn4...@rzlab.ucr.edu
Bug#608144: linux-image-2.6.32-5-xen-amd64: Kernel oops: net/core/dev.c:1582 skb_gso_segment+0x109/0x263() (Bug #596802 reappeared)
On Tue, Jan 04, 2011 at 10:08:32PM +, Ian Campbell wrote: On Tue, 2011-01-04 at 21:44 +0100, Stephan Austermühle wrote: So the problem was already present in -23 and it just seems to have the same symptoms like #596802. OK, thanks for testing that. I wonder if you could play with ethtool to enable/disable various features on the physical NIC. In particular I think it might be worth fiddling with the LRO and GRO settings, via the -k/-K options. I don't think this has anything to do with the physical NIC. LRO is automatically turned off for interfaces that are connected to a bridge, and GRO is safe with bridging. The reason for this is that the warning you are seeing is because the skb in question has skb-gso_size != 0 (i.e. it is apparently a GSO skb) but it is not skb-ip_summed == CHECKSUM_PARTIAL, which is necessary in order to do GSO, (i.e. to send the SKB). It's not so much necessary as the only valid possibility for an skb that requires GSO. On output an skb must have ip_summed = CHECKSUM_NONE (not to be checksummed) or ip_summed = CHECKSUM_PARTIAL (checksum to be calculated by hardware or software). But here we see ip_summed = CHECKSUM_UNNECESSSARY which is only meaningful on input. So, I think what's happening here is: 1. The Windows PVHVM driver claims to support checksum offload and TSO. Windows passes it oversized packets with no checksum information. 2. netback receives these oversized packets and sets gso_size on the skb just as if they were received with LRO or GRO. Since the packet does not have valid checksums either in-band or out-of-band, it labels the skb with ip_summed = CHECKSUM_UNNECESSARY. On Linux the stack always calculates the IPv4 checksum and the TCP/UDP pseudo-header checksum (ip_summed = CHECKSUMMED_PARTIAL refers to this partial checksum information). For packets received from a Linux guest, netback will label the skb accordingly and GSO is happy. netback needs to fix up the checksum information for packets that the guest sent with TSO and no checksum: 1. Calculate the IPv4 header checksum and write it to the packet buffer (not for IPv6, obviously). 2. Calculate the TCP/UDP pseudo-header checksum and store it in skb-csum. 3. Set skb-csum_start and skb-csum_offset per kernel-doc. 4. Set skb-ip_summed = CHECKSUM_PARTIAL. I think one way that such skbs can be injected into the system is via LRO on the physical NIC (LRO is a bit like, but not exactly identical to, the opposite of GSO, AIUI). When an NIC which supports LRO is bridged then these SKBs are passed across the bridge and end up getting treated as GSO on the outgoing path (i.e. the VIF) even though they aren't quite GSO frames, and this triggers the warning in skb_gso_segment. GRO is a generalisation of LRO, I'm not sure if it is supposed to fix this forwarding issue or not. GRO is a specific software implementation of LRO that preserves enough information that it is safe to bridge/forward the resulting skb. The original packets can be reconstructed on transmit (usually through TSO, otherwise through GSO). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104231438.gi3...@decadent.org.uk
Re: Bug#607368: Please decide how kernel ABI should be managed
Ben Hutchings b...@decadent.org.uk writes: Do pay attention. We were discussing the implications of changing our current practice of trying to avoid ABI bumps during freeze and stable updates. We would then probably change the uname release (the ABI identifier) in each version of the package. This is certainly becoming more appealing with DKMS, but with my Stanford sysadmin hat on, I have to admit that we'd find it rather annoying if the ABI changed in stable. I think that may be a good way to go in unstable and testing up to the release, but it would be very nice to not do that after the release. With hundreds of servers, we'd rather not install compilers and DKMS on every one of them, and with lots of machines, the loss of reproducibility from separately compiling the modules on every system is an increasingly large drawback. We currently build internal packages (from the *-source packages provided by Debian) for those external modules that we use so that we can deploy the same thing everywhere, and having to rebuild modules for every kernel update and deploy those new builds with the kernel update would be fairly annoying. With that system, we know for sure that if the module mysteriously fails on one system but not on others, it's not because it's a weird build or has some other compilation issue. In fact, we know almost exactly how annoying it would be, since Red Hat has this policy, and it's been a major pain. The handling of the kernel versioning in stable is currently one of the major selling points for Debian over Red Hat for us. The very few times an ABI change was forced in Debian stable due to some security issue, we had to put a fair bit of work into making sure that everything was upgraded properly everywhere to the new ABI. (So thank you very much for all the work that you put into maintaining the ABI!) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4iki1o2@windlord.stanford.edu
Re: Bug#607368: Please decide how kernel ABI should be managed
On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote: Ben Hutchings b...@decadent.org.uk writes: Do pay attention. We were discussing the implications of changing our current practice of trying to avoid ABI bumps during freeze and stable updates. We would then probably change the uname release (the ABI identifier) in each version of the package. This is certainly becoming more appealing with DKMS, but with my Stanford sysadmin hat on, I have to admit that we'd find it rather annoying if the ABI changed in stable. I think that may be a good way to go in unstable and testing up to the release, but it would be very nice to not do that after the release. However, the upstream policy for stable updates does not support this. With hundreds of servers, we'd rather not install compilers and DKMS on every one of them, and with lots of machines, the loss of reproducibility from separately compiling the modules on every system is an increasingly large drawback. This is why DKMS has the facility to build packages for installation elsewhere. We currently build internal packages (from the *-source packages provided by Debian) for those external modules that we use so that we can deploy the same thing everywhere, and having to rebuild modules for every kernel update and deploy those new builds with the kernel update would be fairly annoying. With that system, we know for sure that if the module mysteriously fails on one system but not on others, it's not because it's a weird build or has some other compilation issue. In fact, we know almost exactly how annoying it would be, since Red Hat has this policy, and it's been a major pain. The handling of the kernel versioning in stable is currently one of the major selling points for Debian over Red Hat for us. [...] Note that Red Hat does maintain the ABI for most functions, even though it change the uname release. If you package OOT modules using the 'KMP' macros for RPM, binary modules will be sym-linked into a 'weak-updates' subdirectory for a newer kernel if their symbol dependencies are still met. We could try to implement something like that in Debian. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Bug#607368: Please decide how kernel ABI should be managed
Ben Hutchings b...@decadent.org.uk writes: On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote: With hundreds of servers, we'd rather not install compilers and DKMS on every one of them, and with lots of machines, the loss of reproducibility from separately compiling the modules on every system is an increasingly large drawback. This is why DKMS has the facility to build packages for installation elsewhere. But there would be no purpose served in using DKMS for this. The only place where DKMS has an advantage over building real Debian packages for the modules is if you're going to let every machine build its own modules. As soon as you are distributing modules built once to multiple machines, using DKMS to do that is vaguely absurd: you have to reinvent all the mechanisms of a repository and package upgrade system, when we already have a perfectly useful and reasonable one in apt repositories with package versioning and proper dependencies. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877heki064@windlord.stanford.edu
Re: Bug#607368: Please decide how kernel ABI should be managed
On Tue, 2011-01-04 at 17:55 -0800, Russ Allbery wrote: Ben Hutchings b...@decadent.org.uk writes: On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote: With hundreds of servers, we'd rather not install compilers and DKMS on every one of them, and with lots of machines, the loss of reproducibility from separately compiling the modules on every system is an increasingly large drawback. This is why DKMS has the facility to build packages for installation elsewhere. But there would be no purpose served in using DKMS for this. The only place where DKMS has an advantage over building real Debian packages for the modules is if you're going to let every machine build its own modules. [...] DKMS does build real Debian packages. And that means that OOT module sources do not need to be packaged differently depending on where the modules will be built. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Bug#607368: Please decide how kernel ABI should be managed
Ben Hutchings b...@decadent.org.uk writes: DKMS does build real Debian packages. And that means that OOT module sources do not need to be packaged differently depending on where the modules will be built. Oh, huh, I hadn't noticed that. Thanks for the pointer! I'll have to play with that; I'd only previously seen the tarball distribution and installation mechanism. The work of providing both the -dkms and the traditional -source package is fairly trivial and not much of a drain on the packager's time once the original -source rules have been written. I'm doing it right now for multiple packages. But writing the original -source package rules file is arcane and very under-documented, so this is potentially a long-term improvement. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y670gl1j@windlord.stanford.edu
Processed: tagging 596390
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 596390 + pending Bug #596390 [linux-2.6] linux-image-2.6.32-bpo.5-amd64: r8169 Link not ready Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 596390: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596390 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129419358617340.transcr...@bugs.debian.org
Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file
I have not experienced a single bit of trouble until upgrading to this kernel. I will try writing a large file to other file systems as well, but I do know that I can write smaller, 1-300mb, files to other file systems without an issue. Yes I'm using aacraid. I'm using an Adaptec 2820 card with 4 500gb drives in raid 10. This is actually the second time it has happened performing the same action. Copying a large file from a Windows box via the Samba share. I will have to find a spare drive to connect and test. -Original Message- From: Timo Juhani Lindfors [mailto:timo.lindf...@iki.fi] Sent: Tuesday, January 04, 2011 2:22 AM To: Gregg Cc: 608...@bugs.debian.org; cont...@bugs.debian.org Subject: Re: Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file package linux-2.6 retitle 608858 copying large file with smbd on raid causes BUG at fs/jbd/transaction.c:1156 thanks [resending via smtp.academica.fi since smtp.netsonic.fi does not seem to be delivering my emails any time soon...] Gregg gkn...@tampabay.rr.com writes: [1393760.788377] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid block bitmap - block_group = 1229, block = 40271874 [1393760.788779] [ cut here ] [1393760.788835] kernel BUG at /build/buildd-linux-2.6_2.6.32-28~bpo50+1-i386-VgAojN/linux-2.6-2.6.32/debia n/build/source_i386_none/fs/jbd/transaction.c:1156! Sounds like an ext3 bug. Either ext3 corrupted its data structures or something else (HDD, RAM) did and ext3 didn't cope with it. Googling for BUG jbd/transaction.c:1156 finds other cases: I installed Debian Squeeze from a net install to a raid 1 array. I have been having a lot of troubles related to being able to write to one or more of the mounted drives - even touch gives me errors. The most interesting line from dmesg is: [15174.549931] kernel BUG at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/fs/jbd/transactio n.c:1156! Here is the full output from dmesg: -- http://forums.debian.net/viewtopic.php?f=5t=56527 1) Are you using aacraid on this dm-5 device too? 2) Can you make the bug occur again? 3) If yes, can you temporarily try it without raid at all? (Just make backups before test) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/000c01cbac7f$81f4f6d0$85dee4...@rr.com
Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file
After forcefully rebooting I have removed VMware from running at boot and will test again. I wanted to make sure nothing was left loaded after just removing the modules. I'm quite experienced in Windows, but don't know the in's and out's of Linux to the extent that I do of Windows. -Original Message- From: Ben Hutchings [mailto:b...@decadent.org.uk] Sent: Tuesday, January 04, 2011 12:03 AM To: Gregg; 608...@bugs.debian.org Subject: Re: Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file Can you reproduce this without VMware modules loaded? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/000d01cbac7f$83601f90$8a205e...@rr.com
Bug#604442: Claim 800,000.00 GBP in the Gnld 2011 Promo Send.
Name: Address: Occupation:
Processed: tagging 607863
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 607863 + pending Bug #607863 [linux-base] linux-base postinst fails to update UUIDs in /boot/boot/grub Ignoring request to alter tags of bug #607863 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 607863: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607863 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129419494321288.transcr...@bugs.debian.org
Processed: tagging 608185
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 608185 + pending Bug #608185 [linux-2.6] btrfs-tools: balance tree action should be only triggered by root Ignoring request to alter tags of bug #608185 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 608185: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608185 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129419494621309.transcr...@bugs.debian.org
Processed: tagging 596390
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 596390 + pending Bug #596390 [linux-2.6] linux-image-2.6.32-bpo.5-amd64: r8169 Link not ready Ignoring request to alter tags of bug #596390 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 596390: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596390 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129419494921346.transcr...@bugs.debian.org
Processed: tagging 608138
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 608138 + pending Bug #608138 [linux-2.6] Annoying warning NMI watchdog failed to create perf event on cpu0 Ignoring request to alter tags of bug #608138 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 608138: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608138 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129419545322912.transcr...@bugs.debian.org
Incomplete upload found in Debian upload queue
Probably you are the uploader of the following file(s) in the Debian upload queue directory: linux-2.6_2.6.37-1~experimental.1.dsc This looks like an upload, but a .changes file is missing, so the job cannot be processed. If no .changes file arrives within 23:12:45, the files will be deleted. If you didn't upload those files, please just ignore this message. Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1panhs-00015q...@franck.debian.org
