Bug#604096: Nvidia + Xen
Hi! I have just installed Debian 6 and Xen, and i cant use Xserver (nvidia) in my Dom0 2.6.32-5-xen-686 . So i cant use this pc for personal user , just for servers =( Is the same bug? Can i use another kernel? Which one? Thank you.
Bug#582605: INFO: task * blocked for more than 120 seconds.
Happens to me too! And there's a lot of people with this problem, Ubuntu 10 have this too. Look the google search (last week): http://www.google.com.br/search?q=task+blocked+for+more+than+120+seconds&hl=pt-BR&tbo=1&prmdo=1&output=search&source=lnt&tbs=qdr:w&ei=pyf9S5fkIdCKuAfdkoGBBg&sa=X&oi=tool&resnum=4&ct=tlink&ved=0CAoQpwU Happens a lot with me with Xen in the Poweredges. Then i changed the DomUs kernel to bigmem and PyGrub, its more stable now. I think Xen works better with 32 bits DomUs. If anyone knows how to fix this, please share. Thank you. On Sat, May 22, 2010 at 4:27 AM, Muhammad Akl wrote: > > Package:linux-image-2.6.26-2-amd64 > > Version : 2.6.26-21lenny4 > > Severity: important > > I'm using Debian lenny and I'm experiencing this bug for about two days ago , > the server was running fine about six months ago ,until those two days , this > behaviour happened three times , > > > and can't find a way to reproduce this behaviour as it happens in random > times , each time the server freezes and no way to login using ssh , > all i can do rebooting the machine via sysreq button. the server is running > apache2, php5, no database on this server. > > > Server hardware (Dell PowerEdge 2950) : > > Cpu : Two Quad-Core Intel(R) Xeon(R) CPU E5440 @ 2.83GHz > > Memory : 8 GB > > here's a sample from the kernel log : > > May 21 17:19:29 debian-srv kernel: [88903.681061] INFO: task pdflush:275 > blocked for more than 120 seconds. > > > May 21 17:19:29 debian-srv kernel: [88903.681117] "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > May 21 17:19:29 debian-srv kernel: [88903.681205] pdflush D > 81022c9d3000 0 275 2 > > > May 21 17:19:29 debian-srv kernel: [88903.681208] 81022cf6db80 > 0046 81022f3b5140 > May 21 17:19:29 debian-srv kernel: [88903.681211] 81022f3d3770 > 81022f2ae380 81022f3d39f8 00058030ca4f > > > May 21 17:19:29 debian-srv kernel: [88903.681213] > 81022f3b5140 8101a9e8b340 > May 21 17:19:29 debian-srv kernel: [88903.681215] Call Trace: > May 21 17:19:29 debian-srv kernel: [88903.681236] [] > :jbd:start_this_handle+0x289/0x304 > > > May 21 17:19:29 debian-srv kernel: [88903.681241] [] > autoremove_wake_function+0x0/0x2e > May 21 17:19:29 debian-srv kernel: [88903.681244] [] > find_busiest_group+0x254/0x6dc > > > May 21 17:19:29 debian-srv kernel: [88903.681249] [] > :jbd:journal_start+0x9b/0xd2 > May 21 17:19:29 debian-srv kernel: [88903.681259] [] > :ext3:ext3_ordered_writepage+0x4e/0x16f > > > May 21 17:19:29 debian-srv kernel: [88903.681263] [] > __writepage+0xa/0x23 > May 21 17:19:29 debian-srv kernel: [88903.681281] [] > write_cache_pages+0x182/0x2b1 > May 21 17:19:29 debian-srv kernel: [88903.681283] [] > __writepage+0x0/0x23 > > > May 21 17:19:29 debian-srv kernel: [88903.681288] [] > thread_return+0x6b/0xac > May 21 17:19:29 debian-srv kernel: [88903.681291] [] > lock_timer_base+0x26/0x4b > May 21 17:19:29 debian-srv kernel: [88903.681295] [] > do_writepages+0x27/0x2d > > > May 21 17:19:29 debian-srv kernel: [88903.681298] [] > __writeback_single_inode+0x144/0x29d > May 21 17:19:29 debian-srv kernel: [88903.681302] [] > delayacct_end+0x7d/0x88 > > > May 21 17:19:29 debian-srv kernel: [88903.681305] [] > sync_sb_inodes+0x1b1/0x293 > May 21 17:19:29 debian-srv kernel: [88903.681308] [] > writeback_inodes+0x62/0xb3 > May 21 17:19:29 debian-srv kernel: [88903.681311] [] > background_writeout+0x87/0xbb > > > May 21 17:19:29 debian-srv kernel: [88903.681314] [] > pdflush+0x0/0x211 > May 21 17:19:29 debian-srv kernel: [88903.681316] [] > pdflush+0x164/0x211 > May 21 17:19:29 debian-srv kernel: [88903.681318] [] > background_writeout+0x0/0xbb > > > May 21 17:19:29 debian-srv kernel: [88903.681334] [] > kthread+0x47/0x74 > May 21 17:19:29 debian-srv kernel: [88903.681337] [] > schedule_tail+0x27/0x5c > May 21 17:19:29 debian-srv kernel: [88903.681339] [] > child_rip+0xa/0x12 > > > May 21 17:19:29 debian-srv kernel: [88903.681343] [] > kthread+0x0/0x74 > May 21 17:19:29 debian-srv kernel: [88903.681345] [] > child_rip+0x0/0x12 > > The Full report is found in attachment , and please let me know if any > additional information are required > > > Regards > > >
Bug#517449: linux-image-2.6.26-2-vserver-amd64: still getting "task blocked for more than 120 seconds." kernel log messages
same to me a have different machines that have different services with this bug On Fri, Mar 26, 2010 at 4:35 AM, Timo Veith wrote: > Hi all, > > sorry if my message from yesterday was noise too, but I haven't > understood yet why those kernel log messages appear anyway. Somebody in > this bug report pointed out that those "INFO: task xy blocked for more > than 120 seconds." are only symptoms of the real problem. Could somebody > explain the actual problem to me please? > > What I have learned from this and from other similar bug reports like > this yet is, that it has something to do with the load which is on the > machine. But that is not clear enough to me. > > TIA and kind regards, > > Timo > > > > -- > To unsubscribe, send mail to 517449-unsubscr...@bugs.debian.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/dd1d2e611003260612g2d9e548ekf176963584a41...@mail.gmail.com
Bug#517449: linux-image-2.6.26-2-vserver-amd64: still getting "task blocked for more than 120 seconds." kernel log messages
Happens to me yesterday with linux-image-2.6.26-2-xen-amd64_2.6.26-19lenny2_amd64.deb in differents machines. Hope this is fixed in 2.6.26-21 On Thu, Mar 25, 2010 at 6:47 AM, Timo Veith wrote: > Package: linux-2.6 > Version: 2.6.26-21lenny4 > Followup-For: Bug #517449 > > > > -- Package-specific info: > ** Version: > Linux version 2.6.26-2-vserver-amd64 (Debian 2.6.26-21lenny4) > (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian > 4.1.2-25)) #1 SMP Tue Mar 9 23:51:13 UTC 2010 > > ** Command line: > root=UUID=1e176c09-1de6-425a-886c-c210b2c74125 ro rootdelay=10 quiet > > ** Not tainted > > ** Kernel log: > [1102456.907369] INFO: task mysqld:28528 blocked for more than 120 seconds. > [1102456.907410] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [1102456.907449] mysqld D 810001040ba0 0 28528 13048 > [1102456.907455] 810195985da8 0086 > 8023d63e > [1102456.907462] 0003 81019942f4d0 81019f0b14d0 > 81019942f758 > [1102456.907467] 0296 > > [1102456.907472] Call Trace: > [1102456.907498] [] lock_timer_base+0x26/0x4b > [1102456.907532] [] :jbd:log_wait_commit+0x9f/0xed > [1102456.907540] [] autoremove_wake_function+0x0/0x2e > [1102456.907559] [] :jbd:journal_stop+0x165/0x18d > [1102456.907571] [] __writeback_single_inode+0x17f/0x29d > [1102456.907578] [] autoremove_wake_function+0x0/0x2e > [1102456.907593] [] sync_inode+0x24/0x31 > [1102456.907610] [] :ext3:ext3_sync_file+0x9e/0xb0 > [1102456.907622] [] do_fsync+0x52/0xa4 > [1102456.907632] [] __do_fsync+0x23/0x36 > [1102456.907640] [] ia32_sysret+0x0/0x1f > [1102456.907656] > [1102459.052442] INFO: task mysqld:14224 blocked for more than 120 seconds. > [1102459.052471] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [1102459.052509] mysqld D 0 14224 13048 > [1102459.052515] 8101964a7da8 0086 > 8023d63e > [1102459.052522] 0003 810197c5d020 81019f13b550 > 810197c5d2a8 > [1102459.052527] 0296 > > [1102459.052532] Call Trace: > [1102459.052557] [] lock_timer_base+0x26/0x4b > [1102459.052592] [] :jbd:log_wait_commit+0x9f/0xed > [1102459.052599] [] autoremove_wake_function+0x0/0x2e > [1102459.052617] [] :jbd:journal_stop+0x165/0x18d > [1102459.052628] [] __writeback_single_inode+0x17f/0x29d > [1102459.052647] [] sync_inode+0x24/0x31 > [1102459.052665] [] :ext3:ext3_sync_file+0x9e/0xb0 > [1102459.052679] [] do_fsync+0x52/0xa4 > [1102459.052688] [] __do_fsync+0x23/0x36 > [1102459.052696] [] ia32_sysret+0x0/0x1f > [1102459.052713] > > ** Model information > sys_vendor: Dell Computer Corporation > product_name: PowerEdge 1850 > product_version: > chassis_vendor: Dell Computer Corporation > chassis_version: > bios_vendor: Dell Computer Corporation > bios_version: A07 > board_vendor: Dell Computer Corporation > board_name: 0D8266 > board_version: A02 > > ** Loaded modules: > Module Size Used by > ib_iser 34168 0 > rdma_cm 31732 1 ib_iser > ib_cm 37800 1 rdma_cm > iw_cm 13448 1 rdma_cm > ib_sa 24704 2 rdma_cm,ib_cm > ib_mad 39208 2 ib_cm,ib_sa > ib_core 59392 6 ib_iser,rdma_cm,ib_cm,iw_cm,ib_sa,ib_mad > ib_addr 10888 1 rdma_cm > iscsi_tcp 21764 0 > libiscsi 32384 2 ib_iser,iscsi_tcp > scsi_transport_iscsi 36256 4 ib_iser,iscsi_tcp,libiscsi > ip6table_filter 7296 0 > ip6_tables 23056 1 ip6table_filter > x_tables 25224 1 ip6_tables > ipmi_si 43628 0 > ipmi_devintf 13200 0 > ipmi_msghandler 38520 2 ipmi_si,ipmi_devintf > loop 19596 0 > snd_pcm 81800 0 > snd_timer 25744 1 snd_pcm > snd 63688 2 snd_pcm,snd_timer > soundcore 12064 1 snd > serio_raw 9988 0 > snd_page_alloc 13072 1 snd_pcm > rng_core 8968 0 > psmouse 42268 0 > video 24212 0 > output 7808 1 video > pcspkr 7040 0 > button 11680 0 > shpchp 34080 0 > pci_hotplug 32056 1 shpchp > e752x_edac 16656 0 > edac_core 49560 1 e752x_edac > dcdbas 11952 0 > evdev 14208 0 > ext3 127632 26 > jbd 51240 1 ext3 > mbcache 12804 1 ext3 > dm_mirror 20608 0 > dm_log 13956 1 dm_mirror > dm_snapshot 19400 0 > dm_mod 59376 54 dm_mirror,dm_log,dm_snapshot > sg
Re: Bug#516374 Help with Xen kernel
I'm now using the most recent update in stable. No crashes in last week. I have ~ 70 DomUs in ~ 8 Dom0 , most of them in 64 because i was thinking that 64 OS is better for 64 architecture, not for a specific use. Dom0 never crashes, just DomUs. For now i will stay with xen-amd64 Lenny kernels and see how it goes. I dont want to migrate 64 -> 32 because i dont have time for that. If it became necessary, then i will do it with the 2.6.32 stuff in my deploy servers to provide you a feedback. Provide feedback in this list/thread ? I'm been using Debian for 10 years and i'm happy to see this great support. Thank you. On Tue, Mar 23, 2010 at 6:02 AM, Ian Campbell wrote: > On Mon, 2010-03-22 at 15:24 -0300, Jorge Eduardo Birck wrote: >> Ok, this bug is fixed in non Xen-specific packages >> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516374) > > The "120 seconds" message is a very generic symptom which can have lots > of root causes. As Ben notes towards the end of the bug that particular > bug has basically become useless because so many different root causes > have been mixed together. > >> , how about >> the Xen-specific kernels, how to use a non-xen kernel in 64 xen >> servers? How to keep it stable? >> >> There's a lot of people using Xen and Debian, how is the best solution >> for a stable (production) kernel? (Xen+Lenny) ? Use the 2.6.32-10-xen >> sid kernel in production servers?!? >> >> 1) Today >> Dom0 - 2.6.26-2-xen-amd64 >> DomU - 2.6.26-2-xen-amd64 -> BUG #516374 very unstable > > Have you tried the most recent kernel in stable-proposed-updates? I > think that has a few fixes relating to Xen in it (I don't know if they > specifically relate to any "120 seconds" issue though). > > As far as I know your other choices are: > * run a backport of the 2.6.32 kernel (for domU either the -amd64 > one or the -xen-amd64 one, I'd lean towards the former unless > you need features only present in the later). > * Build your own kernel from one of the upstream kernels (either > from xen.org or kernel.org) > * Grab and rebuild a supported Xen kernel from another distro > > I am of the opinion that the 2.6.32 stuff is pretty good for domU use, > although you might want to start with a test deployment on some of you > less critical production servers until you build some confidence of your > own. You'd certainly be doing Debian a valuable service by providing > feedback on how this works for you in practice. > > If you have suitable hardware support you might also consider running a > native 64 bit kernel in an HVM domU. > >> 2) Not possible >> Dom0 - 2.6.26-2-xen-amd64 >> DomU - 2.6.26-2-amd64 -> Error: (2, 'Invalid kernel', >> 'elf_xen_note_check: ERROR: Will only load images built for the >> generic loader or Linux images') > > There was no 64-bit pvops support in 2.6.26 so that kernel has no Xen > support. > >> 3) Ok, but no security >> Dom0 - 2.6.26-2-xen-amd64 >> DomU - 2.6.18-6-xen-amd64 -> OK, etch kernel stable, but no security >> upgrades. > > Correct. > >> 4) Not 64 >> Dom0 - 2.6.26-2-xen-686 -> NOT 64 :( , incompatible >> DomU - 2.6.26-2-686-bigmem -> OK! , but i want to use 64 servers. > > You can run 64 bit dom0 with 32 bit domUs, or a mixture or 32 and 64bit > domUs. Probably not what you want from the sounds of things. > > I'm not sure why you need specifically 64 bit servers, in general Xen's > sweet spot performance wise is 32 bit guests on a 64 bit hypervisor so > if you have no specific need for 64 bit I'd recommend using 32 bit > guests. > > Ian. > > -- > Ian Campbell > > You can go anywhere you want if you look serious and carry a clipboard. > -- 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/dd1d2e611003240553q5ec1727cxeaf603282b3d7...@mail.gmail.com
Bug#516374 Help with Xen kernel
Ok, this bug is fixed in non Xen-specific packages (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516374) , how about the Xen-specific kernels, how to use a non-xen kernel in 64 xen servers? How to keep it stable? There's a lot of people using Xen and Debian, how is the best solution for a stable (production) kernel? (Xen+Lenny) ? Use the 2.6.32-10-xen sid kernel in production servers?!? 1) Today Dom0 - 2.6.26-2-xen-amd64 DomU - 2.6.26-2-xen-amd64 -> BUG #516374 very unstable 2) Not possible Dom0 - 2.6.26-2-xen-amd64 DomU - 2.6.26-2-amd64 -> Error: (2, 'Invalid kernel', 'elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images') 3) Ok, but no security Dom0 - 2.6.26-2-xen-amd64 DomU - 2.6.18-6-xen-amd64 -> OK, etch kernel stable, but no security upgrades. 4) Not 64 Dom0 - 2.6.26-2-xen-686 -> NOT 64 :( , incompatible DomU - 2.6.26-2-686-bigmem -> OK! , but i want to use 64 servers. 5) Others, sid kernel?, is not unstable? is it secure? Thank you. -- 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/dd1d2e611003221124y4ddc0806mb76c49b8782c7...@mail.gmail.com
Re: Task blocked for more than 120 seconds
Thanks for the fast answer! On Thu, Mar 18, 2010 at 3:48 PM, Ben Hutchings wrote: > On Thu, Mar 18, 2010 at 03:31:12PM -0300, Jorge Eduardo Birck wrote: >> Hello. >> >> Im having this error: >> >> "task blocked for more than 120 seconds" >> >> In all my Debian Lenny machines, including production servers. I >> always use Debian and a never seen a kernel bug that make my servers >> freezes before. It makes all my infrastructure (debian and xen based) >> go unstable. >> >> This happend especially when i use high IO disk, but it's hard to >> reproduce the error. It happens sometimes when i remove some big >> files, while i'm reading anothers. If i'm using DRBD and Xen, it >> happens more. > > This error indicates a class of bug, not a specific bug. The Xen kernel > flavour is unfortunately very unstable in lenny, and noone seems to be > able to fix it. Note that you can run the 686-bigmem and amd64 kernels as > domU under Xen, and these appear to be much more stable. > > drbd is a separate module not supported by the kernel team. You can > contact the drbd maintainers at > . > >> My question is, how can i reproduce this error? > > That is not the problem; the problem, is how can *we* reproduce this > error and track it down. We don't have an answer to that. > >> Anyone here has the same problem sometime? > > Yes, see <http://bugs.debian.org/src:linux-2.6>. > >> Its fixed in the last kernel update? > > Some causes have been fixed, others not. > >> I don't > see this problem in Etch. Until when i will have etch security >> upgrades? > > Sorry, etch security support has ended. > >> I saw that others Linux distributions have the same problem, but no >> answers in Google. > > -- > Ben Hutchings > We get into the habit of living before acquiring the habit of thinking. > - Albert Camus > -- 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/dd1d2e611003181156w5d2a6aafqad14e5c8417f0...@mail.gmail.com
Task blocked for more than 120 seconds
Hello. Im having this error: "task blocked for more than 120 seconds" In all my Debian Lenny machines, including production servers. I always use Debian and a never seen a kernel bug that make my servers freezes before. It makes all my infrastructure (debian and xen based) go unstable. This happend especially when i use high IO disk, but it's hard to reproduce the error. It happens sometimes when i remove some big files, while i'm reading anothers. If i'm using DRBD and Xen, it happens more. My question is, how can i reproduce this error? Anyone here has the same problem sometime? Its fixed in the last kernel update? I don't see this problem in Etch. Until when i will have etch security upgrades? I saw that others Linux distributions have the same problem, but no answers in Google. Many thanks. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dd1d2e611003181131t5b8682e2i6a0f1c699f733...@mail.gmail.com
