Re: Random panic in load_balance() with 3.16-rc
Hi Michel, On 25/07/14 02:25, Michel Dänzer wrote: Attached is fair.s from Debian gcc 4.8.3-5. Does that look better? I'm going to try reproducing the problem with a kernel built by that now. It looks like gcc-4.9 Debian package version 4.9.1-2 available in sid/jessie may have already fixed this (though Debian's buildd systems may not have been updated with it yet). If you are able to test with that version and let us know, that would be wonderful. Thank you, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d3ed27.7080...@pyro.eu.org
Re: teach os-prober to recognize OpenBSD
Hi, On 30/06/14 21:12, Martin Pelikan wrote: To access [OpenBSD] ufs, you need to mount it with -o ufstype=44bsd [...] Can something along those lines be included in os-prober? Thanks. Unfortunately this might not work from within the installer because Linux no longer builds a ufs kernel module for d-i. (Support for ufs was being dropped). It may only pick up OpenBSD on the next run of update-grub2 after booting the installed system (where ufs.ko seems to be still available). I think this could also be an inconvenience for systems where GNU/Linux is installed alongside GNU/kFreeBSD. Maybe there is some argument to keep providing a ufs udeb, even if partman doesn't allow to create new ufs partitions or install to existing ones. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b1d77d.7020...@pyro.eu.org
Re: teach os-prober to recognize OpenBSD
On 30/06/14 22:57, Martin Pelikan wrote: Unfortunately this might not work from within the installer because Linux no longer builds a ufs kernel module for d-i. [...] So the question is, since you've made a package used by other distributions, do you care about people running it on them? I imagine Debian does care and might add this if it works. I wasn't disputing that; only whether this feature would work within the Debian GNU/Linux installer. I think this could also be an inconvenience for systems where GNU/Linux is installed alongside GNU/kFreeBSD. Just to clarify, I meant that Linux dropping read-only ufs support in the installer might be an inconvenience. I've never run GNU/kFreeBSD, but I'd say it's very unlikely that it would contain this particular OpenBSD copyright. [...] Certainly not in a kernel image file called /bsd. I think GNU/kFreeBSD would be ufstype=ufs2 rather than 44bsd anyway, so I wonder if mount(8) would fail gracefully in this case. I suspect this os-prober script also wouldn't work on GNU/kFreeBSD for this reason. (There's no ufstype option, so I suspect no way to mount an OpenBSD UFS partition, but I may look into it if I have time). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b1e265.2030...@pyro.eu.org
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On 15/12/13 22:10, Robert Millan wrote:
Perhaps we should just disable Via chipset from sys/dev/random/probe.c.
Would this be a terrible loss for a Technology Preview release?
From reading upstream's Errata Note[0], they have more or less done this
and disabled the hardware providers of /dev/{,u}random in stable/8 and
stable/9 by default.
[0]: http://security.freebsd.org/advisories/FreeBSD-EN-14:01.random.asc
Only the new code in kfreebsd/10 will be able to use the output of those
RNGs safely, probably feeding them into Yarrow as a potential extra
source of 'some' usable additional entropy.
VIA RNGs were enabled in 9.1 kernels, Intel Bull Mountain in 9.2, and
both in 8.4. Thankfully wheezy's 9.0 and 8.3 kernels had not enabled
either of those RNGs yet. Only kernels in jessie/sid (and before that,
experimental) have been potentially affected.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
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/52d5ab5f.10...@pyro.eu.org
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On 14/01/14 22:38, Robert Millan wrote: On 14/01/2014 22:25, Steven Chamberlain wrote: Thankfully wheezy's 9.0 and 8.3 kernels had not enabled either of those RNGs yet. Are you sure? This is from 9.0: Ahh, thanks for double-checking this. You're right, kfreebsd-i386 kernels already supported the RNG in VIA Eden 32-bit CPUs... since 5.3. 9.1 merely adds support for the RNG in Via Nano 64-bit CPUs. Actually, it seems I have kfreebsd-i386 9.0 running on a VIA Eden CPU right now with hardware RNG - should be handy for testing: CPU: VIA Eden Processor 500MHz (498.76-MHz 686-class CPU) Origin = CentaurHauls Id = 0x6d0 Family = 6 Model = d Stepping = 0 Features=0xa7c9bbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CLFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE Features2=0x4181SSE3,EST,TM2,xTPR AMD Features=0x10NX VIA Padlock Features=0xffccRNG,AES,AES-CTR,SHA1,SHA256,RSA There was no tunable to control use of this RNG until r240950 (which went into the 9.2 release). The changelog of when it was MFC'd doesn't specifically mention that, but the original commit r240135 does: http://svnweb.freebsd.org/base?view=revisionamp;revision=240135 Also add the tunables to disable hardware generator even if detected. We could perhaps backport the tunable, then apply the patch for EN-14:01.random as-is; thus disabling the RNG by default but providing a loader tunable to turn it back on. And there was also this ironic snippet: From the Intel whitepapers and articles about Bull Mountain, it seems that we do not need to perform post-processing of RDRAND results, [...] Intel claims that sanitization is performed in hardware. I've no reason to think VIA / Centaur Technology (Taiwanese owned) were participating in the NSA's project BULLRUN, but it's nice that kfreebsd 10 is taking a cautious approach to all hardware RNGs now. In any case, FreeBSD did an extra step of AES whitening on the output of VIA's RNG - which was a nice precaution, especially in case of a hardware defect - though it is still performed on-chip so can't be 100% trusted. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52d5cf86.2060...@pyro.eu.org
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
Hi, On 14/12/13 01:08, Henrique de Moraes Holschuh wrote: Yeah, I think Linux went through similar blindness braindamage sometime ago, but blind trust on rdrand has been fixed for a long time now, and it never trusted any of the other HRNGs (or used them for anything at all without a trip through rng-tools userspace until v3.12). I seem to remember that Ted T'so's committed the fix for this only after the release of Linux 3.2, so I assuemd wheezy's kernels might be still affected? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52ac1eb5.7020...@pyro.eu.org
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On 14/12/13 11:18, Cyril Brulebois wrote: If you're talking about this: | commit c2557a303ab6712bb6e09447df828c557c710ac9 | Author: Theodore Ts'o ty...@mit.edu | Date: Thu Jul 5 10:35:23 2012 -0400 | | random: add new get_random_bytes_arch() function | […] it was backported into 3.2.y, that would be 7f5d5266f8a1f7f54707c15e028f220d329726f4 also known as v3.2.27~51. Ah yes, excellent. Thank you. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#613925: linux-image-3.2.0-4-amd64: reiserfs: deadlock affecting writes, getdents
On 17/07/13 14:02, Steven Chamberlain wrote: On 16/07/13 23:02, Moritz Muehlenhoff wrote: Jeff Mahoney has posted patches in the upstream bug in May: https://bugzilla.kernel.org/show_bug.cgi?id=29162 Are you in a position to test them and provide him with feedback? Yes, I will try those patches over the weekend; Actually it does not seem so simple now. The patchset is large and I've realised it does not all apply against 3.2.x. That complicates my testing, and perhaps the ability to backport it to stable kernels. I think the specific location of this deadlock needs to be identified or at least narrowed down a bit first. (Assuming it is in only one place, which it maybe isn't). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/51ec6dce.9020...@pyro.eu.org
Bug#613925: linux-image-3.2.0-4-amd64: reiserfs: deadlock affecting writes, getdents
# restore affected versions found 613925 3.2.35-2 found 613925 3.2.46-1 thanks Hi Moritz, On 16/07/13 23:02, Moritz Muehlenhoff wrote: Jeff Mahoney has posted patches in the upstream bug in May: https://bugzilla.kernel.org/show_bug.cgi?id=29162 Are you in a position to test them and provide him with feedback? Yes, I will try those patches over the weekend; thanks for pointing them out to me. I think I will be able to tell quickly if it has helped or not. If it really is the same problem, the quickest way I've found to trigger it is using Josm with the Bing Sat overlay enabled. Lots of satellite imagery tiles are downloaded into /tmp. Every few minutes of working seems to trigger this bug, locking up all accesses to /tmp, but it seems to recover by itself after a minute or so. xfce4-terminal is very sensitive to this; trying to display more than ~25 lines of output (like the output of `dmesg` or `ps ax`) freezes the terminal window (it may be trying to write scrollback history in /tmp). But if I pipe output to `less` instead it is fully usable. Other triggers for this seem to be iceweasel sometimes (if there are many, many tabs open) or rarely qjackctl (once every few weeks). Killing the responsible process makes the system immediately responsive again. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/51e695dd.6090...@pyro.eu.org
CVE-2013-2224 RHEL-specific?
Hi, I notice CVE-2013-2224 was marked in the security tracker as affecting only RHEL kernels, but I just wanted to double-check that: The issue was allegedly introduced into RHEL by a backport of a mainline commit, to try to fix CVE-2012-3552: f6d8bd051c391c1c0458a30b2a7abcd939329259 (inet: add RCU protection to inet-opt) But the Debian changelog[0] for 2.6.32-48squeeze3 (aka squeeze2) mentions something similar was done: * inet: add RCU protection to inet-opt (CVE-2012-3552) and the actual same commit was seemingly applied as a patch[1]. [0]: http://anonscm.debian.org/viewvc/kernel/dists/squeeze-security/linux-2.6/debian/changelog?revision=20073view=markup [1]: http://anonscm.debian.org/viewvc/kernel/dists/squeeze-security/linux-2.6/debian/patches/bugfix/all/inet-add-RCU-protection-to-inet-opt.patch?view=markuppathrev=19969 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/51d697d2.8020...@pyro.eu.org
Bug#704988: linux-image-3.2.0-4-amd64: nfsd allocation errors in dmesg
Hi, Good to hear you have a workaround. I've no idea why it's trying to make such large memory allocations, but I have seen it before (since squeeze) with drivers for much older Intel NICs. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5165c823.9010...@pyro.eu.org
Bug#704988: linux-image-3.2.0-4-amd64: nfsd allocation errors in dmesg
Hi, On 08/04/13 14:48, Eli Venter wrote: Apr 4 17:44:28 gdx-ilmn kernel: [ 2694.622587] nfsd: page allocation failure: order:2, mode:0x20 Apr 4 17:44:28 gdx-ilmn kernel: [ 2694.622591] Pid: 3539, comm: nfsd Tainted: GW3.2.0-4-amd64 #1 Debian 3.2.41-2 Increasing the value of sysctl vm.min_free_kbytes may help with this. Maybe try doubling it? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5162ed8e.4060...@pyro.eu.org
Bug#703800: linux-headers-3.2.0-4-common-rt: files missing [3.2.39-2 - 3.2.41-1 regression]
Package: linux-headers-3.2.0-4-common-rt Version: 3.2.41-1 Severity: grave Control: fixed -1 3.2.39-2 Hi Debian Kernel Team, Somehow the latest linux-headers-3.2.0-4-common-rt package contained everything except for the actual headers... linux-headers-3.2.0-4-common-rt_3.2.41-1_amd64.deb drwxr-xr-x root/root 0 2013-03-23 12:45 ./ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/ -rw-r--r-- root/root 53780 2013-03-23 09:37 ./usr/src/linux-headers-3.2.0-4-common-rt/Makefile drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/ -rw-r--r-- root/root 3257 2013-03-20 15:03 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/Makefile_32.cpu -rw-r--r-- root/root 6775 2013-03-20 15:03 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/Makefile -rw-r--r-- root/root 1703 2013-03-20 15:03 ./usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/Makefile.um drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/share/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/share/doc/ drwxr-xr-x root/root 0 2013-03-23 12:45 ./usr/share/doc/linux-headers-3.2.0-4-common-rt/ -rw-r--r-- root/root 2470 2013-02-24 03:53 ./usr/share/doc/linux-headers-3.2.0-4-common-rt/copyright -rw-r--r-- root/root192332 2013-03-23 03:54 ./usr/share/doc/linux-headers-3.2.0-4-common-rt/changelog.Debian.gz lrwxrwxrwx root/root 0 2013-03-23 12:45 ./usr/src/linux-headers-3.2.0-4-common-rt/scripts - ../../lib/linux-kbuild-3.2/scripts Thanks! -- System Information: Debian Release: 6.0.5 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- 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/514e14e0.5040...@pyro.eu.org
Bug#613925: linux-image-3.2.0-4-amd64: reiserfs: deadlock affecting writes, getdents
Control: clone -1 -2 Control: reassign -2 src:linux Control: found -2 linux/3.2.35-2 Control: notfound -2 linux2.6/2.6.32-35 Hi, This bug seems to still exist in the current kernel version for Wheezy. But it is very rare; today it happened after 18 days' uptime, and once before after 30+ days uptime. This is a desktop machine with a single SSD SATA drive with usually only light I/O workload. Today I noticed all my iceweasel and xfce4-terminal windows had frozen. From a virtual terminal, as root, ls /tmp froze (in the getdents syscall) but could be killed. My other reiserfs partitions on the same block device worked fine. My 'master' xfce4-terminal process was in a blocked state and could not be killed. This, and some unreaped xfce4-terminal child processes that I'd tried to kill already, had some open, deleted inodes on /tmp I thought I was going to have to reboot, but just out of curiosity I killed iceweasel (via the 'non-responding window' feature of xfce4 window manager). Immediately my system recovered with /tmp readable/writable again. I think this suggests it was not a hardware issue, but some deadlock between processes doing I/O on reiserfs. Last time this happened to me it was the /var partition rather than /tmp This problem didn't ever occur in many months of using the Squeeze 2.6.32 kernel. [I would miss reiserfs very much. It has provided me with 100% durability for many years and performed well. Even when I once trashed the underlying mdraid on another system, reiserfsck rescued my data]. -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/acidbath-root ro threadirqs rootdelay=5 ** Not tainted ** Kernel log: [1122963.228076] INFO: task xfce4-terminal:28023 blocked for more than 120 seconds. [1122963.228252] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [1122963.228255] xfce4-terminal D 88021fc13780 0 28023 1 0x [1122963.228260] 88002571e3c0 0086 8160d020 [1122963.228265] 00013780 8801b4659fd8 8801b4659fd8 88002571e3c0 [1122963.228268] 88021fffbe00 000181070ad5 0246 c900019bf000 [1122963.228272] Call Trace: [1122963.228312] [a01babc3] ? queue_log_writer+0x7e/0xac [reiserfs] [1122963.228319] [8103f411] ? try_to_wake_up+0x197/0x197 [1122963.228331] [a01bf4ea] ? do_journal_begin_r+0x193/0x252 [reiserfs] [1122963.228337] [811078d7] ? poll_freewait+0x97/0x97 [1122963.228348] [a01bf662] ? journal_begin+0xb9/0xf2 [reiserfs] [1122963.228359] [a01b1a86] ? reiserfs_dirty_inode+0x37/0x74 [reiserfs] [1122963.228363] [811079a5] ? __pollwait+0xce/0xce [1122963.228366] [8104b03a] ? current_fs_time+0x31/0x37 [1122963.228371] [811166b3] ? __mark_inode_dirty+0x22/0x17a [1122963.228375] [8110bcb5] ? file_update_time+0xda/0x105 [1122963.228381] [810b5500] ? __generic_file_aio_write+0x160/0x278 [1122963.228385] [81030a81] ? ptep_set_access_flags+0x39/0x45 [1122963.228389] [810cf113] ? do_wp_page+0x260/0x563 [1122963.228393] [810363d8] ? should_resched+0x5/0x23 [1122963.228397] [810b5675] ? generic_file_aio_write+0x5d/0xb5 [1122963.228402] [810f95d4] ? do_sync_write+0xb4/0xec [1122963.228405] [810363d8] ? should_resched+0x5/0x23 [1122963.228410] [81163995] ? security_file_permission+0x16/0x2d [1122963.228414] [810f9cc5] ? vfs_write+0xa2/0xe9 [1122963.228417] [810f9ea2] ? sys_write+0x45/0x6b [1122963.228423] [81352012] ? system_call_fastpath+0x16/0x1b ** Model information sys_vendor: Hewlett-Packard product_name: HP xw9400 Workstation product_version: chassis_vendor: Hewlett-Packard chassis_version: bios_vendor: Hewlett-Packard bios_version: 786D6 v04.02 board_vendor: Hewlett-Packard board_name: 0A1Ch board_version: D ** Loaded modules: adt7475 hwmon_vid snd_ice1712 snd_cs8427 snd_i2c snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_ac97_codec snd_mpu401_uart ac97_bus nls_cp437 vfat fat isofs loop usb_storage snd_seq_dummy xt_conntrack ebtable_nat cpufreq_powersave ebtables cpufreq_stats cpufreq_userspace cpufreq_conservative crc32c parport_pc ppdev lp parport bridge bnep rfcomm bluetooth crc16 binfmt_misc ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse nfsd nfs nfs_acl auth_rpcgss lockd sunrpc des_generic ecb md4 hmac nls_utf8 cifs fscache cdc_ether usbnet mii cdc_acm cdc_phonet phonet ipt_MASQUERADE ipt_REDIRECT iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables 8021q garp stp ip6t_REJECT ip6t_frag xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack xt_multiport ip6table_filter ip6_tables x_tables kvm_amd
Bug#409349: usbhid: control queue full; hung apcupsd task
On 25/11/12 08:32, Jonathan Nieder wrote: Great, thanks. If this is still reproducible on 2.6.37, Did you get a chance to test that? Hi, I still have the affected hardware, but sadly I am still using it in production (six months later than intended). It's an openvz host, so it wouldn't be feasible to be run anything other than the stable 2.6.32 openvz kernel yet. If I can pressure myself to finish migrating it, ideally within two weeks, I'll be free to use it for as much testing as needed to figure this out. And maybe to test some Wheezy stuff before the release. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/50b22866.4090...@pyro.eu.org
Bug#409349: usbhid: control queue full; hung apcupsd task
On 05/04/12 04:52, hugo vanwoerkom wrote: Thanks much. Do you remember roughly when you last experienced this bug? Jan. 31 2011 But I have no records of what kernel I was running then :-( Hi Hugo, Are you still using the APC UPS, and the problem has gone away? What kernel are you running now? That would at least narrow it down to a version where this is fixed. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f7d86ad.2060...@pyro.eu.org
Bug#409349: usbhid: control queue full; hung apcupsd task
fixed 409349 linux-2.6/3.2.12-1 tags 409349 + squeeze thanks On 05/04/12 13:48, hugo vanwoerkom wrote: apcupsd 3.14.10-1 with MODEL: Back-UPS RS 700G and Sid kernel 3.2.0-2-amd64. Can't reproduce problem. Thanks a lot. So far I've not experienced this in 3.2.0-2-amd64 3.2.12-1 either but I've only been testing for a few hours. Quite likely this is now fixed for Wheezy but still affecting Squeeze as I've seen. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f7d95fc.3050...@pyro.eu.org
Bug#409349: usbhid: control queue full; hung apcupsd task
found 409349 linux-2.6/2.6.32-41 thanks On 04/04/12 22:23, Jonathan Nieder wrote: Ping. Is nobody trying to use an APC UPS connected by USB any more? :) Yep! This week on 2.6.32-41 I noticed apcupsd hang after about a day, followed by the 'control queue full' errors an hour later. That was with the patches suggested in #631287 applied, just in case they made any difference to this. What kernels work and don't work? I already tagged affected versions in the BTS; the first report of this was on 2.6.17 and I myself recall seeing it as far back as 2.6.26. I hadn't been able to test the UPS on a 3.y kernel until this week. Right now I have the UPS hooked up to a new server running 3.2.0-2-amd64 (Debian 3.2.12-1) to see if it recurs. Then in a few weeks, I'll be taking the original hardware (on which the issue was easily reproducible) out of production use, so I can try 3.y kernels on that too. (Until now, I couldn't try 3.y kernels on that box as it needs to run OpenVZ containers). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f7cc08e.5000...@pyro.eu.org
Bug#631287: BUG during access to hiddev (APC UPS)
On 04/04/12 23:00, Jonathan Nieder wrote: While I have your attention: does the patch series in #631287 seem to prevent the BUG as advertised without any noticeable unpleasant side-effects? How long have you been testing it? I've been running a 2.6.32-41 kernel with those patches for 8 days, but all I can say is that I haven't noticed any *new* issues. My USB-attached APC UPS is working exactly as before, although still affected by #409349 (control queue full). I have never experienced the #631287 BUG to date, so I can't say if the patches really made an improvement. I would plug/unplug the UPS a few times to check for this, except: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1068 0.0 0.0 0 0 ?DMar28 0:00 [khubd] root 8488 0.0 0.0 12704 220 ?Ds Mar29 0:00 /sbin/apcupsd I've not rebooted since the last time I last experienced #409349, and it seems the UPS was not even detected when I plugged it back in just now. Sometime, perhaps in a few weeks when this box is retired from production use, I should repeatedly plug/unplug the UPS: * on an unpatched kernel, to make sure my specific hardware was affected in the first place * on the patched kernel, to make sure the patches have really fixed it Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f7cca70.1030...@pyro.eu.org
Bug#663269: Bug#663379: Bugs#663379+663269: fix pending
On 11/03/12 16:42, Uwe Kleine-König wrote: I could reproduce your issue and commited a patch that fixes the issue for me. svn export svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian debian Hi, I didn't see anything relevant there. Were you referring to this commit in /dists/sid/ instead? http://anonscm.debian.org/viewvc/kernel?view=revisionsortby=daterevision=18814 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f5cec04.8000...@pyro.eu.org
Re: Bug#409349: usbhid: control queue full; hung apcupsd task
found 2.6.32-40 thanks Hi, Hope it's okay for me to reassign #409349 and #611646 as kernel bugs. It may be only apcupsd users who experience this, but the process hangs due to a system call failing to return, and there were reports of a related error message in the kernel log (control queue full), which seems to have been a precursor to this hang. It's clear that this bug has existed for some time (the initial report was on 2.6.17). I'll have difficulty testing this on 3.2.x kernels because I require OpenVZ on the affected machine (and that's not ported to 3.x kernels yet), and I was unsuccessful so far in reproducing it on a spare box. I notice that most reports were from users of OHCI hardware. I've even seen this on a recent RHEL6-derived kernel just now (amd64 OpenVZ kernel 2.6.32-042stab049.6) : [425881.271304] INFO: task apcupsd:7104 blocked for more than 120 seconds. [425881.278546] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [425881.287407] apcupsd D 88004dc00680 0 7104 10 0x0004 [425881.295778] 880008f57d18 0082 0286 [425881.304301] fffe 88008f33b0a0 8800762fe200 [425881.312839] 880008f57cb8 88004dc00c38 880008f57fd8 880008f57fd8 [425881.321374] Call Trace: [425881.324325] [81396ef5] usb_kill_urb+0x85/0xc0 [425881.330289] [81095310] ? autoremove_wake_function+0x0/0x40 [425881.337470] [81406d79] usbhid_init_reports+0xb9/0x120 [425881.344191] [81408a68] hiddev_ioctl+0x418/0x710 [425881.350357] [81154ba4] ? handle_mm_fault+0x1e4/0x2b0 [425881.356967] [81042b54] ? __do_page_fault+0x1e4/0x480 [425881.363595] [811a0182] vfs_ioctl+0x22/0xa0 [425881.369277] [811a0324] do_vfs_ioctl+0x84/0x5b0 [425881.375361] [8118e9f9] ? __fput+0x1e9/0x280 [425881.381140] [811a089f] sys_ioctl+0x4f/0x80 [425881.386822] [8100b182] system_call_fastpath+0x16/0x1b Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f3ee7f8.2010...@pyro.eu.org
Bug#602991: [squeeze openvz] kernel crash with null pointer dereference while umounting nfs
On 16/02/12 00:27, Jonathan Nieder wrote: George Barnett wrote: [ 317.916307] Pid: 7838, comm: umount Not tainted 2.6.32-5-openvz-amd64 #1 dyomin H8DGU [ 317.916307] RIP: 0010:[812ea21e] [812ea21e] _spin_lock_bh+0xe/0x25 [ 317.916307] [a01b97a4] ? rpc_wake_up_queued_task+0x12/0x29 [sunrpc] [ 317.916307] [a01b9835] ? rpc_killall_tasks+0x7a/0x9b [sunrpc] [ 317.916307] [a0217fed] ? nfs_umount_begin+0x34/0x3a [nfs] [ 317.916307] [81106844] ? sys_umount+0x11b/0x2e6 [ 317.916307] [812ec6a5] ? do_page_fault+0x2e0/0x2fc [ 317.916307] [81010c12] ? system_call_fastpath+0x16/0x1b Hi, FWIW, I found NFS to be very buggy before the 'feoktistov' version of the OpenVZ patchset (introduced in linux-2.6 2.6.32-31); since that version I've had no problems of this nature, and I use nfs quite heavily between OpenVZ containers. The 'dyomin' version mentioned above was based on 2.6.32.22 which I believe had some NFS issues not even specific to OpenVZ, such as kernel.org BZ#24302, and another mentioned in Debian's changelog for 2.6.32-31. Hope that helps, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f3c56e8.1010...@pyro.eu.org
Re: Bug#631287: BUG during access to hiddev (APC UPS) (was: Current status new info)
Hi! On 11/02/12 11:00, Joachim Oehler wrote: # uname -a Linux server 2.6.32-5-686 #1 SMP Mon Jun 13 04:13:06 UTC 2011 i686 GNU/Linux To get the Debian kernel package version please use: $ cat /proc/version From the build date (Jun 13) I would think you were running 2.6.32-35; this is quite old and there have been important security updates since then. You mention having this version installed: ii linux-image-2.6.32-5-686 2.6.32-41Linux 2.6.32 for modern PCs Perhaps you had only installed/upgraded to that version after booting? Jonathan Nieder wrote: If someone has a USB APC UPS, we would like to learn the following from her: 1. confirm that this bug affects your system, using the kernel from squeeze I've been using USB-attached APC UPSes from at least 2011-08 through 2012-01 and didn't experience this bug; during that time I was using up-to-date Debian amd64-openvz kernels from stable/stable-updates/security. 2. confirm that it is fixed using the kernel from sid. I'm not sure if this test is still relevant now that sid has 3.2.x. I haven't yet tried one of these UPSes on 3.2.x but will try to. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f365184.2000...@pyro.eu.org
Re: Re: [Debian] Re: Possible support for openvz also in the next version of stable
Hi, It will be rhel kernels in deb format. I'm going to test out some aspects to see what kind of obstacles we can face. Maybe I should try these too... I'm really undecided what to do with my current OpenVZ installations. My machines are old amd64 without CPU virtualisation capabilities, which rules out KVM. That also means Qemu, VirtualBox etc. would be too slow, and wasteful of resources by running a separate instance of the kernel for each guest. I think Xen would be awkward for the same reason, though I'm keeping it in mind as an option. The shared kernel between guests is openvz's particular strength. I'm under the impression that LXC doesn't yet provide the isolation of superuser privileges (due to procfs?) that I need. Also I still suffer from issues in 2.6.32 (and 2.6.26) on my main production box that I haven't been able to reproduce on any spare machine; I haven't been able to test for these problems in Debian 3.x kernels due to the lack of openvz, so the best I can do is probably try one of these rhel kernels. In the long term maybe openvz will come back for the next Debian release after Wheezy (then maybe in Wheezy backports), or maybe LXC will get the extra features I need. Or perhaps by then I can afford shiny new hardware with CPU support for virtualisation. :) I'm running root system on lvm on cryptfs.. Same here, I run these on top of mdraid. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f2f88b5.1030...@pyro.eu.org
Bug#596649: linux-image-2.6.32-5-openvz-amd64: system crash using rtl818x USB wlan
On 23/12/11 00:47, Jonathan Nieder wrote: Steven Chamberlain wrote: After several hours or days of running aircrack-ng (in this instance only 90 minutes) on a USB rtl8187 wlan interface, a strange kind of kernel lockup happens... Is this still reproducible? Hi Jonathan, I was trying to reproduce this for the past couple of days, using the same USB rtl8187 wlan device on a similar machine I had spare (but with 2.6.32-5-686 version 2.6.32-38), and it hasn't recurred yet. Also I'm now thinking it was a more generic USB/OHCI issue on the original machine, because: 1. with rtl8187 device only -- these crashes were the most serious as they sometimes crashed the whole system: [ 9001.662862] [812e7ccc] ? schedule_timeout+0xad/0xdd [ 9001.669046] [a0176eb9] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] [ 9001.676253] [a00a10d8] ? usb_kill_urb+0x9d/0xbb [usbcore] [ 9001.683018] [81065422] ? autoremove_wake_function+0x0/0x2e [ 9001.689847] [a00a2406] ? usb_start_wait_urb+0x7e/0xb7 [usbcore] [ 9001.697128] [a00a267c] ? usb_control_msg+0x112/0x135 [usbcore] [ 9001.704315] [810468b3] ? finish_task_switch+0x3a/0xaf [ 9001.710714] [a03f3d2e] ? rtl818x_ioread8+0x61/0x7e [rtl8187] [ 9001.717737] [a03f3d6f] ? rtl8187_is_radio_enabled+0x24/0xc0 [rtl8187] [ 9001.725642] [a03f3e30] ? rtl8187_rfkill_poll+0x25/0x78 [rtl8187] [ 9001.733036] [a0217e5d] ? rfkill_poll+0x1b/0x31 [rfkill] [ 9001.739616] [81061952] ? worker_thread+0x188/0x21d [ 9001.745732] [a0217e42] ? rfkill_poll+0x0/0x31 [rfkill] [ 9001.752209] [81065422] ? autoremove_wake_function+0x0/0x2e [ 9001.759049] [810617ca] ? worker_thread+0x0/0x21d [ 9001.764955] [81065156] ? kthread+0xc0/0xca [ 9001.770341] [81011c6a] ? child_rip+0xa/0x20 [ 9001.775816] [81065096] ? kthread+0x0/0xca [ 9001.781131] [81011c60] ? child_rip+0x0/0x20 2. two different series of APC UPS attached via USB cable (hiddev driver), without rtl8187 attached, would sometimes lose communications with: [20761.764191] Call Trace: [20761.766909] [a0159eb9] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] [20761.774308] [a004b10c] ? usb_kill_urb+0x9d/0xbb [usbcore] [20761.781219] [810667da] ? autoremove_wake_function+0x0/0x2e [20761.788210] [a021efeb] ? usbhid_init_reports+0x8c/0xee [usbhid] [20761.795684] [a0220396] ? hiddev_ioctl+0x2bf/0x632 [usbhid] [20761.802705] [810cfd01] ? handle_mm_fault+0x48f/0x9bb [20761.809178] [81073a6b] ? do_uncharge_dcache+0x3d/0x51 [20761.815689] [810fcc36] ? vfs_ioctl+0x21/0x6c [20761.821375] [810fd184] ? do_vfs_ioctl+0x48d/0x4cb [20761.827486] [812ecc05] ? do_page_fault+0x2e0/0x2fc [20761.833743] [810fd1ff] ? sys_ioctl+0x3d/0x5c [20761.839424] [81010c12] ? system_call_fastpath+0x16/0x1b 3. just today (now using 2.6.32-5-openvz-amd64 version 2.6.32-40), I connected one of those UPSes via serial cable instead, using a pl2303 usbserial device, and again it lost communications with a similar-looking issue that has caused only apcupsd to hang: [91922.798791] Call Trace: [91922.801429] [812ea4d4] ? schedule_timeout+0xad/0xdd [91922.807651] [a0189ee9] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] [91922.814882] [a004a25c] ? usb_kill_urb+0x9d/0xbb [usbcore] [91922.821581] [810668b6] ? autoremove_wake_function+0x0/0x2e [91922.828397] [a004b594] ? usb_start_wait_urb+0x7e/0xb7 [usbcore] [91922.835696] [a004b80b] ? usb_control_msg+0x112/0x135 [usbcore] [91922.842885] [a03f41b7] ? pl2303_set_termios+0xaa/0x620 [pl2303] [91922.850155] [a03f423d] ? pl2303_set_termios+0x130/0x620 [pl2303] [91922.857474] [811ea5e1] ? set_termios+0x365/0x3fb [91922.863422] [811ea8df] ? tty_mode_ioctl+0x19c/0x46d [91922.869630] [811ead87] ? tty_ldisc_try+0x40/0x47 [91922.875579] [811ead87] ? tty_ldisc_try+0x40/0x47 [91922.881481] [811eb61a] ? tty_ldisc_ref_wait+0x10/0x90 [91922.887861] [811e685a] ? tty_ioctl+0x975/0x9ad [91922.893604] [8122e41a] ? sys_sendto+0x109/0x138 [91922.899369] [810668b6] ? autoremove_wake_function+0x0/0x2e [91922.906159] [810fd182] ? vfs_ioctl+0x21/0x6c [91922.911698] [810fd6d0] ? do_vfs_ioctl+0x48d/0x4cb [91922.917720] [810f1b90] ? vfs_write+0xcd/0x102 [91922.923316] [810fd74b] ? sys_ioctl+0x3d/0x5c [91922.928873] [81010c12] ? system_call_fastpath+0x16/0x1b The machine having all the problems is essentially a 'production' box and also requires openvz, so it's not practical for me to try linux 3.x on there yet. I must really find a way to reproduce this issue on the 'spare' box. They are both Sun Fire v20z, albeit different hardware revisions but the USB host
Bug#653192: linux 3.2~rc4-1~experimental.1: Intel X-25M SSD destroyed
with CAP_SYS_ADMIN but no CAP_SYSLOG (deprecated). [ 536.201619] Bluetooth: Core ver 2.16 [ 536.201890] NET: Registered protocol family 31 [ 536.201893] Bluetooth: HCI device and connection manager initialized [ 536.201898] Bluetooth: HCI socket layer initialized [ 536.201901] Bluetooth: L2CAP socket layer initialized [ 536.201923] Bluetooth: SCO socket layer initialized [ 536.215707] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 536.215711] Bluetooth: BNEP filters: protocol multicast [ 536.227813] Bridge firewalling registered [ 536.344356] Bluetooth: RFCOMM TTY layer initialized [ 536.344378] Bluetooth: RFCOMM socket layer initialized [ 536.344379] Bluetooth: RFCOMM ver 1.11 [ 536.392138] lp: driver loaded but no devices found [ 536.412532] ppdev: user-space parallel port driver [ 536.431203] sshd (2363): /proc/2363/oom_adj is deprecated, please use /proc/2363/oom_score_adj instead. [ 732.842261] i2c /dev entries driver Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4ef65987.5090...@pyro.eu.org
Bug#623881: linux-image-2.6.32-5-openvz-amd64: many oops after kexec reboot
On 24/04/11 01:54, Steven Chamberlain wrote: ... [in] 2.6.32-31 it still seems reproducible every time. I've just tried going back to 2.6.32-30 (my own build, with fixes for 607041 and 613170 applied because I need them) and kexec works there. So I think a problem was introduced during the other, many changes in 2.6.32-31. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4db892df.3090...@pyro.eu.org
Bug#613170: linux-image-2.6.32-5-openvz-amd64: OpenVZ-specific NFS implementation error
Ola Lundqvist o...@debian.org wrote: Do you know if those patches will appear in the openvz git soon? Hi, I just noticed two commits relating to this issue (OpenVZ bug #1626) made it into 2.6.32-openvz git: http://git.openvz.org/?p=linux-2.6.32-openvz;a=shortlog I've tested NFS on max's 2.6.32-31 test build from 27th Jan, and I've been able to reproduce the reported issue, so I will rebuild and test with these additional patches as soon as I can. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d656c8b@pyro.eu.org
Bug#613170: linux-image-2.6.32-5-openvz-amd64: OpenVZ-specific NFS implementation error
On Wed, Feb 23, 2011 at 08:22:35PM +, Steven Chamberlain wrote: I just noticed two commits relating to this issue (OpenVZ bug #1626) made it into 2.6.32-openvz git: http://git.openvz.org/?p=linux-2.6.32-openvz;a=shortlog Those patches have worked great for me (on amd64); applied cleanly against Debian linux-2.6 2.6.32-30 and fixed the reported issue with nfs. For some time one of my VE's hadn't been shutting down properly, and it turns out this was the reason why. Thanks, everyone! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d65ba9f.50...@pyro.eu.org
Bug#613170: Processed: forcibly merging 607041 613170
On 13/02/11 13:03, Debian Bug Tracking System wrote: forcemerge 607041 613170 Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE Bug#613170: linux-image-2.6.32-5-openvz-amd64: OpenVZ-specific NFS implementation error Bug#590321: vzctl: ip6tables does not work in VE Forcibly Merged 590321 607041 613170. Huh? Bugs 607041/590321 were for IPv6 netfilter, and fixed in Max Attems' 2.6.32-31 test build (unreleased) which brings in the latest patchset from OpenVZ Git. But bug 613170 looks like an OpenVZ nfs issue unrelated to IPv6 or netfilter. The patches for that issue don't seem to be included in OpenVZ's linux-2.6.32-openvz Git branch yet. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d57f632.7090...@pyro.eu.org
Bug#607041: Bug#590321: vzctl: ip6tables does not work in VE
On 15/01/11 16:18, Ola Lundqvist wrote: severity 607041 important merge 607041 590321 thanks Thanks for the information. Merging them. Hi Ola, I notice these bugs didn't actually get merged. From the BTS documentation it seems you must first resassign 590321 to linux-image-2.6.32-5-openvz-amd64 before you can merge or forcemerge them. Right now I'm running this test build posted by Max Attems which I'm happy to say fixes the issue for me (although I had to --force-depends to install it without an updated linux-base package): have a 2.6.32-31 build for testing here, ola or anyone? http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb.sha512sum.asc I also note that 'tc' works now inside VEs; this was a separate issue that someone had reported here: http://bugzilla.openvz.org/1238 Thanks, everyone! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d41df40.8080...@pyro.eu.org
Bug#596649: linux-image-2.6.32-5-openvz-amd64: system crash using rtl818x USB wlan
Hi, I still had the rtl8187 error despite booting with usbcore.autosuspend=-1 on the kernel command line. I wondered if the bug was being triggered by USB suspend/resume, but apparently not. And the rtl8187-related crash actually happened while the interface was down (but rtl8187 module loaded). On 07/01/11 18:37, Steven Chamberlain wrote: Additionally, after this error occurs, other USB devices on the same bus seem to break too: [1416023.409112] generic-usb 0003:051D:0002.0003: control queue full Actually that error could have been a different problem. It recurred just now without even the rtl8187 device plugged in or the module ever having been loaded: [20561.882890] generic-usb 0003:051D:0002.0001: control queue full That is my APC UPS, a usbhid device. After 654 of those messages, that and another USB device on the same bus (USB serial port) locked up (userland programs hang trying to use them): [20761.723850] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [20761.732439] apcupsd D 88008164d800 0 20649 1 0x [20761.739891] 8800bf034000 0082 0292 [20761.747903] 88007c92bcd8 fa40 88007c92bfd8 00016940 [20761.756018] 00016940 88008164d800 88008164daf8 00017fc0f000 [20761.764191] Call Trace: [20761.766909] [a0159eb9] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] [20761.774308] [a004b10c] ? usb_kill_urb+0x9d/0xbb [usbcore] [20761.781219] [810667da] ? autoremove_wake_function+0x0/0x2e [20761.788210] [a021efeb] ? usbhid_init_reports+0x8c/0xee [usbhid] [20761.795684] [a0220396] ? hiddev_ioctl+0x2bf/0x632 [usbhid] [20761.802705] [810cfd01] ? handle_mm_fault+0x48f/0x9bb [20761.809178] [81073a6b] ? do_uncharge_dcache+0x3d/0x51 [20761.815689] [810fcc36] ? vfs_ioctl+0x21/0x6c [20761.821375] [810fd184] ? do_vfs_ioctl+0x48d/0x4cb [20761.827486] [812ecc05] ? do_page_fault+0x2e0/0x2fc [20761.833743] [810fd1ff] ? sys_ioctl+0x3d/0x5c [20761.839424] [81010c12] ? system_call_fastpath+0x16/0x1b It could be relevant that my original rtl8187 lockup issue showed an identical portion within the stack trace: [1410483.801467] [a01bdeb9] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] [1410483.808842] [a008910c] ? usb_kill_urb+0x9d/0xbb [usbcore] [1410483.815768] [810667da] ? autoremove_wake_function+0x0/0x2e I'm not having much fun with USB recently... Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d29e183.4050...@pyro.eu.org
Bug#596649: linux-image-2.6.32-5-openvz-amd64: system crash using rtl818x USB wlan
found 596649 2.6.32-29 thanks [1410483.744597] INFO: task events/3:18 blocked for more than 120 seconds. [1410483.751589] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [1410483.760088] events/3 D 88007f8a1800 018 2 0x [1410483.767576] 880095db1800 0046 00011502c1d3 812e96ec [1410483.775765] fa40 88007f8d7fd8 00016940 [1410483.783936] 00016940 88007f8a1800 88007f8a1af8 000337a31000 [1410483.792107] Call Trace: [1410483.794971] [812e96ec] ? schedule_timeout+0xad/0xdd [1410483.801467] [a01bdeb9] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] [1410483.808842] [a008910c] ? usb_kill_urb+0x9d/0xbb [usbcore] [1410483.815768] [810667da] ? autoremove_wake_function+0x0/0x2e [1410483.822742] [a008a444] ? usb_start_wait_urb+0x7e/0xb7 [usbcore] [1410483.830188] [a008a6bb] ? usb_control_msg+0x112/0x135 [usbcore] [1410483.837547] [81047ae5] ? finish_task_switch+0x3a/0xaf [1410483.844073] [a0a81d2e] ? rtl818x_ioread8+0x61/0x7e [rtl8187] [1410483.851313] [a0a81d6f] ? rtl8187_is_radio_enabled+0x24/0xc0 [rtl8187] [1410483.859389] [a0a81e30] ? rtl8187_rfkill_poll+0x25/0x78 [rtl8187] [1410483.866984] [a033fe5d] ? rfkill_poll+0x1b/0x31 [rfkill] [1410483.873697] [81062d0a] ? worker_thread+0x188/0x21d [1410483.880025] [a033fe42] ? rfkill_poll+0x0/0x31 [rfkill] [1410483.886645] [810667da] ? autoremove_wake_function+0x0/0x2e [1410483.894180] [81062b82] ? worker_thread+0x0/0x21d [1410483.900387] [8106650e] ? kthread+0xc0/0xca [1410483.906015] [81011c6a] ? child_rip+0xa/0x20 [1410483.911788] [8106644e] ? kthread+0x0/0xca [1410483.917400] [81011c60] ? child_rip+0x0/0x20 Additionally, after this error occurs, other USB devices on the same bus seem to break too: [1416023.409112] generic-usb 0003:051D:0002.0003: control queue full -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d275d69.1060...@pyro.eu.org
Bug#607604: linux-image-2.6.32-5-openvz-amd64: nfsd oops after 'exportfs -ra'
Hi, I've re-tested this by tar+untarring the same files and directories into my nfs-exported directory, that was I was previously trying to bring in via a 'mount --bind'. Happily it works that way. So it seems nfsd is having issues with bind mounts onto a directory being exported. Something I still need to check, is whether doing the bind mount *before* nfs-kernel-server has started (eg. via /etc/fstab), works. Currently I've been doing it manually after boot, running 'exportfs -ra', and getting the oops when the export is next mounted by an NFS client. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d179d69.1010...@pyro.eu.org
Bug#607604: linux-image-2.6.32-5-openvz-amd64: nfsd oops after 'exportfs -ra'
08 4c 89 0c 24 48 8b 7f 28 48 8b 5f 50 ff 53 08 48 85 c0 49 89 c4 75 0c 49 c7 c4 8c ff ff ff e9 8d 01 [ 479.781985] RIP [a0664601] exportfs_decode_fh+0x40/0x213 [exportfs] [ 479.781985] RSP 88007ee43ba0 [ 479.781985] CR2: 0008 [ 480.083103] ---[ end trace a42c5a0ce6a3ea7f ]--- Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d11bcce.7040...@pyro.eu.org
Bug#607604: linux-image-2.6.32-5-openvz-amd64: nfsd oops after 'exportfs -ra'
] RIP [a0664601] exportfs_decode_fh+0x40/0x213 [exportfs] [ 525.352026] RSP 88007ed91ba0 [ 525.352026] CR2: 0008 [ 525.373343] ---[ end trace 16befdc2c233113f ]--- Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d0f0614.3070...@pyro.eu.org
Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE
On 17/12/10 06:39, Ola Lundqvist wrote: forwarded 607041 http://bugzilla.openvz.org/show_bug.cgi?id=1723 Thanks for your report. I have forwarded this to upstream now. Thank you. I also noticed that the ip6tables -j LOG target logs into the host node rather than the VE. I think the IPv6 equivalent of the IPv4 log target has not been patched to do this. At least in the current Debian openvz kernel. I'll copy that to the bug report in the OpenVZ tracker. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d0b07ef.1000...@pyro.eu.org
Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE
Package: linux-image-2.6.32-5-openvz-amd64
Version: 2.6.32-29
Hi,
I noticed that on kernel 2.6.32-5-openvz-amd64 (Debian 2.6.32-29), the
amd64 build of ip6tables does not work at all in an OpenVZ VE, but the
i386 build does. Within the OpenVZ host itself though (VE0), both
versions work. So I'm inclined to say this is more likely a
kernel/OpenVZ bug than a bug in ip6tables.
IPv4 iptables works fine in all cases.
I tested this within a OpenVZ VE, which is an amd64 Debian lenny
install, with an i386 chroot inside of it:
# dpkg-query -Wf '${Package}-${Version}_${Architecture}\n' iptables
iptables-1.4.2-6_amd64
# ip6tables -L
FATAL: Could not load /lib/modules/2.6.32-5-openvz-amd64/modules.dep: No
such file or directory
ip6tables v1.4.2: can't initialize ip6tables table `filter': Permission
denied (you must be root)
Perhaps ip6tables or your kernel needs to be upgraded.
# chroot lenny-i386/ dpkg-query -Wf
'${Package}-${Version}_${Architecture}\n' iptables
iptables-1.4.2-6_i386
# chroot lenny-i386/ ip6tables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
...
I believe this strace of the amd64 version shows where the problem occurs:
socket(PF_INET6, SOCK_RAW, IPPROTO_RAW) = 3
getsockopt(3, SOL_IPV6, 0x40 /* IPV6_??? */, 0x7fff508e34d0, 0x7fff508e3538) =
-1 EPERM (Operation not permitted)
After that, ip6tables seems to think some kernel modules must be
missing, so it tries to load them, except that's not correct for OpenVZ
and that leads to the errors visible on stderr.
The same getsockopt() call succeeds in the i386 version:
socket(PF_INET6, SOCK_RAW, IPPROTO_RAW) = 3
getsockopt(3, SOL_IPV6, 0x40 /* IPV6_??? */,
filter\0\377\241\372\3\201\377\377\377\377\6\0\0\0\0\0\0\0Q\367\0\201\377\377\377\377\16...,
[84]) = 0
After an exhaustive search of kernel source I think maybe this is the
source of that -1 EPERM return value:
static int
compat_do_ip6t_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
{
int ret;
if (!capable(CAP_VE_NET_ADMIN))
return -EPERM;
static int
do_ip6t_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
{
int ret;
if (!capable(CAP_NET_ADMIN))
return -EPERM;
It looks like the OpenVZ patch changed CAP_NET_ADMIN to CAP_VE_NET_ADMIN
for compat_do_ip6t_{get,set}_ctl but not for the native functions
ip6t_{get,set}_ctl.
However, the equivalent IPv4 functions have something slightly
different, for all four functions (get and set, compat and native):
if (capable(CAP_NET_ADMIN) !capable(CAP_VE_NET_ADMIN))
In all honesty I don't know what this means -- I don't know if there are
security implications if I changed this. Or maybe it would break
ip6tables in the host system (VE0). I may try fiddling with this
sometime if I get the chance to reboot the machine (a production system,
unfortunately, such is the way of things...).
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
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/4d07297a.7070...@pyro.eu.org
Bug#580507: linux-image-2.6.32-5-openvz-amd64: CONFIG_NF_CONNTRACK_IPV6 is not set
Hi, This is still missing from current 2.6.32-5-openvz-amd64. It's enabled as a module for linux-image-2.6.32-5-amd64 though. It's not clear to me why it's missing from the openvz flavour. Anyway, the lack of nf_conntrack_ipv6 doesn't prevent IPv6 from being used in OpenVZ host/guest VEs, because net.ipv6.conf.default.forwarding still causes the host to act as an IPv6 router for guest VEs. The reason nf_conntrack_ipv6 is desirable is because it allows the use of '-m state --state RELATED,ESTABLISHED' in ip6tables rules (in either the host VE's FORWARD table or guest VEs' INPUT tables), so that traffic to most ports can be filtered except in response to outgoing connections. This gives IPv6 hosts an additional layer of security that was traditionally a side-effect of NAT in IPv4. My suggested alternative in the meantime is to keep ports 1024-65535 open, because source ports for outgoing connections will usually be in that range. Most services will listen on ports 1-1023, which can be filtered/closed except for any services that need to be public. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4d06e773.6080...@pyro.eu.org
Bug#596449: linux-image-2.6.32-bpo.5-openvz-amd64: kernel BUG/OOPS
retitle 596449 linux-image-2.6.32-bpo.5-openvz-amd64: kernel BUG/OOPS thanks I'm also suffering this slightly different-looking kernel BUG but I think it's related to the same issue. Again this was triggered by a PHP web application, but not phpmyadmin this time, and this was with APC disabled (APC uses SHM heavily, and that was mentioned in the backtrace of the last crash). The crashed process remains unkillable except by reboot, and 'ps ax' freezes, as well as other tools such as 'lsof'. I'm going to test with 2.6.32-5-openvz-amd64 from unstable now, to establish if this is purely related to the backported package, or if it's potentially an issue for squeeze. [99948.571072] BUG: unable to handle kernel NULL pointer dereference at 0010 [99948.577964] IP: [8117d2ff] __rb_rotate_left+0x7/0x5b [99948.577964] PGD 7d0af067 PUD 7e858067 PMD 0 [99948.577964] Oops: [#1] SMP [99948.591393] last sysfs file: /sys/devices/system/edac/mc/mc1/csrow2/ch1_dimm_label [99948.591393] CPU 1 [99948.591393] Modules linked in: st osst vzethdev vznetdev simfs vzrst vzcpt vzdquota vzmon vzdev xt_DSCP xt_owner xt_length xt_hl xt_tcpmss xt_TCPMSS xt_limit xt_dscp nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc bridge ipt_MASQUERADE iptable_nat nf_nat iptable_mangle ipt_REJECT ipt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_hashlimit act_police xt_multiport cls_u32 sch_ingress sch_htb iptable_filter ip_tables x_tables aufs(C) 8021q garp stp powernow_k8 ipmi_watchdog ipmi_si ipmi_devintf ipmi_msghandler loop arc4 ecb rtl8187 mac80211 led_class cfg80211 rfkill eeprom_93cx6 container evdev snd_pcm snd_timer snd soundcore snd_page_alloc amd64_edac_mod psmouse serio_raw k8temp edac_core edac_mce_amd processor button pcspkr shpchp i2c_amd756 i2c_core pci_hotplug amd_rng rng_core reiserfs sha256_generic aes_x86_64 aes_generic cbc dm_crypt dm_mirror dm_region_hash dm_log dm_snapshot dm_mod raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod qla2xxx sd_mod crc_t10dif sg sr_mod cdrom ata_generic scsi_transport_fc pata_amd ohci_hcd mptspi mptscsih tg3 mptbase scsi_tgt floppy aic7xxx scsi_transport_spi libphy libata usbcore scsi_mod nls_base thermal fan thermal_sys [last unloaded: st] [99948.591393] Pid: 15838, comm: apache2 Tainted: G C 2.6.32-bpo.5-openvz-amd64 #1 budarin Sun Fire V20z [99948.591393] RIP: 0010:[8117d2ff] [8117d2ff] __rb_rotate_left+0x7/0x5b [99948.591393] RSP: 0018:88007c0e3de0 EFLAGS: 00010282 [99948.591393] RAX: RBX: 88001a84b5b0 RCX: [99948.591393] RDX: RSI: 88007d42a1c8 RDI: 88007d666df0 [99948.591393] RBP: 88001a84b7c0 R08: 88007d666240 R09: 88007d42a1c0 [99948.591393] R10: 00016940 R11: 0202 R12: 88007d666df0 [99948.591393] R13: 88001a84b5b0 R14: 88007d42a1c8 R15: 88007d666210 [99948.591393] FS: 413b4950(0063) GS:88000190() knlGS:b722dbb0 [99948.591393] CS: 0010 DS: ES: CR0: 8005003b [99948.591393] CR2: 0010 CR3: 37946000 CR4: 06e0 [99948.591393] DR0: DR1: DR2: [99948.591393] DR3: DR6: 0ff0 DR7: 0400 [99948.591393] Process apache2 (pid: 15838, veid=1003, threadinfo 88007c0e2000, task 88007c245000) [99948.591393] Stack: [99948.591393] 8117d468 88001a84b790 88001a84b790 88007d42a1c0 [99948.591393] 0 88001a84b5b0 88001a84b5c0 810d245d 8800723435a8 [99948.591393] 0 810d24d2 67548000 88001a84b790 fff4 [99948.591393] Call Trace: [99948.591393] [8117d468] ? rb_insert_color+0xba/0xe2 [99948.591393] [810d245d] ? __vma_link+0x58/0x61 [99948.591393] [810d24d2] ? vma_link+0x6c/0x9b [99948.591393] [810d3d2e] ? mmap_region+0x41c/0x5c5 [99948.591393] [810c866e] ? sys_mmap_pgoff+0xf4/0x19d [99948.591393] [810fc9be] ? sys_fcntl+0x454/0x464 [99948.591393] [81010c12] ? system_call_fastpath+0x16/0x1b [99948.591393] Code: 00 31 c0 eb 19 ff c0 48 89 ee 48 c7 c7 58 30 65 81 89 43 08 e8 c0 b6 16 00 b8 01 00 00 00 5a 5b 5d c3 90 90 48 8b 4f 08 4c 8b 07 48 8b 51 10 49 83 e0 fc 48 85 d2 48 89 57 08 74 0c 48 8b 02 83 [99948.591393] RIP [8117d2ff] __rb_rotate_left+0x7/0x5b [99948.591393] RSP 88007c0e3de0 [99948.591393] CR2: 0010 [99948.941658] ---[ end trace 36e642d477aeb1ac ]--- Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4c8d22e2.2040...@pyro.eu.org
Bug#596449: linux-image-2.6.32-bpo.5-openvz-amd64: kernel BUG/OOPS
Version: 2.6.32-21 Hi again. I booted into the latest linux-image-2.6.32-5-openvz-amd64 from squeeze, and I still see this issue. This time it was triggered by trying to view a Wordpress site hosted in one of the VE's. I don't know's with these PHP apps... I tried to retitle my bug as I'm not so sure it's SHM related any more, and evidently the problem isn't confined to the -bpo package from Backports, either. I'd appreciate if a maintainer could make the appropriate change for me. And possibly mark this as present in 2.6.32-21 if necessary. Thanks. For the time being I'm reverting to 2.6.26-2-openvz-amd64 on this machine (as it's sort of a production server). I've never had this issue in that kernel version. [ 416.222686] BUG: unable to handle kernel NULL pointer dereference at 0010 [ 416.225988] IP: [8117d55b] __rb_rotate_left+0x7/0x5f [ 416.233473] PGD 7cf04067 PUD 7cf05067 PMD 0 [ 416.233473] Oops: [#1] SMP [ 416.233473] last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings [ 416.246994] CPU 3 [ 416.246994] Modules linked in: vzethdev vznetdev simfs vzrst vzcpt vzdquota vzmon vzdev xt_DSCP xt_owner xt_length xt_hl xt_tcpmss xt_TCPMSS xt_limit xt_dscp nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc bridge ipt_MASQUERADE iptable_nat nf_nat iptable_mangle ipt_REJECT ipt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_hashlimit xt_multiport act_police iptable_filter cls_u32 ip_tables x_tables sch_ingress sch_htb aufs(C) 8021q garp stp powernow_k8 ipmi_watchdog ipmi_si ipmi_devintf ipmi_msghandler loop arc4 ecb rtl8187 mac80211 led_class cfg80211 rfkill eeprom_93cx6 container evdev snd_pcm snd_timer snd soundcore snd_page_alloc psmouse serio_raw amd64_edac_mod edac_core edac_mce_amd k8temp i2c_amd756 pcspkr button processor i2c_core amd_rng rng_core shpchp pci_hotplug reiserfs sha256_generic aes_x86_64 aes_generic cbc osst st dm_crypt dm_mirror dm_region_hash dm_log dm_snapshot dm_mod raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod qla2xxx sd_mod crc_t10dif sg sr_mod cdrom ata_generic mptspi mptscsih pata_amd scsi_transport_fc ohci_hcd mptbase scsi_tgt tg3 aic7xxx scsi_transport_spi libata floppy libphy usbcore nls_base scsi_mod thermal fan thermal_sys [last unloaded: qla2xxx] [ 416.246994] Pid: 12020, comm: apache2 Tainted: G C 2.6.32-5-openvz-amd64 #1 budarin Sun Fire V20z [ 416.246994] RIP: 0010:[8117d55b] [8117d55b] __rb_rotate_left+0x7/0x5f [ 416.246994] RSP: 0018:88007cf79de0 EFLAGS: 00010286 [ 416.246994] RAX: RBX: 88007cfcc190 RCX: [ 416.246994] RDX: RSI: 88007cbf0f08 RDI: 88007cf50450 [ 416.246994] RBP: 8800bca51190 R08: 88007cf503a0 R09: 88007cbf0f00 [ 416.246994] R10: 88007cf79fd8 R11: 0202 R12: 88007cf50450 [ 416.246994] R13: 88007cfcc190 R14: 88007cbf0f08 R15: 88007cf50370 [ 416.447902] FS: 40bdb950(0063) GS:88008150() knlGS:b7247bb0 [ 416.447902] CS: 0010 DS: ES: CR0: 8005003b [ 416.447902] CR2: 0010 CR3: 7cf03000 CR4: 06e0 [ 416.447902] DR0: DR1: DR2: [ 416.447902] DR3: DR6: 0ff0 DR7: 0400 [ 416.447902] Process apache2 (pid: 12020, veid=1003, threadinfo 88007cf78000, task 88007cbf9800) [ 416.447902] Stack: [ 416.447902] 8117d6cc 8800bca51160 8800bca51160 88007cbf0f00 [ 416.447902] 0 88007cfcc190 88007cfcc1a0 810d2689 88006aa19ce8 [ 416.447902] 0 810d26fe 68cae000 8800bca51160 fff4 [ 416.447902] Call Trace: [ 416.447902] [8117d6cc] ? rb_insert_color+0xba/0xe2 [ 416.447902] [810d2689] ? __vma_link+0x58/0x61 [ 416.447902] [810d26fe] ? vma_link+0x6c/0x9b [ 416.447902] [810d3f5a] ? mmap_region+0x41c/0x5c5 [ 416.447902] [810c880a] ? sys_mmap_pgoff+0xf4/0x19d [ 416.447902] [810fcc36] ? sys_fcntl+0x454/0x464 [ 416.447902] [81010c12] ? system_call_fastpath+0x16/0x1b [ 416.447902] Code: 00 31 c0 eb 19 ff c0 48 89 ee 48 c7 c7 58 90 65 81 89 43 08 e8 d4 b6 16 00 b8 01 00 00 00 5a 5b 5d c3 90 90 48 8b 4f 08 4c 8b 07 48 8b 41 10 49 83 e0 fc 48 85 c0 48 89 47 08 74 10 48 8b 51 10 [ 416.447902] RIP [8117d55b] __rb_rotate_left+0x7/0x5f [ 416.447902] RSP 88007cf79de0 [ 416.447902] CR2: 0010 [ 416.612855] ---[ end trace 69cec64862afe70f ]--- Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4c8d2b38.9080...@pyro.eu.org
Bug#596449: linux-image-2.6.32-5-openvz-amd64: kernel BUG/Oops [possibly due to aufs]
Hello, Some good news finally! (But perhaps bad for some...) I had some time to do a little more investigation myself into these kernel Oopses, and learned what 'drivers/staging' really means. I assumed it was to do with binary firmware, but of course it refers to a certain kernel module having been loaded from the 'drivers/staging' area for 'lower quality' code -- aufs. I'd completely forgotten that OpenVZ VE 1003, running the PHP apps that appeared to trigger these crashes on my system, was on an aufs filesystem. I've run OpenVZ VEs on aufs filesystems in the past quite successfully on 2.6.26 kernels. I tar'd and untar'd the VE into a non-aufs filesystem, disabled aufs by removing it from /etc/fstab, and booted back into 2.6.32-21. Happily I've so far been unable to reproduce the kernel BUG/Oopses that I was able to reproduce very reliably before. The bad news is that the Debian Live folks could possibly suffer this issue. The kernel Oopses seem to refer to code that is used for shmfs. With OpenVZ there is an shmfs within each VE, and one of my VEs was running on an aufs mount, and I guess the crash has something to do with that. In a Live environment, I think shmfs is mounted on top of an aufs root filesystem, so I suspect this issue may arise in that situation, too. I understand why this issue may need to be marked 'wontfix'. Many thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4c8d4f7c.1000...@pyro.eu.org
Bug#596649: linux-image-2.6.32-5-openvz-amd64: system crash using rtl818x USB wlan
U160/m [9005:f620] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 (1ns min, 6250ns max), Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 25 BIST result: 00 Region 0: I/O ports at 2800 [disabled] [size=256] Region 1: Memory at fe061000 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at c022 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: aic7xxx Kernel modules: aic7xxx 03:01.0 Fibre Channel [0c04]: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA [1077:2312] (rev 02) Subsystem: QLogic Corp. Device [1077:0101] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 128 (16000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 28 Region 0: I/O ports at 3000 [size=256] Region 1: Memory at fe10 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at c030 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: qla2xxx Kernel modules: qla2xxx 03:01.1 Fibre Channel [0c04]: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA [1077:2312] (rev 02) Subsystem: QLogic Corp. Device [1077:0101] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 128 (16000ns min), Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 29 Region 0: I/O ports at 3400 [size=256] Region 1: Memory at fe101000 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at c032 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: qla2xxx Kernel modules: qla2xxx ** USB devices: not available -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.32-5-openvz-amd64 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii linux-base2.6.32-21 Linux image base package ii module-init-tools 3.4-1 tools for managing Linux kernel mo ii vzctl 3.0.22-14 server virtualization solution - c Versions of packages linux-image-2.6.32-5-openvz-amd64 recommends: ii firmware-linux-free2.6.32-20~bpo50+1 Binary firmware for various driver Versions of packages linux-image-2.6.32-5-openvz-amd64 suggests: ii grub-pc [grub] 1.96+20080724-16 GRand Unified Bootloader, version pn linux-doc-2.6.32none (no description available) Versions of packages linux-image-2.6.32-5-openvz-amd64 is related to: pn firmware-bnx2 none (no description available) pn firmware-bnx2x none (no description available) pn firmware-ipw2x00none (no description available) pn firmware-ivtv none (no description available) pn firmware-iwlwifinone (no description available) pn firmware-linux none (no description available) pn firmware-linux-nonfree none (no description available) ii firmware-qlogic 0.24~bpo50+1 Binary firmware for QLogic IBA7220 pn firmware-ralink none (no description available) pn xen-hypervisor none (no description available) -- debconf information: linux-image-2.6.32-5-openvz-amd64/postinst/ignoring-do-bootloader-2.6.32-5-openvz-amd64: linux-image-2.6.32-5-openvz-amd64/postinst/missing-firmware-2.6.32-5-openvz-amd64: linux-image-2.6.32-5-openvz-amd64/postinst/depmod-error-initrd-2.6.32-5-openvz-amd64: false linux-image-2.6.32-5-openvz-amd64/prerm/removing-running-kernel-2.6.32-5-openvz-amd64: true Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4c8d8f52.5020...@pyro.eu.org
Bug#596449: linux-image-2.6.32-bpo.5-openvz-amd64: kernel BUG related to SHM
Kernel modules: aic7xxx 02:05.1 SCSI storage controller [0100]: Adaptec AHA-3960D / AIC-7899A U160/m [9005:00c0] (rev 01) Subsystem: Adaptec AHA-3960D U160/m [9005:f620] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 (1ns min, 6250ns max), Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 25 BIST result: 00 Region 0: I/O ports at 2800 [disabled] [size=256] Region 1: Memory at fe061000 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at c022 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: aic7xxx Kernel modules: aic7xxx 03:01.0 Fibre Channel [0c04]: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA [1077:2312] (rev 02) Subsystem: QLogic Corp. Device [1077:0101] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 128 (16000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 28 Region 0: I/O ports at 3000 [size=256] Region 1: Memory at fe10 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at c030 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: qla2xxx Kernel modules: qla2xxx 03:01.1 Fibre Channel [0c04]: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X HBA [1077:2312] (rev 02) Subsystem: QLogic Corp. Device [1077:0101] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 128 (16000ns min), Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 29 Region 0: I/O ports at 3400 [size=256] Region 1: Memory at fe101000 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at c032 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: qla2xxx Kernel modules: qla2xxx ** USB devices: not available -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.32-bpo.5-openvz-amd64 depends on: ii debconf [debconf-2.0] 1.5.24Debian configuration management sy ii initramfs-tools [linux 0.92o tools for generating an initramfs ii linux-base 2.6.32-20~bpo50+1 Linux image base package ii module-init-tools 3.4-1 tools for managing Linux kernel mo ii vzctl 3.0.22-14 server virtualization solution - c Versions of packages linux-image-2.6.32-bpo.5-openvz-amd64 recommends: ii firmware-linux-free2.6.32-20~bpo50+1 Binary firmware for various driver Versions of packages linux-image-2.6.32-bpo.5-openvz-amd64 suggests: ii grub-pc [grub] 1.96+20080724-16 GRand Unified Bootloader, version pn linux-doc-2.6.32none (no description available) Versions of packages linux-image-2.6.32-bpo.5-openvz-amd64 is related to: pn firmware-bnx2 none (no description available) pn firmware-bnx2x none (no description available) pn firmware-ipw2x00none (no description available) pn firmware-ivtv none (no description available) pn firmware-iwlwifinone (no description available) pn firmware-linux none (no description available) pn firmware-linux-nonfree none (no description available) ii firmware-qlogic 0.24~bpo50+1 Binary firmware for QLogic IBA7220 pn firmware-ralink none (no description available) pn xen-hypervisor none (no description available) -- debconf information: linux-image-2.6.32-bpo.5-openvz-amd64/postinst/ignoring-do-bootloader-2.6.32-bpo.5-openvz-amd64: * linux-image-2.6.32-bpo.5-openvz-amd64/postinst/missing-firmware-2.6.32-bpo.5-openvz-amd64: linux-image-2.6.32-bpo.5-openvz-amd64/prerm/removing-running-kernel-2.6.32-bpo.5-openvz-amd64: true linux-image-2.6.32-bpo.5-openvz-amd64/postinst/depmod-error-initrd-2.6.32-bpo.5-openvz-amd64: false Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4c8ba90d.6060
Bug#509613: linux-image-2.6-openvz-amd64: kernel oops on net device reconfiguration
Hi, I was having problems with linux-image-2.6.26-1-openvz-amd64 that seem very similar to this. If I tried starting/rebooting any VE after creating any NAT iptables rules, I got a NULL pointer dereference followed by OOPSes just as the VE's network interfaces came up. I've attached the relevant kernel output in case anyone should experience the same. I tried the patch from Lars Hanke, as well as several others from the OpenVZ git repository, all to no avail. I very much appreciated the instructions for patching/rebuilding a Debian-packaged kernel though. However, I tried lenny-proposed-updates as suggested by Dann Frazier and installed linux-image-2.6.26-2-openvz-amd64 and I'm very pleased to say my problem has been fixed. Many thanks to all involved! Regards, -- Steven Chamberlain ste...@pyro.eu.org [0.00] Linux version 2.6.26-1-openvz-amd64 (Debian 2.6.26-13lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 13 19:02:24 UTC 2009 [0.00] Command line: root=/dev/hda7 ro [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f400 (usable) [0.00] BIOS-e820: 0009f400 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1fff (usable) [0.00] BIOS-e820: 1fff - 1fff3000 (ACPI NVS) [0.00] BIOS-e820: 1fff3000 - 2000 (ACPI data) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 131056) 1 entries of 3200 used [0.00] max_pfn_mapped = 1048576 [0.00] init_memory_mapping [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F7880, 0014 (r0 Nvidia) [0.00] ACPI: RSDT 1FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] ACPI: FACP 1FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] ACPI: DSDT 1FFF3180, 6360 (r1 NVIDIA AWRDACPI 1000 MSFT 10E) [0.00] ACPI: FACS 1FFF, 0040 [0.00] ACPI: SRAT 1FFF9600, 00A0 (r1 AMDHAMMER 1 AMD 1) [0.00] ACPI: MCFG 1FFF9700, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] ACPI: APIC 1FFF9540, 007C (r1 Nvidia AWRDACPI 42302E31 AWRD 0) [0.00] SRAT: PXM 0 - APIC 0 - Node 0 [0.00] SRAT: PXM 0 - APIC 1 - Node 0 [0.00] SRAT: Node 0 PXM 0 0-a [0.00] Entering add_active_range(0, 0, 159) 0 entries of 3200 used [0.00] SRAT: Node 0 PXM 0 10-2000 [0.00] Entering add_active_range(0, 256, 131056) 1 entries of 3200 used [0.00] NUMA: Allocated memnodemap from b000 - b480 [0.00] NUMA: Using 20 for the hash shift. [0.00] Bootmem setup node 0 -1fff [0.00] NODE_DATA [b480 - 0001047f] [0.00] bootmap [00011000 - 00014fff] pages 4 [0.00] early res: 0 [0-fff] BIOS data page [0.00] early res: 1 [6000-7fff] TRAMPOLINE [0.00] early res: 2 [20-66a817] TEXT DATA BSS [0.00] early res: 3 [1fd9c000-1ffdfe3e] RAMDISK [0.00] early res: 4 [9f400-f] BIOS reserved [0.00] early res: 5 [8000-afff] PGTABLE [0.00] early res: 6 [b000-b47f] MEMNODEMAP [0.00] [e200-e27f] PMD - [81000120-8100019f] on node 0 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 131056 [0.00] On node 0 totalpages: 130959 [0.00] DMA zone: 64 pages used for memmap [0.00] DMA zone: 1234 pages reserved [0.00] DMA zone: 2701 pages, LIFO batch:0 [0.00] DMA32 zone: 1984 pages used for memmap [0.00] DMA32 zone: 124976 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] If you got timer trouble try acpi_use_timer_override [0.00] ACPI: PM-Timer IO Port: 0x4008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1
