Bug#552142: Acknowledgement (linux-image-2.6.26-2-686: machine hangs with nf_conntrack: table full, dropping packet - needs hard reboot)
On Fri, Oct 23, 2009 at 07:27:58PM +0200, Toni Mueller wrote: I'm a bit confused as to why the wrong value gets set at boot time, but it doesn't really improve on the situation... The buckets are created during module loading. But /etc/sysctl.conf is evaluated earlier. Aren't you seeing errors about unknown keys during boot? Bastian -- Humans do claim a great deal for that particular emotion (love). -- Spock, The Lights of Zetar, stardate 5725.6 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian Kernel Group Meeting
On Fri, Oct 23, 2009 at 10:27:28AM +0100, Ian Campbell wrote: On Fri, 2009-10-23 at 11:06 +0200, Bastian Blank wrote: It is based on the pv-ops tree. Excellent, I think that's the right choice. If there is anything I can do to help please let me know. Well, the most important thing is to help Jeremy to get the Xen tree in shape. It still carries things that raised concerns like the APIC support or are simply not in a shape to go everywhere like the ACPI changes or the default config settings that build anything into the core and not as module. It just looks like a dump for everything. What you can also try is to get the Xen utils running on a distro supportable kernel, aka with anything built as module. That may also need to rename some modules, for example blkbk is no good name. To follow the convention it should be named xen-blkback. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, Friday's Child, stardate 3497.2 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers
Package: linux-headers-2.6.30-2-amd64 Version: 2.6.30-8 Severity: normal this bug is coming out of bug # 550595 alsa-source does not compile against patched headers. See BTS for above mentioned bug. I tried to build the modules via m-a. m-a buildlog attached to #550595 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-headers-2.6.30-2-amd64 depends on: ii gcc-4.3 4.3.4-5The GNU C compiler ii linux-headers-2.6.30-2-common 2.6.30-8 Common header files for Linux 2.6. ii linux-kbuild-2.6.30 2.6.30-1 Kbuild infrastructure for Linux 2. linux-headers-2.6.30-2-amd64 recommends no packages. linux-headers-2.6.30-2-amd64 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535331: 2.6.26-17lenny2 = 2.6.26-19 OK, 2.6.26-19 = 2.6.26-19lenny1 NOT OK
Just to add another data point, lilo failed to run again for me too on the 2.6.26-19lenny1 upgrade. Even after working on the previous kernel upgrade! I'm now totally lost wrt what triggers this bug... To summarize: 2.6.26-17lenny2 = 2.6.26-19 lilo OK 2.6.26-19 = 2.6.26-19lenny1 lilo not running There were no changes to neither initramfs-tools nor /etc/kernel-img.conf between these upgrades. My /etc/kernel-img.conf is still adler:/tmp# cat /etc/kernel-img.conf # Kernel Image management overrides # See kernel-img.conf(5) for details do_symlinks = Yes do_initrd = Yes do_bootloader = yes The upgrade log is shorter, and the shortage is of course the problem: Setting up linux-image-2.6.26-2-686 (2.6.26-19lenny1) ... Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-19 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-19 was configured last, according to dpkg) Setting up linux-libc-dev (2.6.26-19lenny1) ... (nothing more) At this point, the previous upgrade continued with update-initramfs: deferring update (trigger activated) so maybe this is some trigger-related problem? I do however note that the initrd.img is updated, even though the message update-initramfs: Generating /boot/initrd.img-2.6.26-2-686 also is missing. Any clues are appreciated. It's a real hassle to have to log in to each and every server and manually run lilo after each kernel security update, or risk dead servers on the next reboot. Bjørn -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers
Processing commands for cont...@bugs.debian.org: reassign 552203 alsa-source Bug #552203 [linux-headers-2.6.30-2-amd64] linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers Bug reassigned from package 'linux-headers-2.6.30-2-amd64' to 'alsa-source'. Bug No longer marked as found in versions linux-2.6/2.6.30-8. forcemerge 550595 552203 Bug#550595: alsa-source does not compile on amd64 Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers Forcibly Merged 550595 552203. severity 550595 grave Bug #550595 [alsa-source] alsa-source does not compile on amd64 Bug #552203 [alsa-source] linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers Severity set to 'grave' from 'normal' Severity set to 'grave' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers
reassign 552203 alsa-source forcemerge 550595 552203 severity 550595 grave thanks On Sat, Oct 24, 2009 at 10:19:35AM +0200, Wolfgang Schnitker wrote: this bug is coming out of bug # 550595 Well, you have to show why this is a bug here. I see none, so I'm merging the two. alsa-source does not compile against patched headers. I was not able to build it at all. I tried to build the modules via m-a. m-a buildlog attached to #550595 Okay, problems I read out of that: - SUBDIRS= is deprecated, use M=. - Never ever override CPP or CC for Debian provided kernels. Excerpt from hand-build: | $ ./configure --with-build=/lib/modules/$(uname -r)/build [...] | $ make [...] | make -C /lib/modules/2.6.31-trunk-amd64/source SUBDIRS=/tmp/source/modules/alsa-driver CPP=gcc -E CC=gcc modules | make[1]: Entering directory `/usr/src/linux-headers-2.6.31-trunk-common' | | ERROR: Kernel configuration is invalid. | include/linux/autoconf.h or include/config/auto.conf are missing. | Run 'make oldconfig make prepare' on kernel src to fix it. | | | WARNING: Symbol version dump /usr/src/linux-headers-2.6.31-trunk-common/Module.symvers |is missing; modules will have no dependencies and modversions. | | find: `/usr/src/linux-headers-2.6.31-trunk-common/alsa-kernel/': No such file or directory So it also ignores the provided tree. Setting to grave as modules have to work against Debian kernels. Bastian -- Insults are effective only where emotion is present. -- Spock, Who Mourns for Adonais? stardate 3468.1 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552142: Acknowledgement (linux-image-2.6.26-2-686: machine hangs with nf_conntrack: table full, dropping packet - needs hard reboot)
On Sat, Oct 24, 2009 at 12:31:35PM +0200, Toni Mueller wrote: On Sat, 24.10.2009 at 09:28:22 +0200, Bastian Blank wa...@debian.org wrote: Aren't you seeing errors about unknown keys during boot? No, I didn't, or at least not in any of the system's logs. This is sent to /dev/console, not the log. Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, The Enemy Within, stardate unknown -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552142: Acknowledgement (linux-image-2.6.26-2-686: machine hangs with nf_conntrack: table full, dropping packet - needs hard reboot)
On Sat, 24.10.2009 at 09:28:22 +0200, Bastian Blank wa...@debian.org wrote: The buckets are created during module loading. But /etc/sysctl.conf is evaluated earlier. Aren't you seeing errors about unknown keys during boot? No, I didn't, or at least not in any of the system's logs. But I also didn't see any traces of sysctl being executed, and I'm a bit confused about how, or why, sysctl runs that early. I found messages about the loading of the nf_conntrack module, with the 32k max buckets. So you suggest that I should make that number be a module's parameter? -- Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552142: Acknowledgement (linux-image-2.6.26-2-686: machine hangs with nf_conntrack: table full, dropping packet - needs hard reboot)
On Sat, 24.10.2009 at 12:48:05 +0200, Bastian Blank wa...@debian.org wrote: On Sat, Oct 24, 2009 at 12:31:35PM +0200, Toni Mueller wrote: On Sat, 24.10.2009 at 09:28:22 +0200, Bastian Blank wa...@debian.org wrote: Aren't you seeing errors about unknown keys during boot? No, I didn't, or at least not in any of the system's logs. This is sent to /dev/console, not the log. Well, then I might not have seen it, but I can try to reproduce the situation. Isn't there a way to capture such messages in the kernel's log? -- Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552214: (no subject)
Subject: linux-image-2.6.26-1-686: je n'arrive pas à avoir un affichage graphique avec ma lenny et une carte graphique ATI Radeon HD Package: linux-image-2.6.26-1-686 Version: 2.6.26-13lenny2 Severity: critical Justification: breaks unrelated software -- Package-specific info: ** Version: Linux version 2.6.26-1-686 (Debian 2.6.26-13lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 13 18:08:45 UTC 2009 ** Command line: root=/dev/sdc1 ro single ** Not tainted ** Kernel log: [6.055401] usb 5-2: configuration #1 chosen from 1 choice [6.063999] usb 5-2: New USB device found, idVendor=04d9, idProduct=048e [6.064037] usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [6.064088] usbcore: registered new interface driver hiddev [6.096888] input: Logitech Logitech USB Keyboard as /class/input/input0 [6.100903] input,hidraw0: USB HID v1.11 Keyboard [Logitech Logitech USB Keyboard] on usb-:00:1d.0-1 [6.120787] input: Logitech Logitech USB Keyboard as /class/input/input1 [6.120787] input,hidraw1: USB HID v1.11 Device [Logitech Logitech USB Keyboard] on usb-:00:1d.0-1 [6.156787] input: HID 04d9:048e as /class/input/input2 [6.168806] ata3: SATA link down (SStatus 0 SControl 300) [6.172785] input,hidraw2: USB HID v1.10 Mouse [HID 04d9:048e] on usb-:00:1d.0-2 [6.172785] usbcore: registered new interface driver usbhid [6.172785] usbhid: v2.6:USB HID core driver [6.538040] ata4: SATA link down (SStatus 0 SControl 300) [6.967549] ahci :03:00.0: AHCI 0001. 32 slots 2 ports 3 Gbps 0x3 impl SATA mode [6.967587] ahci :03:00.0: flags: 64bit ncq pm led clo pmp pio slum part [6.967622] PCI: Setting latency timer of device :03:00.0 to 64 [6.971512] scsi4 : ahci [6.971512] scsi5 : ahci [6.971512] ata5: SATA max UDMA/133 abar m8...@0xe700 port 0xe7000100 irq 19 [6.971512] ata6: SATA max UDMA/133 abar m8...@0xe700 port 0xe7000180 irq 19 [7.534400] ieee1394: Host added: ID:BUS[0-00:1023] GUID[007b0ced1fd0] [7.546321] ata5: SATA link down (SStatus 0 SControl 300) [7.878328] ata6: SATA link down (SStatus 0 SControl 300) [7.898306] JMB: IDE controller (0x197b:0x2363 rev 0x02) at PCI slot :03:00.1 [7.898306] JMicron IDE :03:00.1: enabling device ( - 0001) [7.898306] ACPI: PCI Interrupt :03:00.1[B] - GSI 16 (level, low) - IRQ 16 [7.898306] JMB: 100% native mode on irq 16 [7.898306] PCI: Setting latency timer of device :03:00.1 to 64 [7.898306] ide0: BM-DMA at 0xc400-0xc407 [7.898306] ide1: BM-DMA at 0xc408-0xc40f [7.898306] Probing IDE interface ide0... [9.239862] hda: TSSTcorp CDDVDW SH-S222A, ATAPI CD/DVD-ROM drive [9.911519] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [9.911691] hda: drive side 80-wire cable detection failed, limiting max speed to UDMA33 [9.911725] hda: UDMA/33 mode selected [9.912909] Probing IDE interface ide1... [ 10.674139] ide0 at 0xc000-0xc007,0xc102 on irq 16 [ 10.680196] ide1 at 0xc200-0xc207,0xc302 on irq 16 [ 11.253139] Driver 'sd' needs updating - please use bus_type methods [ 11.253139] sd 0:0:0:0: [sda] 293044655 512-byte hardware sectors (150039 MB) [ 11.253139] sd 0:0:0:0: [sda] Write Protect is off [ 11.253139] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 11.253139] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 11.253139] sd 0:0:0:0: [sda] 293044655 512-byte hardware sectors (150039 MB) [ 11.253139] sd 0:0:0:0: [sda] Write Protect is off [ 11.253139] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 11.253139] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 11.253139] sda: sda1 [ 11.257139] sd 0:0:0:0: [sda] Attached SCSI disk [ 11.257139] sd 1:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB) [ 11.257139] sd 1:0:0:0: [sdb] Write Protect is off [ 11.257139] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 11.257139] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 11.257139] sd 1:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB) [ 11.257139] sd 1:0:0:0: [sdb] Write Protect is off [ 11.257139] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 11.257139] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 11.257139] sdb:6hda: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache [ 11.261146] Uniform CD-ROM driver Revision: 3.20 [ 11.265139] sdb1 [ 11.265139] sd 1:0:0:0: [sdb] Attached SCSI disk [ 11.265139] sd 1:0:1:0: [sdc] 586072368 512-byte hardware sectors (300069 MB) [ 11.265139] sd 1:0:1:0: [sdc] Write Protect is off [ 11.265139] sd 1:0:1:0: [sdc] Mode Sense: 00 3a 00 00 [ 11.265139] sd 1:0:1:0: [sdc] Write cache: enabled, read cache: enabled, doesn't
Processed: severity of 552214 is normal
Processing commands for cont...@bugs.debian.org: severity 552214 normal Bug #552214 [linux-image-2.6.26-1-686] (no subject) Severity set to 'normal' from 'critical' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552214: (no subject)
On Sat, Oct 24, 2009 at 01:33:14PM +0200, y wrote: Who? I like to know who I'm talking with. Subject: linux-image-2.6.26-1-686: je n'arrive pas à avoir un affichage graphique avec ma lenny et une carte graphique ATI Radeon HD Sorry, but we don't speak french here. And even after my try to translate that, I'm unable to see what you want. Package: linux-image-2.6.26-1-686 Version: 2.6.26-13lenny2 Severity: critical Justification: breaks unrelated software No, it does not. -- Package-specific info: ** Version: Linux version 2.6.26-1-686 (Debian 2.6.26-13lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 13 18:08:45 UTC 2009 You want to do an upgrade of that system immediately. 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:9498] (prog-if 00 [VGA controller]) This is an ATI Radeon HD 4650 aka a R700. No information was available for this kind of chip at the release of Lenny, so it may not work at all. Bastian -- Fascinating is a word I use for the unexpected. -- Spock, The Squire of Gothos, stardate 2124.5 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processing of linux-2.6_2.6.26-20_i386.changes
linux-2.6_2.6.26-20_i386.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.26-20.dsc linux-2.6_2.6.26-20.diff.gz linux-doc-2.6.26_2.6.26-20_all.deb linux-manual-2.6.26_2.6.26-20_all.deb linux-patch-debian-2.6.26_2.6.26-20_all.deb linux-source-2.6.26_2.6.26-20_all.deb linux-support-2.6.26-2_2.6.26-20_all.deb linux-tree-2.6.26_2.6.26-20_all.deb linux-image-2.6.26-2-486_2.6.26-20_i386.deb linux-headers-2.6.26-2-486_2.6.26-20_i386.deb linux-image-2.6.26-2-686_2.6.26-20_i386.deb linux-headers-2.6.26-2-686_2.6.26-20_i386.deb linux-image-2.6.26-2-686-bigmem_2.6.26-20_i386.deb linux-headers-2.6.26-2-686-bigmem_2.6.26-20_i386.deb linux-image-2.6.26-2-amd64_2.6.26-20_i386.deb linux-headers-2.6.26-2-amd64_2.6.26-20_i386.deb linux-headers-2.6.26-2-common_2.6.26-20_i386.deb linux-image-2.6.26-2-openvz-686_2.6.26-20_i386.deb linux-headers-2.6.26-2-openvz-686_2.6.26-20_i386.deb linux-headers-2.6.26-2-common-openvz_2.6.26-20_i386.deb linux-headers-2.6.26-2-all_2.6.26-20_i386.deb linux-headers-2.6.26-2-all-i386_2.6.26-20_i386.deb linux-libc-dev_2.6.26-20_i386.deb linux-image-2.6.26-2-vserver-686_2.6.26-20_i386.deb linux-headers-2.6.26-2-vserver-686_2.6.26-20_i386.deb linux-image-2.6.26-2-vserver-686-bigmem_2.6.26-20_i386.deb linux-headers-2.6.26-2-vserver-686-bigmem_2.6.26-20_i386.deb linux-headers-2.6.26-2-common-vserver_2.6.26-20_i386.deb linux-image-2.6.26-2-xen-686_2.6.26-20_i386.deb linux-modules-2.6.26-2-xen-686_2.6.26-20_i386.deb linux-headers-2.6.26-2-xen-686_2.6.26-20_i386.deb xen-linux-system-2.6.26-2-xen-686_2.6.26-20_i386.deb linux-headers-2.6.26-2-common-xen_2.6.26-20_i386.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552237: 2.6.30/2.6.31: iwlagn page allocation failure. order:4, mode:0xd0
Package: linux-image-2.6.30-2-amd64 Version: 2.6.30-8 Severity: normal Hi, wireless connection suddenly disconnected, dmesg shows: [432878.569664] wlan0: disassociating by local choice (reason=3) [432878.573647] wlan0: direct probe to AP 00:24:97:89:f5:70 try 1 [432878.928058] wlan0: deauthenticating by local choice (reason=3) [432888.127757] NetworkManager: page allocation failure. order:4, mode:0xd0 [432888.127770] Pid: 2299, comm: NetworkManager Not tainted 2.6.30-2-amd64 #1 [432888.127776] Call Trace: [432888.127795] [80297eb9] ? __alloc_pages_internal+0x404/0x427 [432888.127805] [802bb124] ? kmem_getpages+0x68/0x12b [432888.127813] [802bb33a] ? fallback_alloc+0x153/0x1cd [432888.127821] [802bb4c4] ? cache_alloc_node+0x110/0x12f [432888.127829] [802bc01d] ? kmem_cache_alloc+0xf9/0x16a [432888.127862] [a0288d16] ? iwl_tx_queue_init+0x8d/0x276 [iwlcore] [432888.127888] [a0289089] ? iwl_txq_ctx_reset+0x18a/0x20d [iwlcore] [432888.127915] [a0284631] ? iwl_hw_nic_init+0x11d/0x13c [iwlcore] [432888.127936] [a029fd2e] ? __iwl_up+0x2df/0x2ee [iwlagn] [432888.127953] [a02a031a] ? iwl_mac_start+0x5dd/0x756 [iwlagn] [432888.127964] [8047da14] ? addrconf_notify+0x6f5/0x769 [432888.127973] [80482063] ? fib6_walk+0x5f/0x65 [432888.127982] [804820ea] ? fib6_clean_all+0x81/0xa3 [432888.127990] [80481adf] ? fib6_age+0x0/0x68 [432888.127998] [80482912] ? fib6_clean_node+0x0/0x96 [432888.128057] [a022e2eb] ? ieee80211_open+0x2cc/0x759 [mac80211] [432888.128069] [8020e5fa] ? __switch_to+0xff/0x263 [432888.128079] [80359ec4] ? __nla_reserve+0x1e/0x46 [432888.128088] [80413035] ? dev_open+0x75/0xb7 [432888.128096] [80412b06] ? dev_change_flags+0xaf/0x16d [432888.128106] [8041a40a] ? do_setlink+0x2a2/0x36f [432888.128114] [8041a669] ? rtnl_setlink+0x113/0x117 [432888.128124] [8041b33d] ? rtnetlink_rcv_msg+0x0/0x1f5 [432888.128132] [8041b33d] ? rtnetlink_rcv_msg+0x0/0x1f5 [432888.128141] [8042b7db] ? netlink_rcv_skb+0x34/0x7d [432888.128149] [8041b337] ? rtnetlink_rcv+0x1f/0x25 [432888.128156] [8042b358] ? netlink_unicast+0xe2/0x148 [432888.128165] [80235608] ? __wake_up+0x30/0x44 [432888.128173] [8042b623] ? netlink_sendmsg+0x265/0x278 [432888.128180] [802355b5] ? __wake_up_sync_key+0x3a/0x56 [432888.128191] [80403f24] ? sock_sendmsg+0xa3/0xbb [432888.128200] [80254742] ? autoremove_wake_function+0x0/0x2e [432888.128209] [804038ce] ? sock_aio_read+0xb9/0xc4 [432888.128218] [8040c628] ? verify_iovec+0x46/0x82 [432888.128226] [80404153] ? sys_sendmsg+0x217/0x28a [432888.128236] [804065c6] ? lock_sock_nested+0x9b/0xa6 [432888.128244] [804038f3] ? sockfd_lookup_light+0x1a/0x51 [432888.128254] [802ce79c] ? d_kill+0x4c/0x55 [432888.128264] [8020fa42] ? system_call_fastpath+0x16/0x1b [432888.128269] Mem-Info: [432888.128274] Node 0 DMA per-cpu: [432888.128281] CPU0: hi:0, btch: 1 usd: 0 [432888.128286] CPU1: hi:0, btch: 1 usd: 0 [432888.128291] Node 0 DMA32 per-cpu: [432888.128297] CPU0: hi: 186, btch: 31 usd: 0 [432888.128303] CPU1: hi: 186, btch: 31 usd: 6 [432888.128314] Active_anon:184809 active_file:40735 inactive_anon:62659 [432888.128317] inactive_file:401417 unevictable:7 dirty:69192 writeback:12 unstable:0 [432888.128321] free:5294 slab:53425 mapped:14736 pagetables:4998 bounce:0 [432888.128327] Node 0 DMA free:10456kB min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB present:9328kB pages_scanned:0 all_unreclaimable? no [432888.128342] lowmem_reserve[]: 0 2967 2967 2967 [432888.128352] Node 0 DMA32 free:10720kB min:6956kB low:8692kB high:10432kB active_anon:739236kB inactive_anon:250636kB active_file:162940kB inactive_file:1605668kB unevictable:28kB present:3038380kB pages_scanned:0 all_unreclaimable? no [432888.128368] lowmem_reserve[]: 0 0 0 0 [432888.128377] Node 0 DMA: 4*4kB 3*8kB 1*16kB 3*32kB 3*64kB 3*128kB 2*256kB 0*512kB 1*1024kB 0*2048kB 2*4096kB = 10456kB [432888.128402] Node 0 DMA32: 1850*4kB 56*8kB 2*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 10728kB [432888.128426] 499312 total pagecache pages [432888.128430] 0 pages in swap cache [432888.128435] Swap cache stats: add 0, delete 0, find 0/0 [432888.128439] Free swap = 0kB [432888.128443] Total swap = 0kB [432888.162238] 774221 pages RAM [432888.162245] 12328 pages reserved [432888.162249] 339839 pages shared [432888.162252] 480634 pages non-shared [432888.162262] iwlagn :0c:00.0: kmalloc for auxiliary BD structures failed [432888.162307] iwlagn :0c:00.0: Tx 12 queue init failed [432888.163080] iwlagn :0c:00.0: Unable to init nic rmmod/modprobe doesn't seem
Processed: tagging 544264
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 544264 + pending Bug #544264 [linux-2.6] devicekit-power: AC unplug and replug is not detected Added tag(s) 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 debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552088: linux-image-2.6-686: ath5k phy1: noise floor calibration timeout
On Fri, Oct 23, 2009 at 06:05:18PM +0200, Dennis Leeuw wrote: Thank you for the quick response. See below. well mine is even shorter, so snipping your long story, sorry on the run.. please check for newer linux image from backports.org it has newer ath5k. wireless drivers are not easy to backport due to wireless stack interdependency. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processing of linux-2.6_2.6.31-1_amd64.changes
linux-2.6_2.6.31-1_amd64.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.31-1.dsc linux-2.6_2.6.31-1.diff.gz linux-tree-2.6.31_2.6.31-1_all.deb linux-support-2.6.31-1_2.6.31-1_all.deb linux-patch-debian-2.6.31_2.6.31-1_all.deb firmware-linux-free_2.6.31-1_all.deb linux-source-2.6.31_2.6.31-1_all.deb linux-doc-2.6.31_2.6.31-1_all.deb linux-manual-2.6.31_2.6.31-1_all.deb linux-headers-2.6.31-1-amd64_2.6.31-1_amd64.deb linux-image-2.6.31-1-amd64_2.6.31-1_amd64.deb linux-headers-2.6.31-1-common_2.6.31-1_amd64.deb linux-headers-2.6.31-1-all_2.6.31-1_amd64.deb linux-headers-2.6.31-1-all-amd64_2.6.31-1_amd64.deb linux-libc-dev_2.6.31-1_amd64.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
linux-2.6_2.6.31-1_amd64.changes is NEW
firmware-linux-free_2.6.31-1_all.deb to pool/main/l/linux-2.6/firmware-linux-free_2.6.31-1_all.deb linux-2.6_2.6.31-1.diff.gz to pool/main/l/linux-2.6/linux-2.6_2.6.31-1.diff.gz linux-2.6_2.6.31-1.dsc to pool/main/l/linux-2.6/linux-2.6_2.6.31-1.dsc linux-doc-2.6.31_2.6.31-1_all.deb to pool/main/l/linux-2.6/linux-doc-2.6.31_2.6.31-1_all.deb (new) linux-headers-2.6.31-1-all-amd64_2.6.31-1_amd64.deb optional kernel All header files for Linux 2.6.31 This package depends against all architecture-specific kernel header files for Linux kernel version 2.6.31, generally used for building out-of-tree kernel modules. (new) linux-headers-2.6.31-1-all_2.6.31-1_amd64.deb optional kernel All header files for Linux 2.6.31 This package depends against all architecture-specific kernel header files for Linux kernel version 2.6.31, generally used for building out-of-tree kernel modules. (new) linux-headers-2.6.31-1-amd64_2.6.31-1_amd64.deb optional kernel Header files for Linux 2.6.31-1-amd64 This package provides the architecture-specific kernel header files for Linux kernel 2.6.31-1-amd64, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.31-1-amd64, and can be used for building modules that load into the kernel provided by the linux-image-2.6.31-1-amd64 package. (new) linux-headers-2.6.31-1-common_2.6.31-1_amd64.deb optional kernel Common header files for Linux 2.6.31-1 This package provides the architecture-specific common kernel header files for Linux kernel version 2.6.31-1, generally used for building out-of-tree kernel modules. To obtain a complete set of headers you also need to install the linux-headers-2.6.31-1-(flavour) package, matching the flavour of the kernel you intend the build for. (new) linux-image-2.6.31-1-amd64_2.6.31-1_amd64.deb optional kernel Linux 2.6.31 for 64-bit PCs The Linux kernel 2.6.31 and modules for use on PCs with AMD64 or Intel 64 processors. . This kernel also runs on a Xen hypervisor. It supports only unprivileged (domU) operation. linux-libc-dev_2.6.31-1_amd64.deb to pool/main/l/linux-2.6/linux-libc-dev_2.6.31-1_amd64.deb linux-manual-2.6.31_2.6.31-1_all.deb to pool/main/l/linux-2.6/linux-manual-2.6.31_2.6.31-1_all.deb linux-patch-debian-2.6.31_2.6.31-1_all.deb to pool/main/l/linux-2.6/linux-patch-debian-2.6.31_2.6.31-1_all.deb linux-source-2.6.31_2.6.31-1_all.deb to pool/main/l/linux-2.6/linux-source-2.6.31_2.6.31-1_all.deb (new) linux-support-2.6.31-1_2.6.31-1_all.deb optional devel Support files for Linux 2.6.31 This package provides support files for the Linux kernel build, e.g. scripts to handle ABI information and for generation of build system meta data. linux-tree-2.6.31_2.6.31-1_all.deb to pool/main/l/linux-2.6/linux-tree-2.6.31_2.6.31-1_all.deb Changes: linux-2.6 (2.6.31-1) unstable; urgency=low . [ Ben Hutchings ] * Include aufs2, marked as staging (Closes: #541828) * Include speakup modules under staging * Add stable release 2.6.31.5 * [x86_64] Enable NUMA_EMU (Closes: #541389) . [ Martin Michlmayr ] * CPUidle: always return with interrupts enabled. * [armel/orion5x, armel/kirkwood] Enable FB since some Kirkwood machines have a VGA chip (e.g. OpenRD-Client) and because it's possible to use a DisplayLink USB virtual graphics adapter. . [ maximilian attems ] * [alpha] Disable SND_MIXART, causes gcc ICE. * [x86] Enable modular X86_MCE_INJECT. * [x86_32] Set LSM_MMAP_MIN_ADDR to zero to unbreak dosemu and 16-bit Wine, ia64 and x86_64 to 65536 otherwise default to 32768. * Unset UEVENT_HELPER_PATH to save some boot cycles. . [ Bastian Blank ] * Set ABI to 1. * Enable Apple PMU battery. (closes: #544264) Override entries for your package: firmware-linux-free_2.6.31-1_all.deb - optional kernel linux-2.6_2.6.31-1.dsc - source devel linux-doc-2.6.31_2.6.31-1_all.deb - optional doc linux-libc-dev_2.6.31-1_amd64.deb - optional devel linux-manual-2.6.31_2.6.31-1_all.deb - optional doc linux-patch-debian-2.6.31_2.6.31-1_all.deb - optional kernel linux-source-2.6.31_2.6.31-1_all.deb - optional kernel linux-tree-2.6.31_2.6.31-1_all.deb - optional devel Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 541389 541828 544264 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: severity of 535331 is serious
Processing commands for cont...@bugs.debian.org: # Stable upgrades can make the system unbootable severity 535331 serious Bug #535331 [linux-image-2.6.26-2-686] lilo not run after install/upgrade Severity set to 'serious' from 'normal' 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 debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552255: linux-image-2.6.26-2-686: /proc permission bypass
Package: linux-image-2.6.26-2-686 Version: 2.6.26-17 Severity: important Currently discussed on bugtraq Cut-n-pasting the email Hi! This is forward from lkml, so no, I did not invent this hole. Unfortunately, I do not think lkml sees this as a security hole, so... Jamie Lokier said: a) the current permission model under /proc/PID/fd has a security hole (which Jamie is worried about) I believe its bugtraq time. Being able to reopen file with additional permissions looks like a security problem... Jamie, do you have some test script? And do you want your 15 minutes of bugtraq fame? ;-). The reopen does check the inode permission, but it does not require you have any reachable path to the file. Someone _might_ use that as a traditional unix security mechanism, but if so it's probably quite rare. Ok, I got this, with two users. I guess it is real (but obscure) security hole. So, we have this scenario. pavel/root is not doing anything interesting in the background. pa...@toy:/tmp$ uname -a Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux pa...@toy:/tmp mkdir my_priv; cd my_priv pa...@toy:/tmp/my_priv$ echo this file should never be writable unwritable_file # lock down directory pa...@toy:/tmp/my_priv$ chmod 700 . # relax file permissions, directory is private, so this is safe # check link count on unwritable_file. We would not want someone # to have a hard link to work around our permissions, would we? pa...@toy:/tmp/my_priv$ chmod 666 unwritable_file pa...@toy:/tmp/my_priv$ cat unwritable_file this file should never be writable pa...@toy:/tmp/my_priv$ cat unwritable_file got you # Security problem here [Please pause here for a while before reading how guest did it.] Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so. So what did happen? User guest was able to work around directory permissions in the background, using /proc filesystem. gu...@toy:~$ bash 3 /tmp/my_priv/unwritable_file # Running inside nested shell gu...@toy:~$ read A 3 gu...@toy:~$ echo $A this file should never be writable gu...@toy:~$ cd /tmp/my_priv gu...@toy:/tmp/my_priv$ ls unwritable_file # pavel did chmod 000, chmod 666 here gu...@toy:/tmp/my_priv$ ls ls: cannot open directory .: Permission denied # Linux correctly prevents guest from writing to that file gu...@toy:/tmp/my_priv$ cat unwritable_file cat: unwritable_file: Permission denied gu...@toy:/tmp/my_priv$ echo got you 3 bash: echo: write error: Bad file descriptor # ...until we take a way around it with /proc filesystem. Oops. gu...@toy:/tmp/my_priv$ echo got you /proc/self/fd/3 -- Package-specific info: -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26 (SMP w/1 CPU core; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-2-686 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.26-2-686 recommends: ii libc6-i6862.7-18 GNU C Library: Shared libraries [i Versions of packages linux-image-2.6.26-2-686 suggests: ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v ii lilo 1:22.8-7 LInux LOader - The Classic OS load pn linux-doc-2.6.26 none(no description available) -- debconf-show failed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
linux-2.6_2.6.26-19lenny1_i386.changes ACCEPTED
Accepted: linux-2.6_2.6.26-19lenny1.diff.gz to pool/main/l/linux-2.6/linux-2.6_2.6.26-19lenny1.diff.gz linux-2.6_2.6.26-19lenny1.dsc to pool/main/l/linux-2.6/linux-2.6_2.6.26-19lenny1.dsc linux-doc-2.6.26_2.6.26-19lenny1_all.deb to pool/main/l/linux-2.6/linux-doc-2.6.26_2.6.26-19lenny1_all.deb linux-headers-2.6.26-2-486_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-486_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-686-bigmem_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-686-bigmem_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-686_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-all-i386_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-all-i386_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-all_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-all_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-amd64_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-amd64_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-common-openvz_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-common-openvz_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-common-vserver_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-common-vserver_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-common-xen_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-common-xen_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-common_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-common_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-openvz-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-openvz-686_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-vserver-686-bigmem_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-vserver-686-bigmem_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-vserver-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-vserver-686_2.6.26-19lenny1_i386.deb linux-headers-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-headers-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-486_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-486_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-686-bigmem_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-686-bigmem_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-686_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-amd64_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-amd64_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-openvz-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-openvz-686_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-vserver-686-bigmem_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-vserver-686-bigmem_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-vserver-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-vserver-686_2.6.26-19lenny1_i386.deb linux-image-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-image-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb linux-libc-dev_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-libc-dev_2.6.26-19lenny1_i386.deb linux-manual-2.6.26_2.6.26-19lenny1_all.deb to pool/main/l/linux-2.6/linux-manual-2.6.26_2.6.26-19lenny1_all.deb linux-modules-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/linux-modules-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb linux-patch-debian-2.6.26_2.6.26-19lenny1_all.deb to pool/main/l/linux-2.6/linux-patch-debian-2.6.26_2.6.26-19lenny1_all.deb linux-source-2.6.26_2.6.26-19lenny1_all.deb to pool/main/l/linux-2.6/linux-source-2.6.26_2.6.26-19lenny1_all.deb linux-support-2.6.26-2_2.6.26-19lenny1_all.deb to pool/main/l/linux-2.6/linux-support-2.6.26-2_2.6.26-19lenny1_all.deb linux-tree-2.6.26_2.6.26-19lenny1_all.deb to pool/main/l/linux-2.6/linux-tree-2.6.26_2.6.26-19lenny1_all.deb xen-linux-system-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb to pool/main/l/linux-2.6/xen-linux-system-2.6.26-2-xen-686_2.6.26-19lenny1_i386.deb Override entries for your package: linux-2.6_2.6.26-19lenny1.dsc - optional devel linux-doc-2.6.26_2.6.26-19lenny1_all.deb - optional doc linux-headers-2.6.26-2-486_2.6.26-19lenny1_i386.deb - optional devel linux-headers-2.6.26-2-686-bigmem_2.6.26-19lenny1_i386.deb - optional devel linux-headers-2.6.26-2-686_2.6.26-19lenny1_i386.deb - optional devel linux-headers-2.6.26-2-all-i386_2.6.26-19lenny1_i386.deb - optional devel linux-headers-2.6.26-2-all_2.6.26-19lenny1_i386.deb - optional devel linux-headers-2.6.26-2-amd64_2.6.26-19lenny1_i386.deb - optional devel
Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers
* Ben Hutchings [091024 20:15 +0100] On Sat, 2009-10-24 at 20:38 +0200, Elimar Riesebieter wrote: [...] There is no trouble to be saved. We are providing the newest alsa driver sources so that they can be build with whatever 2.6 kernel you want. Well that's nice for people who are using Debian stable, but doesn't answer why this belongs in Debian testing/unstable. Well, 2.6.30 provides alsa 1.0.20. The Debian alsa-source package 1.0.21 provides many improvments, optimizations and new drivers. This is the intention of the alsa developers as well. So FMPOV the Debian kernel maintainers have to cooperate with that idea too. No, we don't. Upgrading drivers outside the kernel image package is a really bad idea because: 1. Most users never install those driver packages, so they don't get the benefit Many users want the actual drivers of alsa. The hardware development is much faster than the Debian kernel maintainers can follow up. So you need our support ;-) 2. The driver package can fall behind the kernel package, but will still be used in preference to the version in the kernel package alsa-source is most newer than the Debian kernel provides. 3. Users can report bugs against the kernel and it won't be obvious that they're using a different version of the driver The Debian Kernel is used to be stable. This is what stable means by its word and not what users want. 4. Duplicated code makes the security team unhappy There is no code duplicated. The alsa-source is meant to be the same as provided with vanilla. If there are specific new drivers, bug fixes or device id updates that should be added to a stable release, please let us know and we can update the kernel package. Hmm, patch as patch can? This is not the way Linux is alive from. Also, please get rid of linux-sound-base because OSS is dead. You are a only forward looking hacker. We want to provide this to older versions too. Please have a look at the Debian kernel patches for the reaseon why alsa-source package doesn't build against the Debian kernels but to the stock ones. Try talking to your co-maintainers ;-) We talk on a regular basis and no-one seems to think this is a bug in the kernel header packages. The alsa-source build system is doing something strange and wrong. So you must be able to point out why Debians alsa-source builds against stock kernels and not against Debian ones, please. Thanks for cooperation Elimar -- It's a good thing we don't get all the government we pay for. signature.asc Description: Digital signature
Processing of firmware-nonfree_0.20_amd64.changes
firmware-nonfree_0.20_amd64.changes uploaded successfully to localhost along with the files: firmware-nonfree_0.20.dsc firmware-nonfree_0.20.tar.gz firmware-linux_0.20_all.deb firmware-bnx2_0.20_all.deb firmware-bnx2x_0.20_all.deb firmware-intelwimax_0.20_all.deb firmware-ipw2x00_0.20_all.deb firmware-ivtv_0.20_all.deb firmware-iwlwifi_0.20_all.deb firmware-linux-nonfree_0.20_all.deb firmware-qlogic_0.20_all.deb firmware-ralink_0.20_all.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers
On Sat, 2009-10-24 at 22:12 +0200, Elimar Riesebieter wrote: * Ben Hutchings [091024 20:15 +0100] On Sat, 2009-10-24 at 20:38 +0200, Elimar Riesebieter wrote: [...] There is no trouble to be saved. We are providing the newest alsa driver sources so that they can be build with whatever 2.6 kernel you want. Well that's nice for people who are using Debian stable, but doesn't answer why this belongs in Debian testing/unstable. Well, 2.6.30 provides alsa 1.0.20. The Debian alsa-source package 1.0.21 provides many improvments, optimizations and new drivers. And 2.6.31 was uploaded today (and has been available in experimental for a few weeks already). This is the intention of the alsa developers as well. So FMPOV the Debian kernel maintainers have to cooperate with that idea too. No, we don't. Upgrading drivers outside the kernel image package is a really bad idea because: 1. Most users never install those driver packages, so they don't get the benefit Many users want the actual drivers of alsa. Which are in the Linux kernel package. The hardware development is much faster than the Debian kernel maintainers can follow up. So you need our support ;-) We really don't need this kind of 'support'. 2. The driver package can fall behind the kernel package, but will still be used in preference to the version in the kernel package alsa-source is most newer than the Debian kernel provides. Maybe it is today. 3. Users can report bugs against the kernel and it won't be obvious that they're using a different version of the driver The Debian Kernel is used to be stable. This is what stable means by its word and not what users want. You just told us that users want newer drivers. Which is it? 4. Duplicated code makes the security team unhappy There is no code duplicated. The alsa-source is meant to be the same as provided with vanilla. The code is duplicated between the linux-2.6 and alsa-source source packages. If there are specific new drivers, bug fixes or device id updates that should be added to a stable release, please let us know and we can update the kernel package. Hmm, patch as patch can? This is not the way Linux is alive from. It is exactly the way every distribution with a long-term stable releaase maintains its kernel package. Also, please get rid of linux-sound-base because OSS is dead. You are a only forward looking hacker. We want to provide this to older versions too. Please have a look at the Debian kernel patches for the reaseon why alsa-source package doesn't build against the Debian kernels but to the stock ones. Try talking to your co-maintainers ;-) We talk on a regular basis and no-one seems to think this is a bug in the kernel header packages. The alsa-source build system is doing something strange and wrong. So you must be able to point out why Debians alsa-source builds against stock kernels and not against Debian ones, please. No, we don't have to solve your problem. I'll be happy to take over maintenance of alsa-driver if, as it seems. you are not competent to do so. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Processed: tagging 552255, severity of 552255 is normal
Processing commands for cont...@bugs.debian.org: tags 552255 security Bug #552255 [linux-image-2.6.26-2-686] linux-image-2.6.26-2-686: /proc permission bypass Added tag(s) security. severity 552255 normal Bug #552255 [linux-image-2.6.26-2-686] linux-image-2.6.26-2-686: /proc permission bypass 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 debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552255: linux-image-2.6.26-2-686: /proc permission bypass
On Sat, 2009-10-24 at 20:19 +0100, Anton Ivanov wrote: Package: linux-image-2.6.26-2-686 Version: 2.6.26-17 Severity: important Currently discussed on bugtraq Cut-n-pasting the email Hi! This is forward from lkml, so no, I did not invent this hole. Unfortunately, I do not think lkml sees this as a security hole, so... Jamie Lokier said: a) the current permission model under /proc/PID/fd has a security hole (which Jamie is worried about) I believe its bugtraq time. Being able to reopen file with additional permissions looks like a security problem... Jamie, do you have some test script? And do you want your 15 minutes of bugtraq fame? ;-). The reopen does check the inode permission, but it does not require you have any reachable path to the file. Someone _might_ use that as a traditional unix security mechanism, but if so it's probably quite rare. Ok, I got this, with two users. I guess it is real (but obscure) security hole. So obscure that it doesn't really count as important. So, we have this scenario. pavel/root is not doing anything interesting in the background. pa...@toy:/tmp$ uname -a Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux pa...@toy:/tmp mkdir my_priv; cd my_priv pa...@toy:/tmp/my_priv$ echo this file should never be writable unwritable_file # lock down directory pa...@toy:/tmp/my_priv$ chmod 700 . # relax file permissions, directory is private, so this is safe # check link count on unwritable_file. We would not want someone # to have a hard link to work around our permissions, would we? pa...@toy:/tmp/my_priv$ chmod 666 unwritable_file [...] But who's really going to do that, other that to demonstrate this? Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers
pkg-alsa-de...@lists.alioth.debian.org Bcc: Subject: Re: Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers Reply-To: In-Reply-To: 1256416319.3916.309.ca...@localhost Organization: LXTEC * Ben Hutchings [091024 21:31 +0100] On Sat, 2009-10-24 at 20:38 +0200, Elimar Riesebieter wrote: [...] No, we don't have to solve your problem. I'll be happy to take over maintenance of alsa-driver if, as it seems. you are not competent to do so. Competence is shown in cooperation. It seems, you need much more experience to do so. Why did you closed #552203? Did you perform a professional solution? Have a nice sunday ;) Elimar -- It's a good thing we don't get all the government we pay for. signature.asc Description: Digital signature
Re: Bug#552203: linux-headers-2.6.30-2-amd64: alsa-source does not compile against debian patched kernel headers
On Sat, 2009-10-24 at 23:15 +0200, Elimar Riesebieter wrote: * Ben Hutchings [091024 21:31 +0100] On Sat, 2009-10-24 at 20:38 +0200, Elimar Riesebieter wrote: [...] No, we don't have to solve your problem. I'll be happy to take over maintenance of alsa-driver if, as it seems. you are not competent to do so. Competence is shown in cooperation. It seems, you need much more experience to do so. Please don't lecture me about cooperation. Cooperation does not mean solving all the problems people present to you, in the way that they want. Why did you closed #552203? Did you perform a professional solution? I was mistaken about the assignment of that bug. I have reopened it. Have a nice sunday ;) This is not so easy when there are hundreds of other bugs to look at. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: Debian Kernel Group Meeting
On Thu, 2009-10-15 at 13:31 +0100, Vincent Sanders wrote: [...] 7) Steve Langasek to talk to Marco further. [...] Steve has been busy, so I've taken on this task. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: RFC: Bug handling policy
On Sat, 2009-10-17 at 17:14 +0100, Ben Hutchings wrote: I've drafted a policy based on what I believe to be best practice. Please comment - is anything wrong, or anything missing? I also left some questions in square brackets. There is now one week left of the comment period. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
[help] try to build loadable .ko file for a specific kernel (2.6.24-1-486)
Hello guys, I am trying to build a loadable .ko file for a Linux box with specific linux kernel (uname -r result is 2.6.24-1-486) installed on it. This Linux box contains no directory named /lib/modules/2.6.24-1-486/build; and it contains no related kernel header files for its 2.6.24-1-486 kernel. The remaining docs of it say that some test/unstable Debian release with 2.6.24 kernel is OK to produce loadable .ko kernel modules for it. I tried several 2.6.24 kernels, and just got the version verifying failure info below: # insmod my_kernel_mod.ko insmod: error inserting 'my_kernel_mod.ko': -1 Invalid module format # dmesg|tail my_kernel_mod: disagrees about version of symbol struct_module my_kernel_mod: disagrees about version of symbol struct_module Thus, I think I do need the Linux kernel source files (or just header files) with specific kernel version: 2.6.24-1-486. But, I cannot find this kind of 2.6.24-1-486 stuffs, event after I visit the web pages of www.kernel.org/and www.debian.org/. Does any one know how to get the Linux kernel source files (or just header files) with the specific kernel version 2.6.24-1-486?? Thanks a lot in advance. Deng
Re: [help] try to build loadable .ko file for a specific kernel (2.6.24-1-486)
On Sat, 2009-10-24 at 18:04 -0400, Ye Deng wrote: Hello guys, I am trying to build a loadable .ko file for a Linux box with specific linux kernel (uname -r result is 2.6.24-1-486) installed on it. This Linux box contains no directory named /lib/modules/2.6.24-1-486/build; and it contains no related kernel header files for its 2.6.24-1-486 kernel. [...] This was never part of any stable release, so the source package and header packages are no longer available from the Debian archive. I suggest you upgrade to Linux 2.6.26 as included in Debian 5.0 'lenny'. If you really must have 2.6.24 then you could use the linux-image-2.6.24-etchnhalf.1-486 and linux-headers-2.6.24-etchnhalf.1-486 packages from Debian 4.0 'etch'. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#552270: orion5x crypto module not enabled
Package: linux-2.6 Version: 2.6.31-1~experimental.2 Martin Michlmayr backported the CESA patches from 2.6.32 to 2.6.31 but didn't enable them as module even though changelog indicates that * [armel/orion5x] Enable CRYPTO_DEV_MV_CESA. This is from the used config: obstschale:/boot# cat config-2.6.31-trunk-kirkwood | grep CESA # CONFIG_CRYPTO_DEV_MV_CESA is not set obstschale:/boot# uname -r 2.6.31-trunk-kirkwood Please enable, Thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
firmware-nonfree_0.20_amd64.changes is NEW
firmware-bnx2_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-bnx2_0.20_all.deb firmware-bnx2x_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-bnx2x_0.20_all.deb (new) firmware-intelwimax_0.20_all.deb optional non-free/kernel Binary firmware for Intel WiMAX Connection This package contains the binary firmware for Intel WiMAX Connection devices supported by the i2400m-usb driver. . Contents: * Intel WiMAX Connection 2400 USB firmware, version 1.4 firmware-ipw2x00_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-ipw2x00_0.20_all.deb firmware-ivtv_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-ivtv_0.20_all.deb firmware-iwlwifi_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-iwlwifi_0.20_all.deb firmware-linux-nonfree_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-linux-nonfree_0.20_all.deb firmware-linux_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-linux_0.20_all.deb firmware-nonfree_0.20.dsc to pool/non-free/f/firmware-nonfree/firmware-nonfree_0.20.dsc firmware-nonfree_0.20.tar.gz to pool/non-free/f/firmware-nonfree/firmware-nonfree_0.20.tar.gz firmware-qlogic_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-qlogic_0.20_all.deb firmware-ralink_0.20_all.deb to pool/non-free/f/firmware-nonfree/firmware-ralink_0.20_all.deb Changes: firmware-nonfree (0.20) experimental; urgency=low . [ Ben Hutchings ] * firmware-linux-nonfree Replaces and Conflicts with old firmware-linux (Closes: #551146) * Update upstream URL for firmware-ralink (Closes: #551975) * Add AdvanSys SCSI controller firmware for use with advansys driver (Closes: #535922) * Add firmware-intelwimax package, initially containing Intel WiMAX Connection 2400 USB firmware for use with i2400m-usb driver (Closes: #550917) * Update description of firmware-bnx2 contents, thanks to Geoff Simmons gsimm...@gsimmons.org (Closes: #536050) * Include module/driver names in descriptions of all specific packages (Closes: #510220) Override entries for your package: firmware-bnx2_0.20_all.deb - optional non-free/kernel firmware-bnx2x_0.20_all.deb - optional non-free/kernel firmware-ipw2x00_0.20_all.deb - optional non-free/kernel firmware-ivtv_0.20_all.deb - optional non-free/kernel firmware-iwlwifi_0.20_all.deb - optional non-free/kernel firmware-linux-nonfree_0.20_all.deb - optional non-free/kernel firmware-linux_0.20_all.deb - optional non-free/kernel firmware-nonfree_0.20.dsc - source non-free/kernel firmware-qlogic_0.20_all.deb - optional non-free/kernel firmware-ralink_0.20_all.deb - optional non-free/kernel Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 510220 535922 536050 550917 551146 551975 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538158: Still a problem as of 5.0.3
On Thu, 2009-10-22 at 01:20 +0100, Ben Hutchings wrote: On Wed, 2009-10-21 at 17:01 -0400, Arcady Genkin wrote: [...] Before that, when we were testing the servers, the problem sometimes would occur several times per day on each machine. The kernel has not changed since end of August, I believe. Perhaps an idle system is more susceptible to this problem. It seems unlikely, but it is conceivable. In fact, after further investigation, it looks quite plausible that this bug is related to long idle periods. I found some bug fixes made in Linux 2.6.27 that may address this. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Bug#552255: linux-image-2.6.26-2-686: /proc permission bypass
We have been having a back and fourth on this with a couple of people. It has not shown up on BUGTRAQ yet because it is sitting in the moderator queue. First of all, any permission bypass is bad. Principle of least surprise. Second, the important thing here is that directory permissions are ignored. Whatever the reason, that is not good. The case shown by Pavel is an extreme example (using 666), but you can most likely have a less extreme example where this can be put to good use. Third, there is a non-zero size class of applications where it is likely such idiocy like 666 protected one level above by dir to be found - ported from Windows. Under windows, locking is non-advisory and apps tend to scribble under themselves. So if you open a file with an exclusive Read/write lock nobody can read/write it regardless of permissions. When a program gets ported to unix developers (or the porting toolkit) replaces the code with flocks or fcntl which are advisory and the file becomes nicely accessible. No such code in debian proper, but that does not mean that there is no such code out there in the wild. Fourth, during the discussion it was claimed that this does not work on Linux proper. I have some doubts about the claim, but cannot verify it (I am off on holiday in an hour or so). It maybe Debian specific or specific to a patch which Debian and more than one other distro is using (ptrace comes to mind). I personally do not think that is the case, however it is worth checking and if it is coming from the ptrace patches double check if they do not introduce something worse than that somewhere. Cheers, On Sat, 2009-10-24 at 21:18 +0100, Ben Hutchings wrote: On Sat, 2009-10-24 at 20:19 +0100, Anton Ivanov wrote: Package: linux-image-2.6.26-2-686 Version: 2.6.26-17 Severity: important Currently discussed on bugtraq Cut-n-pasting the email Hi! This is forward from lkml, so no, I did not invent this hole. Unfortunately, I do not think lkml sees this as a security hole, so... Jamie Lokier said: a) the current permission model under /proc/PID/fd has a security hole (which Jamie is worried about) I believe its bugtraq time. Being able to reopen file with additional permissions looks like a security problem... Jamie, do you have some test script? And do you want your 15 minutes of bugtraq fame? ;-). The reopen does check the inode permission, but it does not require you have any reachable path to the file. Someone _might_ use that as a traditional unix security mechanism, but if so it's probably quite rare. Ok, I got this, with two users. I guess it is real (but obscure) security hole. So obscure that it doesn't really count as important. So, we have this scenario. pavel/root is not doing anything interesting in the background. pa...@toy:/tmp$ uname -a Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux pa...@toy:/tmp mkdir my_priv; cd my_priv pa...@toy:/tmp/my_priv$ echo this file should never be writable unwritable_file # lock down directory pa...@toy:/tmp/my_priv$ chmod 700 . # relax file permissions, directory is private, so this is safe # check link count on unwritable_file. We would not want someone # to have a hard link to work around our permissions, would we? pa...@toy:/tmp/my_priv$ chmod 666 unwritable_file [...] But who's really going to do that, other that to demonstrate this? Ben. -- Understanding is a three-edged sword: your side, their side, and the truth. --Kosh Naranek A. R. Ivanov E-mail: aiva...@sigsegv.cx WWW: http://www.sigsegv.cx/ pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov ariva...@sigsegv.cx Fingerprint: C824 CBD7 EE4B D7F8 5331 89D5 FCDA 572E DDE5 E715 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552255: linux-image-2.6.26-2-686: /proc permission bypass
On Sun, 2009-10-25 at 02:29 +, Anton Ivanov wrote: We have been having a back and fourth on this with a couple of people. It has not shown up on BUGTRAQ yet because it is sitting in the moderator queue. First of all, any permission bypass is bad. Principle of least surprise. Second, the important thing here is that directory permissions are ignored. Sure, the current directory permissions are irrelevant when you already have a file descriptor - you can carry on reading and writing to the file if the file permissions let you. The problem here is that /proc/self/fd, unlike dup(), can be used to upgrade a read-only file descriptor to a read-write file descriptor based on the file's current permissions. Whatever the reason, that is not good. The case shown by Pavel is an extreme example (using 666), but you can most likely have a less extreme example where this can be put to good use. Third, there is a non-zero size class of applications where it is likely such idiocy like 666 protected one level above by dir to be found - ported from Windows. Under windows, locking is non-advisory and apps tend to scribble under themselves. So if you open a file with an exclusive Read/write lock nobody can read/write it regardless of permissions. When a program gets ported to unix developers (or the porting toolkit) replaces the code with flocks or fcntl which are advisory and the file becomes nicely accessible. No such code in debian proper, but that does not mean that there is no such code out there in the wild. I imagine such applications are already totally insecure. Fourth, during the discussion it was claimed that this does not work on Linux proper. In a listing of /proc/self/fd the files appear with read and/or write permissions depending on the file descriptor mode. But when a process tries to open them they are treated as symbolic links, which have no permissions of their own. This is fairly obvious when looking at the code and it's not something we change. I have some doubts about the claim, but cannot verify it (I am off on holiday in an hour or so). It maybe Debian specific or specific to a patch which Debian and more than one other distro is using (ptrace comes to mind). I personally do not think that is the case, however it is worth checking and if it is coming from the ptrace patches double check if they do not introduce something worse than that somewhere. I don't know what patches you're talking about. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
