Re: Generating a cloud / VM kernel package
Hi, On Sat Aug 26, 2017 at 11:48:22 +0200, Thomas Goirand wrote: > Dear Kernel maintainers, > > As you may know, it's been years that Ubuntu is shipping a kernel > designed for the cloud. Such a kernel is simply a version of the kernel > that is stripped down for running on VMs. The point here is that VMs do > not need all the drivers that we typically build for the generic Debian > kernel (and if one still needs it, a fallback to the generic kernel is > always possible). This makes the kernel binary package a lot smaller, > and also potentially reduces the surface of attack in case of a security > problem. For example, we wouldn't need ax25, appletalk and such, which > are unfortunately automatically loaded in case matching packets are > received by the kernel, and which have been proven to be problematic in > terms of security maintenance. Most hardware drivers would also go away. > > Since it is only a mater of *removing* some modules, I don't think > adding a cloud / VM kernel flavor would be a lot of maintenance. Though > of course, as I wouldn't be the one doing it, it is not up to me to > judge the amount of work. > > Could we see this happening in Debian? Please let us know your thoughts. I personaly think this is a good idea in general. Most cloud providers will probably want/love this, esp. when it comes to specifica of their environments. On the other hand I have some concerns: a) we need to decide then if we need one kernel flavour for each cloud provider or if we can agree on a basic set of kernel compile options that every cloud provider can use. b) most kernels Debian ships are kernels that have most drivers needed as modules, so even though the kernel images are big, the kernel should only load modules it really needs. Thomas, can you elaborate why you think this a good idea? Is this about boot time of the kernel image? The thing I really do not want to have is additional kernel source uploads to the archive for just those cloud kernel images, but you already considered that a bad idea (from what I read between your lines). Cheers, Martin -- Martin Zobel-Helas <zo...@debian.org>Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Bug#772435: slow SSD performance with Apple PCIe SSD on MBP 11.2
Region 0: Memory at a090 (64-bit, non-prefetchable) [disabled] [size=64K] Region 2: Memory at 8000 (64-bit, prefetchable) [disabled] [size=256M] Region 4: Memory at a080 (64-bit, non-prefetchable) [disabled] [size=1M] Capabilities: access denied 04:00.0 SATA controller [0106]: Samsung Electronics Co Ltd Apple PCIe SSD [144d:1600] (rev 01) (prog-if 01 [AHCI 1.0]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 256 bytes Interrupt: pin A routed to IRQ 48 Region 5: Memory at a070 (32-bit, non-prefetchable) [size=8K] Expansion ROM at a071 [disabled] [size=64K] Capabilities: access denied Kernel driver in use: ahci ** USB devices: Bus 002 Device 002: ID 05ac:8406 Apple, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 006: ID 05ac:8289 Apple, Inc. Bus 001 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 001 Device 003: ID 05ac:0263 Apple, Inc. Apple Internal Keyboard / Trackpad (MacBook Retina) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-3.16.0-4-amd64 depends on: ii debconf [debconf-2.0] 1.5.54 ii initramfs-tools [linux-initramfs-tool] 0.116 ii kmod18-3 ii linux-base 3.5 ii module-init-tools 18-3 Versions of packages linux-image-3.16.0-4-amd64 recommends: pn firmware-linux-free none pn irqbalance none Versions of packages linux-image-3.16.0-4-amd64 suggests: pn debian-kernel-handbook none ii extlinux3:6.03+dfsg-2 ii grub-efi2.02~beta2-15 pn linux-doc-3.16 none Versions of packages linux-image-3.16.0-4-amd64 is related to: pn firmware-atherosnone pn firmware-bnx2 none pn firmware-bnx2x none pn firmware-brcm80211 none pn firmware-intelwimax none pn firmware-ipw2x00none pn firmware-ivtv none pn firmware-iwlwifinone pn firmware-libertas none pn firmware-linux none pn firmware-linux-nonfree none pn firmware-myricomnone pn firmware-netxen none pn firmware-qlogic none pn firmware-ralink none pn firmware-realteknone pn xen-hypervisor none -- debconf information: linux-image-3.16.0-4-amd64/prerm/removing-running-kernel-3.16.0-4-amd64: true linux-image-3.16.0-4-amd64/postinst/mips-initrd-3.16.0-4-amd64: linux-image-3.16.0-4-amd64/postinst/depmod-error-initrd-3.16.0-4-amd64: false -- Martin Zobel-Helas zo...@debian.orgDebian System Administrator Debian GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B signature.asc Description: Digital signature
Bug#766195: [PATCH] ipv6: reuse ip6_frag_id from ip6_ufo_append_data
Hi, On Wed Oct 22, 2014 at 01:02:07 +0100, Ben Hutchings wrote: I think this is the upstream change which would fix this. Please test this on top of the previous one, in case there are any more cases where ipv6_select_ident() may be called with a rt == NULL. However, it seems that with this change, when a VM offloads UDP/IPv6 fragmentation to us, we will always set the fragmentation ID to 0. I'm not sure whether that's a regression from 3.2.62, but I think it is. We should not be choosing fragment IDs for VMs, but currently they aren't telling us what to use! I've queried this upstream. i have build a new kernel with the above mentioned patches applied. This package is now available on https://people.debian.org/~zobel/linux-image-3.2.0-4-amd64_3.2.63-2a~test_amd64.deb Both machines that i installed the kernel on run for quite some time without any issue now. Before those patches they stayed up only for a few minutes. Cheers, Martin -- Martin Zobel-Helas zo...@debian.orgDebian System Administrator Debian GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141023141618.ga31...@ftbfs.de
Bug#764223: booting eder.debian.org fails
Hi, On Mon Oct 06, 2014 at 17:06:23 +0100, Ben Hutchings wrote: On Mon, 2014-10-06 at 13:20 +, Martin Zobel-Helas wrote: Source: linux-image-loongson-2e Version: 3.16+61~bpo70+1 Severity: grave Booting eder.debian.org with this kernel fails while booting linux-image-3.14-0.bpo.2-loongson-2e works just fine: [...] [4.70] swapper: page allocation failure: order:0, mode:0x10d1 [4.708000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.16-0.bpo.2-loongson-2e #1 Debian 3.16.3-2~bpo70+1 [4.716000] Stack : 8000 803f4f98 8095 80953908 8074cec8 8080b267 0001 0040 10d1 8080 806582d0 98004e0777f8 10d1 801781cc 98004e073930 8074cec8 00ff8080b226 98004e077750 801f6904 b54c6fb4 10d1 0001 80109c60 8088ef28 801f6904 ... [4.784000] Call Trace: [4.788000] [80109c60] show_stack+0x78/0x90 [4.792000] [801f6904] warn_alloc_failed+0xfc/0x140 [4.80] [801f9f7c] __alloc_pages_nodemask+0x7c4/0xa30 [4.808000] [801fa20c] __get_free_pages+0x24/0xa0 [4.812000] [80119bec] mips_dma_alloc_coherent+0x10c/0x1e0 [4.82] [804ac320] dmam_alloc_coherent+0x80/0xf8 [4.824000] [804ec978] ata_bmdma_port_start+0x48/0x78 So we couldn't allocate memory for a DMA buffer (using GFP_KERNEL | __GFP_NORETRY | GFP_DMA). [...] [4.972000] DMA free:0kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:16384kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes [...] And we have no memory available in the DMA zone. But this is an ISA DMA zone (first 16 MB of bus addresses). Why would it need memory in that range? Maybe its DMA mask is no longer initialised correctly (pata_via doesn't set it explicitly, but for PCI devices it should normally be set to DMA_BIT_MASK(32) by default). Can you test some intermediate kernel versions to narrow this down? There should be several on snapshot.debian.org. zobel@eder:~% uname -a Linux eder 3.16-rc5-loongson-2e #1 Debian 3.16~rc5-1~exp1 (2014-07-15) mips64 GNU/Linux The 3.16rc5 kernel still boots. Hope that helps to narrow down the problem. Cheers, Martin -- Martin Zobel-Helas zo...@debian.orgDebian System Administrator Debian GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010103301.ga21...@ftbfs.de
Bug#764223: booting eder.debian.org fails
Source: linux-image-loongson-2e Version: 3.16+61~bpo70+1 Severity: grave Booting eder.debian.org with this kernel fails while booting linux-image-3.14-0.bpo.2-loongson-2e works just fine: Loading Linux ... Loading initial ramdisk ... Starting kernel (no output to be expected) ... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16-0.bpo.2-loongson-2e (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 Debian 3.16.3-2~bpo70+1 (2014-09-21) [0.00] memsize=256, highmemsize=768 [0.00] CpuClock = 66634 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 6302 (ICT Loongson-2) [0.00] FPU revision is: 0501 [0.00] Checking for the multiply/shift bug... no. [0.00] Checking for the daddiu bug... no. [0.00] Determined physical RAM map: [0.00] memory: 1000 @ (usable) [0.00] memory: 0400 @ 1000 (reserved) [0.00] memory: 3000 @ 2000 (usable) [0.00] memory: 03ff @ 1c01 (reserved) [0.00] Initial ramdisk at: 0x980002c5 (14057094 bytes) [0.00] Zone ranges: [0.00] DMA [mem 0x-0x00ff] [0.00] Normal [mem 0x0100-0x4fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x13ff] [0.00] node 0: [mem 0x1c004000-0x4fff] [0.00] Reserving 0MB of memory at 0MB for crashkernel [0.00] Primary instruction cache 64kB, VIPT, direct mapped, linesize 32 bytes. [0.00] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 32 bytes [0.00] Unified secondary cache 512kB 4-way, linesize 32 bytes. [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 73474 [0.00] Kernel command line: machtype=lemote-fuloong-2e-unknown root=/dev/sda2 console=ttyS0,115200 ro rd_start=0x82c5 rd_size=0xd67e86 [0.00] PID hash table entries: 4096 (order: 1, 32768 bytes) [0.00] Dentry cache hash table entries: 262144 (order: 7, 2097152 bytes) [0.00] Inode-cache hash table entries: 131072 (order: 6, 1048576 bytes) [0.00] Memory: 985344K/1179632K available (K kernel code, 701K rwdata, 1536K rodata, 496K init, 33345K bss, 194288K reserved) [0.00] NR_IRQS:128 [0.00] Console: colour dummy device 80x25 [0.004000] Calibrating delay loop... 443.90 BogoMIPS (lpj=887808) [0.032000] pid_max: default: 32768 minimum: 301 [0.036000] Security Framework initialized [0.04] AppArmor: AppArmor disabled by boot time parameter [0.044000] Yama: disabled by default; enable with sysctl kernel.yama.* [0.048000] Mount-cache hash table entries: 4096 (order: 1, 32768 bytes) [0.052000] Mountpoint-cache hash table entries: 4096 (order: 1, 32768 bytes) [0.056000] Initializing cgroup subsys memory [0.06] Initializing cgroup subsys devices [0.064000] Initializing cgroup subsys freezer [0.068000] Initializing cgroup subsys net_cls [0.072000] Initializing cgroup subsys blkio [0.076000] Initializing cgroup subsys perf_event [0.08] Initializing cgroup subsys net_prio [0.084000] Checking for the daddi bug... no. [0.088000] ftrace: allocating 17522 entries in 18 pages [0.14] devtmpfs: initialized [0.152000] NET: Registered protocol family 16 [0.176000] vgaarb: loaded [0.176000] SCSI subsystem initialized [0.18] PCI host bridge to bus :00 [0.184000] pci_bus :00: root bus resource [mem 0x1400-0x1c00] [0.188000] pci_bus :00: root bus resource [io 0x4000-0x] [0.192000] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [0.196000] via686b fix: ISA bridge [0.196000] via686b fix: ISA bridge done [0.20] pci :00:05.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7] [0.204000] pci :00:05.1: legacy IDE quirk: reg 0x14: [io 0x03f6] [0.208000] pci :00:05.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177] [0.212000] pci :00:05.1: legacy IDE quirk: reg 0x1c: [io 0x0376] [0.216000] via686b fix: IDE [0.216000] via686b fix: IDE done [0.22] pci :00:05.4: quirk: [io 0xeee0-0xeeef] claimed by vt82c686 SMB [0.224000] vgaarb: device added: PCI::00:06.0,decodes=io+mem,owns=io+mem,locks=none [0.228000] pci :00:06.0: BAR 0: assigned [mem 0x1400-0x15ff pref] [0.232000] pci :00:06.0: BAR 6: assigned [mem 0x1600-0x1601 pref] [0.236000] pci :00:07.0: BAR 6: assigned [mem 0x1602-0x1603 pref] [0.24] pci :00:06.0: BAR 2: assigned [mem 0x1604-0x1604] [
Re: Meeting(s) at FOSDEM
Hi, On Thu Feb 05, 2009 at 12:30:46 +, Steve McIntyre wrote: On Sun, Feb 01, 2009 at 02:53:58PM +, Steve McIntyre wrote: Hi folks, Apologies for the massive cross-posting, but I'm trying to arrange some discussions between the various teams, or at least those members who will be at FOSDEM. Topics I'd like us to talk about include: 1. how the d-i daily builds are done and distributed 2. how the needs of the kernel d-i teams can better be reconciled I'm guessing that quite a number of people may be interested in these, and in other topics. Is there anything else I'm missing that you would like to discuss? Then: when and where would be a good time to meet up? Hello? Anyone? not sure if i am going to fosdem at all. MAYBE i will go on sunday, but that is not carved in stone yet. Greetings Martin -- Martin Zobel-Helas zo...@debian.org | Debian System Administrator Debian GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#493994: linux-modules-extra-2.6_2.6.26-1(sparc/unstable): FTBFS on sparc
Package: linux-modules-extra-2.6 Version: 2.6.26-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of linux-modules-extra-2.6_2.6.26-1 on spontini by sbuild/sparc 99.99 Build started at 20080805-0144 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 5), linux-support-2.6.26-1, linux-headers-2.6.26-1-all-alpha [alpha], linux-headers-2.6.26-1-all-amd64 [amd64], linux-headers-2.6.26-1-all-arm [arm], linux-headers-2.6.26-1-all-armel [armel], linux-headers-2.6.26-1-all-hppa [hppa], linux-headers-2.6.26-1-all-i386 [i386], linux-headers-2.6.26-1-all-ia64 [ia64], linux-headers-2.6.26-1-all-m68k [m68k], linux-headers-2.6.26-1-all-mips [mips], linux-headers-2.6.26-1-all-mipsel [mipsel], linux-headers-2.6.26-1-all-powerpc [powerpc], linux-headers-2.6.26-1-all-s390 [s390], linux-headers-2.6.26-1-all-sparc [sparc], atl2-source [alpha amd64 arm armel hppa i386 ia64 m68k mipsel powerpc sparc], aufs-source, btrfs-source [alpha amd64 armel i386 m68k s390], et131x-source [alpha amd64 arm armel hppa i386 ia64 m68k mipsel powerpc sparc], loop-aes-source, lzma-source, nilfs2-source, redhat-cluster-source, sfc-source [alpha amd64 arm armel hppa i386 ia64 m68k mipsel powerpc sparc], speakup-source [alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc sparc], squashfs-source [alpha amd64 arm armel i386 ia64 m68k mips mipsel powerpc s390 sparc], gspca-source [amd64 i386 powerpc], iscsitarget-source [amd64 arm armel i386 ia64 m68k powerpc s390 sparc], r6040-source [amd64 i386], tp-smapi-source [amd64 i386], virtualbox-ose-source [amd64 i386], eeepc-acpi-source, kqemu-source [i386], virtualbox-ose-guest-source [i386] [...] /build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2/atl2_main.c:: error: 'EOPNOTSUPP' undeclared (first use in this function) /build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2/atl2_main.c: In function 'atl2_up': /build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2/atl2_main.c:1180: error: 'EIO' undeclared (first use in this function) /build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2/atl2_main.c: In function 'atl2_probe': /build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2/atl2_main.c:1446: error: 'ENOMEM' undeclared (first use in this function) /build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2/atl2_main.c:1468: error: 'EIO' undeclared (first use in this function) make[4]: *** [/build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2/atl2_main.o] Error 1 make[3]: *** [_module_/build/buildd/linux-modules-extra-2.6-2.6.26/debian/build/build_sparc_none_sparc64_atl2] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.26-1-sparc64' make[2]: *** [debian/stamps/build_sparc_none_sparc64_atl2] Error 2 make[2]: Leaving directory `/build/buildd/linux-modules-extra-2.6-2.6.26' make[1]: *** [build_sparc_none_sparc64_atl2] Error 2 make[1]: Leaving directory `/build/buildd/linux-modules-extra-2.6-2.6.26' make: *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=sparcpkg=linux-modules-extra-2.6ver=2.6.26-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493993: linux-modules-contrib-2.6_2.6.26-1(sparc/unstable): FTBFS on sparc
Package: linux-modules-contrib-2.6 Version: 2.6.26-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of linux-modules-contrib-2.6_2.6.26-1 on spontini by sbuild/sparc 99.99 Build started at 20080805-0124 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 5), linux-support-2.6.26-1, linux-headers-2.6.26-1-all-alpha [alpha], linux-headers-2.6.26-1-all-amd64 [amd64], linux-headers-2.6.26-1-all-arm [arm], linux-headers-2.6.26-1-all-armel [armel], linux-headers-2.6.26-1-all-hppa [hppa], linux-headers-2.6.26-1-all-i386 [i386], linux-headers-2.6.26-1-all-ia64 [ia64], linux-headers-2.6.26-1-all-m68k [m68k], linux-headers-2.6.26-1-all-mips [mips], linux-headers-2.6.26-1-all-mipsel [mipsel], linux-headers-2.6.26-1-all-powerpc [powerpc], linux-headers-2.6.26-1-all-s390 [s390], linux-headers-2.6.26-1-all-sparc [sparc], rt73-source [...] /build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73/rtmp_main.c: In function 'usb_rtusb_probe': /build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73/rtmp_main.c:2160: error: 'ENOMEM' undeclared (first use in this function) /build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73/rtmp_main.c:2200: error: implicit declaration of function 'le32_to_cpu' /build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73/rtmp_main.c:2203: error: 'ENODEV' undeclared (first use in this function) /build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73/rtmp_main.c: In function 'usb_rtusb_init': /build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73/rtmp_main.c:2353: error: 'E2BIG' undeclared (first use in this function) make[4]: *** [/build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73/rtmp_main.o] Error 1 make[3]: *** [_module_/build/buildd/linux-modules-contrib-2.6-2.6.26/debian/build/build_sparc_none_sparc64_rt73] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.26-1-sparc64' make[2]: *** [debian/stamps/build_sparc_none_sparc64_rt73] Error 2 make[2]: Leaving directory `/build/buildd/linux-modules-contrib-2.6-2.6.26' make[1]: *** [build_sparc_none_sparc64_rt73] Error 2 make[1]: Leaving directory `/build/buildd/linux-modules-contrib-2.6-2.6.26' make: *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=sparcpkg=linux-modules-contrib-2.6ver=2.6.26-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482007: redhat-cluster_2.20080229-1.1(sparc/unstable): FTBFS on sparc, error: 'ret' may be used uninitialized in this function
Package: redhat-cluster Version: 2.20080229-1.1 Severity: serious There was an error while trying to autobuild your package: Automatic build of redhat-cluster_2.20080229-1.1 on spontini by sbuild/sparc 99.99 Build started at 20080519-2319 [...] ** Using build dependencies supplied by package: Build-Depends: dpatch, debhelper (= 4.2.28), libxml2-dev, libncurses5-dev, libopenais-dev (= 0.82-2), libvolume-id-dev (= 0.105-4), linux-libc-dev (= 2.6.24), libvirt-dev (= 0.3.0) [amd64 i386], libnss3-dev [amd64 i386], libnspr4-dev [amd64 i386], bzip2, libslang2-dev [...] gcc -o clufindhostname clufindhostname.o -L/usr/lib -L../clulib -lclulib gcc -g -O2 -Wall -Wformat=2 -O2 -g -I/build/buildd/redhat-cluster-2.20080229/config -DDEFAULT_CONFIG_DIR=\/etc/cluster\ -DDEFAULT_CONFIG_FILE=\cluster.conf\ -DRELEASE_VERSION=\2.0\ -Wall -Wformat=2 -O2 -g -I/build/buildd/redhat-cluster-2.20080229/config -DDEFAULT_CONFIG_DIR=\/etc/cluster\ -DDEFAULT_CONFIG_FILE=\cluster.conf\ -DRELEASE_VERSION=\2.0\ -Wall -Wformat=2 -O2 -g -I/build/buildd/redhat-cluster-2.20080229/config -DDEFAULT_CONFIG_DIR=\/etc/cluster\ -DDEFAULT_CONFIG_FILE=\cluster.conf\ -DRELEASE_VERSION=\2.0\ -Wall -Wformat=2 -O2 -g -I/build/buildd/redhat-cluster-2.20080229/config -DDEFAULT_CONFIG_DIR=\/etc/cluster\ -DDEFAULT_CONFIG_FILE=\cluster.conf\ -DRELEASE_VERSION=\2.0\ -Werror -Wstrict-prototypes -Wshadow -fPIC -D_GNU_SOURCE -I/build/buildd/redhat-cluster-2.20080229/ccs/lib -I/build/buildd/redhat-cluster-2.20080229/cman/lib -I/build/buildd/redhat-cluster-2.20080229/dlm/lib -I/usr/include -I/build/buildd/redhat-cluster-2.20080229/rgmanager/src/utils/../../include -I/usr/include -c -o clustat.o /build/buildd/redhat-cluster-2.20080229/rgmanager/src/utils/clustat.c cc1: warnings being treated as errors /build/buildd/redhat-cluster-2.20080229/rgmanager/src/utils/clustat.c: In function 'txt_cluster_status': /build/buildd/redhat-cluster-2.20080229/rgmanager/src/utils/clustat.c:830: error: 'ret' may be used uninitialized in this function make[4]: *** [clustat.o] Error 1 make[4]: Leaving directory `/build/buildd/redhat-cluster-2.20080229/rgmanager/src/utils' make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/buildd/redhat-cluster-2.20080229/rgmanager/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/build/buildd/redhat-cluster-2.20080229/rgmanager' make[1]: *** [rgmanager] Error 2 make[1]: Leaving directory `/build/buildd/redhat-cluster-2.20080229' make: *** [build-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=sparcpkg=redhat-clusterver=2.20080229-1.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475467: linux-modules-extra-2.6_2.6.24-7(sparc/unstable): FTBFS
Package: linux-modules-extra-2.6 Version: 2.6.24-7 Severity: serious There was an error while trying to autobuild your package: Automatic build of linux-modules-extra-2.6_2.6.24-7 on lebrun by sbuild/sparc 98 Build started at 20080411-0009 [...] ** Using build dependencies supplied by package: Build-Depends: atl2-source [alpha amd64 arm armel hppa i386 ia64 m68k mipsel powerpc sparc], aufs-source, btrfs-source [alpha amd64 armel i386 m68k s390], debhelper (= 5), drbd8-source [amd64 arm armel hppa i386 ia64 m68k powerpc sparc], et131x-source, gspca-source [amd64 i386 powerpc], iscsitarget-source, kqemu-source [i386], linux-headers-2.6.24-1-all-alpha [alpha], linux-headers-2.6.24-1-all-amd64 [amd64], linux-headers-2.6.24-1-all-arm [arm], linux-headers-2.6.24-1-all-armel [armel], linux-headers-2.6.24-1-all-hppa [hppa], linux-headers-2.6.24-1-all-i386 [i386], linux-headers-2.6.24-1-all-ia64 [ia64], linux-headers-2.6.24-1-all-m68k [m68k], linux-headers-2.6.24-1-all-mips [mips], linux-headers-2.6.24-1-all-mipsel [mipsel], linux-headers-2.6.24-1-all-powerpc [powerpc], linux-headers-2.6.24-1-all-s390 [s390], linux-headers-2.6.24-1-all-sparc [sparc], linux-support-2.6.24-1, loop-aes-source, lzma-source, r6040-source [amd64 i386], redhat-cluster-source, sfc-source, squashfs-source [alpha amd64 arm armel i386 ia64 m68k mips mipsel powerpc s390 sparc], tp-smapi-source [amd64 i386], unionfs-source, virtualbox-ose-guest-source [i386], virtualbox-ose-source [i386] [...] make[3]: Entering directory `/usr/src/linux-headers-2.6.24-1-sparc64' LD /build/buildd/linux-modules-extra-2.6-2.6.24/debian/build/build_sparc_none_sparc64_sfc/built-in.o CC [M] /build/buildd/linux-modules-extra-2.6-2.6.24/debian/build/build_sparc_none_sparc64_sfc/efx.o In file included from /build/buildd/linux-modules-extra-2.6-2.6.24/debian/build/build_sparc_none_sparc64_sfc/net_driver.h:52, from /build/buildd/linux-modules-extra-2.6-2.6.24/debian/build/build_sparc_none_sparc64_sfc/efx.c:40: /build/buildd/linux-modules-extra-2.6-2.6.24/debian/build/build_sparc_none_sparc64_sfc/kernel_compat.h:341:4: error: #error Need definition for regs_return_value() make[4]: *** [/build/buildd/linux-modules-extra-2.6-2.6.24/debian/build/build_sparc_none_sparc64_sfc/efx.o] Error 1 make[3]: *** [_module_/build/buildd/linux-modules-extra-2.6-2.6.24/debian/build/build_sparc_none_sparc64_sfc] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.24-1-sparc64' make[2]: *** [debian/stamps/build_sparc_none_sparc64_sfc] Error 2 make[2]: Leaving directory `/build/buildd/linux-modules-extra-2.6-2.6.24' make[1]: *** [build_sparc_none_sparc64_sfc] Error 2 make[1]: Leaving directory `/build/buildd/linux-modules-extra-2.6-2.6.24' make: *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 A full build log can be found at: http://buildd.debian.org/build.php?arch=sparcpkg=linux-modules-extra-2.6ver=2.6.24-7
Re: Please add following hint to block linux-2.6 until Beta1 is out
Hi, On Thu Feb 14, 2008 at 16:49:51 -0200, Otavio Salvador wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello RM and SRM teams, I hereby ask for a block on linux-2.6 source package until d-i Beta1 gets out. If it migrates before we do the final images we can need to delay d-i release. ACK from SRM side. -- Martin Zobel-Helas [EMAIL PROTECTED] | Debian Release Team Member Debian GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463653: linux-modules-2.6.18-6-xen-amd64: e1000 doesn't work any more
Package: linux-modules-2.6.18-6-xen-amd64 Version: 2.6.18.dfsg.1-17etch1 Severity: important With the update to 2.6.18-6-xen-amd64 the e1000 module doesn't seem to work any more. I found the following in the kern.log when trying to load the kernel module: Feb 1 16:33:35 urd kernel: e1000: :08:00.0: e1000_probe: PHY reset is blocked due to SOL/IDER session. Feb 1 16:33:35 urd kernel: e1000: :08:00.0: e1000_probe: The EEPROM Checksum Is Not Valid Feb 1 16:33:35 urd kernel: e1000: probe of :08:00.0 failed with error -5 TIA Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#433187: [Fwd: Re: Fix for sparc64 cpu hangs.]
Hi,
do we have confirmation, that this fixes our problems with the sparc
buildd? If yes, i would say, lets reschedule another round of kernels
for r2.
Martin
Greetings
Martin
On Wed Nov 07, 2007 at 11:41:11 +0100, Bernd Zeimetz wrote:
Original Message
From: [EMAIL PROTECTED] Wed Nov 7 06:14:01 2007
Return-Path: [EMAIL PROTECTED]
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: from localhost (mail.recluse.de [78.47.255.98]) by
mail.recluse.de (Postfix) with ESMTP id B51FF392926 for [EMAIL PROTECTED];
Wed, 7 Nov 2007 06:14:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at recluse.de
Received: from mail.recluse.de ([78.47.255.98]) by localhost
(mail.recluse.de [78.47.255.98]) (amavisd-new, port 10024) with ESMTP id
G2XieC59A2xV for [EMAIL PROTECTED]; Wed, 7 Nov 2007 06:14:00 +0100
(CET)
Received: from sunset.davemloft.net (unknown [74.93.104.97]) by
mail.recluse.de (Postfix) with ESMTP id 8373A392919 for [EMAIL PROTECTED];
Wed, 7 Nov 2007 06:13:58 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net
(Postfix) with ESMTP id 1BEBEC8C526;Tue, 6 Nov 2007 21:13:57 -0800 (PST)
Date: Tue, 06 Nov 2007 21:13:56 -0800 (PST)
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Fix for sparc64 cpu hangs.
From: David Miller [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: David Miller [EMAIL PROTECTED]
Date: Tue, 06 Nov 2007 20:34:33 -0800 (PST)
[FUTEX]: Fix address computation in compat code.
Sorry, I just noticed there is a second handle_futex_death()
call in compat_exit_robust_list() which has the same
address computation bug.
Here is an updated patch:
[FUTEX]: Fix address computation in compat code.
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:
(void __user *)entry + futex_offset
'entry' is a 'struct robust_list __user *', and
'futex_offset' is a 'compat_long_t' (typically a 's32').
Things explode if the 32-bit sign bit is set in futex_offset.
Type promotion sign extends futex_offset to a 64-bit value before
adding it to 'entry'.
This triggered a problem on sparc64 running 32-bit applications which
would lock up a cpu looping forever in the fault handling for the
userspace load in handle_futex_death().
Compat userspace runs with address masking (wherein the cpu zeros out
the top 32-bits of every effective address given to a memory operation
instruction) so the sparc64 fault handler accounts for this by
zero'ing out the top 32-bits of the fault address too.
Since the kernel properly uses the compat_uptr interfaces, kernel side
accesses to compat userspace work too since they will only use
addresses with the top 32-bit clear.
Because of this compat futex layer bug we get into the following loop
when executing the get_user() load near the top of handle_futex_death():
1) load from address '0xf7f16bd8', FAULT
2) fault handler clears upper 32-bits, processes fault
for address '0xf7f16bd8' which succeeds
3) goto #1
I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
for their tireless efforts helping me track down this bug.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
index 00b5726..1931457 100644
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -30,6 +30,15 @@ fetch_robust_entry(compat_uptr_t *uentry, struct
robust_list __user **entry,
return 0;
}
+static void __user *futex_uaddr(struct robust_list *entry,
+ compat_long_t futex_offset)
+{
+ compat_uptr_t base = ptr_to_compat(entry);
+ void __user *uaddr = compat_ptr(base + futex_offset);
+
+ return uaddr;
+}
+
/*
* Walk curr-robust_list (very carefully, it's a userspace list!)
* and mark any locks found there dead, and notify any waiters.
@@ -76,11 +85,13 @@ void compat_exit_robust_list(struct task_struct *curr)
* A pending lock might already be on the list, so
* dont process it twice:
*/
- if (entry != pending)
- if (handle_futex_death((void __user *)entry +
futex_offset,
- curr, pi))
- return;
+ if (entry != pending) {
+ void __user *uaddr = futex_uaddr(entry,
+ futex_offset);
+ if (handle_futex_death(uaddr, curr, pi))
+
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Hi, On Tue Sep 04, 2007 at 10:17:33 +0200, Fabio Massimo Di Nitto wrote: Josip Rodin wrote: On Tue, Sep 04, 2007 at 06:16:05AM +0200, Fabio Massimo Di Nitto wrote: #433187 is the bug that has killed the buildds on lebrun and spontini, right? AIUC, yes. at least i can reproduce that on my buildd. Hi guys, We (David Miller and I) are already working on this. We finally got some info dump from a debugging patched kernel and I expect we will have a fix within the next 3/4 weeks. From our first look it seems like a futex bug and some users have reported that the latest 2.6.23-rcX do not show this behavior. Clearly we also want to figure out a fix for .22. Fabio I should mention that lebrun.d.o is still dead since the last attempt (ssh unresponsive since 2007-08-30 ~21:25), when it was running a 2.6.22.5 with one davem patch applied (one line in kernel/futex_compat.c). If you need something more done to lebrun, such as kicking it back to life, just tell me... If you have console access, it would be good to get a processor dump by break + p. I can easily reproduce that with my Sparc Ultra60 here, which is running as buildd for experimental. The machines has the very same problem. I will try that tonight. Best you fetch me on IRC, nick zobel on IRCnet, OFTC and freenode. If we can get the patch down to something which can also be applied to a plain Etch kernel, i would also speak with Dann if he as Etch Kernel Maintainer would be willing to accept the patch for the next point release kernel. I (as stable release manager) would be willing to accept it, if Dann is supporting this. Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes
Hi, On Tue Sep 04, 2007 at 00:09:53 +0200, Josip Rodin wrote: Hi, #433187 is the bug that has killed the buildds on lebrun and spontini, right? AIUC, yes. at least i can reproduce that on my buildd. Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433250: Loading bluetooth stack produces kernel dump
Hi, On Sat Aug 04, 2007 at 11:09:51 +0200, maximilian attems wrote: On Mon, 16 Jul 2007, Martin Zobel-Helas wrote: On Mon, 2007-07-16 at 07:31 +0200, Bastian Blank wrote: lsusb -vv? The reported function checks a reported maximum value against the written one. This can be anything up to broken firmware. Nothing related to bluetooth. See attachment. Bus 001 Device 006: ID 046d:c707 Logitech, Inc. how is linux image 2.6.22 working on it? I will test it next week. currently 300km away from that machine. Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433250: Loading bluetooth stack produces kernel dump
On Mon, 2007-07-16 at 07:31 +0200, Bastian Blank wrote: lsusb -vv? The reported function checks a reported maximum value against the written one. This can be anything up to broken firmware. Nothing related to bluetooth. See attachment. Bus 005 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize064 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.21-2-686 ehci_hcd iProduct2 EHCI Host Controller iSerial 1 :00:1d.7 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 11 bDescriptorType 41 nNbrPorts 8 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 0x00 PortPwrCtrlMask0xff 0xff Hub Port Status: Port 1: .0100 power Port 2: .0100 power Port 3: .0100 power Port 4: .0100 power Port 5: .0100 power Port 6: .0100 power Port 7: .0100 power Port 8: .0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 002 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize064 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.21-2-686 uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:1d.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0xff Hub Port Status: Port 1: .0100 power Port 2: .0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 003 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize064 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.21-2-686 uhci_hcd iProduct2 UHCI Host Controller iSerial 1
Bug#405187: Please provide xen-vserver flavour for k7
Package: linux-2.6 Severity: wishlist Please provide a flavour -xen-vserver-k7. Greetings Martin -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (1003, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405187: closed by Bastian Blank [EMAIL PROTECTED] (Re: Bug#405187: Please provide xen-vserver flavour for k7)
reopen 405187 thanks On Mon, Jan 01, 2007 at 04:22:12PM +0100, Martin Zobel-Helas wrote: Please provide a flavour -xen-vserver-k7. 2.6.18-4 will not longer contain any k7 flavour of the xen images. please give reasons for this. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402770: linux-2.6: ip_conntrack module oopses
Package: linux-image-2.6-r4k-ip22 Version: 2.6.18+5 Severity: critical Hi, on my mips Indy IP22 the kernel ooopses, when ipconntrack module is loaded and i try to ping that machine. ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (512 buckets, 4096 max) - 304 bytes per conntrack BUG: warning at kernel/softirq.c:137/local_bh_enable() Call Trace: [8800f850] dump_stack+0x18/0x58 [88041824] local_bh_enable+0x11c/0x128 [c00cad58] $L436+0x50/0x88 [ip_conntrack] Greetings Martin -- Martin Zobel-Helas GPG Key-ID:0x5d64f870 Debian DevelopereMail Privat: [EMAIL PROTECTED] Debian Stable Release Manager eMail Debian: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
List established.
Hi. We now established the list * debian-kernel-maint Greetings Martin, Debian listmaster of the day. -- Martin Zobel-Helas GPG Key-ID:0x5d64f870 Debian DevelopereMail Privat: [EMAIL PROTECTED] Debian Stable Release Manager eMail Debian: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
Dear Bastian Blank, The attached patch is a port of my original patch to the version in sarge. diff -u grub-0.95+cvs20040624/debian/changelog grub-0.95+cvs20040624/debian/changelog --- grub-0.95+cvs20040624/debian/changelog +++ grub-0.95+cvs20040624/debian/changelog @@ -1,3 +1,9 @@ +grub (0.95+cvs20040624-17sarge1) stable; urgency=low + + * + + -- Bastian Blank [EMAIL PROTECTED] Fri, 28 Apr 2006 22:41:04 +0200 + grub (0.95+cvs20040624-17) unstable; urgency=low could you please include a proper changelog entry? Otherwise we will reject it from the stable update. Thanks Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: timeline for next kernel update round
Hi Moritz, On Wednesday, 15 Mar 2006, you wrote: Hi Moritz, On Wednesday, 15 Mar 2006, you wrote: Frans Pop wrote: On Wednesday 15 March 2006 00:15, Moritz Muehlenhoff wrote: The update is built and tested, it'll appear soon. It contains three ABI changing security fixes, so the ABI will be bumped. I can't speak for d-i. i had some discussion with Frans Pop today and we agreed that it might make more sense to have a new sarge d-i with R3 rather than R2. That's also due to the fact that he can't tell me how long it might take to build new sarge based d-i packages. (spoke about 2-8 weeks). ups, mea culpa, Frans said 2-4 weeks. Sorry about that. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge kernels and Volatile
Hi Horms, On Monday, 01 Aug 2005, Horms ([EMAIL PROTECTED]) wrote: On Mon, Aug 01, 2005 at 11:52:48AM +0200, Andreas Barth wrote: * Horms ([EMAIL PROTECTED]) [050801 11:43]: On Mon, Aug 01, 2005 at 09:28:37AM +0200, Andreas Barth wrote: * Horms ([EMAIL PROTECTED]) [050801 08:23]: Ok. Which updates do you have at hand currently that you want to push in? Also, you might consider if the current approach to rebuild the kernels is the best one (but that's of course up to you as long as you do the work :). I am not sure what you are getting at there. The current build process is a mess. We are tying to sort that out with single-source, which is what you can see for 2.6.12. If we can get this working, and convince ourselves that moving sarge from 2.6.8 to 2.6.12 is possible, then yes, we should do that. But for now, I'm really looking for a way to do maintenance on 2.4.27 and 2.6.8. Yes, that was about my intention as well. So, yes, please move forward with 2.4.27 and 2.6.8 and send a list of recommended updates. I need to go through the BTS and see what else could go in. But what I have right now is listed at in the following Changelogs. http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog?op=filerev=0sc=0 http://svn.debian.org/wsvn/kernel/trunk/kernel/i386/kernel-image-2.6.8-i386-2.6.8/debian/changelog?op=filerev=0sc=0 http://svn.debian.org/wsvn/kernel/trunk/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/changelog?op=filerev=0sc=0 http://svn.debian.org/wsvn/kernel/trunk/kernel-2.4/i386/kernel-image-2.4.27-i386-2.4.27/debian/changelog?op=filerev=0sc=0 IMHO this changes should go via security.debian.org. Nearly every changelog entry lists a CVE ID. Joey (and the rest of the security team), what is needed to get this via security.d.o? Martin -- Martin Zobel-Helas debian-volatile team member -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ABI-changing kernel security fixes for sarge
Hi Martin, On Friday, 25 Mar 2005, Martin 'Joey' Schulze wrote: Matthew Wilcox wrote: On Wed, Mar 23, 2005 at 04:09:42PM +0100, Frank Lichtenheld wrote: Absolutely. It's bound to happen again. We also need to figure out how to do driver updates during sarge's lifetime. I suspect virtually everybody has had the experience of trying to install woody on a new PC. Some of the problems I remember: For this I have suggested to use a semi-official / unofficial repository for the installer and kernels. I agree that there should be some way to support new hardware, but it doesn't have to be in the main archive of ftp.debian.org, imho. I think, debian-volatile might be a good place for this. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
Hi Matthew, On Thursday, 24 Mar 2005, you wrote: On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. It's all hppa machines, not just hppa64. IIRC we did some upgrade tests on hppa(32) at the BSP in Frankfurt in November last year and had no problems with that, but i might be wrong. Frank, could you please confirm this, as i recall you and Uli did these tests Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposal for kernel-modules directory (post-sarge)
-= Proposal for kernel-modules directory (post-sarge) =- As you all know, Debian kernel modules reside in /usr/src/modules. I would like to propose to change this to a more apache-config-like behavoir, means having a directory /usr/src/modules-availible and /usr/src/modules-enabled and doing symlinks to from first to second dir. Advantages: === + gives the posibility to run make-kpkg modules and only build specified kernel-modules, without needing to delete the unwanted ones. + source of kernel-modules can be updated more easily. + source of kernel-modules do not reside in tar.gz or tar.bz2 in /usr/src any more (which is not standardised BTW). Disadvantages: == + needs a change of every existing kernel-module-source package + needs a change of kernel-package Greetings Martin -- Fly me away to the bright side of the moon ... signature.asc Description: Digital signature
Re: kernel-image-2.6.8-alpha
Norbert Tretkowski wrote: I built kernel-image-2.6.8-alpha and will upload soon if I get no negative feedback. It can be downloaded from here: deb http://people.debian.org/~nobse/kernel/kernel-image-2.6.8-alpha/ ./ works fine here. greetings Martin -- Martin Zobel-Helas [EMAIL PROTECTED] or [EMAIL PROTECTED] http://www.helas.net or http://mhelas.blogspot.com GPGKey-Fingerprint: 14744CACEF5CECFAE29E2CB17929AB90F7AC3AF0
