Bug#604824: linux-2.6: problems with ata disk interface: temporary freezes
Hallo, here it is $(lspci -vn) and $(dmesg) without pci=noacpi from today boot. Quite embarassingly it does not contain any error message. Fulvio [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-686 (Debian 2.6.32-27) (m...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 22:47:19 UTC 2010 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] NSC Geode by NSC [0.00] Cyrix CyrixInstead [0.00] Centaur CentaurHauls [0.00] Transmeta GenuineTMx86 [0.00] Transmeta TransmetaCPU [0.00] UMC UMC UMC UMC [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f000 (usable) [0.00] BIOS-e820: 0009f000 - 000a (reserved) [0.00] BIOS-e820: 0010 - 7ffd8000 (usable) [0.00] BIOS-e820: 7ffd8000 - 8000 (reserved) [0.00] BIOS-e820: e000 - f0007000 (reserved) [0.00] BIOS-e820: f0008000 - f000c000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed2 - fee1 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] DMI 2.3 present. [0.00] last_pfn = 0x7ffd8 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 0FEDA mask E write-through [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT not supported by CPU. [0.00] initial memory mapped : 0 - 0180 [0.00] init_memory_mapping: -373fe000 [0.00] 00 - 40 page 4k [0.00] 40 - 003700 page 2M [0.00] 003700 - 00373fe000 page 4k [0.00] kernel direct mapping tables up to 373fe000 @ 7000-d000 [0.00] RAMDISK: 377cc000 - 37fef746 [0.00] Allocated new RAMDISK: 0010 - 00923746 [0.00] Move RAMDISK from 377cc000 - 37fef745 to 0010 - 00923745 [0.00] ACPI: RSDP 000fc9b0 00014 (v00 DELL ) [0.00] ACPI: RSDT 7ffd8790 00040 (v01 DELLCPi R 27D5091E ASL 0061) [0.00] ACPI: FACP 7ffd9400 00074 (v01 DELLCPi R 27D5091E ASL 0061) [0.00] ACPI: DSDT 7ffda000 0355D (v01 INT430 SYSFexxx 1001 MSFT 010E) [0.00] ACPI: FACS 7ffe8800 00040 [0.00] ACPI: APIC 7ffd9c00 00068 (v01 DELLCPi R 27D5091E ASL 0047) [0.00] ACPI: ASF! 7ffd9800 0005B (v16 DELLCPi R 27D5091E ASL 0061) [0.00] ACPI: MCFG 7ffd9bc0 0003E (v16 DELLCPi R 27D5091E ASL 0061) [0.00] ACPI: SSDT 7ffd8be6 00280 (v01 PmRef Cpu0Ist 3000 INTL 20030522) [0.00] ACPI: SSDT 7ffd8a0e 001D8 (v01 PmRef Cpu0Cst 3001 INTL 20030522) [0.00] ACPI: SSDT 7ffd8813 001FB (v01 PmRefCpuPm 3000 INTL 20030522) [0.00] ACPI: Local APIC address 0xfee0 [0.00] 1163MB HIGHMEM available. [0.00] 883MB LOWMEM available. [0.00] mapped low ram: 0 - 373fe000 [0.00] low ram: 0 - 373fe000 [0.00] node 0 low ram: - 373fe000 [0.00] node 0 bootmap 9000 - fe80 [0.00] (9 early reservations) == bootmem [00 - 00373fe000] [0.00] #0 [00 - 001000] BIOS data page == [00 - 001000] [0.00] #1 [001000 - 002000]EX TRAMPOLINE == [001000 - 002000] [0.00] #2 [006000 - 007000] TRAMPOLINE == [006000 - 007000] [0.00] #3 [000100 - 00014c7bb4]TEXT DATA BSS == [000100 - 00014c7bb4] [0.00] #4 [09f000 - 10]BIOS reserved == [09f000 - 10] [0.00] #5 [00014c8000 - 00014ce188] BRK == [00014c8000 - 00014ce188] [0.00] #6 [007000 - 009000] PGTABLE == [007000 - 009000] [0.00] #7 [10 - 923746] NEW RAMDISK == [10 - 923746] [0.00] #8 [009000 - 01] BOOTMAP == [009000 - 01] [0.00] Zone PFN ranges: [0.00] DMA 0x - 0x1000 [0.00] Normal 0x1000 - 0x000373fe [0.00] HighMem
Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
On sam., 2010-11-27 at 23:56 +, Ben Hutchings wrote: On Sat, 2010-11-27 at 23:34 +0100, Yves-Alexis Perez wrote: [...] == Configuration The KConfig is the one I use, which is open to discussion (like everything else anyway). I've tried to be fairly secure, so some features might not work for some people. When possible, options are configurable at runtime using sysctl. Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so people can fine-tune their installation. I didn't find a way to ship it cleanly in a linux-image package so if anyone has an idea please say so. I suggest you put it in a separate package e.g. linux-grsec-base and have the image packages depend on or recommend it. Good point, especially if there's some work to do for adding groups, it might be better to do that in a linux-grsec-base package than in the linux-image one. [...] === Trusted Path Execution Trusted Path Execution (TPE) is a way to restrict code execution. Basically, binaries execution is forbidden from paths not owned by root. It's configured using a GID (which I chose to be 500, once again it can and should be discussed), it and can be opt-in (users belonging to the group are prevented to execute “untrusted” binaries) or opt-out (only people belonging to the group can execute “untrusted” binaries). I chose the latter, to have a “secure by default” system. === Socket restrictions The same kind of restrictions exist on socket, gid-based again: when you add users to the relevant group, you deny them the right to create sockets. I've chosen gids 501, 502 and 503 for respectively “all” sockets, “client” sockets and “server” sockets. Once again, this is configurable using sysctls. These gids are in the 'dynamically assigned' range and must not be configured into the kernel; see Debian policy §9.2. On this, I'm not sure (but will ask base-passwd maintainers for advice). The gids are configured in KConfig, but can be changed dynamically using sysctl (though that means before procpcs is run the gid is still the static one). It'd be nice to have the same gids on every system, but I'm not sure it's really indispensable. [...] == Conclusion So, what do you think? Does it look like a good idea, are there some blockers, some implementation details to discuss? Any comment is welcome. Ideally I'd like to see the worthwhile bits merged upstream in some form, with the most paranoid stuff in an LSM. But I'm not going to spend time on that myself. If you're prepared to maintain this and accept that it might not be kept for more than one release then I have no objection. Yeah, agreed about the upstreaming part (and I'll try to give some help there too). And yes, ideally it shouldn't be kept too long before reaching upstream. I'll do some tests on a linux-grsec-base package and see about the gid stuff and report back later. Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM -- 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/1290937478.14495.38.ca...@hidalgo
Bug#601341: #601341, #602418 and #604096 seem to be duplicates
reassign 604096 linux-2.6 forcemerge 601341 602418 604096 # see original bug reports affects 601341 xserver-xorg # see http://xenbits.xen.org/people/ianc/ tag 601341 patch # IMHO that should be fixed for squeeze severity 601341 serious thanks Am Dienstag, den 23.11.2010, 10:41 +0100 schrieb Alexander Kurtz: I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC Any objections? Since I received no objections, I'm merging these bugs now. Feel free to unmerge if necessary. Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Processed: Re: #601341, #602418 and #604096 seem to be duplicates
Processing commands for cont...@bugs.debian.org: reassign 604096 linux-2.6 Bug #604096 [xserver-xorg] xserver-xorg: freezes when running as dom0 under Xen 4.0 at startup Bug reassigned from package 'xserver-xorg' to 'linux-2.6'. Bug No longer marked as found in versions xorg/1:7.5+8. forcemerge 601341 602418 604096 Bug#601341: xserver-xorg-video-nouveau: hangs X fb console on black screen on dom0 xen instance Bug#602418: linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver Bug#604096: xserver-xorg: freezes when running as dom0 under Xen 4.0 at startup Forcibly Merged 601341 602418 604096. # see original bug reports affects 601341 xserver-xorg Bug #601341 [linux-2.6] xserver-xorg-video-nouveau: hangs X fb console on black screen on dom0 xen instance Bug #602418 [linux-2.6] linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver Bug #604096 [linux-2.6] xserver-xorg: freezes when running as dom0 under Xen 4.0 at startup Added indication that 601341 affects xserver-xorg Added indication that 602418 affects xserver-xorg Added indication that 604096 affects xserver-xorg # see http://xenbits.xen.org/people/ianc/ tag 601341 patch Bug #601341 [linux-2.6] xserver-xorg-video-nouveau: hangs X fb console on black screen on dom0 xen instance Bug #602418 [linux-2.6] linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver Bug #604096 [linux-2.6] xserver-xorg: freezes when running as dom0 under Xen 4.0 at startup Added tag(s) patch. Added tag(s) patch. Added tag(s) patch. # IMHO that should be fixed for squeeze severity 601341 serious Bug #601341 [linux-2.6] xserver-xorg-video-nouveau: hangs X fb console on black screen on dom0 xen instance Bug #602418 [linux-2.6] linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver Bug #604096 [linux-2.6] xserver-xorg: freezes when running as dom0 under Xen 4.0 at startup Severity set to 'serious' from 'normal' Severity set to 'serious' from 'normal' Severity set to 'serious' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 601341: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601341 602418: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602418 604096: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604096 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.129093875518927.transcr...@bugs.debian.org
Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
28.11.2010 05:25, Ben Hutchings wrote: Please can you test whether this is fixed in 2.6.32-28? We backported a KVM feature (VCPU_EVENTS) which meant we needed an additional fix beyond the one which Michael Tokarev identified, and that was done in -28. Yes, with 2.6.32-28 686 kernel I can't reproduce the problem anymore, kvm works as intended, while reverting back to -27 returns the issue. Reading #599507 again, together with this #604604 and also #604900, it looks like all this stuff is the same thing. There's also #580652. Out of curiocity, why this feature (VCPU_EVENTS) were backported/applied in the first place (it was in 2.6.32-12)? Isn't it somewhat too buggy having in mind all the above? Thank you! /mjt -- 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/4cf23166.1000...@msgid.tls.msk.ru
Processed: severity of 601341 is important
Processing commands for cont...@bugs.debian.org: severity 601341 important Bug #601341 [linux-2.6] xserver-xorg-video-nouveau: hangs X fb console on black screen on dom0 xen instance Bug #602418 [linux-2.6] linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver Bug #604096 [linux-2.6] xserver-xorg: freezes when running as dom0 under Xen 4.0 at startup Severity set to 'important' from 'serious' Severity set to 'important' from 'serious' Severity set to 'important' from 'serious' thanks Stopping processing here. Please contact me if you need assistance. -- 601341: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601341 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.129094857428232.transcr...@bugs.debian.org
Bug#604891: (rpc.gssd: Failed to create machine krb5 context with any credentials cache)
It seems the issue is solved. Due to a bad BIOS-Setup (dynamic clock ticks) the time slow down. NTP wasn't be able to correct this. After fixing this the observed misbehavior vanished. The Bug can be closes. Sorry for the noise. -- 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/20101128140255.ga6...@phoenix.lab.swapon.de
Processed: your mail
Processing commands for cont...@bugs.debian.org: reassign 605246 linux-2.6 Bug #605246 [eeepc-acpi-scripts] Built-in 3G modem can prevent sleep mode Bug reassigned from package 'eeepc-acpi-scripts' to 'linux-2.6'. Bug No longer marked as found in versions eeepc-acpi-scripts/1.1.11. End of message, stopping processing here. Please contact me if you need assistance. -- 605246: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605246 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.129095534728562.transcr...@bugs.debian.org
Bug#604891: marked as done (rpc.gssd: Failed to create machine krb5 context with any credentials cache)
Your message dated Sun, 28 Nov 2010 15:56:27 +0100 with message-id 201011281556.27697.hol...@layer-acht.org and subject line Re: Bug#604891: (rpc.gssd: Failed to create machine krb5 context with any credentials cache) has caused the Debian Bug report #604891, regarding rpc.gssd: Failed to create machine krb5 context with any credentials cache 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.) -- 604891: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604891 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: nfs-common Version: 1:1.2.2-4 Severity: normal I mount a NFS4-Share with krb5p and automounter. After some time the client refuses the mount. The rpc.gssd complains: rpc.gssd[12224]: in authgss_create() rpc.gssd[12224]: in authgss_refresh() rpc.gssd[12224]: in authgss_marshal() rpc.gssd[12224]: xdr_rpc_gss_cred: encode success (v 1, proc 1, seq 0, svc 1, ctx (nil):0) rpc.gssd[12224]: xdr_rpc_gss_init_args: encode success (token 0x1e667e0:542) rpc.gssd[12224]: in authgss_validate() rpc.gssd[12224]: xdr_rpc_gss_init_res decode success (ctx (nil):0, maj 851968, min -1765328347, win 128, token (nil):0) rpc.gssd[10927]: WARNING: Failed to create machine krb5 context with any credentials cache for server reliant.lab.swapon.de Which is not true: $ date Thu Nov 25 06:54:40 CET 2010 $ sudo klist -c /tmp/krb5cc_machine_LAB.SWAPON.DE Credentials cache: FILE:/tmp/krb5cc_machine_LAB.SWAPON.DE Principal: nfs/phoenix.lab.swapon...@lab.swapon.de Issued Expires Principal Nov 24 20:18:54 Nov 25 20:13:54 krbtgt/lab.swapon...@lab.swapon.de Nov 24 20:18:54 Nov 25 20:13:54 nfs/reliant.lab.swapon...@lab.swapon.de When I restart the rpc.gssd, everything works well again. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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 nfs-common depends on: ii adduser 3.112 add and remove users and groups ii initscripts 2.88dsf-12 scripts for initializing and shutt ii libc62.11.2-7Embedded GNU C Library: Shared lib ii libcap2 1:2.19-3support for getting/setting POSIX. ii libcomerr2 1.41.12-2 common error description library ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libgssapi-krb5-2 1.8.3+dfsg-2MIT Kerberos runtime libraries - k ii libgssglue1 0.1-4 mechanism-switch gssapi library ii libk5crypto3 1.8.3+dfsg-2MIT Kerberos runtime libraries - C ii libkrb5-31.8.3+dfsg-2MIT Kerberos runtime libraries ii libnfsidmap2 0.23-2 An nfs idmapping library ii librpcsecgss30.19-2 allows secure rpc communication us ii libwrap0 7.6.q-19Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip ii netbase 4.43Basic TCP/IP networking system ii portmap 6.0.0-2 RPC port mapper ii ucf 3.0025+nmu1 Update Configuration File: preserv nfs-common recommends no packages. nfs-common suggests no packages. -- no debconf information ---End Message--- ---BeginMessage--- On Sonntag, 28. November 2010, Friedemann Stoyan wrote: Due to a bad BIOS-Setup (dynamic clock ticks) the time slow down. NTP wasn't be able to correct this. After fixing this the observed misbehavior vanished. The Bug can be closes. Sorry for the noise. signature.asc Description: This is a digitally signed message part. ---End Message---
Re: [PATCH] econet: Move to staging; remove from defconfig
On Sat, 2010-11-27 at 22:38 -0800, David Miller wrote: From: Ben Hutchings b...@decadent.org.uk Date: Sun, 28 Nov 2010 01:53:35 + On Sat, 2010-11-27 at 17:26 -0800, David Miller wrote: From: Greg KH gre...@suse.de Date: Sat, 27 Nov 2010 16:21:35 -0800 And I need an ack from the networking maintainer to be able to accept this also. I'm not applying this, nor do I want anyone else to. If people think this protocol is not maintained adequately right now, wait until you push it into staging. Furthermore, once Phil Blundell was made aware of security holes in econet he fixed them within a few days. Which is much better than I can say for some of the other protocols and filesystems in the tree. Those bugs were present for years and would have been obvious to anyone who cared to read the code. While I very much appreciate Phil's quick response, I don't think this reactive maintenance is enough. These same arguments could for be made for RDS. Look at all the hellacious awful obvious crap we've discovered in that code recently. A simple read would have caught those too, and I don't see it's maintainer doing such things. Indeed, hence the change I made for the upcoming Debian release was: * af_802154,decnet,econet,rds,x25: Disable auto-loading as mitigation against local exploits. These protocol modules are not widely used and can be explicitly loaded or aliased on systems where they are wanted. (While decnet may be in better shape than the others, auto-loading is unnecessary for us as the userland support package explicitly loads it..) So, you're very much still not convincing Ben, but feel free to keep trying. I'm not going to try any more. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#605246: [Debian-eeepc-devel] Bug#605246: Built-in 3G modem can prevent sleep mode
I tried putting the device to sleep after telling the kernel to ignore USB wakeup requests from the 3G modem, and it works, apparently without nasty side effects, the 3G still works after. I think eeepc-acpi-scripts should include a sleep.d hook to do this. A better solution would be to see if this is fixed upstream, and if so, backport the fix for the kernel in Squeeze. Would you please try the kernel in experimental to see if the problem is resolved there? Okay, I installed the linux-image-2.6.36-trunk-686-bigmem package (plus linux-base) and moved my sleep.d hook out of the way. Then I shut down completely and booted into the new kernel. The system does stay asleep, so that's fixed. However, after waking up, the system freezes for a few seconds several times. I didn't see that with 2.6.32 and hook-disabled wakeup. This seems to go away after a while, it could be one freeze for each USB device while rebinding it or something. There are reproducibly (I tested three times) four freezes, and there are four USB-devices other than root hubs. According to gnokii --monitor once, the 3G device came back up and registered with the network. -- 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/aanlktimgrobmqxr9yjb9w78zwe10wdop0e580fpho...@mail.gmail.com
Bug#605246: [Debian-eeepc-devel] Bug#605246: Built-in 3G modem can prevent sleep mode
On Sun, 2010-11-28 at 16:14 +0100, Maik Zumstrull wrote:
I tried putting the device to sleep after telling the kernel to ignore
USB wakeup requests from the 3G modem, and it works, apparently
without nasty side effects, the 3G still works after. I think
eeepc-acpi-scripts should include a sleep.d hook to do this.
A better solution would be to see if this is fixed upstream, and if so,
backport the fix for the kernel in Squeeze. Would you please try the
kernel in experimental to see if the problem is resolved there?
Okay, I installed the linux-image-2.6.36-trunk-686-bigmem package
(plus linux-base) and moved my sleep.d hook out of the way. Then I
shut down completely and booted into the new kernel.
The system does stay asleep, so that's fixed.
Please can you test whether the attached patch fixes our package of
Linux 2.6.32. You will need to rebuild the kernel package by following
the instructions at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.
However, after waking
up, the system freezes for a few seconds several times.
[...]
This should be treated as a separate bug; I'll follow up to the new bug
number shortly.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
commit 62c008d3ef95c2a52aa4e6946e8dc55a8d8af2d7
Author: Alan Stern st...@rowland.harvard.edu
Date: Fri Apr 2 13:21:33 2010 -0400
USB: don't enable remote wakeup by default
commit 7aba8d014341341590ecb64050b7a026642a62eb upstream.
This patch (as1364) avoids enabling remote wakeup by default on all
non-root-hub USB devices. Individual drivers or userspace will have
to enable it wherever it is needed, such as for keyboards or network
interfaces. Note: This affects only system sleep, not autosuspend.
External hubs will continue to relay wakeup requests received from
downstream through their upstream port, even when remote wakeup is not
enabled for the hub itself. Disabling remote wakeup on a hub merely
prevents it from generating wakeup requests in response to connect,
disconnect, and overcurrent events.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
commit d3281620ac5baed761e5134f85dc102645a3804b
Author: Dan Streetman ddstr...@ieee.org
Date: Wed Jan 6 09:56:53 2010 -0500
USB: retain USB device power/wakeup setting across reconfiguration
commit 16985408b5c48585762ec3b9b7bae1dec4ad7437 upstream.
Currently a non-root-hub USB device's wakeup settings are initialized when the
device is set to a configured state using device_init_wakeup(), but this is not
correct as wakeup is split into capable (can_wakeup) and enabled
(should_wakeup). The settings should be initialized instead in the device
initialization (usb_new_device) with the capable setting disabled and the
enabled setting enabled. The capable setting should be set based on the
device being configured or unconfigured, and enabled setting set based on
the sysfs power/wakeup control.
This patch retains the sysfs power/wakeup setting of a non-root-hub USB device
over a USB device re-configuration, which can happen (for example) after a
suspend/resume cycle.
Signed-off-by: Dan Streetman ddstr...@ieee.org
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
[bwh: Backport to 2.6.32]
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 12254e1..d2069a0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1403,11 +1403,11 @@ void usb_set_device_state(struct usb_device *udev,
|| new_state == USB_STATE_SUSPENDED)
; /* No change to wakeup settings */
else if (new_state == USB_STATE_CONFIGURED)
-device_init_wakeup(udev-dev,
+device_set_wakeup_capable(udev-dev,
(udev-actconfig-desc.bmAttributes
USB_CONFIG_ATT_WAKEUP));
else
-device_init_wakeup(udev-dev, 0);
+device_set_wakeup_capable(udev-dev, 0);
}
if (udev-state == USB_STATE_SUSPENDED
new_state != USB_STATE_SUSPENDED)
@@ -1765,10 +1765,17 @@ int usb_new_device(struct usb_device *udev)
{
int err;
- /* Increment the parent's count of unsuspended children */
- if (udev-parent)
+ if (udev-parent) {
+ /* Increment the parent's count of unsuspended children */
usb_autoresume_device(udev-parent);
+ /* Initialize non-root-hub device wakeup to disabled;
+ * device (un)configuration controls wakeup capable
+ * sysfs power/wakeup controls wakeup enabled/disabled
+ */
+ device_init_wakeup(udev-dev, 0);
+ }
+
err = usb_enumerate_device(udev); /* Read descriptors */
if (err 0)
goto fail;
signature.asc
Description: This is a digitally signed message part
Processed: cloning 605246, found 605246 in 2.6.32-28, found -1 in 2.6.36-1~experimental.1 ...
Processing commands for cont...@bugs.debian.org: clone 605246 -1 Bug#605246: Built-in 3G modem can prevent sleep mode Bug 605246 cloned as bug 605275. found 605246 2.6.32-28 Bug #605246 [linux-2.6] Built-in 3G modem can prevent sleep mode There is no source info for the package 'linux-2.6' at version '2.6.32-28' with architecture '' Unable to make a source version for version '2.6.32-28' Bug Marked as found in versions 2.6.32-28. found -1 2.6.36-1~experimental.1 Bug #605275 [linux-2.6] Built-in 3G modem can prevent sleep mode There is no source info for the package 'linux-2.6' at version '2.6.36-1~experimental.1' with architecture '' Unable to make a source version for version '2.6.36-1~experimental.1' Bug Marked as found in versions 2.6.36-1~experimental.1. retitle -1 EeePC 1005HAG freezes briefly after resuming Bug #605275 [linux-2.6] Built-in 3G modem can prevent sleep mode Changed Bug title to 'EeePC 1005HAG freezes briefly after resuming' from 'Built-in 3G modem can prevent sleep mode' thanks Stopping processing here. Please contact me if you need assistance. -- 605275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605275 605246: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605246 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 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.129096248831609.transcr...@bugs.debian.org
Processed: tagging 605246
Processing commands for cont...@bugs.debian.org: tags 605246 + patch moreinfo Bug #605246 [linux-2.6] Built-in 3G modem can prevent sleep mode Added tag(s) moreinfo and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 605246: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605246 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.129096263832117.transcr...@bugs.debian.org
Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
On Sun, 2010-11-28 at 13:39 +0300, Michael Tokarev wrote: 28.11.2010 05:25, Ben Hutchings wrote: Please can you test whether this is fixed in 2.6.32-28? We backported a KVM feature (VCPU_EVENTS) which meant we needed an additional fix beyond the one which Michael Tokarev identified, and that was done in -28. Yes, with 2.6.32-28 686 kernel I can't reproduce the problem anymore, kvm works as intended, while reverting back to -27 returns the issue. Excellent. Reading #599507 again, together with this #604604 and also #604900, it looks like all this stuff is the same thing. There's also #580652. Could be, but error code -22 (EINVAL) is not very specific. Out of curiocity, why this feature (VCPU_EVENTS) were backported/applied in the first place (it was in 2.6.32-12)? Isn't it somewhat too buggy having in mind all the above? The svn changelog says: r15572 | maks | 2010-04-27 17:36:34 +0100 (Tue, 27 Apr 2010) | 3 lines backport KVM: x86: Add KVM_GET/SET_VCPU_EVENTS is said to help with troubles on vmsave/restore. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: reassign 604604 to linux-2.6, forcibly merging 599507 604604
Processing commands for cont...@bugs.debian.org: reassign 604604 linux-2.6 2.6.32-27 Bug #604604 [linux-image-2.6.32-5-686] qemu-kvm: vm entry failed with error 0x; kvm_run returned -22 Bug reassigned from package 'linux-image-2.6.32-5-686' to 'linux-2.6'. Bug No longer marked as found in versions linux-2.6/2.6.32-27. Bug #604604 [linux-2.6] qemu-kvm: vm entry failed with error 0x; kvm_run returned -22 There is no source info for the package 'linux-2.6' at version '2.6.32-27' with architecture '' Unable to make a source version for version '2.6.32-27' Bug Marked as found in versions 2.6.32-27. forcemerge 599507 604604 Bug#599507: KVM: SVM: Fix wrong intercept masks on 32 bit Bug#604604: qemu-kvm: vm entry failed with error 0x; kvm_run returned -22 Forcibly Merged 599507 604604. thanks Stopping processing here. Please contact me if you need assistance. -- 599507: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599507 604604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604604 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.12909630372199.transcr...@bugs.debian.org
Bug#605275: EeePC 1005HAG freezes briefly after resuming
On Sun, 2010-11-28 at 16:14 +0100, Maik Zumstrull wrote:
I tried putting the device to sleep after telling the kernel to ignore
USB wakeup requests from the 3G modem, and it works, apparently
without nasty side effects, the 3G still works after. I think
eeepc-acpi-scripts should include a sleep.d hook to do this.
A better solution would be to see if this is fixed upstream, and if so,
backport the fix for the kernel in Squeeze. Would you please try the
kernel in experimental to see if the problem is resolved there?
Okay, I installed the linux-image-2.6.36-trunk-686-bigmem package
(plus linux-base) and moved my sleep.d hook out of the way. Then I
shut down completely and booted into the new kernel.
The system does stay asleep, so that's fixed. However, after waking
up, the system freezes for a few seconds several times. I didn't see
that with 2.6.32 and hook-disabled wakeup. This seems to go away after
a while, it could be one freeze for each USB device while rebinding it
or something. There are reproducibly (I tested three times) four
freezes, and there are four USB-devices other than root hubs.
According to gnokii --monitor once, the 3G device came back up and
registered with the network.
Please provide a kernel log from after wakeup ('dmesg' command) and a
list of the USB devices ('lsusb' command).
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
Processed: tagging 605275
Processing commands for cont...@bugs.debian.org: tags 605275 + moreinfo Bug #605275 [linux-2.6] EeePC 1005HAG freezes briefly after resuming Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 605275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605275 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.12909633233651.transcr...@bugs.debian.org
Bug#604096: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, 2010-11-23 at 12:56 +0100, Lionel Elie Mamane wrote: On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. Ian, can you identify which patch we're currently missing? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#605246: [Debian-eeepc-devel] Bug#605246: Built-in 3G modem can prevent sleep mode
Please can you test whether the attached patch fixes our package of Linux 2.6.32. You will need to rebuild the kernel package by following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. On it. -- 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/aanlkti=y9f2nkof621i+8pxsd=ryzptin1j6qca3q...@mail.gmail.com
Bug#594561: State of the bug 594561
[Please remember to reply-to-all, including the bug address.] On Sun, 2010-11-28 at 10:42 +0100, Wenceslao González-Viñas wrote: Dear Ben, thank you very much! In fact there is some problem: It gives this error: insmod: error inserting 'rt2870sta.ko': -1 Invalid module format There should be some more information in the kernel log; please report that. Actually, first try running 'modprobe crc_ccitt' before the insmod command. Could this be due to that I updated the system. Now, I have kernel: Linux box 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 GNU/Linux [...] I don't think so. Whenever we do make an incompatible change, we increase the 'ABI version' which is the number that appears after the upstream version above, i.e. currently 5. We have not made such a change since package version 2.6.32-12 released in May. It's quite possible that I made a mistake here but it worked for me. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#605284: linux-image-2.6.36-trunk-686-bigmem: Kernel Oops in kerberized NFS4
Package: linux-2.6 Version: 2.6.36-1~experimental.1 Severity: normal Tags: upstream Just this... I use a NFS4-kerberized setup with a debian based NFS server. The Oops happened after having tried to access a NFS share with GNOME nautilus. As my LAN is using IPv6 with the client having the IPv6 privacy extensions enabled, it might have happened after a temporary address became invalid. The share in question is mounted at boot time. On the server there are several lines like that in the kernel log (no idea if this could have its share, too): Nov 28 17:38:30 moah kernel: [176768.913791] RPC: AUTH_GSS upcall timed out. Nov 28 17:38:30 moah kernel: [176768.913794] Please check user daemon is running. This bug report is on an Oops on the corresponding nfs CLIENT. Maybe the server is setup in a wrong way, but I suppose the clients shouldn't oops under any circumstances. If there is further information needed, please contact me. Regards, Jens -- Package-specific info: ** Version: Linux version 2.6.36-trunk-686-bigmem (Debian 2.6.36-1~experimental.1) (m...@stro.at) (gcc version 4.4.5 20100902 (prerelease) (Debian 4.4.4-13) ) #1 SMP Thu Oct 28 14:50:48 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.36-trunk-686-bigmem root=/dev/sda3 ro quiet ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [86841.728706] BUG: unable to handle kernel NULL pointer dereference at 0058 [86841.728856] IP: [fafa0002] rpcauth_refreshcred+0xc/0x120 [sunrpc] [86841.728996] *pdpt = 337ec001 *pde = [86841.729106] Oops: [#1] SMP [86841.729173] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq [86841.729304] Modules linked in: tun kvm_amd kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp nls_utf8 isofs udf ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables cpufreq_stats cpufreq_conservative cpufreq_powersave parport_pc cpufreq_userspace ppdev lp parport sco bridge stp bnep rfcomm l2cap bluetooth rfkill binfmt_misc des_generic cbc rpcsec_gss_krb5 nfsd nfs lockd fscache nfs_acl auth_rpcgss sunrpc fuse ext4 jbd2 crc16 xfs exportfs ext2 it87 hwmon_vid powernow_k8 mperf loop dm_crypt snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel radeon snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi ttm drm_kms_helper snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device drm bas_gigaset gigaset snd kernelcapi crc_ccitt soundcore i2c_piix4 i2c_algo_bit shpchp i2c_core tpm_tis tpm snd_page_alloc button evdev pci_hotplug wmi tpm_bios processor pcspkr k 8temp ext3 jbd mbcache dm_mod sg sr_mod sd_mod cdrom usbhid crc_t10dif ata_generic hid ahci libahci pata_atiixp ohci_hcd libata ehci_hcd r8169 firewire_ohci firewire_core mii usbcore floppy scsi_mod thermal crc_itu_t thermal_sys nls_base [last unloaded: kvm] [86841.731723] [86841.731757] Pid: 4210, comm: 192.168.52.1-ma Not tainted 2.6.36-trunk-686-bigmem #1 GA-MA780G-UD3H/GA-MA780G-UD3H [86841.731931] EIP: 0060:[fafa0002] EFLAGS: 00010296 CPU: 1 [86841.732012] EIP is at rpcauth_refreshcred+0xc/0x120 [sunrpc] [86841.732012] EAX: c96c5400 EBX: c96c5400 ECX: 0006 EDX: faf99423 [86841.732012] ESI: c96c5400 EDI: EBP: ESP: e1aeddd4 [86841.732012] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [86841.732012] Process 192.168.52.1-ma (pid: 4210, ti=e1aec000 task=f22dd280 task.ti=e1aec000) [86841.732012] Stack: [86841.732012] f77c635c c96c5400 f66e4700 0001 000d faf99f91 fbaf350b c96c5400 [86841.732012] 0 c96c5438 faf9f18c f77c6200 c96c5400 e1aede2c [86841.732012] 0 faf9a509 e1aede6c f6627700 e1aede48 faf9a5f0 f6627700 [86841.732012] Call Trace: [86841.732012] [faf99f91] ? call_decode+0x24c/0x5a4 [sunrpc] [86841.732012] [fbaf350b] ? nfs4_xdr_dec_setclientid+0x0/0x138 [nfs] [86841.732012] [faf9f18c] ? __rpc_execute+0x65/0x190 [sunrpc] [86841.732012] [faf9a509] ? rpc_run_task+0xa3/0xa9 [sunrpc] [86841.732012] [faf9a5f0] ? rpc_call_sync+0x3c/0x56 [sunrpc] [86841.732012] [fbaed739] ? nfs4_proc_setclientid+0x167/0x1cc [nfs] [86841.732012] [fbaf57c8] ? nfs4_init_clientid+0x3e/0x8d [nfs] [86841.732012] [fbaf548d] ? nfs4_run_state_manager+0x5d/0x268 [nfs] [86841.732012] [fbaf5430] ? nfs4_run_state_manager+0x0/0x268 [nfs] [86841.732012] [c104a0ee] ? kthread+0x63/0x68 [86841.732012] [c104a08b] ? kthread+0x0/0x68 [86841.732012] [c100897e] ? kernel_thread_helper+0x6/0x10 [86841.732012] Code: 24 08 f0 ff 08 0f 94 c2 84 d2 74 09 8b 44 24 08 e8 47 fd 0a c6 83 c4 10 89 d8 5b 5e 5f 5d c3 55 57 56 89 c6 53 83 ec 1c 8b 68 10 8b 5d 58 85 db 0f 85 cd 00 00 00 0f b7 40 70 8b 56 20 89 c1 83 [86841.735069] EIP: [fafa0002] rpcauth_refreshcred+0xc/0x120 [sunrpc] SS:ESP 0068:e1aeddd4 [86841.735069] CR2: 0058 [86841.763350] ---[ end trace d24945f56a784cde ]--- ** Model information not available **
Bug#604096: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Sun, 2010-11-28 at 16:58 +, Ben Hutchings wrote: On Tue, 2010-11-23 at 12:56 +0100, Lionel Elie Mamane wrote: On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. Ian, can you identify which patch we're currently missing? They are the changes attached to Reinstating GPU fixes to Xen flavour on debian-kernel (1290518224.5514.27.ca...@zakaz.uk.xensource.com) last week. That patch correspond to several separate commits upstream in xen.git: d541daf6b95641953a1eb1938c640a0178bed726 pvops: make pte_flags() go via pvops e1687eae6f85475ebf8579039badafbbe5602014 fb: propagate VM_IO to VMA. c54d5aa10b7a96d182c6dff5160834a0374f9b31 ttm: Change VMA flags if they != to the TTM flags. c57bd3e45674e26c1eb99b65a8ed9db49651aa4a amd64-agp:Use Xen back-door to get page's physical address for AMD64 chipsets. 1e6dcf8d925ac125c780c693f89134532c6e121a intel-agp: Use Xen back-door to get page's physical address for i8[1,3]0 a2395df466453e0bf7ee223c449a29dd3b0ed7f0 intel-agp: Warn when !USE_PCI_DMA_API and inserting bogus bus addresses. 2b6c99e135cd8467f7a5999ee3e9bb877426a8b0 agp-backend: Use Xen back-door to get bus address for scratch page. 0f03e715260f3b715a0f55cd1efd0100d121c27b agp: If _GFP_DMA_32 flag is set enforce pages to be under 4GB under Xen. 597bbe84922e0966a77d05d62857f3553c7aeffe agp: Program the GART with the real physical address under Xen. 534c050301a7c672e3c035034fa6b9c7752f9066 agp: Use Xen back-door to get bus address for legacy code. 9551827190db2d34f106255f0b5bfdc452e85cd8 ttm: Set VM_IO only on pages with TTM_MEMTYPE_FLAG_NEEDS_IOREMAP set. 0675de9b57cf7afa00ceab93a3ca180c085c3f9a ttm: When TTM_PAGE_FLAG_DMA32 allocate pages under 4GB under Xen. but I think they can be considered as a single set for the purposes of resolving these tickets. IIRC the original discussion regarding the omission of these changes from the last Xen pvops merge starts at 20100817192832.ga22...@wavehammer.waldi.eu.org (on debian-kernel back in August). Ian. -- Ian Campbell I feel like a wet parking meter on Darvon! signature.asc Description: This is a digitally signed message part
Bug#605284: linux-image-2.6.36-trunk-686-bigmem: Kernel Oops in kerberized NFS4
On Sun, 2010-11-28 at 18:24 +0100, Jens Reinsberger wrote: Package: linux-2.6 Version: 2.6.36-1~experimental.1 Severity: normal Tags: upstream Just this... I use a NFS4-kerberized setup with a debian based NFS server. The Oops happened after having tried to access a NFS share with GNOME nautilus. As my LAN is using IPv6 with the client having the IPv6 privacy extensions enabled, it might have happened after a temporary address became invalid. The share in question is mounted at boot time. On the server there are several lines like that in the kernel log (no idea if this could have its share, too): Nov 28 17:38:30 moah kernel: [176768.913791] RPC: AUTH_GSS upcall timed out. Nov 28 17:38:30 moah kernel: [176768.913794] Please check user daemon is running. This bug report is on an Oops on the corresponding nfs CLIENT. Maybe the server is setup in a wrong way, but I suppose the clients shouldn't oops under any circumstances. If there is further information needed, please contact me. Please report this upstream at https://bugzilla.kernel.org under product 'File System', component 'NFS'. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: tagging 605284
Processing commands for cont...@bugs.debian.org: tags 605284 + moreinfo Bug #605284 [linux-2.6] linux-image-2.6.36-trunk-686-bigmem: Kernel Oops in kerberized NFS4 Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 605284: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605284 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.129096829227327.transcr...@bugs.debian.org
Bug#605275: EeePC 1005HAG freezes briefly after resuming
On Sun, 2010-11-28 at 18:38 +0100, Maik Zumstrull wrote:
Please provide a kernel log from after wakeup ('dmesg' command) and a
list of the USB devices ('lsusb' command).
Attached.
Well there's nothing obvious there but it looks like the wifi driver
takes some time to start up again after resuming. Could you test
whether this happens if you disable wifi before suspending?
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
Bug#604824: linux-2.6: problems with ata disk interface: temporary freezes
On Sun, 2010-11-28 at 10:21 +0100, Fulvio Ciriaco wrote: Hallo, here it is $(lspci -vn) and $(dmesg) without pci=noacpi from today boot. Quite embarassingly it does not contain any error message. Could you try each of the following options in place of 'pci=noacpi': pci=nomsi lapic noapic and report whether any of them make a difference. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#603229: Scheduler grouping failure; division by zero in select_task_rq_fair
On Sun, 2010-11-28 at 06:00 +0100, Frede Feuerstein wrote: [...] The division by zero appears to be a result of getting bad information from the firmware about the groups of processors. Well, technically a division error always is a result of bad data fed to that division. I rather meant, that this is the point to backtrace the error. Though the bios of the w2100z is known for some problems, the cpus are reported correctly by the bios and it is the latest version (R01-B5-S1). I realise that this same bad information did not previously result in a crash, but I (and the upstream developers) need to know what that information is before we can understand how this can be avoided. Are there any means to gather more information ? Tell me and i shall do it. I think this is now enough information. Ingo, Peter, the output from scheduler domain/group setup was: [0.536554] CPU0 attaching sched-domain: [0.540004] domain 0: span 0-1 level MC [0.548002] groups: 0 1 [0.560003] domain 1: span 0-3 level NODE [0.568002]groups: [0.574179] ERROR: domain-cpu_power not set [0.576002] [0.580002] ERROR: groups don't span domain-span [0.584004] CPU1 attaching sched-domain: [0.588007] domain 0: span 0-1 level MC [0.596002] groups: 1 0 (cpu_power = 1023) [0.612002] ERROR: parent span is not a superset of domain-span [0.616003] domain 1: span 1-3 level CPU [0.624002]groups: 1 (cpu_power = 2048) 2-3 (cpu_power = 2048) [0.644003]domain 2: span 0-3 level NODE [0.652004] groups: 1-3 (cpu_power = 4096) [0.668002] ERROR: domain-cpu_power not set [0.672002] [0.676002] ERROR: groups don't span domain-span [0.680004] CPU2 attaching sched-domain: [0.684003] domain 0: span 2-3 level MC [0.692003] groups: 2 3 [0.704003] domain 1: span 1-3 level CPU [0.712003]groups: 2-3 (cpu_power = 2048) 1 (cpu_power = 2048) [0.736003]domain 2: span 0-3 level NODE [0.744003] groups: 1-3 (cpu_power = 4096) [0.760003] ERROR: domain-cpu_power not set [0.764003] [0.768003] ERROR: groups don't span domain-span [0.772004] CPU3 attaching sched-domain: [0.776003] domain 0: span 2-3 level MC [0.784003] groups: 3 2 [0.794183] domain 1: span 1-3 level CPU [0.83]groups: 2-3 (cpu_power = 2048) 1 (cpu_power = 2048) [0.822183]domain 2: span 0-3 level NODE [0.828003] groups: 1-3 (cpu_power = 4096) [0.842180] ERROR: domain-cpu_power not set [0.844003] [0.848003] ERROR: groups don't span domain-span and the oops is: [0.852154] divide error: [#1] SMP [0.856002] last sysfs file: [0.856002] CPU 1 [0.856002] Modules linked in: [0.856002] Pid: 2, comm: kthreadd Not tainted 2.6.32-5-amd64 #1 W1100z/2100z [0.856002] RIP: 0010:[810416e9] [810416e9] select_task_rq_fair+0x665/0 x800 [0.856002] RSP: 0018:88003fdb7c90 EFLAGS: 00010046 [0.856002] RAX: RBX: RCX: [0.856002] RDX: RSI: 0200 RDI: 0200 [0.856002] RBP: 88004120fd50 R08: R09: 88007f98f0b0 [0.856002] R10: R11: 000252d0 R12: 88007f98f060 [0.856002] R13: 88007f98f070 R14: R15: 00015780 [0.856002] FS: () GS:88004120() knlGS: [0.856002] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [0.856002] CR2: CR3: 01001000 CR4: 06e0 [0.856002] DR0: DR1: DR2: [0.856002] DR3: DR6: 0ff0 DR7: 0400 [0.856002] Process kthreadd (pid: 2, threadinfo 88003fdb6000, task 88003fdc8710) [0.856002] Stack: [0.856002] 00015780 00015780 00015780 00015780 [0.856002] 0 00015780 00015788 00015788 8146c260 [0.856002] 0 0008 88007f9b 880041215780 81317f88 [0.856002] Call Trace: [0.856002] [8104d2b2] ? copy_process+0x1007/0x115f [0.856002] [810475f4] ? select_task_rq+0xb/0x3e [0.856002] [8104b53b] ? wake_up_new_task+0x35/0xf6 [0.856002] [8104d65e] ? do_fork+0x254/0x31e [0.856002] [81041aa9] ? pick_next_task_fair+0xca/0xd6 [0.856002] [8104802b] ? finish_task_switch+0x3a/0xaf [0.856002] [81011b42] ? kernel_thread+0x82/0xe0 [0.856002] [810648c8] ? kthread+0x0/0x81 [0.856002] [81011ba0] ? child_rip+0x0/0x20 [0.856002] [8106488d] ? kthreadd+0xb1/0xec [0.856002] [814f3140] ? early_idt_handler+0x0/0x71 [0.856002] [81011baa] ? child_rip+0xa/0x20 [0.856002] [814f3140] ?
Processed: tagging 603229, bug 603229 is forwarded to linux-ker...@vger.kernel.org
Processing commands for cont...@bugs.debian.org: tags 603229 - moreinfo Bug #603229 [linux-2.6] linux-image-2.6.32-5-amd64: 2.6.32.x-kernel fails to boot, unless acpi=off is set Removed tag(s) moreinfo. forwarded 603229 linux-ker...@vger.kernel.org Bug #603229 [linux-2.6] linux-image-2.6.32-5-amd64: 2.6.32.x-kernel fails to boot, unless acpi=off is set Set Bug forwarded-to-address to 'linux-ker...@vger.kernel.org'. thanks Stopping processing here. Please contact me if you need assistance. -- 603229: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603229 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.129097529725039.transcr...@bugs.debian.org
Bug#594561: State of the bug 594561
Dear Ben, Module crc_ccitt was already loaded. (anyway I removed and loaded again). After insmod rt2870sta it gave same error and kern.log gave: rt2870sta: module has no symbols (stripped?) Thanks and sorry not to cc to bug error address in previous email. Best, Wenceslao Ben Hutchings b...@decadent.org.uk ha escrito: [Please remember to reply-to-all, including the bug address.] On Sun, 2010-11-28 at 10:42 +0100, Wenceslao González-Viñas wrote: Dear Ben, thank you very much! In fact there is some problem: It gives this error: insmod: error inserting 'rt2870sta.ko': -1 Invalid module format There should be some more information in the kernel log; please report that. Actually, first try running 'modprobe crc_ccitt' before the insmod command. Could this be due to that I updated the system. Now, I have kernel: Linux box 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 GNU/Linux [...] I don't think so. Whenever we do make an incompatible change, we increase the 'ABI version' which is the number that appears after the upstream version above, i.e. currently 5. We have not made such a change since package version 2.6.32-12 released in May. It's quite possible that I made a mistake here but it worked for me. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. Este mensaje ha sido enviado desde https://webmail.unav.es -- 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/20101128212040.111324m4u2hvt...@webmail.unav.es
Processed: tagging 604956
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 604956 + pending Bug #604956 [linux-2.6] CVE-2010-3698 fix crashes i386 KVM userspace with amd64 kernel Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 604956: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604956 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.129097591527565.transcr...@bugs.debian.org
Bug#604459: 604459 more info
On Wed, 2010-11-24 at 06:08 -0700, Nicholas Holley wrote: This is possibly the same bug as is listed in the nouveau bug tracker at https://bugs.freedesktop.org/show_bug.cgi?id=27501 The symptoms in post number one are very similar to mine down. It appears this was fixed in Ubuntu kernel 2.6.32-21.31 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546393/comments/119 and later modifications in 2.6.35-22.33 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546393/comments/132 I'm guessing these patches are in the (very) distant future for Debian but during the Squeeze install, there should be a script that detects the affected hardware and reverts to the nv driver or takes other steps to prevent a failed boot. We're sharing DRM driver fixes for 2.6.33[*] with Ubuntu and should pick this up shortly. Sorry we haven't applied it yet. * Yes, our base kernel version for 'squeeze' is 2.6.32, but we updated the whole of the DRM system to 2.6.33. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#604948: IPv6 problems in Squeeze
On Fri, 26 Nov 2010, Kolbjørn Barmen wrote: auto eth0 iface eth0 inet static address 10.10.10.10 gateway 10.10.10.1 netmask 255.255.255.0 iface eth0 inet6 static address 2001:700:0::beaf gateway 2001:700::1 netmask 64 up /sbin/sysctl -w net.ipv6.conf.eth0.autoconf=0 up /sbin/sysctl -w net.ipv6.conf.eth0.accept_ra=0 But this only work _most_ of the time. Every now and then the sysctl lines are not performed quickly enough and due to bad luck the server also picks up autoconf address and router announcement, ending up with double set of addresses and non-static default route. How about using pre-up? Wouldn't that always work? Certainly should. I remember having played with pre-up, but do not remember why I ended up with up instead. I have played around with this over the weekend, and using pre-up is just as unreliable as using up , the result is the same, every now and then machines comes up with autoconfigured address and routes. The only reliable way is to use kernel parameters ipv6.disable_ipv6=1 ipv6.autoconf=0 and then configure things manually in /etc/sysctl.d/ipv6.conf accordingly: net.ipv6.conf.default.autoconf=0 net.ipv6.conf.default.accept_ra=0 net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.all.autoconf=0 net.ipv6.conf.all.accept_ra=0 net.ipv6.conf.lo.disable_ipv6=0 I really find this entire issue most inconvenient, and the only _proper_ solution would be to have autoconf/accept_ra by default off in the kernel itself, and then let the distros/users enable it with sysctl, which is pretty darn easy to do, compared to what's needed for static setups now. But I already lost that battle last year, allthough it did lead to the kernel module options we have now :P Ah well, as IPv6 becomes more and more mandatory, I suppose others will find themselves in the same situation as we are, there will be outcry, and attitudes will hopefulle change. -- Kolbjørn Barmen UNINETT Driftsenter -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1011282204090.6...@hpsmurf.kolla.no
Bug#594561: State of the bug 594561
On Sun, 2010-11-28 at 21:20 +0100, Wenceslao González-Viñas wrote: Dear Ben, Module crc_ccitt was already loaded. (anyway I removed and loaded again). After insmod rt2870sta it gave same error and kern.log gave: rt2870sta: module has no symbols (stripped?) Sorry, I ran 'strip' on this file to remove unnecessary data. I forgot that it removes too much from kernel modules. I've put a fixed version up at the same URL. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594561: State of the bug 594561
Here it is the output of dmesg (attached). Best, Wenceslao Ben Hutchings b...@decadent.org.uk ha escrito: On Sun, 2010-11-28 at 21:20 +0100, Wenceslao González-Viñas wrote: Dear Ben, Module crc_ccitt was already loaded. (anyway I removed and loaded again). After insmod rt2870sta it gave same error and kern.log gave: rt2870sta: module has no symbols (stripped?) Sorry, I ran 'strip' on this file to remove unnecessary data. I forgot that it removes too much from kernel modules. I've put a fixed version up at the same URL. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. Este mensaje ha sido enviado desde https://webmail.unav.es [ 4685.815040] rt2870sta: module is from the staging directory, the quality is unknown, you have been warned. [ 4685.821411] rtusb init --- [ 4685.821655] === pAd = c9001149c000, size = 502256 === [ 4685.821658] -- RTMPAllocAdapterBlock, Status=0 [ 4685.823263] usbcore: registered new interface driver rt2870 [ 4685.839920] usb 1-8: firmware: requesting rt3070.bin [ 4686.112855] -- RTMPAllocTxRxRingMemory, Status=0 [ 4686.114489] --RTUSBVenderReset [ 4686.114614] --RTUSBVenderReset [ 4686.393575] 1. Phy Mode = 0 [ 4686.393579] 2. Phy Mode = 0 [ 4686.393582] NVM is Efuse and its size =2d[2d0-2fc] [ 4686.405449] [ 4686.405450] Block 0:3070 0101 2200 a72d [ 4686.407946] Block 0:ddfb [ 4686.410571] Block 1: 0511 0002 [ 4686.413195] Block 1: 0110 0330 [ 4686.415695] Block 2: 0005 [ 4686.418194] Block 2: [ 4686.420694] Block 3: 0707 0707 0707 [ 4686.423194] Block 3:0707 0707 0707 0707 [ 4686.425695] Block 4: [ 4686.428195] Block 4: c5ff [ 4686.430693] Block 5:a5b5 627a 3a50 012a [ 4686.433193] Block 5: [ 4686.435693] Block 6: [ 4686.438192] Block 6: [ 4686.440692] Block 7: 6688 6688 [ 4686.443191] Block 7: 6688 6688 [ 4686.445692] Block 8:0112 0200 4000 [ 4686.448192] Block 8:083a a701 0101 0201 [ 4686.450690] Block 9:0103 060a 0200 [ 4686.453190] Block 9:4000 0001 0209 0043 [ 4686.455690] Block a:0101 8000 09e1 0004 [ 4686.458189] Block a:0700 05ff 0507 [ 4686.460689] Block b:0281 0200 0700 0105 [ 4686.463188] Block b:0002 0002 0507 0202 [ 4686.465688] Block c:0200 0700 0305 0002 [ 4686.468189] Block c:0002 0507 0204 0200 [ 4686.470687] Block d:0700 0505 0002 0002 [ 4686.473187] Block d:0507 0206 0200 [ 4686.475686] Block e:6152 696c 6b6e 2020 [ 4686.478185] Block e:6957 6572 656c 7373 [ 4686.480686] Block f:3120 6e31 2020 2020 [ 4686.483185] Block f:2e31 3030 [ 4686.485685] Block 10:0112 0200 4000 [ 4686.488186] Block 10:148f 3070 0001 0706 [ 4686.490684] Block 11:0108 060a 0200 [ 4686.493184] Block 11:4000 0001 0209 0020 [ 4686.495684] Block 12:0101 8000 09e1 0004 [ 4686.498182] Block 12:0200 0608 0a50 0507 [ 4686.500682] Block 13:0281 0200 0700 0105 [ 4686.503182] Block 13:0002 0002 [ 4686.505682] Block 14: [ 4686.508182] Block 14: [ 4686.510681] Block 15: [ 4686.513181] Block 15: [ 4686.515681] Block 16: 003f [ 4686.518305] Block 16: [ 4686.520805] Block 17:6000 a270 a2ff 7060 [ 4686.523305] Block 17:ffa2 ffa2 [ 4686.525805] Block 18:0304 0409 [ 4686.528305] Block 18: [ 4686.530803] Block 19: [ 4686.533303] Block 19: [ 4686.535803] Block 1a: [ 4686.538302] Block 1a: [ 4686.540802] Block 1b: [ 4686.543302] Block 1b: [ 4686.545802] Block 1c: [ 4686.548302] Block 1c: [ 4686.550801] Block 1d: [ 4686.553300] Block 1d: [ 4686.555800] Block 1e:030e 0052 0061 006c [ 4686.558549] Block 1e:0069 006e 006b [ 4686.561049] Block 1f:031e 0038 0030 0032 [ 4686.563548] Block 1f:002e 0031 0031 0020 [ 4686.566048] Block 20:006e 0020 0057 004c [ 4686.568549] Block 20:0041 004e [ 4686.571047] Block 21:0304 0409 [ 4686.573547] Block 21: [ 4686.576050] Block 22: 0308 0031 002e [ 4686.578546] Block 22:0030 [ 4686.581046] Block 23: [ 4686.583545] Block 23: [ 4686.586046] Block 24: [ 4686.588546] Block 24: [ 4686.591044] Block 25: [ 4686.593545] Block 25: [ 4686.596048] Block 26: [ 4686.598543] Block 26: [ 4686.601043] Block 27: [ 4686.603542] Block 27: [ 4686.606042] Block 28:
Bug#604755: [Fwd: Bug#604755: perf timechart: segfault in perf_session__process_events]
Forwarded Message From: Jonathan Nieder jrnie...@gmail.com Reply-to: Jonathan Nieder jrnie...@gmail.com, 604...@bugs.debian.org To: sub...@bugs.debian.org Subject: Bug#604755: perf timechart: segfault in perf_session__process_events Date: Tue, 23 Nov 2010 21:59:45 -0600 Package: linux-tools-2.6.36 Version: 2.6.36-1~experimental.1 Tags: upstream Can't seem to get perf timechart working. $ uname -r 2.6.36-trunk-686 # perf timechart record echo hi hi [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.079 MB perf.data (~3471 samples) ] # chmod a+r perf.data $ gdb --args perf_2.6.36 timechart [...] (gdb) run Starting program: /usr/bin/perf_2.6.36 timechart [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x08061969 in ?? () (gdb) bt #0 0x08061969 in ?? () #1 0x0808998e in ?? () #2 0x080888a6 in ?? () #3 0x080894b8 in __perf_session__process_events () #4 0x08089890 in perf_session__process_events () #5 0x08060041 in cmd_timechart () #6 0x0805210e in ?? () #7 0x080527cd in main () Also was reproducible with upstream linux and perf 2.6.37-rc3. Valgrind trace (source line numbers refer to v2.6.37-rc3): Invalid read of size 4 at 0x805B5C1: process_sample_event (builtin-timechart.c:505) by 0x808654D: process_finished_round (session.c:410) by 0x8085CF5: perf_session__process_event (session.c:633) by 0x808732F: __perf_session__process_events (session.c:827) by 0x80875CF: perf_session__process_events (session.c:867) by 0x805BDE0: cmd_timechart (builtin-timechart.c:949) by 0x804CCED: run_builtin (perf.c:286) by 0x804D47E: main (perf.c:357) Address 0x5416558 is 8 bytes after a block of size 72 alloc'd at 0x4023F50: malloc (vg_replace_malloc.c:236) by 0x8085EFA: perf_session__process_event (session.c:553) by 0x808732F: __perf_session__process_events (session.c:827) by 0x80875CF: perf_session__process_events (session.c:867) by 0x805BDE0: cmd_timechart (builtin-timechart.c:949) by 0x804CCED: run_builtin (perf.c:286) by 0x804D47E: main (perf.c:357) Is this a known problem? Where should it be reported? (Ooh, this time it wrote a timechart before segfaulting! Apparently v2.6.37-rc3 userspace + debian 2.6.36 kernel is the recipe for success...) Ciao, Jonathan signature.asc Description: This is a digitally signed message part
Processed: bug 604755 is forwarded to linux-ker...@vger.kernel.org
Processing commands for cont...@bugs.debian.org: forwarded 604755 linux-ker...@vger.kernel.org Bug #604755 [linux-tools-2.6.36] perf timechart: segfault in perf_session__process_events Set Bug forwarded-to-address to 'linux-ker...@vger.kernel.org'. thanks Stopping processing here. Please contact me if you need assistance. -- 604755: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604755 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.129098018417384.transcr...@bugs.debian.org
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Sun, 28 Nov 2010 04:18:25 + Ben Hutchings b...@debian.org wrote: On Sun, 2010-11-28 at 08:28 +1100, Neil Brown wrote: The fix I would recommend for 2.6.26 is to add if (q-merge_bvec_fn) rs-max_phys_segments = 1; to dm_set_device_limits. Though the redhat one is probably adequate. If you really need an upstream fix, you will need to chase upstream to apply one :-( I won't do that myself - as you can see, I don't really understand the issue fully. Is that fix also valid (modulo renaming of max_phys_segments) for later versions? Yes. For current mainline it would look like replacing if (q-merge_bvec_fn !ti-type-merge) limits-max_sectors = min_not_zero(limits-max_sectors, (unsigned int) (PAGE_SIZE 9)); with if (q-merge_bvec_fn !ti-type-merge) limits-max_segments = 1; (the test on -type-merge is important and applies to 2.6.26 as well). NeilBrown signature.asc Description: PGP signature
Bug#605246: [Debian-eeepc-devel] Bug#605246: Built-in 3G modem can prevent sleep mode
Please can you test whether the attached patch fixes our package of Linux 2.6.32. The system goes to sleep and doesn't immediately wake up. Good. There are no freezes as in #605275. Wifi comes back up. 3G needs to be left alone for a moment (immediate gnokii --monitor once fails), but does come back (second attempt usually works). -- 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/aanlktinojhvjdgvanct4+z8a743dquu3jzpmrp87v...@mail.gmail.com
Bug#605335: nfs-kernel-server: IP address wildcards don't work when avahi-daemon is running
Package: nfs-kernel-server Version: 1:1.2.2-4 Severity: important I just installed avahi-daemon on my server, and after I had restarted nfs- kernel-server I was no longer able to mount my nfs drives. (it would give me access denied errors) After trying some different things, I had found out that the problem was with using wildcards for IP addresses. (example: 192.168.*.*) I had one export with an exact IP address, which worked fine, but the wildcard addresses gave access denied errors. When I stopped avahi-daemon and restarted nfs-kernel-server I was able to connect again. I was able to work around this by adding another export with *.local as the wildcard, but that isn't as safe as using IP addresses. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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/bash -- 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/20101128230729.3798.99078.report...@localhost.localdomain
Bug#605275: EeePC 1005HAG freezes briefly after resuming
Well there's nothing obvious there but it looks like the wifi driver takes some time to start up again after resuming. Could you test whether this happens if you disable wifi before suspending? Doesn't help, the freezes are still there. I used the Fn+F2 shortcut to disconnect. That leaves the wifi-related modules loaded. I then tried again after rmmoding all wifi-related modules I could find. Still freezes. -- 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/aanlktin=wh0yppr9xaxucyhqch9+8qko0wh+uuskf...@mail.gmail.com
Bug#605335: marked as done (nfs-kernel-server: IP address wildcards don't work when avahi-daemon is running)
Your message dated Sun, 28 Nov 2010 23:20:11 + with message-id 1290986411.3292.360.ca...@localhost and subject line Re: Bug#605335: nfs-kernel-server: IP address wildcards don't work when avahi-daemon is running has caused the Debian Bug report #605335, regarding nfs-kernel-server: IP address wildcards don't work when avahi-daemon is running 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.) -- 605335: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605335 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: nfs-kernel-server Version: 1:1.2.2-4 Severity: important I just installed avahi-daemon on my server, and after I had restarted nfs- kernel-server I was no longer able to mount my nfs drives. (it would give me access denied errors) After trying some different things, I had found out that the problem was with using wildcards for IP addresses. (example: 192.168.*.*) I had one export with an exact IP address, which worked fine, but the wildcard addresses gave access denied errors. When I stopped avahi-daemon and restarted nfs-kernel-server I was able to connect again. I was able to work around this by adding another export with *.local as the wildcard, but that isn't as safe as using IP addresses. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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/bash ---End Message--- ---BeginMessage--- On Sun, 2010-11-28 at 15:07 -0800, Aaron Barany wrote: Package: nfs-kernel-server Version: 1:1.2.2-4 Severity: important I just installed avahi-daemon on my server, and after I had restarted nfs- kernel-server I was no longer able to mount my nfs drives. (it would give me access denied errors) After trying some different things, I had found out that the problem was with using wildcards for IP addresses. (example: 192.168.*.*) I had one export with an exact IP address, which worked fine, but the wildcard addresses gave access denied errors. When I stopped avahi-daemon and restarted nfs-kernel-server I was able to connect again. I was able to work around this by adding another export with *.local as the wildcard, but that isn't as safe as using IP addresses. This is not a bug. The manual page exports(5) says that [w]ildcard characters generally do not work on IP addresses, though they may work by accident when reverse DNS lookups fail. avahi's multicast DNS service presumably causes reverse DNS lookups for the local network to succeed when they did not before. The correct syntax is address/netmask, e.g. 192.168.0.0/16. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part ---End Message---
Processed: tagging 605246
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 605246 + pending Bug #605246 [linux-2.6] Built-in 3G modem can prevent sleep mode Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 605246: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605246 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.129098698611238.transcr...@bugs.debian.org
Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888
On Sat, 27 Nov 2010 21:53:39 + Ben Hutchings b...@decadent.org.uk wrote: On Wed, 2010-11-24 at 19:48 +0100, Ivan Sergio Borgonovo wrote: [...] I don't know how to help further to increase the chances that squeeze will have support for these controllers. If you could point me to some instructions I could follow to give you some useful feedback I'll be happy to try. I've applied the upstream changes to add support for the 9240. You can test the result by following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official-vcs. The distribution name to use is 'sid' (all our changes for 'squeeze' are still going via 'sid'). I got it compiled. It is working on my workstation. I hope I'll have a chance to try it on a box with that controller on Tuesday. Can anyone be so kind to point me to another RTFM where I can find clear instruction on how to substitute the kernel into a Debian ISO/cross prepare(sid - squeeze) a Debian install ISO? I tried it before, hybridizing 3.6.32 and .36 and it failed to work... but I'm not sure if it failed because I didn't prepare well the ISO or because the hybridized kernel didn't work. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it -- 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/20101129003213.2224c...@dawn.webthatworks.it
Bug#605275: EeePC 1005HAG freezes briefly after resuming
On Mon, 2010-11-29 at 00:07 +0100, Maik Zumstrull wrote: Well there's nothing obvious there but it looks like the wifi driver takes some time to start up again after resuming. Could you test whether this happens if you disable wifi before suspending? Doesn't help, the freezes are still there. I used the Fn+F2 shortcut to disconnect. That leaves the wifi-related modules loaded. I then tried again after rmmoding all wifi-related modules I could find. Still freezes. OK, let's go with your guess that this is USB-related. Please report this upstream at https://bugzilla.kernel.org under product 'Drivers', component 'USB'. Let us know the bug number or URL so we can track it. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888
On Mon, 2010-11-29 at 00:32 +0100, Ivan Sergio Borgonovo wrote: On Sat, 27 Nov 2010 21:53:39 + Ben Hutchings b...@decadent.org.uk wrote: On Wed, 2010-11-24 at 19:48 +0100, Ivan Sergio Borgonovo wrote: [...] I don't know how to help further to increase the chances that squeeze will have support for these controllers. If you could point me to some instructions I could follow to give you some useful feedback I'll be happy to try. I've applied the upstream changes to add support for the 9240. You can test the result by following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official-vcs. The distribution name to use is 'sid' (all our changes for 'squeeze' are still going via 'sid'). I got it compiled. It is working on my workstation. I hope I'll have a chance to try it on a box with that controller on Tuesday. Can anyone be so kind to point me to another RTFM where I can find clear instruction on how to substitute the kernel into a Debian ISO/cross prepare(sid - squeeze) a Debian install ISO? [...] There are some instructions at http://wiki.debian.org/DebianInstaller/Modify/CustomKernel but I don't know whether they still work. It is *not* sufficient to replace the linux-image package which gets intalled; you also have to update the separate driver udeb package which is used within the installer. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Mon, 2010-11-29 at 09:37 +1100, Neil Brown wrote: On Sun, 28 Nov 2010 04:18:25 + Ben Hutchings b...@debian.org wrote: On Sun, 2010-11-28 at 08:28 +1100, Neil Brown wrote: The fix I would recommend for 2.6.26 is to add if (q-merge_bvec_fn) rs-max_phys_segments = 1; to dm_set_device_limits. Though the redhat one is probably adequate. If you really need an upstream fix, you will need to chase upstream to apply one :-( I won't do that myself - as you can see, I don't really understand the issue fully. Is that fix also valid (modulo renaming of max_phys_segments) for later versions? Yes. For current mainline it would look like replacing if (q-merge_bvec_fn !ti-type-merge) limits-max_sectors = min_not_zero(limits-max_sectors, (unsigned int) (PAGE_SIZE 9)); with if (q-merge_bvec_fn !ti-type-merge) limits-max_segments = 1; (the test on -type-merge is important and applies to 2.6.26 as well). Why is it not necessary to set seg_boundary_mask to PAGE_CACHE_SIZE - 1, as for md devices? Ben. -- Ben Hutchings, Debian Developer and kernel team member signature.asc Description: This is a digitally signed message part
Bug#605275: EeePC 1005HAG freezes briefly after resuming
Please report this upstream at https://bugzilla.kernel.org under product 'Drivers', component 'USB'. Let us know the bug number or URL so we can track it. Reported as: https://bugzilla.kernel.org/show_bug.cgi?id=23962 -- 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/aanlkti=akvl_aluehavyvce-wxuxj=pvzj4td7ocg...@mail.gmail.com
Processed: bug 605275 is forwarded to https://bugzilla.kernel.org/show_bug.cgi?id=23962
Processing commands for cont...@bugs.debian.org: forwarded 605275 https://bugzilla.kernel.org/show_bug.cgi?id=23962 Bug #605275 [linux-2.6] EeePC 1005HAG freezes briefly after resuming Set Bug forwarded-to-address to 'https://bugzilla.kernel.org/show_bug.cgi?id=23962'. thanks Stopping processing here. Please contact me if you need assistance. -- 605275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605275 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.129099011225613.transcr...@bugs.debian.org
Processed: tagging 605275
Processing commands for cont...@bugs.debian.org: tags 605275 - moreinfo Bug #605275 [linux-2.6] EeePC 1005HAG freezes briefly after resuming Removed tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 605275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605275 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.129099011925639.transcr...@bugs.debian.org
Bug#565225: Resume device should be detected when creating initramfs, or not at all
Hi,
I got bitten by this bug as well, similarly to Michael Conner above:
I installed uswsusp to be able to hibernate/resume.
s2disk worked flawlessly, but on booting the system simply did not
bother to resume, booting normally instead.
My analysis:
After digging through the initramfs scripts, I discovered that this is
because on booting resume is only triggered if $resume is set.
As far as I understand, the initramfs takes $resume from the kernel
command line (if set), and from /etc/initramfs-tools/conf.d/resume
otherwise.
In my case /etc/initramfs-tools/conf.d/resume did not exist.
It should have been created by the preinst of initramfs-tools; however
the preinst ( /var/lib/dpkg/info/initramfs-tools.preinst ) uses vol_id:
---snip
# First time install. Can we autodetect the RESUME partition?
if [ -r /proc/swaps ]; then
RESUME=$(tail -n $(($(wc -l /proc/swaps | awk ' { print
$1 } ') - 1)) /proc/swaps | sort -rk3 | head -n 1 | awk ' { print $1 } ')
if command -v vol_id /dev/null 21; then
UUID=$(vol_id -u $RESUME || true)
elif [ -x /lib/udev/vol_id ]; then
UUID=$(/lib/udev/vol_id -u $RESUME || true)
fi
if [ -n $UUID ]; then
RESUME=UUID=$UUID
fi
fi
---snap---
This will always fail, because vol_id is no longer part of Debian (it was
removed from udev for version 146-1, see
/usr/share/doc/udev/changelog.Debian.gz ).
In summary:
* Resume from hibernation will only work if /etc/initramfs-tools/conf.d/resume
sets RESUME
* However, there is no (working) code to write
/etc/initramfs-tools/conf.d/resume, and no documentation explaining that it
needs to be set manually to make resume work
Thus, resume will probably fail to work in most cases.
I believe there are actually several bugs here:
1) The code in the preinst of initramfs-tools to detect the swap partition does
not work, because it uses vol_id.
2) Even if 1) were fixed, there may be cases where the swap partition is
incorrectly detected at installation time, or later changes. So fixing
preinst is not enough.
I agree with bug submitter jidanni that the swap partition should be detected
when building the initramfs, not during preinst.
3) Additionally, I don't quite understand why uswsusp refuses to resume if
$resume is not set (in
/usr/share/initramfs-tools/scripts/local-premount/uswsusp ).
The script does not actually use the value of $resume, it just aborts if it
is not set :-(.
I guess this could be considered a bug in uswsusp; I can report it against
uswsusp if discussion of this bug indicates that this makes sense.
To fix this, I would propose the following:
* Drop the code in initramfs-tools.preinst which tries to write RESUME to
/etc/initramfs-tools/conf.d/resume , which does not work anyway.
* Document (e.g. in /usr/share/doc/initramfs-tools/README.Debian ) that
/etc/initramfs-tools/conf.d/resume can be used to set the resume device.
* When building the initramfs, use the value from
/etc/initramfs-tools/conf.d/resume
if it exists; otherwise try to find it yourself:
- if /etc/uswsusp.conf exists, it probably makes sense to read it (resume
device =)
- otherwise grab the current swap device (the config script from uswsusp
already has code for that)
This is still problematic if there is 1 swap device. Even better probably
would be to use debconf to prompt for the resume device, if this is
practical...
I am willing to help implement / test this, but first I'll wait for some
feedback if I'm even on the right track :-).
Greetings,
S.Leske
--
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/20101129003821.gb15...@localhost
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Mon, 29 Nov 2010 00:08:47 + Ben Hutchings b...@debian.org wrote:
if (q-merge_bvec_fn !ti-type-merge)
limits-max_segments = 1;
(the test on -type-merge is important and applies to 2.6.26 as well).
Why is it not necessary to set seg_boundary_mask to PAGE_CACHE_SIZE - 1,
as for md devices?
Sorry. It is necessary of course. I guess I was being a bit hasty and
forgetting all the details.
if (q-merge_bvec_fn !ti-type-merge) {
limits-max_segments = 1; /* Make sure only one segment in each bio */
limits-seg_boundary_mask = PAGE_CACHE_SIZE-1; /* make sure that
segment is in just one page */
}
NeilBrown
signature.asc
Description: PGP signature
Bug#594561: State of the bug 594561
On Sun, 2010-11-28 at 22:38 +0100, Wenceslao González-Viñas wrote: Here it is the output of dmesg (attached). Sorry, but there's something I missed - there are two different ways of reading the ROM. I have put yet another version at the same URL, which will read the ROM in the other way. Please load it and report the new log messages. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: tagging 604457
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 604457 + pending Bug #604457 [linux-2.6] linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k Bug #461644 [linux-2.6] linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems Added tag(s) pending. Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 604457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604457 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.129099472411461.transcr...@bugs.debian.org
Processed: tagging 604457
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 604457 + pending Bug #604457 [linux-2.6] linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k Bug #461644 [linux-2.6] linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems Ignoring request to alter tags of bug #604457 to the same tags previously set Ignoring request to alter tags of bug #461644 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 604457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604457 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.129099478611672.transcr...@bugs.debian.org
Processed: tagging 604457
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 604457 + pending Bug #604457 [linux-2.6] linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k Bug #461644 [linux-2.6] linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems Ignoring request to alter tags of bug #604457 to the same tags previously set Ignoring request to alter tags of bug #461644 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 604457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604457 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.129099625916379.transcr...@bugs.debian.org
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Mon, 2010-11-29 at 11:48 +1100, Neil Brown wrote:
On Mon, 29 Nov 2010 00:08:47 + Ben Hutchings b...@debian.org wrote:
if (q-merge_bvec_fn !ti-type-merge)
limits-max_segments = 1;
(the test on -type-merge is important and applies to 2.6.26 as well).
Why is it not necessary to set seg_boundary_mask to PAGE_CACHE_SIZE - 1,
as for md devices?
Sorry. It is necessary of course. I guess I was being a bit hasty and
forgetting all the details.
if (q-merge_bvec_fn !ti-type-merge) {
limits-max_segments = 1; /* Make sure only one segment in each bio */
limits-seg_boundary_mask = PAGE_CACHE_SIZE-1; /* make sure that
segment is in just one page */
}
Thanks again. I'll apply this change in Debian and try to get it
upstream if we don't see any regressions.
Ben.
--
Ben Hutchings, Debian Developer and kernel team member
signature.asc
Description: This is a digitally signed message part
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Wed, 2010-11-24 at 17:01 +0100, Wouter D'Haeseleer wrote:
Hi Ben,
I have now successfully compiled the kernel including the patch which
this time applied without problem.
However the original bug is still present with the patch you grabbed
upstream.
For testing purpose I have tried also the patch which is supplied by
redhat and I can confirm that this patch is working without a problem.
So it looks like the patch from Neil Brown does not work for this bug.
The result of my conversation with Neil Brown is that his fix covers
only md devices at the top of a stack whereas the Red Hat patch covers
only dm devices at the top of a stack. We should really be fixing both
in the same way.
Please can you test the attached patch, which covers both dm and md.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
commit a451e30d044e5b29f31d965a32d17bf7e97f99b0
Author: Ben Hutchings b...@decadent.org.uk
Date: Sun Nov 28 23:46:46 2010 +
dm: Deal with merge_bvec_fn in component devices better
This is analogous to commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71,
which does the same for md-devices at the top of the stack. The
following explanation is taken from that commit. Thanks to Neil Brown
ne...@suse.de for the advice.
If a component device has a merge_bvec_fn then as we never call it
we must ensure we never need to. Currently this is done by setting
max_sector to 1 PAGE, however this does not stop a bio being created
with several sub-page iovecs that would violate the merge_bvec_fn.
So instead set max_segments to 1 and set the segment boundary to the
same as a page boundary to ensure there is only ever one single-page
segment of IO requested at a time.
This can particularly be an issue when 'xen' is used as it is
known to submit multiple small buffers in a single bio.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
commit 71ff0067805fb917142a745246f7996f3ad86d5b
Author: NeilBrown ne...@suse.de
Date: Mon Mar 8 16:44:38 2010 +1100
md: deal with merge_bvec_fn in component devices better.
commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 upstream.
If a component device has a merge_bvec_fn then as we never call it
we must ensure we never need to. Currently this is done by setting
max_sector to 1 PAGE, however this does not stop a bio being created
with several sub-page iovecs that would violate the merge_bvec_fn.
So instead set max_segments to 1 and set the segment boundary to the
same as a page boundary to ensure there is only ever one single-page
segment of IO requested at a time.
This can particularly be an issue when 'xen' is used as it is
known to submit multiple small buffers in a single bio.
Signed-off-by: NeilBrown ne...@suse.de
Cc: sta...@kernel.org
[bwh: Backport to Linux 2.6.26]
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 94116ea..186445d0 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -506,17 +506,15 @@ void dm_set_device_limits(struct dm_target *ti, struct block_device *bdev)
rs-max_sectors =
min_not_zero(rs-max_sectors, q-max_sectors);
- /* FIXME: Device-Mapper on top of RAID-0 breaks because DM
- *currently doesn't honor MD's merge_bvec_fn routine.
- *In this case, we'll force DM to use PAGE_SIZE or
- *smaller I/O, just to be safe. A better fix is in the
- *works, but add this for the time being so it will at
- *least operate correctly.
+ /*
+ * Since we don't call merge_bvec_fn, we must never risk
+ * violating it, so limit max_phys_segments to 1 lying within
+ * a single page.
*/
- if (q-merge_bvec_fn)
- rs-max_sectors =
- min_not_zero(rs-max_sectors,
- (unsigned int) (PAGE_SIZE 9));
+ if (q-merge_bvec_fn) {
+ rs-max_phys_segments = 1;
+ rs-seg_boundary_mask = PAGE_CACHE_SIZE - 1;
+ }
rs-max_phys_segments =
min_not_zero(rs-max_phys_segments,
diff --git a/drivers/md/linear.c b/drivers/md/linear.c
index ec921f5..fe8508a 100644
--- a/drivers/md/linear.c
+++ b/drivers/md/linear.c
@@ -136,12 +136,14 @@ static linear_conf_t *linear_conf(mddev_t *mddev, int raid_disks)
blk_queue_stack_limits(mddev-queue,
rdev-bdev-bd_disk-queue);
/* as we don't honour merge_bvec_fn, we must never risk
- * violating it, so limit -max_sector to one PAGE, as
- * a one page request is never in violation.
+ * violating it, so limit max_segments to 1 lying within
+ * a single page.
*/
- if (rdev-bdev-bd_disk-queue-merge_bvec_fn
- mddev-queue-max_sectors (PAGE_SIZE9))
- blk_queue_max_sectors(mddev-queue, PAGE_SIZE9);
+ if (rdev-bdev-bd_disk-queue-merge_bvec_fn) {
+ blk_queue_max_phys_segments(mddev-queue, 1);
+ blk_queue_segment_boundary(mddev-queue,
+ PAGE_CACHE_SIZE - 1);
+ }
disk-size = rdev-size;
conf-array_size +=
Processed: tagging 604457
Processing commands for cont...@bugs.debian.org: tags 604457 + patch Bug #604457 [linux-2.6] linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k Bug #461644 [linux-2.6] linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems Ignoring request to alter tags of bug #604457 to the same tags previously set Ignoring request to alter tags of bug #461644 to the same tags previously set thanks Stopping processing here. Please contact me if you need assistance. -- 604457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604457 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.129099851423029.transcr...@bugs.debian.org
Bug#604096: Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Sun, 2010-11-28 at 18:12 +, Ian Campbell wrote: On Sun, 2010-11-28 at 16:58 +, Ben Hutchings wrote: On Tue, 2010-11-23 at 12:56 +0100, Lionel Elie Mamane wrote: On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. Ian, can you identify which patch we're currently missing? They are the changes attached to Reinstating GPU fixes to Xen flavour on debian-kernel (1290518224.5514.27.ca...@zakaz.uk.xensource.com) last week. [...] IIRC the original discussion regarding the omission of these changes from the last Xen pvops merge starts at 20100817192832.ga22...@wavehammer.waldi.eu.org (on debian-kernel back in August). Thanks for the pointers. I agree with Bastian that some of these changes are really quite nasty. Do you and other Xen developers have any plan for how to fix the GART and TTM mapping problems in a cleaner way as Xen dom0 support goes upstream? If there is no such plan then I would rather disable these drivers than make them work temporarily with a hack. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
Excuse me, I have some questions about the firmware patch. 1. I should convert the data into the binary files (.bin). Is it right? 2. Where should I update the firmware files? Is the path the linux-2.6/firmeware? However, according to linux-2.6/firmeware/README.AddingFirmware, I should update they to another repository: git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git Then, how the firmware merge with kernel-2.6? Or, where could I find the firmware in the kernel-2.6 repository? Best Regards, Hayes -Original Message- From: Ben Hutchings [mailto:b...@debian.org] Sent: Saturday, November 27, 2010 7:12 AM To: Francois Romieu; Hayeswang Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org; David Miller; 564...@bugs.debian.org Subject: Re: [PATCH] net/r8169: Correct the ram code for RTL8111D(L) On Fri, 2010-11-26 at 23:49 +0100, Francois Romieu wrote: Ben Hutchings b...@debian.org : On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote: Correct the binary code (Low pass filter DLY_CAP fine tune from uC). The incorrect ram code would make the nic working abnormally. [...] I'm glad you finally acknowledge that this is code rather than simple register initialisation. I am not sure that Hayes is a native english speaker. I am glad to see him posting here. Right. Hayes, by 'you' I meant Realtek, not you personally. If my reply seemed aggressive, I apologise. [...] Below are the changes Debian currently applies in preparation for proper licencing of the firmware. Do you have some scripts to convert the data at hand ? [...] No, it's easy enough to convert a single array by copying it into a C file that dumps it to stdout (assuming the file's byte order is defined to match your own machine). It might be worth adding some sort of header with a version and checksum. Your choice, really. Ben. -- Ben Hutchings, Debian Developer and kernel team member -- 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/ce0f8b12f31d4e82860f4ce06907e...@realtek.com.tw
Re: Bug#605009: serious performance regression with ext4
I did some experimenting, and I figured out what was going on. You're
right, (c) doesn't quite work, because delayed allocation meant that
the writeout didn't take place until the fsync() for each file
happened. I didn't see this at first; my apologies.
However, this *does* work:
extract(a);
sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE);
extract(b.dpkg-new);
sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WRITE);
extract(c.dpkg-new);
sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WRITE);
sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
fdatasync(a);
fdatasync(b.dpkg-new);
fdatasync(c.dpkg-new);
rename(b.dpkg-new, b);
rename(c.dpkg-new, c);
This assumes that files b and c existed beforehand, but a is a new file.
What's going on here? sync_file_range() is a Linux specific system
call that has been around for a while. It allows program to control
when writeback happens in a very low-level fashion. The first set of
sync_file_range() system calls causes the system to start writing back
each file once it has finished being extracted. It doesn't actually
wait for the write to finish; it just starts the writeback.
The second series of sync_file_range() calls, with the operation
SYNC_FILE_RANGE_WAIT_BEFORE, will block until the previously initiated
writeback has completed. This basically ensures that the delayed
allocation has been resolved; that is, the data blocks have been
allocated and written, and the inode updated (in memory), but not
necessarily pushed out to disk.
The fdatasync() call will actually force the inode to disk. In the
case of the ext4 file system, the first fdatasync() will actually push
all of the inodes to disk, and all of the subsequent fdatasync() calls
are in fact no-ops (assuming that files 'a', 'b', and 'c' are all on
the same file system). But what it means is that it minimizes the
number of (heavyweight) jbd2 commits to a minimum.
It uses a linux-specific system call --- sync_file_range --- but the
result should be faster performance across the board for all file
systems. So I don't consider this an ext4-specific hack, although it
probably does makes things faster for ext4 more than any other file
system.
I've attached the program I used to test and prove this mechanism, as
well as the kernel tracepoint script I used to debug why (c) wasn't
working, which might be of interest to folks on debian-kernel.
Basically it's a demonstration of how cool ftrace is. :-)
But using this program on a file system composed of a 5400rpm laptop
drive running LVM and LUKS, I get:
mass-sync-tester -d:dpkg current: time: 0.83/ 0.01/ 0.00
versus
mass-sync-tester -n:dpkg fixed: time: 0.07/ 0.00/ 0.01
- Ted
/*
* Mass sync tester
*/
#define _GNU_SOURCE
#include stdio.h
#include unistd.h
#include stdlib.h
#include sys/types.h
#include sys/time.h
#include sys/stat.h
#include fcntl.h
#include sys/resource.h
#include getopt.h
#include errno.h
#include string.h
void write_file(const char *name, int sync, int sync_range)
{
int fd, i, ret;
char buf[1024];
fd = open(name, O_WRONLY|O_TRUNC|O_CREAT, 0666);
if (fd 0) {
fprintf(stderr, open(%s) in write_file: %s\n,
name, strerror(errno));
exit(1);
}
memset(buf, 0, sizeof(buf));
for (i=0; i 16; i++) {
ret = write(fd, buf, sizeof(buf));
if (ret 0) {
fprintf(stderr, writing %s: %s\n,
name, strerror(errno));
exit(1);
}
}
if (sync) {
ret = fsync(fd);
if (ret 0) {
fprintf(stderr, fsyncing %s in write_file: %s\n,
name, strerror(errno));
exit(1);
}
}
if (sync_range) {
ret = sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WRITE);
if (ret 0) {
fprintf(stderr, sync_file_range %s in write_file: %s\n,
name, strerror(errno));
exit(1);
}
}
ret = close(fd);
if (ret 0) {
fprintf(stderr, closing %s in write_file: %s\n,
name, strerror(errno));
exit(1);
}
}
void rename_file(const char *src, const char *dest)
{
int ret;
ret = rename(src, dest);
if (ret) {
fprintf(stderr, renaming %s to %s: %s\n, src, dest,
strerror(errno));
exit(1);
}
}
void sync_file(const char *name)
{
int fd, i, ret;
fd = open(name, O_RDONLY|O_NOATIME, 0666);
if (fd 0) {
fprintf(stderr, open(%s) in sync_file: %s\n,
name, strerror(errno));
exit(1);
}
ret = fsync(fd);
if (ret 0) {
fprintf(stderr, fsyncing %s in sync_file: %s\n,
name, strerror(errno));
exit(1);
}
ret = close(fd);
if (ret 0) {
fprintf(stderr, closing %s in sync_file: %s\n,
name, strerror(errno));
exit(1);
}
}
void datasync_file(const char *name)
{
int fd, i, ret;
fd = open(name, O_RDONLY|O_NOATIME, 0666);
if (fd 0) {
fprintf(stderr, open(%s) in datasync_file: %s\n,
name, strerror(errno));
exit(1);
}
ret = fdatasync(fd);
if (ret 0) {
fprintf(stderr,
Re: Bug#605009: serious performance regression with ext4
(pruned cc list) Guillem Jover wrote: Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) instead, skimming over the kernel source seems to indicate it might end up doing more or less the same thing but in a portable way? Probably a silly question, but what does The specified data will not be accessed in the near future have to do with preventing delayed allocation? Put another way: if this works now, is it likely to continue to work? -- 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/20101129062458.ga5...@burratino
Re: Bug#605009: serious performance regression with ext4
Hi Ted! On Sun, 2010-11-28 at 23:11:52 -0500, Ted Ts'o wrote: I did some experimenting, and I figured out what was going on. You're right, (c) doesn't quite work, because delayed allocation meant that the writeout didn't take place until the fsync() for each file happened. I didn't see this at first; my apologies. Thanks for the analysis. However, this *does* work: extract(a); sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE); extract(b.dpkg-new); sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WRITE); extract(c.dpkg-new); sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WRITE); The man page and the kernel sources seem to indicate this might block depending on the size of the request queue? sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); fdatasync(a); fdatasync(b.dpkg-new); fdatasync(c.dpkg-new); rename(b.dpkg-new, b); rename(c.dpkg-new, c); What's going on here? sync_file_range() is a Linux specific system call that has been around for a while. It allows program to control when writeback happens in a very low-level fashion. The first set of sync_file_range() system calls causes the system to start writing back each file once it has finished being extracted. It doesn't actually wait for the write to finish; it just starts the writeback. Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) instead, skimming over the kernel source seems to indicate it might end up doing more or less the same thing but in a portable way? Could someone with ext4/btrfs/xfs/etc test w/ and w/o the attached patch against dpkg? thanks, guillem diff --git a/src/archives.c b/src/archives.c index a2cba6a..a94096f 100644 --- a/src/archives.c +++ b/src/archives.c @@ -683,6 +683,9 @@ tarobject(void *ctx, struct tar_entry *ti) _(backend dpkg-deb during `%.255s'), path_quote_filename(fnamebuf, ti-name, 256)); } + +posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED); + r = ti-size % TARBLKSZ; if (r 0) if (safe_read(tc-backendpipe, databuf, TARBLKSZ - r) == -1)
[RFC/PATCH 0/4] Re: Bug#605009: serious performance regression with ext4
Hi Guillem, Here are some rough patches implementing Ted's suggestions: Ted Ts'o wrote: extract(a); sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE); extract(b.dpkg-new); sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WRITE); extract(c.dpkg-new); sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WRITE); sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); sync_file_range(fd.b, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); sync_file_range(fd.c, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE); fdatasync(a); fdatasync(b.dpkg-new); fdatasync(c.dpkg-new); rename(b.dpkg-new, b); rename(c.dpkg-new, c); Exceptions to what Ted did: this does not special-case new files and it intersperses fdatasync and rename. If that matters I'd be interested to learn that. Results (on ext4) suggest that patches 1 and 4 matter and the rest are within noise. Timings are rough; sometimes replicates vary by as much as a second. Numbers are cold cache (i.e., after running sync and echo 3.../drop_caches), best of 3, dpkg --install python2.7 and python2.7-minimal. before: 5.73user 1.62system 0:33.84elapsed 21%CPU (0avgtext+0avgdata 89968maxresident)k 0inputs+0outputs (0major+46962minor)pagefaults 0swaps patch 1 (use SYNC_FILE_RANGE_WRITE): 5.64user 1.69system 0:10.47elapsed 69%CPU (0avgtext+0avgdata 9maxresident)k 0inputs+0outputs (0major+46948minor)pagefaults 0swaps patch 1+2 (use SYNC_FILE_RANGE_WAIT_BEFORE): 5.48user 1.61system 0:10.43elapsed 70%CPU (0avgtext+0avgdata 9maxresident)k 0inputs+0outputs (0major+46958minor)pagefaults 0swaps patch 1+2+3 (delay first fsync): 5.63user 1.66system 0:10.45elapsed 70%CPU (0avgtext+0avgdata 89984maxresident)k 0inputs+0outputs (0major+46966minor)pagefaults 0swaps patch 1+2+3+4 (use fdatasync): 5.65user 1.60system 0:10.24elapsed 71%CPU (0avgtext+0avgdata 90016maxresident)k 0inputs+0outputs (0major+46977minor)pagefaults 0swaps Jonathan Nieder (4): dpkg: On Linux initiate writeback of unpacked files ASAP dpkg: On Linux finish writeback before fsync dpkg: Write back all files before first fsync dpkg: Use fdatasync instead of fsync src/archives.c | 50 +- 1 files changed, 49 insertions(+), 1 deletions(-) -- 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/20101129064825.ga6...@burratino
[PATCH 1/4] dpkg: On Linux initiate writeback of unpacked files ASAP
To avoid performance degradation on filesystems with allocate on
flush semantics (like xfs, ubifs, hfs+, and ext4 without nodelalloc),
start writing back each file once it has finished being extracted.
This doesn't actually wait for the write to finish; it just starts
the writeback.
The sync_file_range call has been available since Linux 2.6.17.
On non-Linux systems we can skip it.
Suggested-by: Ted Ts'o ty...@mit.edu
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
src/archives.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/src/archives.c b/src/archives.c
index d68f9d6..d423f45 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -66,6 +66,20 @@
struct pkginfo *conflictor[MAXCONFLICTORS];
int cflict_index = 0;
+#ifdef SYNC_FILE_RANGE_WRITE
+static int
+begin_writeback(int fd)
+{
+ return sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WRITE);
+}
+#else
+static int
+begin_writeback(int fd)
+{
+ return 0;
+}
+#endif
+
/**
* Special routine to handle partial reads from the tarfile.
*/
@@ -712,6 +726,8 @@ tarobject(void *ctx, struct tar_entry *ti)
ohshite(_(error setting ownership of `%.255s'), ti-name);
if (fchmod(fd, st-mode ~S_IFMT))
ohshite(_(error setting permissions of `%.255s'), ti-name);
+if (begin_writeback(fd))
+ ohshite(_(error beginning writeback of '%.255s'), ti-name);
/* Postpone the fsync, to try to avoid massive I/O degradation. */
if (!fc_unsafe_io)
--
1.7.2.3
--
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/20101129065009.gb6...@burratino
[PATCH 2/4] dpkg: On Linux finish writeback before fsync
The second sync_file_range() call, with the operation
SYNC_FILE_RANGE_WAIT_BEFORE, will block until the previously initiated
writeback has completed. This basically ensures that the delayed
allocation has been resolved; that is, the data blocks have been
allocated and written, and the inode updated (in memory), but not
necessarily pushed out to disk.
Ted suggests finishing writeback for all files before calling fsync,
so later fdatasync can become no-ops, minimizing the number of
(costly) jbd2 commits. And we should probably do that. To make
bisecting for performance easier, let's try this simpler step first.
Suggested-and-explained-by: Ted Ts'o ty...@mit.edu
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
src/archives.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/src/archives.c b/src/archives.c
index d423f45..17e8c89 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -80,6 +80,20 @@ begin_writeback(int fd)
}
#endif
+#ifdef SYNC_FILE_RANGE_WAIT_BEFORE
+static int
+finish_writeback(int fd)
+{
+ return sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
+}
+#else
+static int
+finish_writeback(int fd)
+{
+ return 0;
+}
+#endif
+
/**
* Special routine to handle partial reads from the tarfile.
*/
@@ -900,6 +914,8 @@ tar_deferred_extract(struct fileinlist *files, struct
pkginfo *pkg)
fd = open(fnamenewvb.buf, O_WRONLY);
if (fd 0)
ohshite(_(unable to open '%.255s'), fnamenewvb.buf);
+ if (finish_writeback(fd))
+ohshite(_(unable to write out file '%.255s'), fnamenewvb.buf);
if (fsync(fd))
ohshite(_(unable to sync file '%.255s'), fnamenewvb.buf);
if (close(fd))
--
1.7.2.3
--
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/20101129065111.gc6...@burratino
[PATCH 3/4] dpkg: Write back all files before first fsync
This basically ensures that the delayed allocation has been resolved;
that is, the data blocks have been allocated and written, and the
inode updated (in memory), but not necessarily pushed out to disk.
This way, on ext4 the first fsync() can force the inodes to disk and
the remaining fsync() become almost no-ops.
Suggested-and-explained-by: Ted Ts'o ty...@mit.edu
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
src/archives.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/archives.c b/src/archives.c
index 17e8c89..ed00ce7 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -896,6 +896,24 @@ tar_deferred_extract(struct fileinlist *files, struct
pkginfo *pkg)
const char *usename;
for (cfile = files; cfile; cfile = cfile-next) {
+int fd;
+
+if (!(cfile-namenode-flags fnnf_deferred_fsync))
+ continue;
+usenode = namenodetouse(cfile-namenode, pkg);
+usename = usenode-name + 1; /* Skip the leading '/'. */
+setupfnamevbs(usename);
+
+fd = open(fnamenewvb.buf, O_WRONLY);
+if (fd 0)
+ ohshite(_(unable to open '%.255s'), fnamenewvb.buf);
+if (finish_writeback(fd))
+ ohshite(_(unable to write out file '%.255s'), fnamenewvb.buf);
+if (close(fd))
+ ohshite(_(error closing/writing `%.255s'), fnamenewvb.buf);
+ }
+
+ for (cfile = files; cfile; cfile = cfile-next) {
debug(dbg_eachfile, deferred extract of '%.255s', cfile-namenode-name);
if (!(cfile-namenode-flags fnnf_deferred_rename))
@@ -914,8 +932,6 @@ tar_deferred_extract(struct fileinlist *files, struct
pkginfo *pkg)
fd = open(fnamenewvb.buf, O_WRONLY);
if (fd 0)
ohshite(_(unable to open '%.255s'), fnamenewvb.buf);
- if (finish_writeback(fd))
-ohshite(_(unable to write out file '%.255s'), fnamenewvb.buf);
if (fsync(fd))
ohshite(_(unable to sync file '%.255s'), fnamenewvb.buf);
if (close(fd))
--
1.7.2.3
--
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/20101129065150.gd6...@burratino
[PATCH 4/4] dpkg: Use fdatasync instead of fsync
It is not important to get metadata such as modification time of files right immediately during an upgrade; that can wait for a later sync(). The result is a small but appreciable performance improvement (~1% when testing on a laptop hard disk on ext4). Suggested-by: Ted Ts'o ty...@mit.edu Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- That's the end of the series. I don't like the feeling of voodoo in patches 2 and 3. Is there a simple way to observe their effect? If so, is there a way to achieve that that is easier to explain? src/archives.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/archives.c b/src/archives.c index ed00ce7..7b5b475 100644 --- a/src/archives.c +++ b/src/archives.c @@ -932,7 +932,7 @@ tar_deferred_extract(struct fileinlist *files, struct pkginfo *pkg) fd = open(fnamenewvb.buf, O_WRONLY); if (fd 0) ohshite(_(unable to open '%.255s'), fnamenewvb.buf); - if (fsync(fd)) + if (fdatasync(fd)) ohshite(_(unable to sync file '%.255s'), fnamenewvb.buf); if (close(fd)) ohshite(_(error closing/writing `%.255s'), fnamenewvb.buf); -- 1.7.2.3 -- 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/20101129065558.ge6...@burratino
Re: Bug#605009: serious performance regression with ext4
Hi Guillem, Guillem Jover wrote: Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) instead, skimming over the kernel source seems to indicate it might end up doing more or less the same thing but in a portable way? Could someone with ext4/btrfs/xfs/etc test w/ and w/o the attached patch against dpkg? ext4: yes, this brings the running time down from 34sec to 10.5sec, just like sync_file_range with SYNC_FILE_RANGE_WRITE does. Regards, 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/20101129070141.ga6...@burratino
Bug#594561: State of the bug 594561
Hereby I attach new output, Wenceslao Ben Hutchings b...@decadent.org.uk ha escrito: On Sun, 2010-11-28 at 22:38 +0100, Wenceslao González-Viñas wrote: Here it is the output of dmesg (attached). Sorry, but there's something I missed - there are two different ways of reading the ROM. I have put yet another version at the same URL, which will read the ROM in the other way. Please load it and report the new log messages. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. -- Este mensaje ha sido enviado desde https://webmail.unav.es [ 8695.930670] rt2870sta: module is from the staging directory, the quality is unknown, you have been warned. [ 8695.937697] rtusb init --- [ 8695.937909] === pAd = c90011336000, size = 502256 === [ 8695.937912] -- RTMPAllocAdapterBlock, Status=0 [ 8695.940195] usbcore: registered new interface driver rt2870 [ 8695.948338] usb 1-8: firmware: requesting rt3070.bin [ 8696.220278] -- RTMPAllocTxRxRingMemory, Status=0 [ 8696.221828] --RTUSBVenderReset [ 8696.221953] --RTUSBVenderReset [ 8696.500913] 1. Phy Mode = 0 [ 8696.500917] 2. Phy Mode = 0 [ 8696.500920] NVM is Efuse and its size =2d[2d0-2fc] [ 8696.512787] [ 8696.512789] Block 0:3070 0130 0101 0001 [ 8696.515285] Block 0:2200 2d22 a72d 00a7 [ 8696.517785] Block 1:ddfb 00dd [ 8696.520411] Block 1: [ 8696.522784] Block 2: [ 8696.524783] Block 2: [ 8696.526783] Block 3: [ 8696.528783] Block 3: [ 8696.530783] Block 4: [ 8696.532783] Block 4: [ 8696.534782] Block 5: [ 8696.536782] Block 5: [ 8696.538907] Block 6: [ 8696.541406] Block 6:0511 0205 0002 [ 8696.543906] Block 7: 10ff 0110 0001 [ 8696.546408] Block 7: 3000 0330 0003 [ 8696.548905] Block 8: 00ff [ 8696.551405] Block 8: 0500 0005 [ 8696.553905] Block 9: [ 8696.556404] Block 9: ff00 00ff [ 8696.558904] Block a: 0700 0707 0007 [ 8696.561404] Block a:0707 0707 0707 0007 [ 8696.563903] Block b:0707 0707 0707 0007 [ 8696.566402] Block b:0707 0707 0707 0007 [ 8696.568902] Block c: 00ff [ 8696.571402] Block c: 00ff [ 8696.573902] Block d: 00ff [ 8696.576402] Block d: c5ff 00c5 [ 8696.578901] Block e:a5b5 7aa5 627a 0062 [ 8696.581401] Block e:3a50 2a3a 012a 0001 [ 8696.583901] Block f: 00ff [ 8696.586399] Block f: 00ff [ 8696.588775] Block 10: [ 8696.590774] Block 10: [ 8696.592774] Block 11: [ 8696.594774] Block 11: [ 8696.596773] Block 12: [ 8696.598772] Block 12: [ 8696.600773] Block 13: [ 8696.602773] Block 13: [ 8696.604773] Block 14: [ 8696.606772] Block 14: [ 8696.608771] Block 15: [ 8696.610771] Block 15: [ 8696.612771] Block 16: [ 8696.614771] Block 16: [ 8696.616770] Block 17: [ 8696.618770] Block 17: [ 8696.620894] Block 18: [ 8696.622894] Block 18: [ 8696.624894] Block 19: [ 8696.626894] Block 19: [ 8696.629018] Block 1a: [ 8696.631518] Block 1a: [ 8696.634018] Block 1b: [ 8696.636520] Block 1b: 5500 0055 [ 8696.639017] Block 1c: 88aa 6688 0066 [ 8696.641517] Block 1c: 88aa 6688 0066 [ 8696.644039] Block 1d: 88aa 6688 0066 [ 8696.646516] Block 1d: 88aa 6688 0066 [ 8696.649140] Block 1e: [ 8696.651140] Block 1e: [ 8696.653265] Block 1f: [ 8696.655264] Block 1f: [ 8696.657265] Block 20: [ 8696.659264] Block 20: [ 8696.661264] Block 21: [ 8696.663263] Block 21: [ 8696.665389] Block 22: [ 8696.667388] Block 22: [ 8696.669387] Block 23: [ 8696.671387] Block 23: [ 8696.673387] Block 24: [ 8696.675386] Block 24: [ 8696.677386] Block 25: [ 8696.679386] Block 25: [ 8696.681510] Block 26: [ 8696.683510] Block 26: [ 8696.685510] Block 27: [ 8696.687761] Block 27: [ 8696.689760] Block 28: [ 8696.691759] Block 28: [ 8696.693759] Block 29: [
