Processed: Re: Bug#514292: linux-image-2.6.28-1-amd64: Bad page state in process 'emacs'
Processing commands for cont...@bugs.debian.org: > reassign 514292 linux-2.6 Bug#514292: linux-image-2.6.28-1-amd64: Bad page state in process 'emacs' Warning: Unknown package 'linux-image-2.6.28-1-amd64' Bug reassigned from package `linux-image-2.6.28-1-amd64' to `linux-2.6'. > reassign 514288 linux-2.6 Bug#514288: stock debian kernels map heap, data, and other sections as rwx Warning: Unknown package 'linux-image-2.6.24-e' Bug reassigned from package `linux-image-2.6.24-e' to `linux-2.6'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514288: stock debian kernels map heap, data, and other sections as rwx
Package: linux-image-2.6.24-e Version: 2.6.24-6~etchnhalf.7 On both vmlinuz-2.6.18-5-686 and vmlinuz-2.6.24-etchnhalf.1-686 kernels, the debian system maps the heap, binary data, and other data sections as rwx, instead of the normal and sensible rw-. Examples: grep rwx /proc/1/maps 0805-08051000 rwxp 7000 08:01 48968 /sbin/init 08051000-08072000 rwxp 08051000 00:00 0 [heap] b7d88000-b7d89000 rwxp b7d88000 00:00 0 b7d8b000-b7d8d000 rwxp 1000 08:01 375948 /lib/tls/i686/cmov/libdl-2.3.6.so b7eb9000-b7ebb000 rwxp 0012c000 08:01 375945 /lib/tls/i686/cmov/libc-2.3.6.so b7ebb000-b7ebf000 rwxp b7ebb000 00:00 0 b7ed2000-b7ed4000 rwxp 00012000 08:01 359138 /lib/libselinux.so.1 b7f0a000-b7f0b000 rwxp 00035000 08:01 359139 /lib/libsepol.so.1 b7f0b000-b7f15000 rwxp b7f0b000 00:00 0 b7f19000-b7f1b000 rwxp b7f19000 00:00 0 b7f3-b7f32000 rwxp 00014000 08:01 360971 /lib/ld-2.3.6.so -- pidof sshd 2807 2804 2692 debian-vmware:/home/x# grep -c rwx /proc/2807/maps 44 It seems incorrect and also very bad from a security standpoint to have this behavior. I am aware that the kernel does not ask for these mappings to be created, but it also should enforce some sort of W^X behavior. The loader or whichever userland application that asks for the mappings should also be alterted to follow the normal memory permission standards.
finalizing 2.6.28 config options
hello :) have gone through the open 2.6.28 Kconfig variables for x86_64 and set the evident ones, those below are still open. once we have settled those. i'll see to have also a clean x86_32 config. * XEN_DEBUG_FS ian can you please decide on that one for x86? have seen it enabled in fedora but Kconfig speaks of performance hit. * MEMTEST do we want it? it is disabled by default if needs bootparam to be enabled. although defaults to N and i see it disabled in fedora!? * X86_CHECK_BIOS_CORRUPTION default disabled, diagnostic tool guess not, but.. * FIRMWARE_IN_KERNEL default enabled we probably don't ship right yet relevant firmware separetly? * MTD_DATAFLASH_WRITE_VERIFY data integrity, but default disabled? not seen in any fedora config * MTD_DATAFLASH_OTP OTP data support, default disabled? * VIDEO_FIXED_MINOR_RANGES usefull for !udev setups defaults unset and so seen in fedora * HID_COMPAT default set useful for !udev setups seen unset in fedora * USB_SERIAL_KEYSPAN_MPR USB_SERIAL_KEYSPAN_USA28 USB_SERIAL_KEYSPAN_USA28X USB_SERIAL_KEYSPAN_USA28XA USB_SERIAL_KEYSPAN_USA28XB USB_SERIAL_KEYSPAN_USA19 USB_SERIAL_KEYSPAN_USA18X USB_SERIAL_KEYSPAN_USA19W USB_SERIAL_KEYSPAN_USA19QW USB_SERIAL_KEYSPAN_USA19QI USB_SERIAL_KEYSPAN_USA49W USB_SERIAL_KEYSPAN_USA49WLC bunch of new firmware for some option style serial dev not looked at their licences yet nor request_firmware() usage * STAGING pile of crap drivers disabled in fedora, users might request it, but currently seems not really supportable. so i'd be for unsetting, but want opinons? * SUNRPC_REGISTER_V4 experimental default disabled but seen enabled in fedora requires portmapper that supports protocol version 4!? * SYSCTL_SYSCALL_CHECK might uncover things, maybe for some time in squeeze?? * IRQSOFF_TRACER SCHED_TRACER CONTEXT_SWITCH_TRACER BOOT_TRACER default disabled, but enabled on fedora * STRICT_DEVMEM is userspace ready for that!? probably should da a testboot and see if lenny xorg comes up with it enabled. * X86_VERBOSE_BOOTUP default yes and guess debian users like it!? * EARLY_PRINTK_DBGP defaults no, seen enabled on fedora * OPTIMIZE_INLINING shall we trust gcc? default disabled can reduce kernel size and requires gcc 4.x :) thanks for your input. would like to have those set by this week, so that we can soon jump on the .29 resume and butter goodness :D -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: finalizing 2.6.28 config options
On Fri, 2009-02-06 at 14:42 +0100, maximilian attems wrote: > hello :) > > have gone through the open 2.6.28 Kconfig variables for x86_64 and set the > evident ones, those below are still open. once we have settled those. i'll > see to have also a clean x86_32 config. > > * XEN_DEBUG_FS > ian can you please decide on that one for x86? > have seen it enabled in fedora but Kconfig speaks of performance hit. I think leave it off, it's probably only really useful for developers anyway and anybody who is having a problem this would help diagnose is probably going to have to rebuild at some point anyway. Ian. -- Ian Campbell I was in a beauty contest one. I not only came in last, I was hit in the mouth by Miss Congeniality. -- Phyllis Diller -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514048: Missing dependency on zlib1g-dev
> Documentation/lguest is not built during the normal built. See for
> example the linux-2.6 build. So you did something different and have to
> show what you're really calling.
Well, I just tried it again, making sure that I did a "make-kpkg clean"
first, and it failed again. The sequence of commands was
cd /usr/src/linux-source-2.6.26
make-kpkg clean
make-kpkg --initrd --append-to-version -custom1-686 --revision 1 kernel_image
("make menuconfig" has previously been run.) That is my standard method of
making custom kernel image packages, and has been for years. Here are the
last few lines of output:
CC sound/usb/usx2y/snd-usb-usx2y.mod.o
LD [M] sound/usb/usx2y/snd-usb-usx2y.ko
make[1]: Leaving directory '/usr/src/linux-source-2.6.26'
/usr/bin/make EXTRAVERSION=-custom1-686 ARCH=i386 \
-C Documentation/lguest
make[1]: Entering directory '/usr/src/linux-source-2.6.26/Documentation/lguest'
cc -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include
lguest.c -lz -o lguest
lguest.c:34:18: error: zlib.h: No such file or directory
make[1]: ***[lguest] Error 1
make[1]: Leaving directory '/usr/src/linux-source-2.6.26/Documentation/lguest'
make: *** [debian/stamp/build/kernel] Error 2
This is followed by a shell prompt. Am I doing something wrong? Does
kernel-package have a bug? Or does kernel-package need to document a
requirement for zlib1g-dev for recent kernels?
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514048: Missing dependency on zlib1g-dev
On Fri, Feb 06, 2009 at 09:25:34AM -0500, zlinux...@wowway.com wrote: > > Documentation/lguest is not built during the normal built. See for > > example the linux-2.6 build. So you did something different and have to > > show what you're really calling. > > Well, I just tried it again, making sure that I did a "make-kpkg clean" > first, and it failed again. The sequence of commands was So kernel-package is the culprit. Bug them. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Missing dependency on zlib1g-dev
Processing commands for cont...@bugs.debian.org: > reassign 514048 kernel-package 11.015 Bug#514048: Missing dependency on zlib1g-dev Bug reassigned from package `linux-source-2.6.26' to `kernel-package'. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501326: linux-image-2.6.26-1-amd64: actually it powers off, only fails to suspend
Package: linux-image-2.6.26-1-amd64 Version: 2.6.26-13 Followup-For: Bug #501326 Actually the kernel powers off just fine (but I normally never do that) it just fails to suspend to disk (the system resumes immediately). So this might be somewhat different problem. Thanks Michal -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497931: forcedeth: don't work after resume
Hi again! I've tested the patch Ayaz Abdulla written and attached to the bug report I've mentioned above, and it seems to fix the bug. See http://bugzilla.kernel.org/show_bug.cgi?id=10487#c21 for the patch and other comments about it. Note that this patch seems not to be applied in 2.6.29-rc3. Regards, Colomban -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: finalizing 2.6.28 config options
On 2009-02-06, maximilian attems wrote: > hello :) > > have gone through the open 2.6.28 Kconfig variables for x86_64 and set the > evident ones, those below are still open. once we have settled those. i'll > see to have also a clean x86_32 config. > > * STAGING > pile of crap drivers > disabled in fedora, users might request it, but currently seems > not really supportable. so i'd be for unsetting, but want opinons? The following drivers from staging are already present in the archive as OOT modules: - comedi - rt2860 - et131x - wlan-ng So, while staging drivers certainly shouldn't be built by default it makes sense to build these from the official kernel tree in the future. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#457775: Similar problem with linux-image-2.6.18-6-686
Package: linux-image-2.6.18-6-686
Followup-For: Bug #457775
I ran aptitude install snmpd
and syslogd said on console:
Bad page state in process 'aptitude'
page:c11eddc0 flags:0x8000 mapping: mapcount:-1 count:0
Trying to fix it up, but a reboot is needed
I'm unable to reproduce this bug and after a new try of this installation,
snmpd is properly installed.
dmesg says:
[ cut here ]
kernel BUG at mm/rmap.c:522!
invalid opcode: [#1]
SMP
Modules linked in: ipt_REDIRECT xt_tcpudp iptable_nat ip_nat ip_conntrack
nfnetlink iptable_filter ip_tables x_tables ipv6 button ac battery ext3 jbd
mbcache dm_snapshot dm_mirror dm_mod loop tsdev i2c_i801 i2c_core serio_raw
shpchp parport_pc parport pci_hotplug evdev psmouse rtc floppy pcspkr xfs
sd_mod ata_piix libata ehci_hcd 3w_ scsi_mod e1000 generic ide_core
uhci_hcd usbcore thermal processor fan
CPU:3
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.18-6-686 #1)
EIP is at page_remove_rmap+0x14/0x2d
eax: ebx: c11eddc0 ecx: c11eddc0 edx: 0003
esi: b717 edi: 0020 ebp: ca1395c0 esp: eb52de14
ds: 007b es: 007b ss: 0068
Process php-cgi (pid: 3641, ti=eb52c000 task=dff4eaa0 task.ti=eb52c000)
Stack: c014b739 dff34518 eb52de7c 0001 b717d000 d8c44b70
db410580 c20238a0 ff8c c114272c d8c44b70 0035be70 b717d000
eb52de7c dfb4156c db410580 eb52deb8 c014ddec eb52de78
Call Trace:
[] unmap_vmas+0x25e/0x4af
[] exit_mmap+0x6a/0xd7
[] mmput+0x20/0x76
[] do_exit+0x193/0x71b
[] sys_exit_group+0x0/0xd
[] get_signal_to_deliver+0x395/0x3bc
[] do_page_fault+0x0/0x481
[] do_notify_resume+0x71/0x5d7
[] force_sig_info_fault+0x24/0x28
[] vfs_write+0x103/0x143
[] do_page_fault+0x478/0x481
[] do_page_fault+0x0/0x481
[] work_notifysig+0x13/0x19
Code: ff ff 85 c0 89 c6 75 c9 b0 01 86 43 28 83 c4 20 89 e8 5b 5e 5f 5d c3 89
c1 f0 83 40 08 ff 0f 98 c0 84 c0 74 1e 8b 41 08 40 79 08 <0f> 0b 0a 02 20 ab 29
c0 8b 51 10 89 c8 83 f2 01 83 e2 01 e9 bf
EIP: [] page_remove_rmap+0x14/0x2d SS:ESP 0068:eb52de14
<1>Fixing recursive fault but reboot is needed!
Bad page state in process 'aptitude'
page:c11eddc0 flags:0x8000 mapping: mapcount:-1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
[] bad_page+0x41/0x67
[] free_hot_cold_page+0x5b/0xfa
[] __pagevec_free+0x14/0x1a
[] release_pages+0xff/0x13b
[] __pagevec_release+0x15/0x1d
[] truncate_inode_pages_range+0xcb/0x253
[] xfs_vn_unlink+0x2f/0x3b [xfs]
[] truncate_inode_pages+0x9/0xf
[] generic_delete_inode+0xb6/0x10f
[] iput+0x64/0x66
[] do_unlinkat+0xa7/0x113
[] _atomic_dec_and_lock+0x2a/0x44
[] dput+0x2a/0x11b
[] __fput+0x11c/0x13f
[] mntput_no_expire+0x11/0x6a
[] sysenter_past_esp+0x56/0x79
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages linux-image-2.6.18-6-686 depends on:
ii coreutils5.97-5.3The GNU core utilities
ii debconf [debconf-2.0]1.5.11etch2 Debian configuration management sy
ii initramfs-tools [linux-initr 0.85i tools for generating an initramfs
ii module-init-tools3.3-pre4-2 tools for managing Linux kernel mo
Versions of packages linux-image-2.6.18-6-686 recommends:
ii libc6-i686 2.3.6.ds1-13etch8 GNU C Library: Shared libraries [i
-- debconf information:
shared/kernel-image/really-run-bootloader: true
linux-image-2.6.18-6-686/preinst/elilo-initrd-2.6.18-6-686: true
linux-image-2.6.18-6-686/preinst/already-running-this-2.6.18-6-686:
linux-image-2.6.18-6-686/postinst/depmod-error-2.6.18-6-686: false
linux-image-2.6.18-6-686/preinst/initrd-2.6.18-6-686:
linux-image-2.6.18-6-686/postinst/old-initrd-link-2.6.18-6-686: true
linux-image-2.6.18-6-686/preinst/bootloader-initrd-2.6.18-6-686: true
linux-image-2.6.18-6-686/preinst/abort-install-2.6.18-6-686:
linux-image-2.6.18-6-686/preinst/lilo-has-ramdisk:
linux-image-2.6.18-6-686/preinst/overwriting-modules-2.6.18-6-686: true
linux-image-2.6.18-6-686/postinst/bootloader-error-2.6.18-6-686:
linux-image-2.6.18-6-686/prerm/would-invalidate-boot-loader-2.6.18-6-686: true
linux-image-2.6.18-6-686/postinst/bootloader-test-error-2.6.18-6-686:
linux-image-2.6.18-6-686/postinst/create-kimage-link-2.6.18-6-686: true
linux-image-2.6.18-6-686/postinst/depmod-error-initrd-2.6.18-6-686: false
linux-image-2.6.18-6-686/preinst/lilo-initrd-2.6.18-6-686: true
linux-image-2.6.18-6-686/postinst/old-dir-initrd-link-2.6.18-6-686: true
linux-image-2.6.18-6-686/preinst/failed-to-move-modules-2.6.18-6-686:
linux-image-2.6.18-6-686/preinst/abort-overwrite-2.6.18-6-686:
linux-image-2.6.18-6-686/prerm/removing-running-kernel-2.6.18-6-686: true
linux-image-2.6.
Bug#514247: [solved]
I updated the Firmware of the Perc3Di Controller to 2.8-1 Build 7692. Now it works. Regards, Boris -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514370: initramfs-tools: how do we authenticate initrd images
Package: initramfs-tools
Version: 0.92o
Severity: wishlist
I always wonder (often late) that why don't I file a bugreport also for
Debian.
Description of problem:
Taken from RH Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=435033
The dependency on initrd is increasing with every release. With features
like
SAN Boot, the OS is heavily dependent on a proper initrd.
Currently, we don't seem to be having a proper way of supporting initrd
images
like we do for other packages (RPM signed packages or non-tainted
kernels)
It is difficult, during root cause of problems reported by customers, to
be sure
that they are running the recommended setup as instructed by the OS
vendor. This
is very true because most 3rd party ISVs or applications
modify/overwrite the
initrd generated under the OS Vendor's guidelines.
We need an infrastructure to track down the correct initrd being used to
boot
the OS.
Version-Release number of selected component (if applicable):
All
How reproducible:
Always
Steps to Reproduce:
1. Tamper some behavior for the initrd.
2. Create the tampered initrd image by overwriting the original initrd
image.
And
1. Boot into the OS.
2. There is no way to know what initrd image was used during boot.
Actual results:
There is no way to identify the authenticity of the initrd image. And
there is
no way to identify what initrd image is used during boot.
Expected results:
We should have a signature based verification of the initrd image (Just
like GPG
signed RPM packages). But how are we going to sign the image during
installtime
creation is a problem.
And we also need a way to identify (on the basis of name) what initrd
image is
used to boot. Something like /proc/cmdline
=
Above mentioned kind of problems must be the ones why tytso came up with
the
idea of Tainting the kernel from Userspace.
We would not want to spend time debugging, when the user did
unacceptable
things with her OS installation. (Here initrd being the example).
Let me try another minimalistic approach :-)
In the kernel RPM package, during post installation we could generate
the
checksum:
%define kernel_variant_post(v:r:) \
%{expand:%%kernel_devel_post %{?-v*}}\
%{expand:%%kernel_variant_posttrans %{?-v*}}\
%{expand:%%post %{?-v*}}\
%{-r:\
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
[ -f /etc/sysconfig/kernel ]; then\
/bin/sed -r -i -e
's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/'
/etc/sysconfig/kernel || exit $?\
fi}\
/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{KVERREL}%{?-v:.%{-v*}} || exit $?\
# Proposed approach
/sbin/gen-checksum initrd >
/boot/%{KVERREL}%{?-v:.%{-v*}}.initrd.checksum
We add the checksum to /boot or where ever appropriate (inside the
initrd image
?).
During boot, the initrc script in the initrd could do the checksum check
of the
initrd image.
And if the checksum of the initrd image, that we are booting from,
doesn't
tally with the checksum that was generated during kernel installation,
we
*Taint the kernel from Userspace*.
That's all.
Are there other official Red Hat tools that are allowed to mangle with
the
initrd image ? If yes, they also need fall under a similar policy
Now, in our debugging logs, if we see "Tainted U", we know that the user
possibly did something nasty or non-standard.
Do you guys think this approach could help improve the current "Initrd
Dependency" flux?
The bug report is mostly a copy/paste from the RH bugzilla.
For Debian, I'm not sure how we'd want to taclke this.
Do we really care that the user uses the initrd image generated _only_
from post-inst of an official kernel deb package installation ?
Would we be accepting bugs as valid if the initrd was tampered by a 3rd
party ISV ?
Support statement for Debian is different. So I'm not sure if this
problem really applies to Debian or not.
Ritesh
-- Package-specific info:
-- /proc/cmdline
root=/dev/mapper/VgSda2-ROOT ro vga=788 quiet splash
-- /proc/filesystems
ext3
fuseblk
-- lsmod
Module Size Used by
hdaps 9592 1
tp_smapi 19472 0
thinkpad_ec 6776 2 hdaps,tp_smapi
tun 9636 1
michael_mic 2464 6
arc41984 6
ecb 2784 6
ieee80211_crypt_tkip 8192 3
radeon128484 0
drm77416 1 radeon
rfcomm 31216 0
l2cap 19008 5 rfcomm
bluetooth 48960 4 rfcomm,l2cap
xt_limit2212 3
xt_state2208 11
iptable_filter 2784 1
ip_tables 10320 1 iptable_filter
nf_conntrack_ipv4 11980 11
nf_defrag_ipv4 2080 1 nf_conntrack_ipv4
nf_conntrack_ipv6 11768 0
ipv6 234544 19 nf_conntrack_ipv6
nf_conntrack_tftp 4308 0
nf_conntrack_h323 43424 0
nf_conntrack_sip 16116 0
nf_conntrack_irc
Bug#513537: linux-image-2.6.26-1-openvz-amd64 hanging
Hi Daniel,
I don't have much light to shed on your bug, except that I've got something
similar without the nvidia kernel taint.
You wrote:
> XFS > LVM > dm_crypt > MD (RAID1) > { SATA AHCI, IDE PIIX }
I'm running: ext3 loopback > ext3 > LVM > aacraid scsi.
The bug was triggered while I was executing "invoke-rc.d vz stop" and
simultaneously copying from the underlying ext3 to the ext3-loopback
file.
In every case the Call Traces end at: system_call_after_swapgs+0x8a/0x8f
I've been trying to 'kill -9' all of the blocked processes, and that gives me,
for example:
[3594730.862500] BUG: soft lockup - CPU#1 stuck for 61s! [apache2:4576]
[3594730.862500] Modules linked in: vzethdev vznetdev simfs vzrst vzcpt tun
vzmon xt_length ipt_ttl xt_tcpmss xt_TCPMSS iptable_mangle iptable_filter
xt_multiport xt_limit xt_dscp ipt_REJECT xt_tcpudp iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack vzdquota vzdev ip_tables x_tables ipv6 loop
snd_pcm snd_timer snd soundcore snd_page_alloc parport_pc parport pcspkr
psmouse serio_raw k8temp i2c_amd8111 amd_rng rng_core i2c_amd756 i2c_core
button shpchp pci_hotplug evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot
dm_mod ide_cd_mod cdrom ide_pci_generic amd74xx ide_core sd_mod floppy
ata_generic libata dock ohci_hcd tg3 aacraid scsi_mod thermal processor fan
thermal_sys [last unloaded: simfs]
[3594730.862500] CPU 1:
[3594730.862500] Modules linked in: vzethdev vznetdev simfs vzrst vzcpt tun
vzmon xt_length ipt_ttl xt_tcpmss xt_TCPMSS iptable_mangle iptable_filter
xt_multiport xt_limit xt_dscp ipt_REJECT xt_tcpudp iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack vzdquota vzdev ip_tables x_tables ipv6 loop
snd_pcm snd_timer snd soundcore snd_page_alloc parport_pc parport pcspkr
psmouse serio_raw k8temp i2c_amd8111 amd_rng rng_core i2c_amd756 i2c_core
button shpchp pci_hotplug evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot
dm_mod ide_cd_mod cdrom ide_pci_generic amd74xx ide_core sd_mod floppy
ata_generic libata dock ohci_hcd tg3 aacraid scsi_mod thermal processor fan
thermal_sys [last unloaded: simfs]
[3594730.862500] Pid: 4576, comm: apache2 Not tainted 2.6.26-1-openvz-amd64
#1 036test001
[3594730.862500] RIP: 0010:[] []
_spin_lock+0xc/0x15
[3594730.862500] RSP: 0018:810003367d10 EFLAGS: 0293
[3594730.862500] RAX: 1614 RBX: 81007e8e34a8 RCX:
[3594730.862500] RDX: e24e2968 RSI: 0002 RDI:
81007f5a67e0
[3594730.862500] RBP: 0246 R08: 0008 R09:
810001101700
[3594730.862500] R10: 0002 R11: R12:
81010f80
[3594730.862500] R13: e25612c0 R14: 8027a4ce R15:
0004
[3594730.862500] FS: 7f6e32f0f750() GS:81007f5a6a40()
knlGS:
[3594730.862500] CS: 0010 DS: ES: CR0: 8005003b
[3594730.862500] CR2: 0183c1c8 CR3: 549b5000 CR4:
06e0
[3594730.862500] DR0: DR1: DR2:
[3594730.862500] DR3: DR6: 0ff0 DR7:
0400
[3594730.862500]
[3594730.862500] Call Trace:
[3594730.862500] [] ? shmem_free_blocks+0x27/0x42
[3594730.862500] [] ? shmem_truncate_range+0x763/0x808
[3594730.862500] [] ? shmem_delete_inode+0x65/0xde
[3594730.862500] [] ? shmem_delete_inode+0x0/0xde
[3594730.862500] [] ? generic_delete_inode+0xa3/0x115
[3594730.862500] [] ? d_kill+0x38/0x59
[3594730.862500] [] ? dput+0x119/0x14f
[3594730.862500] [] ? __fput+0x14f/0x178
[3594730.862500] [] ? remove_vma+0x53/0x88
[3594730.862500] [] ? do_munmap+0x205/0x227
[3594730.862500] [] ? __down_write_nested+0x12/0xa1
[3594730.862500] [] ? sys_munmap+0x40/0x5a
[3594730.862500] [] ? system_call_after_swapgs+0x8a/0x8f
[3594730.862500]
Things are continuing to block, e.g.:
[3594580.540114] INFO: task sshd:23585 blocked for more than 120 seconds.
[3594580.540182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[3594580.540283] sshd D 81013d92d7d0 0 23585 15642
[3594580.540288] 8101207a1bb0 0086
0002
[3594580.540294] 81013d92d7d0 81007f5b2810 81013d92da58
0003bd68fcf8
[3594580.540300] 0002
[3594580.540305] Call Trace:
[3594580.540329] [] mix_pool_bytes_extract+0x5c/0x155
[3594580.540338] [] __mutex_lock_slowpath+0x64/0x9b
[3594580.540346] [] mutex_lock+0xa/0xb
[3594580.540352] [] rtnetlink_rcv+0x9/0x1e
[3594580.540357] [] netlink_unicast+0x215/0x28d
[3594580.540362] [] __alloc_skb+0x8d/0x153
[3594580.540370] [] netlink_sendmsg+0x25b/0x26e
[3594580.540382] [] sock_sendmsg+0xcb/0xe3
[3594580.540393] [] autorem
