Bug#599161: ditto
On Tue, Jan 03, 2012 at 01:42:38PM +, Ian Campbell wrote: On Wed, 2011-12-28 at 01:49 +0100, Josip Rodin wrote: This clock jump by 2999 seconds also happened here, so per: http://old-list-archives.xen.org/archives/html/xen-devel/2011-02/msg01557.html we switched to clocksource=pit in /etc/default/grub's $GRUB_CMDLINE_XEN on the dom0. This seemed to have avoided the problem, but since then, the clock jumps started happening like this: Dec 21 19:42:23 dom0machine kernel: [6034768.658836] Clocksource tsc unstable (delta = -811538856601 ns) In addition, now I checked what the said machine thinks is its clocksource: % cat /sys/devices/system/clocksource/clocksource0/current_clocksource /sys/devices/system/clocksource/clocksource0/available_clocksource xen xen So there's neither pit nor tsc in the available list :) A PV kernel will (or should) always use xen as it's clocksource. This is a PV timesource based around the TSC + correction factors (to account for drift and PCPU migration). The clocksource=pit on the hypervisor command line controls the hypervisor's own timesource and not the dom0 kernels. I'm not sure how you query the hypervisor for its timesource but I guess it'll be in xl dmesg somewhere (Platform timer is ...). Ah, d'oh :) sorry, I wasn't really thinking. The xm dmesg output on HP DL360 machines that we have set to clocksource=pit and that have nevertheless happened to shifted by more than 35996 seconds in at least five incidents in the last six months says: (XEN) Platform timer is 1.193MHz PIT On a couple of FS RX300's that happened not to have clocksource=pit set but had time shift by 2999.69 seconds it's this: (XEN) Platform timer is 14.318MHz HPET Both also show the following message after the time shift: (XEN) Platform timer appears to have unexpectedly wrapped 10 or more times. The message you quote above says *tsc* unstable. Prior to that was the system actually using the tsc clocksource? It really shouldn't have been... Before that message did available_clocksource contain TSC? What about current_clocksource? (Before here ~= on a freshly booted system) The dom0 machines where we set clocksource=pit do see the sole xen clocksource. That didn't stop the time from going awry. On the dom0 machines that don't have the hypervisor fixated on clocksource=pit: * one dom0 that sees both xen and tsc in available_clocksource, but uses xen as current_clocksource. Not sure what it used at the time of the failure in September, probably the same because we didn't touch that. * one that recently failed has: % dmesg | grep unstable [4613030.883101] Clocksource tsc unstable (delta = -2999660301416 ns) % cat /sys/devices/system/clocksource/clocksource0/* xen xen What are your exact hypervisor and kernel command lines? Other than clocksource=pit are you overriding anything else in this regard? Most of the machines now seem to have: GRUB_CMDLINE_LINUX=console=tty0 console=ttyS1,115200n1 elevator=deadline GRUB_CMDLINE_XEN=dom0_mem=512M clocksource=pit cpuidle=0 The machines without clocksource=pit only had dom0_mem=512M for the hypervisor and nothing for the dom0 kernel. Can you press the 's' hypervisor debug key and report the resulting text from dmesg. (press a debug key == xl debug-key s + xl dmesg or press Ctrl-A 3 times on serial then press 's'). (Note that I used xm for both of those commands, I don't have xl.) This is the output on a couple of of the DL360's with clocksource=pit: (XEN) TSC has constant rate, deep Cstates possible, so not reliable, warp=3066 (count=1) (XEN) dom2: mode=0,ofs=0x21e231c896,khz=2333479,inc=1,vtsc count: 10647611967 kernel, 454486411 user (XEN) dom12: mode=0,ofs=0x21a01e68ddeb,khz=2333479,inc=1,vtsc count: 2478607037 kernel, 199833427 user (XEN) dom17: mode=0,ofs=0x8d12c3820bf0b,khz=2333479,inc=1,vtsc count: 918220049 kernel, 56818086 user (XEN) dom18: mode=0,ofs=0x8d1334e2f635f,khz=2333479,inc=1,vtsc count: 4707785417 kernel, 197043637 user (XEN) dom21: mode=0,ofs=0x1004cc1e5bf801,khz=2333479,inc=1,vtsc count: 6386763431 kernel, 166512523 user (XEN) dom22: mode=0,ofs=0x14b5955232a7e1,khz=2333479,inc=1,vtsc count: 2218555643 kernel, 88962103 user (XEN) TSC has constant rate, deep Cstates possible, so not reliable, warp=1715 (count=1) (XEN) dom1: mode=0,ofs=0x149170bd5f,khz=2333479,inc=1,vtsc count: 36234921552 kernel, 294922844 user This is the output on an RX300 without clocksource=pit: (XEN) TSC marked as reliable, warp = 0 (count=2) (XEN) dom1: mode=0,ofs=0x59e046806,khz=2400116,inc=1 (XEN) No domains have emulated TSC And finally this is the output on the odd machine that has tsc as an available clock source: (XEN) TSC marked as reliable, warp = 0 (count=2) (XEN) dom1: mode=0,ofs=0x593b1f9e8,khz=2400190,inc=1 (XEN) dom4: mode=0,ofs=0xf3c77d49e41e6,khz=2400190,inc=1 (XEN) No domains have emulated TSC In the latter case, I've no idea why the domU with the ID 4
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
Hi, On 2011-11-17 00:52:18 +, Ben Hutchings wrote: On Thu, Nov 17, 2011 at 01:29:08AM +0100, Vincent Lefevre wrote: The boot sometimes freezes with the message: waiting for /dev to be fully populated. There was a bug report against udev (bug #606192), which is closed, suggesting a kernel bug if the timeout doesn't occur, which is the case here (with linux-image-3.1.0-1-amd64 3.1.1-1). [...] Please start the kernel without 'quiet' (the GRUB 'rescue mode' entries will do this) so the kernel logs more to the console, and send us the resulting messages (a photograph with readable text is fine). It happened yeaterday, for the first time after I removed the 'quiet' option. There were a few lines about the wifi chipset, and the last message was: iwlagn :0c:00.0: Refused to change power state, currently in D3 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- 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/20120104084848.ga24...@xvii.vinc17.org
Bug#628480: linux-image-2.6.32-5-xen-amd64: System hangs after reboot command
Hi, unfortunately this is bug does not apply to Debian only. MSI has changed some ACPI tables as of BIOS Version 8.7, which lead to this result. You can either downgrade to 8.6 or boot the kernel with acpi=ht. Other common workarounds like 'reboot=b' do not work. Regards, Markus -- 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.deb.2.00.1201041113480.5...@perseus.mschade.de
Bug#628480: linux-image-2.6.32-5-xen-amd64: System hangs after reboot command
On Wed, 2012-01-04 at 11:20 +0100, Markus Schade wrote: Hi, unfortunately this is bug does not apply to Debian only. MSI has changed some ACPI tables as of BIOS Version 8.7, which lead to this result. Does this also affect native kernels? If this issue is with the ACPI interpreter then I would expect so since this is done by the dom0 kernel in a Xen system too. You can either downgrade to 8.6 or boot the kernel with acpi=ht. Other common workarounds like 'reboot=b' do not work. Those are hypervisor or kernel options? Ian. -- Ian Campbell Remember, God could only create the world in 6 days because he didn't have an established user base. -- 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/1325677270.25206.245.ca...@zakaz.uk.xensource.com
Uploading linux-2.6 (3.1.8-1)
I intend to upload linux-2.6 to unstable later this week, once upstream stable update 3.1.8 is released. Linux 3.2 is also likely to be released very soon, but I think we still have some work to do on updating the configuration for it. Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Sometimesleft click don't work
Hello. I have a HP 530 notebook with damaged touchpad that doesn't work mouse's left click. That's OK, it's a hardware problem. Now I'm using an external usb mouse and sometimes its left click also doesn't work. It's necessary restart usbhid module to get it work again. Linux debian 3.1.0-1-amd64 #1 SMP Sun Dec 11 20:36:41 UTC 2011 x86_64 GNU/Linux linux-image-3.1.0-1-amd64 Package: linux-image-3.1.0-1-amd64 Version: 3.1.6-1 Many thanks. William. -- 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/4f045c2c.9030...@gmail.com
Bug#654598: Please enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP
Package: linux-2.6 Hi, Please enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP to allow management of swap in the memory resource controller, a useful addition to CONFIG_CGROUP_MEM_RES_CTLR. Thanks! -- Cedric Dubois -- 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/667697ea-6756-45d6-8c13-b770e36d9...@slider.be
Bug#652678: linux-image-3.1.0-1-amd64: psmouse fails to autodetect Elan touchpad
Hi Ben, thanks for your information; I didn't even look at the code of the patch. After having read your email, I've installed 3.2.0-rc7 from experimental. As you assumed, it correctly identifies my Elan touchpad and the synaptics driver also works as expected. Please close the issue. Thanks again, Andreas Original-Nachricht Datum: Thu, 29 Dec 2011 17:18:46 +0100 Von: Ben Hutchings b...@decadent.org.uk An: Andreas Ames andreas.a...@gmx.de, 652...@bugs.debian.org Betreff: Re: Bug#652678: linux-image-3.1.0-1-amd64: psmouse fails to autodetect Elan touchpad On Mon, 2011-12-19 at 21:32 +0100, Andreas Ames wrote: Package: linux-2.6 Version: 3.1.1-1 Severity: normal Dear Maintainer, the psmouse driver of the referenced kernel fails to recognise the Elan touchpad of my notebook; it reports a Logitech Wheel Mouse instead. Thus I couldn't get the middle button click to work under X (amongst other functions). After applying the patch as referenced in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/681904/comments/64 the driver detects the touchpad as expected. [...] Unfortunately, that patch is just a mess. It has not been sent upstream and is not suitable for Debian. However, there are many changes in v3.2 that appear to add support for some newer firmware/hardware versions. Please could you test version 3.2-rc7 from experimental? Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- 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/20120104220533.211...@gmx.net
Bug#652678: marked as done (linux-image-3.1.0-1-amd64: psmouse fails to autodetect Elan touchpad)
Your message dated Wed, 4 Jan 2012 16:37:33 -0600 with message-id 20120104223733.gd3...@elie.chipublib.org and subject line Re: psmouse fails to autodetect Elan touchpad has caused the Debian Bug report #652678, regarding linux-image-3.1.0-1-amd64: psmouse fails to autodetect Elan touchpad 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.) -- 652678: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652678 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 3.1.1-1 Severity: normal Dear Maintainer, the psmouse driver of the referenced kernel fails to recognise the Elan touchpad of my notebook; it reports a Logitech Wheel Mouse instead. Thus I couldn't get the middle button click to work under X (amongst other functions). After applying the patch as referenced in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/681904/comments/64 the driver detects the touchpad as expected. cheers, aa -- Package-specific info: ** Version: Linux version 3.1.0-1-amd64 (Debian 3.1.1-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 SMP Mon Nov 14 08:02:25 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-amd64 root=UUID=b61405bd-d5ec-4f48-8f06-692aaded5b8f ro video=vesafb:mtrr:3,ywrap vga=792 quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [8.310300] input: WebCam SCB-1100N as /devices/pci:00/:00:13.2/usb2/2-2/2-2:1.0/input/input11 [8.310641] usbcore: registered new interface driver uvcvideo [8.310645] USB Video Class driver (1.1.1) [9.684302] Adding 9751548k swap on /dev/sda7. Priority:-1 extents:1 across:9751548k [9.690319] EXT4-fs (sda5): re-mounted. Opts: (null) [ 10.000650] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro [ 10.109404] loop: module loaded [ 11.050073] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) [ 11.978688] RPC: Registered named UNIX socket transport module. [ 11.978693] RPC: Registered udp transport module. [ 11.978695] RPC: Registered tcp transport module. [ 11.978696] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 12.110026] FS-Cache: Loaded [ 12.141846] FS-Cache: Netfs 'nfs' registered for caching [ 12.153373] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 13.328982] fuse init (API version 7.17) [ 15.100357] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12 [ 17.235458] r8169 :03:00.0: eth0: link down [ 17.236461] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 17.458414] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 20.218850] vgaarb: this pci device is not a vga device [ 20.218877] vgaarb: this pci device is not a vga device [ 20.218890] vgaarb: this pci device is not a vga device [ 20.218902] vgaarb: this pci device is not a vga device [ 20.218915] vgaarb: this pci device is not a vga device [ 20.218930] vgaarb: this pci device is not a vga device [ 20.218943] vgaarb: this pci device is not a vga device [ 20.218956] vgaarb: this pci device is not a vga device [ 20.218968] vgaarb: this pci device is not a vga device [ 20.218981] vgaarb: this pci device is not a vga device [ 20.218993] vgaarb: this pci device is not a vga device [ 20.219006] vgaarb: this pci device is not a vga device [ 20.219018] vgaarb: this pci device is not a vga device [ 20.219030] vgaarb: this pci device is not a vga device [ 20.219042] vgaarb: this pci device is not a vga device [ 20.219054] vgaarb: this pci device is not a vga device [ 20.219067] vgaarb: this pci device is not a vga device [ 20.219079] vgaarb: this pci device is not a vga device [ 20.219091] vgaarb: this pci device is not a vga device [ 20.219104] vgaarb: this pci device is not a vga device [ 20.219116] vgaarb: this pci device is not a vga device [ 20.219127] vgaarb: this pci device is not a vga device [ 20.219139] vgaarb: this pci device is not a vga device [ 20.219151] vgaarb: this pci device is not a vga device [ 20.219163] vgaarb: this pci device is not a vga device [ 20.219176] vgaarb: this pci device is not a vga device [ 20.219187] vgaarb: this pci device is not a vga device [ 20.219200] vgaarb: this pci device is not a vga device [ 20.219221] vgaarb: device changed decodes: PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none [ 20.219240] vgaarb: this pci device is not a vga device [ 20.219254] vgaarb: this pci device is not a vga device [ 20.256343] [fglrx] ATIF
Bug#654206: [PATCH] ext4: Report max_batch_time option correctly
On Mon, Jan 02, 2012 at 02:13:02PM +, Ben Hutchings wrote: Currently the value reported for max_batch_time is really the value of min_batch_time. Reported-by: Russell Coker russ...@coker.com.au Signed-off-by: Ben Hutchings b...@decadent.org.uk Applied, thanks. - Ted -- 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/20120105022310.ga24...@thunk.org
Bug#653179: [rt2x00-users] Fwd: linux-image-3.1.0-1-amd64: Can't switch off WoW option of RT5390 wi-fi card, notebook wakes on wi-fi activity
Well, I tried the following: 1. Installed back preinstalled version of Windows 7 and gave my notebook to guarantee service. They returned it in one day, saying that WoW option were enabled. As I wrote earlier WoW can be managed under Win7 (in properties of Ralink card). 2. I had flashed cracked version of BIOS with unlocked advanced menus. Then I disable Wake on PME (PCI Power Management Enable wake up events). Well, now my notebook do not wakes (and from power off). Maybe installed version of Ralink card is a special modification for HP, or it is capable with some ACPI management? Best, kh 29.12.2011, 00:14, Ivo Van Doorn ivdo...@gmail.com: On Wed, Dec 28, 2011 at 12:09 PM, Gertjan van Wingerde gwinge...@gmail.com wrote: On 12/28/11 08:56, Helmut Schaa wrote: Hi, Am Sonntag, 25. Dezember 2011, 09:07:42 schrieb pol kh: I'd like to be able to manage WoW option on Ralink 5390 on my HP Pavilion dv6-6030er. WoW is enabled by default in BIOS, which is locked by vendor. So I can't switch it off. Using ethtool doesn't help, because driver can't hanlder with WoW. My notebook wakes on wi-fi activity when I'd like it to be asleep. I had sent a bug report to Debian GNU/Linux maintainers and got the following answer (below my bug report is attached): this sounds really strange :). Unfortunately nobody is working on WoW support for rt2x00 currently. Ivo, Gertjan, do we have any information yet how WoW for the ralink devices is supposed to work? Since the WoW framework was already merged AFAIK it might be a trivial thing to add ... No, I've never seen any information about this. A quick look at the Ralink legacy drivers also reveal that these do not contain any code for this, so it will be difficult to add support for this in rt2x00. Even the specsheets don't contain any reference about WoW, so I really can't say anything about it either. Ivo -- 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/680521325738...@web129.yandex.ru
