Processed: Re: Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
Processing commands for cont...@bugs.debian.org: reassign 634149 src:linux-2.6 Bug #634149 [qemu-kvm] kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64 Bug reassigned from package 'qemu-kvm' to 'src:linux-2.6'. tags 634149 - moreinfo + confirmed Bug #634149 [src:linux-2.6] kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64 Removed tag(s) moreinfo. Bug #634149 [src:linux-2.6] kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64 Added tag(s) confirmed. merge 633589 634149 Bug#633589: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64 Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64 Merged 633589 634149. thanks Stopping processing here. Please contact me if you need assistance. -- 634149: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634149 633589: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633589 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131106537814540.transcr...@bugs.debian.org
Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
severity 634149 wishlist quit Hi, Michael Tokarev wrote: So, the problem is that with this kernel commit: commit 7972995b0c346de76fe260ce0fd6bcc8ffab724a Author: Gleb Natapov g...@redhat.com Date: Thu Mar 18 15:20:24 2010 +0200 KVM: x86 emulator: Move string pio emulation into emulator.c [...] which went into mainline with 2.6.35, there has been quite some changes in PIO emulation handling in kvm which resulted in correct but slow (as opposed by fast but incorrect) emulation. This slowed down guests that use PIO to access disks. Among these are WinXP (it switches from DMA to PIO after some I/O errors), WinNT (ditto) and - apparently - Hurd. Thanks for a nice explanation. [...] I'd mark this as notabug (not possible with BTS) or wontfix, but it's definitely possible to optimize the new code further to speed things up. If it's worth the effort is another question. That means wishlist, and probably not worth tracking unless we want to document it somewhere or someone is interested in working on it, right? Svante, if I were in your shoes, I'd come up with some words of warning for a qemu-performance.txt file and send them (ideally as a patch against the qemu or qemu-kvm package) to k...@vger.kernel.org, cc-ing this bug. And if you are looking for a low-level Hurd coding project, perhaps look into teaching the Hurd some performance tricks --- it would help on raw hardware, too. :) Investigating how to improve kvm's PIO emulation might also be interesting. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110719090546.ga14...@elie.gateway.2wire.net
Processed: Re: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
Processing commands for cont...@bugs.debian.org: severity 634149 wishlist Bug #634149 [src:linux-2.6] kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64 Bug #633589 [src:linux-2.6] kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64 Severity set to 'wishlist' from 'important' Severity set to 'wishlist' from 'important' quit Stopping processing here. Please contact me if you need assistance. -- 634149: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634149 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.131106638818033.transcr...@bugs.debian.org
Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
Jonathan Nieder wrote: Michael Tokarev wrote: So, the problem is that with this kernel commit: commit 7972995b0c346de76fe260ce0fd6bcc8ffab724a Author: Gleb Natapov g...@redhat.com Date: Thu Mar 18 15:20:24 2010 +0200 KVM: x86 emulator: Move string pio emulation into emulator.c [...] which went into mainline with 2.6.35, there has been quite some changes in PIO emulation handling in kvm which resulted in correct but slow (as opposed by fast but incorrect) emulation. This slowed down guests that use PIO to access disks. [...] That means wishlist, and probably not worth tracking unless we want to document it somewhere or someone is interested in working on it, right? On second thought, a regression's a regression --- going from usable but subtly buggy to unusable is not progress. :) Maybe it would be possible to introduce some kind of parameter to get back the speed at the cost of correctness again? Just musing. Sorry for the noise; I'll leave this to the experts. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110719091309.ga24...@elie.gateway.2wire.net
Bug#620234: marked as done (kernel crashes after /dev (6.0.1 amd64))
Your message dated Tue, 19 Jul 2011 12:07:39 +0200 with message-id 1311070059.1715.64.camel@localhost and subject line Re: Bug#620234: installation-reports: AMD64 does not boot on Opteron 170 has caused the Debian Bug report #620234, regarding kernel crashes after /dev (6.0.1 amd64) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 620234: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620234 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Severity: critical Tags: d-i Justification: breaks the whole system After the installation of Debian GNU/linux 6.0.0.1 AMD64 the kernel crashes after /dev. The monitor goes in standby and nothing happend, i can only press the reset button. The used hardware is ok, WindowsXP SP3 runs and Slackware64 13.1 too. I have the detailed hardware on sysprofile http://www.sysprofile.de/id40682. -- Package-specific info: Boot method: CD Image version: 6.0.0.1 AMD64 Date: Date and time of the install Machine: AMD Opteron 170 with MSI mainboard K8T Neo2-F V2 (newest BIOS) Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=6.0 (squeeze) - installer build 20110106+b1 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux Amnesiac 2.6.32-5-486 #1 Fri Dec 10 15:32:53 UTC 2010 i686 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface [8086:2560] (rev 03) lspci -knn: Subsystem: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface [8086:2560] lspci -knn: Kernel driver in use: agpgart-intel lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge [8086:2561] (rev 03) lspci -knn: 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 02) lspci -knn: Subsystem: Intel Corporation Device [8086:24cb] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 02) lspci -knn: Subsystem: Intel Corporation Device [8086:24cb] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 02) lspci -knn: Subsystem: Intel Corporation Device [8086:24cb] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 02) lspci -knn: Subsystem: AOPEN Inc. Device [a0a0:040a] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 82) lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge [8086:24c0] (rev 02) lspci -knn: 00:1f.1 IDE interface [0101]: Intel Corporation 82801DB (ICH4) IDE Controller [8086:24cb] (rev 02) lspci -knn: Subsystem: Intel Corporation 82801DB (ICH4) IDE Controller [8086:24cb] lspci -knn: Kernel driver in use: ata_piix lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] (rev 02) lspci -knn: Subsystem: Intel Corporation Device [8086:24cb]
Bug#634681: linux-image-2.6.39-2-686-pae: Usb oops with 2.6.39 (elv_put_request)
Package: linux-2.6 Version: 2.6.39-3 Severity: important Plug/unplug (interface disconnected)/plug cycle with Huawei E1552 USB 3G modem (also emulates cdrom) sometimes causes kernel oops. Wlan was disabled at crash time. Oops message is at end of this message. -- Package-specific info: ** Version: Linux version 2.6.39-2-686-pae (Debian 2.6.39-3) (b...@decadent.org.uk) (gcc version 4.4.6 (Debian 4.4.6-6) ) #1 SMP Tue Jul 5 03:48:49 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.39-2-686-pae root=UUID=62cb7fd9-4ec9-4341-a4f6-9b8915f25a70 ro quiet ** Tainted: WC (1536) * Taint on warning. * Module from drivers/staging has been loaded. ** Kernel log: [ 11.864809] [drm] Connector 1: [ 11.864811] [drm] VGA [ 11.864813] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 11.864816] [drm] Encoders: [ 11.864817] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 11.864820] [drm] Connector 2: [ 11.864821] [drm] HDMI-A [ 11.864823] [drm] HPD1 [ 11.864825] [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c [ 11.864828] [drm] Encoders: [ 11.864829] [drm] DFP1: INTERNAL_UNIPHY [ 11.936853] [drm] radeon: power management initialized [ 11.991446] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 11.993499] Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa4/0xa [ 12.045115] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input8 [ 12.106383] HDA Intel :00:14.2: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 12.187711] hda_codec: ALC269VB: BIOS auto-probing. [ 12.191024] input: HDA ATI SB Mic as /devices/pci:00/:00:14.2/sound/card0/input9 [ 12.191167] input: HDA ATI SB Headphone as /devices/pci:00/:00:14.2/sound/card0/input10 [ 12.957622] [drm] fb mappable at 0xC0141000 [ 12.957626] [drm] vram apper at 0xC000 [ 12.957628] [drm] size 4325376 [ 12.957630] [drm] fb depth is 24 [ 12.957632] [drm]pitch is 5632 [ 12.957798] fbcon: radeondrmfb (fb0) is primary device [ 13.011803] Console: switching to colour frame buffer device 170x48 [ 13.027432] fb0: radeondrmfb frame buffer device [ 13.027435] drm: registered panic notifier [ 13.027443] [drm] Initialized radeon 2.9.0 20080528 for :01:05.0 on minor 0 [ 13.027488] HDA Intel :01:05.1: PCI INT B - GSI 19 (level, low) - IRQ 19 [ 13.027548] HDA Intel :01:05.1: setting latency timer to 64 [ 13.342919] EXT4-fs (sdc1): re-mounted. Opts: (null) [ 13.427712] EXT4-fs (sdc1): re-mounted. Opts: errors=remount-ro [ 13.470358] loop: module loaded [ 13.727521] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) [ 14.584343] fuse init (API version 7.16) [ 15.948604] powernow-k8: Found 1 AMD Athlon(tm) II Neo K125 Processor (1 cpu cores) (version 2.20.00) [ 15.948647] powernow-k8:0 : pstate 0 (1700 MHz) [ 15.948650] powernow-k8:1 : pstate 1 (1300 MHz) [ 15.948653] powernow-k8:2 : pstate 2 (800 MHz) [ 16.310958] Bluetooth: RFCOMM TTY layer initialized [ 16.310969] Bluetooth: RFCOMM socket layer initialized [ 16.310974] Bluetooth: RFCOMM ver 1.11 [ 16.364565] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 16.364574] Bluetooth: BNEP filters: protocol multicast [ 16.402401] Bridge firewalling registered [ 18.387806] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 18.397134] sky2 :03:00.0: eth0: enabling interface [ 18.397500] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 25.385107] EXT4-fs (sdc1): re-mounted. Opts: errors=remount-ro,commit=60 [ 25.398795] EXT4-fs (sdb1): re-mounted. Opts: commit=60 [ 408.184184] usb 2-2: new high speed USB device number 3 using ehci_hcd [ 408.327872] usb 2-2: New USB device found, idVendor=12d1, idProduct=1446 [ 408.327882] usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [ 408.327890] usb 2-2: Product: HUAWEI Mobile [ 408.327895] usb 2-2: Manufacturer: HUAWEI Technology [ 408.334085] scsi6 : usb-storage 2-2:1.0 [ 408.334540] scsi7 : usb-storage 2-2:1.1 [ 409.075787] usb 2-2: USB disconnect, device number 3 [ 415.880194] usb 2-2: new high speed USB device number 4 using ehci_hcd [ 416.023850] usb 2-2: New USB device found, idVendor=12d1, idProduct=1001 [ 416.023861] usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [ 416.023869] usb 2-2: Product: HUAWEI Mobile [ 416.023874] usb 2-2: Manufacturer: HUAWEI Technology [ 416.032158] scsi11 : usb-storage 2-2:1.3 [ 416.034134] scsi12 : usb-storage 2-2:1.4 [ 416.138395] usbcore: registered new interface driver usbserial [ 416.138413] USB Serial support registered for generic [ 416.138912] usbcore: registered new interface driver usbserial_generic [ 416.138915] usbserial: USB Serial Driver core [ 416.183585] USB Serial support registered for GSM modem (1-port) [ 416.184222] option 2-2:1.0: GSM modem (1-port) converter detected [ 416.184400] usb 2-2: GSM modem (1-port)
Bug#634697: update kernel 2.6.39-2-amd64
Package: firmware-realtek Version: 0.32 Since the update of the kernel from 2.6.38-2 to 2.6.39-2, I cannot get my card to work. I have re-installed the package with the new kernel running. With 2.6.38 kernel, the r8192se_pci.ko module activates the card. It is not present with 2.6.39: pascal@ordidesfilles ~ $ find /lib/modules/2.6.39-2-amd64/ -name '*819*' /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce/rtl8192ce.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192c /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192c/rtl8192c-common.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu /lib/modules/2.6.39-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/media/video/bt819.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192u /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192u/r8192u_usb.ko /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192e /lib/modules/2.6.39-2-amd64/kernel/drivers/staging/rtl8192e/r8192e_pci.ko pascal@ordidesfilles ~ $ find /lib/modules/2.6.38-2-amd64/ -name '*819*' /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/r8192se_pci.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce /lib/modules/2.6.38-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192ce/rtl8192ce.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/media/video/bt819.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192u /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192u/r8192u_usb.ko /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192e /lib/modules/2.6.38-2-amd64/kernel/drivers/staging/rtl8192e/r8192e_pci.ko lspci lists: 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1318682830.4939241311084374650.javamail.r...@zimbra3-e1.priv.proxad.net
Bug#577925:
it would be great to have this in Squeeze. thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/93576245.753.1311085404586.JavaMail.root@quaglia
Processed: reassign 634697 to src:linux-2.6
Processing commands for cont...@bugs.debian.org: reassign 634697 src:linux-2.6 2.6.39-3 Bug #634697 [firmware-realtek] update kernel 2.6.39-2-amd64 Bug reassigned from package 'firmware-realtek' to 'src:linux-2.6'. Bug No longer marked as found in versions firmware-nonfree/0.32. Bug #634697 [src:linux-2.6] update kernel 2.6.39-2-amd64 Bug Marked as found in versions linux-2.6/2.6.39-3. thanks Stopping processing here. Please contact me if you need assistance. -- 634697: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634697 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13110867112836.transcr...@bugs.debian.org
Bug#622146: nfs-common: compatibility between squeeze and sid broken
Hi Sam, I've also run into this bug, in the context of preparing to update nfs-utils in Ubuntu for IPv6 support. My NFS server is running squeeze, and updating causes the client and server to fail to negotiate as described. It seems that it's possible to work around it by adding this single line to the server: permitted_enctypes = des-cbc-crc in addition to the 'allow_weak_crypto = true' that was already there. But what's confusing is that before this change, I had a DES3 *only* key for this server, and everything was working! How could that be if the server didn't support the DES3? To work around this problem locally without having to set permitted_enctypes for all other services on the NFS server, I've added a new separate krb5.conf file under /etc, and am setting KRB5_CONFIG in /etc/init.d/nfs-kernel-server to point to that path. You mention that fixing this properly requires backporting patches to both nfs-utils and krb5. Could you provide a reference for the krb5 patch? (I assume the nfs-utils one is the one Luk already linked to) I'm potentially willing to help with getting this int a stable update. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#622146: nfs-common: compatibility between squeeze and sid broken
Steve == Steve Langasek vor...@debian.org writes:
Steve Hi Sam, I've also run into this bug, in the context of
Steve preparing to update nfs-utils in Ubuntu for IPv6 support. My
Steve NFS server is running squeeze, and updating causes the client
Steve and server to fail to negotiate as described.
Your nfs server is squeeze and your client was squeeze but is now more
than squeeze?
(substitute ubuntu releases with pre-ipv6 nfs-utils as appropriate for
squeeze?)
R24603 in MIT upstream subversion.
See attached.
I'm happy to interact with SRM for the krb5 side of it. However, the
bug as reported didn't seem to be this one because the server involved
was older than squeeze.
so I didn't actually have any users rrequesting a solution to a problem
I knew how to solve. If you have a problem that this krb5 patch and the
mentioned nfs-utils patch solve then we definitely should propose a
backport to SRM. I'll be happy to prepare krb5 packages.
From 82affd78ac2c2b13bacf8e004f13f2d0dba5acea Mon Sep 17 00:00:00 2001
From: ghudson ghudson@dc483132-0cff-0310-8789-dd5450dbe970
Date: Tue, 25 Jan 2011 00:23:48 +
Subject: [PATCH] ticket: 6852
subject: Make gss_krb5_set_allowable_enctypes work for the acceptor
target_version: 1.9.1
tags: pullup
With the addition of enctype negotiation in 1.7, a gss-krb5 acceptor
can choose an enctype for the acceptor subkey other than the one in
the keytab. If the resulting security context will be exported and
re-imported by another gss-krb5 implementation (such as one in the
kernel), the acceptor needs a way to restrict the set of negotiated
enctypes to those supported by the other implementation. We had that
functionality for the initiator already in the form of
gss_krb5_set_allowable_enctypes; this change makes it work for the
acceptor as well.
git-svn-id: svn://anonsvn.mit.edu/svn/krb5/trunk@24603 dc483132-0cff-0310-8789-dd5450dbe970
---
src/lib/gssapi/krb5/accept_sec_context.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/lib/gssapi/krb5/accept_sec_context.c b/src/lib/gssapi/krb5/accept_sec_context.c
index 9d40f68..c3cb2f1 100644
--- a/src/lib/gssapi/krb5/accept_sec_context.c
+++ b/src/lib/gssapi/krb5/accept_sec_context.c
@@ -623,6 +623,15 @@ kg_accept_krb5(minor_status, context_handle,
goto fail;
}
+/* Limit the encryption types negotiated (if requested). */
+if (cred-req_enctypes) {
+if ((code = krb5_set_default_tgs_enctypes(context,
+ cred-req_enctypes))) {
+major_status = GSS_S_FAILURE;
+goto fail;
+}
+}
+
if ((code = krb5_rd_req(context, auth_context, ap_req,
cred-default_identity ? NULL : cred-name-princ,
cred-keytab,
--
1.7.4.1
Bug#622146: nfs-common: compatibility between squeeze and sid broken
On Tue, Jul 19, 2011 at 02:31:36PM -0400, Sam Hartman wrote: Steve == Steve Langasek vor...@debian.org writes: Steve Hi Sam, I've also run into this bug, in the context of Steve preparing to update nfs-utils in Ubuntu for IPv6 support. My Steve NFS server is running squeeze, and updating causes the client Steve and server to fail to negotiate as described. Your nfs server is squeeze and your client was squeeze but is now more than squeeze? (substitute ubuntu releases with pre-ipv6 nfs-utils as appropriate for squeeze?) Yes - Ubuntu currently has an nfs-utils package based on 1:1.2.2-4 (precisely the version in squeeze), and I'm in the process of updating it to 1.2.4. R24603 in MIT upstream subversion. See attached. Thanks! I'm happy to interact with SRM for the krb5 side of it. However, the bug as reported didn't seem to be this one because the server involved was older than squeeze. Oh, the original report said that the problem happened with a squeeze server. Only agi reported it with a lenny server. so I didn't actually have any users rrequesting a solution to a problem I knew how to solve. If you have a problem that this krb5 patch and the mentioned nfs-utils patch solve then we definitely should propose a backport to SRM. I'll be happy to prepare krb5 packages. So the originally linked patch for nfs-utils, http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=d6c1b35c6b40243bfd6fba2591c9f8f2653078c0, doesn't apply cleanly against the nfs-utils 1.2.2 in squeeze; it appears to have some prerequisites. (The number of args to gssd_acquire_cred has changed.) Anyone know which commits we need here? Or should I just rewrite gssd_acquire_cred(NULL, GSS_C_NT_HOSTBASED_SERVICE) to gssd_acquire_cred(NULL)? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#622146: nfs-common: compatibility between squeeze and sid broken
I don't have checkouts handy, but my strong suspicion is that if someone is now passing in GSS_C_NT_HOSTBASED_SERVICE into gssd_acquire_cred and there isn't an argument slot, you can leave it off. gss_c_nt_hostbased_service has always been the default for gssd. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tslpql67xrp@mit.edu
Bug#634794: cdrom eject button has stopped working
Package: linux-2.6
Version: 2.6.39-2
Severity: normal
File: linux
The cdrom eject button appears to have stopped working and the eject command
does not work either.
eject /dev/cdrom
This just returns to a prompt, and the drive stays closed. It used to
work before when the drives all had /dev/hd* names. This must have happened
when the devices became renamed. The cdrom works fine otherwise, but I have
to use a special tool (made from a paperclip) to extract the discs now.
A system trace reveals:
open(/dev/sr0, O_RDWR|O_NONBLOCK) = 3
ioctl(3, CDROMEJECT, 0x802) = -1 EIO (Input/output error)
I'm not sure what model drive it is at this time, but it is an IDE one
connected via a ribbon cable to the motherboard.
-- Package-specific info:
** Version:
Linux version 2.6.39-2-486 (Debian 2.6.39-2) (b...@decadent.org.uk) (gcc
version 4.4.6 (Debian 4.4.6-3) ) #1 Wed Jun 8 10:50:02 UTC 2011
** Command line:
auto BOOT_IMAGE=Linux ro root=805 ipv6.disable=1 quiet
** Not tainted
** Kernel log:
[3210188.319343] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[3210188.319356] sr 1:0:0:0: [sr0] Sense Key : Illegal Request [current]
[3210188.319366] sr 1:0:0:0: [sr0] Add. Sense: Illegal mode for this track
[3210188.319389] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a 60 00 00 40 00
[3210188.319406] end_request: I/O error, dev sr0, sector 59776
[3210188.319418] Buffer I/O error on device sr0, logical block 7472
[3210188.319431] Buffer I/O error on device sr0, logical block 7473
[3210188.319439] Buffer I/O error on device sr0, logical block 7474
[3210188.319446] Buffer I/O error on device sr0, logical block 7475
[3210188.319453] Buffer I/O error on device sr0, logical block 7476
[3210188.319460] Buffer I/O error on device sr0, logical block 7477
[3210188.319467] Buffer I/O error on device sr0, logical block 7478
[3210188.319473] Buffer I/O error on device sr0, logical block 7479
[3210188.319480] Buffer I/O error on device sr0, logical block 7480
[3210188.319487] Buffer I/O error on device sr0, logical block 7481
[3210219.104064] ata2: lost interrupt (Status 0x50)
[3210219.104115] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[3210219.104130] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a a0 00 00 40 00
[3210219.104160] ata2.00: cmd a0/01:00:00:00:fc/00:00:00:00:00/a0 tag 0 dma
131072 in
[3210219.104163] res 40/00:03:00:08:00/00:00:00:00:00/a0 Emask 0x4
(timeout)
[3210219.104171] ata2.00: status: { DRDY }
[3210219.104216] ata2: soft resetting link
[3210219.284262] ata2.00: configured for MWDMA2
[3210219.284379] ata2.00: TEST_UNIT_READY failed (err_mask=0x2)
[3210224.260084] ata2: soft resetting link
[3210224.440255] ata2.00: configured for MWDMA2
[3210224.448079] ata2.00: TEST_UNIT_READY failed (err_mask=0x2)
[3210224.448088] ata2.00: limiting speed to MWDMA2:PIO3
[3210229.416084] ata2: soft resetting link
[3210229.596278] ata2.00: configured for MWDMA2
[3210229.596397] ata2.00: TEST_UNIT_READY failed (err_mask=0x2)
[3210229.596404] ata2.00: disabled
[3210229.596456] ata2: soft resetting link
[3210229.752154] ata2: EH complete
[3210229.752262] sr 1:0:0:0: [sr0] Unhandled error code
[3210229.752269] sr 1:0:0:0: [sr0] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[3210229.752279] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a a0 00 00 40 00
[3210229.752296] end_request: I/O error, dev sr0, sector 60032
[3210229.752306] quiet_error: 22 callbacks suppressed
[3210229.752313] Buffer I/O error on device sr0, logical block 7504
[3210229.752324] Buffer I/O error on device sr0, logical block 7505
[3210229.752331] Buffer I/O error on device sr0, logical block 7506
[3210229.752338] Buffer I/O error on device sr0, logical block 7507
[3210229.752344] Buffer I/O error on device sr0, logical block 7508
[3210229.752351] Buffer I/O error on device sr0, logical block 7509
[3210229.752357] Buffer I/O error on device sr0, logical block 7510
[3210229.752364] Buffer I/O error on device sr0, logical block 7511
[3210229.752371] Buffer I/O error on device sr0, logical block 7512
[3210229.752379] Buffer I/O error on device sr0, logical block 7513
[3210229.752447] sr 1:0:0:0: [sr0] Unhandled error code
[3210229.752452] sr 1:0:0:0: [sr0] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[3210229.752460] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a 60 00 00 02 00
[3210229.752474] end_request: I/O error, dev sr0, sector 59776
** Model information
not available
** Loaded modules:
Module Size Used by
tun17630 0
snd_via82xx22532 0
snd_ac97_codec 83728 1 snd_via82xx
ac97_bus 12462 1 snd_ac97_codec
snd_pcm_oss35824 0
snd_mixer_oss 17649 1 snd_pcm_oss
snd_pcm52675 3 snd_via82xx,snd_ac97_codec,snd_pcm_oss
snd_page_alloc 12841 2 snd_via82xx,snd_pcm
snd_mpu401_uart13299 1 snd_via82xx
snd_seq_midi 12744 0
snd_rawmidi
Bug#634794: cdrom eject button has stopped working
Hi, Mark Hobley wrote: open(/dev/sr0, O_RDWR|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0x802) = -1 EIO (Input/output error) I'm not sure what model drive it is at this time, but it is an IDE one connected via a ribbon cable to the motherboard. Could you attach full output from dmesg (so we can see what model of CD-ROM we are talking about)? Thanks much. Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110719232435.ga7...@elie.gateway.2wire.net
Symbolic links to kernel image files and initial RAM file system image files
It's hard to believe that it's been over a year since we discussed this topic. (See http://lists.debian.org/debian-kernel/2010/06/msg01049.html.) Time flies when you're having fun, I guess. ;-) Anyway, back when the boot loader hook script policy was being formulated, shortly before the Squeeze freeze, I brought up the subject of symbolic links to kernel image files and initial RAM file system image files, their maintenance, and their use by boot loader configuration files. This subject is not really addressed in the current hook script policy for boot loaders. Nevertheless, traditional boot loaders, such as lilo and zipl, particularly the way their configuration files are set up by the Debian installer, do use these symbolic links. The last time I checked, the do_symlinks = yes setting in /etc/kernel-img.conf was still honored by the maintainer scripts for official stock Debian kernel image packages; therefore, as long as the user runs only official Debian stock kernel image packages he can keep current by setting do_symlinks = yes in /etc/kernel-img.conf (along with companion options such as link_in_boot and relative_links). However, the last time I checked, do_symlinks = yes in /etc/kernel-img.conf is not honored by the maintainer scripts that are packaged with a kernel image package created by current versions of make-kpkg or make deb-pkg. Consequently, for custom kernel image packages at least, we have a chink in the armor for boot loaders to get out of sync with installed kernel images. Boot loader hook scripts are not currently required to maintain symbolic links, and none of the boot loader hook scripts that I have looked at do so. But neither do the hook scripts provided by these traditional boot loaders edit the configuration file (similar to the update-grub command of grub version 1) to reference the kernel image files and their initial RAM file system image files directly, so that symbolic links are not needed. Thus we have the situation where the boot loader is implicitly assuming that the symbolic links are going to be maintained somehow, someway, and, for custom kernels, no official part of the Debian system is maintaining them. For my own use on my own systems, I have written hook scripts which maintain the symbolic links; and if anyone wants them, they are available for download on my web site. But obviously they are not part of the official Debian system. While we still have plenty of time before the Wheezy freeze, I would like to discuss what, if anything, should be done about this situation. I see several alternatives: o Require boot loader hook scripts to either edit their configuration files or maintain the symbolic links o Provide hook scripts in some other package (base-files? initramfs-tools?) that maintain symbolic links o Eliminate symbolic links entirely and require boot loader hook scripts to edit their configuration files o Bury our heads in the sand and ignore the problem (Obviously I don't care for that last one or I wouldn't have started this thread!) The second option would seem to be the quickest solution, but the quickest solution is not always the best solution. Perhaps there are other alternatives that I haven't thought of. What are your thoughts? P.S. For this initial post I have CC-ed debian-boot and debian-devel, as there may be interested parties on that list that are not subscribed to debian-kernel, but it is my intention that the discussion take place on debian-kernel. So please excuse this initial cross-post. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1702198171.779349.139811090.javamail.r...@md01.wow.synacor.com
Bug#634794: cdrom eject button has stopped working
--- On Wed, 20/7/11, Jonathan Nieder jrnie...@gmail.com wrote: Could you attach full output from dmesg (so we can see what model of CD-ROM we are talking about)? There is nothing in dmesg about the drive, but the system has been up a while. Is there some way I can query for the cdrom drive information? I found this in /proc/sys/dev/cdrom/info, if it means anything: CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: sr0 drive speed:32 drive # of slots: 1 Can close tray: 1 Can open tray: 1 Can lock tray: 1 Can change speed: 1 Can select disk:0 Can read multisession: 1 Can read MCN: 1 Reports media changed: 1 Can play audio: 1 Can write CD-R: 0 Can write CD-RW:0 Can read DVD: 0 Can write DVD-R:0 Can write DVD-RAM: 0 Can read MRW: 1 Can write MRW: 1 Can write RAM: 1 # hdparm /dev/sr0 /dev/sr0: HDIO_DRIVE_CMD(identify) failed: Input/output error IO_support= 0 (default) readonly = 0 (off) readahead = 256 (on) HDIO_GETGEO failed: Inappropriate ioctl for device # hdparm -I /dev/sr0: HDIO_DRIVE_CMD(identify) failed: Input/output error I'll have to shutdown to refresh dmesg, or maybe open up the case and have a look. Mark. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1311131494.83478.yahoomailclas...@web26502.mail.ukl.yahoo.com
Bug#634794: cdrom eject button has stopped working
Mark Hobley wrote: --- On Wed, 20/7/11, Jonathan Nieder jrnie...@gmail.com wrote: Could you attach full output from dmesg (so we can see what model of CD-ROM we are talking about)? There is nothing in dmesg about the drive, but the system has been up a while. [...] I'll have to shutdown to refresh dmesg, or maybe open up the case and have a look. Yes, a dmesg after a fresh reboot would be useful. You can also find previous kernel messages in /var/log/kern.log* if the kernel ring buffer has filled up. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110720035407.ga12...@elie.gateway.2wire.net
