Discuss

discuss@lists.centos.org

34753 discussions

centos 5.3 upgrade and duplicate processes running
by Melinda Odom 20 Apr '09

20 Apr '09

Hi, I have a P4 3.2 linux server. Every since I upgrade to centos 5.3 I see duplicates when running top - c like: 3 root 34 19 0 0 0 S 0.0 0.0 0:00.13 [ksoftirqd/0] 4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 [watchdog/0] 5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 [migration/1] 6 root 34 19 0 0 0 S 0.0 0.0 0:00.64 [ksoftirqd/1] 7 root RT -5 0 0 0 S 0.0 0.0 0:00.00 [watchdog/1] 8 root 10 -5 0 0 0 S 0.0 0.0 0:00.03 [events/0] 9 root 10 -5 0 0 0 S 0.0 0.0 0:00.12 [events/1] 10 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 [khelper] 11 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 [kthread] 15 root 10 -5 0 0 0 S 0.0 0.0 0:02.17 [kblockd/0] 16 root 10 -5 0 0 0 S 0.0 0.0 0:03.28 [kblockd/1] 17 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 [kacpid] 90 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 [cqueue/0] 91 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 [cqueue/1] 94 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 [khubd] 96 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 [kseriod] 160 root 15 0 0 0 0 S 0.0 0.0 0:12.92 [pdflush] 161 root 15 0 0 0 0 S 0.0 0.0 0:21.17 [pdflush] I don't have watchdog installed either. It seems my load has also gone up How would I fix this so there are not duplicates running? Best Regards, Melinda Odom Design Hosting, Inc. Web Design, Web Hosting, & Ecommerce Solutions 479-471-0891 CST info(a)designhosting.biz http://www.designhosting.biz

4 3

rpmbuild failure
by lhecking＠users.sourceforge.net 20 Apr '09

20 Apr '09

I'm trying to rebuild nx-3.2.0-8.el5.centos.src.rpm from the extras repo. It works on a machine running 5.1, but fails on another running 5.3. The working machine is arch=x86_64, the other i386. The strange bit is the line rpmbuild complains about: it's the last line in the spec file, at the end of the %changelog section: [...] Processing files: nx-debuginfo-3.2.0-8 Finding Provides: /usr/src/redhat/SOURCES/nxfind-provides.sh error: line 352: Dependency tokens must begin with alpha-numeric, '_' or '/': - Updated SuSE package to work with Fedora error: Failed to find Provides: Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/nx-3.2.0-8-root-root RPM build errors: line 352: Dependency tokens must begin with alpha-numeric, '_' or '/': - Updated SuSE package to work with Fedora Failed to find Provides: #

1 1

Re: [CentOS] Dual-boot with WinXP, CentOS already installed
by JohnS 20 Apr '09

20 Apr '09

On Thu, 2009-04-16 at 14:08 +0200, Sorin Srbu wrote: > Hi all, > > I'd like to deploy a solution with dual-booting systems where CentOS 5.3 is > already installed and WinXP will be installed to a separate disk. > > I found > http://apcmag.com/how_to_dual_boot_linux_and_windows_xp_linux_installed_fir… > and it seems straight forward enough, although the description is for Ubuntu. > > The problem as I see it, is that the how-to differs from how CentOS looks in > /etc/grub.conf and the boot-loader in Ubuntu with respect to making grub work > again after the Windows install. > > I found Tldp.org mentioning dual-boot plenty, but most or all articles listed > are using lilo as a boot-loader, which seems a bit obsolete and besides I > can't quite translate the instructions from lilo to grub. 8-/ > > Basically, what would I need to change in the how-to from apcmag.com above?? > Thanks for any pointers. ---- Just one question for you.. What brand of mother board do you have? There is a better way than trying to kill an OS via Grub or any boot loader via software. JohnStanley

2 1

The law difference between country
by Hidetsugu Hiraki 20 Apr '09

20 Apr '09

Dear Madam or Sir, I live in Japan. So I must comply with the nation's law. When I install software for Linux, is there any easy way to know whether the the installation and use of the software is legal or not? Please teach me. Hiraki

3 4

OT: Possible for Malware against Windows boxes to attack Firefox on Linux?
by Lanny Marcus 19 Apr '09

19 Apr '09

My belief is that this is not possible, but there are many extremely knowledgeable people participating on this list and I would like to know if it is in fact possible. I am running CentOS 5.3 (32 bit) fully updated. Browser is Mozilla Firefox v.3.0.7. I believe both times this happened, once yesterday and once today, I was surfing on the web site of my favorite singer/musical group; or in the forum, which is a highly restricted area. Today when it happened, I believe I was looking at a video coming from YouTube.com I contacted the webmaster, someone I communicate with frequently, thinking that something on one or more of his web pages is infected, but he wrote back, thinking that my box (dual boot MS Windows XP and CentOS on the same hard drive) is infected by this malware and that his web site is clean. Below is part of the description he sent me in an email. I have seen the pop ups, a request to install Install-2006-60.exe which I declined...., etc. Comes from <http://antispywarepcscanner.com> Is there any way the Firefox web browser could have been corrupted by this, while using CentOS Linux? TIA! Lanny 16.04.2009 | Malware Type: Browser Hijackers Malware Description: Antispywarepcscanner.com appears to be another web pimp of the hazardous fake anti-spyware tool called Personal Antivirus. Do not get flattered by the seemingly decent-looking and pleasant design of Antispywarepcscanner.com website; the fact that it pushes rogue anti-spyware automatically makes this domain a fraudulent one. Besides, Antispywarepcscanner.com may act as an obsessive browser-hijacker that redirects your web-surfing to its URL without the slightest hint of your approval. The forced diverts to Antispywarepcscanner.com are explainable by the fact that these redirections are preceded by the intrusion of Zlob trojans that obscurely trespass on your PC and forcedly modify browser settings. When you hit Antispywarepcscanner.com, you will see either the misleading advertising of Personal Antivirus scareware, or witness the deceptive online scan performed by the above-mentioned rogue utility. No matter what tricks the fraudsters prepared for you on Antispywarepcscanner.com, do not believe a single thing you see on that site. The advertising misinformation praising Personal Antivirus is totally deceptive and ought to be ignored. The worst thing about Antispywarepcscanner.com is that you will keep getting redirected there until you do something about the malicious activity of the corresponding hijacker on your computer. So, you first and the most reasonable step should be Antispywarepcscanner.com hijacker removal. After that, you are strongly recommended to check your system for additional malware with the aid of a trustworthy automatic removal tool

12 27

X won't start
by Robert 19 Apr '09

19 Apr '09

This machine is running CentOS 5.3, fully updated Linux mavis.localdomain 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 athlon i386 GNU/Linux. Video is an ATI Radeon 9000. X froze overnight and attempts to restart it fail. I tried an old kernel (2.6.18-92.1.22.el5) before realizing that root can start X and a virgin user can start X. I still can't use my original user name. I'm sure the last line of this is telling me something that I'm missing. (**) RADEON(0): RADEONDRIStop (**) RADEON(0): EngineRestore (16/16) (**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0) (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x9d2831c) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000000c 0x00030065 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3 (**) RADEON(0): Disposing accel... (**) RADEON(0): Disposing cusor info (**) RADEON(0): Disposing DGA (**) RADEON(0): Unmapping memory (**) RADEON(0): RADEONDRICloseScreen FreeFontPath: FPE "unix/:7100" refcount is 2, should be 1; fixing. If it matters I normally boot into run level 3, log in and issue "startx" from the BASH prompt. Any ideas welcome.

3 5

Re: [CentOS] httpd crashes after signal HUP
by Per Qvindesland 19 Apr '09

19 Apr '09

Have you tried this: http://www.electrictoolbox.com/seg-fault-or-similar-nasty-error/ Per --- Original message follows --- SUBJECT: Re: [CentOS] httpd crashes after signal HUP FROM: "RedShift" TO: "CentOS mailing list" DATE: 19-04-2009 9:49 >----- Oorspronkelijk bericht ----- >Van : RedShift [mailto:redshift@pandora.be] >Verzonden : zondag , april 19, 2009 09:42 AM >Aan : centos(a)centos.org >Onderwerp : [CentOS] httpd crashes after signal HUP > >Hello > > >I'm running CentOS 5.3 with httpd-2.2.3-22.el5.centos.x86_64 and php-5.1.6-23.2.el5_3.x86_64. When the logrotate scripts run and send the HUP signal to httpd, the httpd process quits instead of reloading. The only thing I can find in the logs is this: > >[Sun Apr 19 04:02:04 2009] [notice] seg fault or similar nasty error detected in the parent process > >There wasn't any segfault reported in dmesg and I couldn't find anything else in the other logs (messages, etc...) > >It's reproducable every time, when I send the HUP signal to the master httpd process the same thing happens. > >My configuration is nothing special, just the stock one, with a few unnecesary modules commented out and one virtual host. > A follow-up, I cannot seem to reproduce this on my laptop (using i386 instead of x86_64) with the same configuration. Glenn _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos

3 4

httpd crashes after signal HUP
by RedShift 19 Apr '09

19 Apr '09

Hello I'm running CentOS 5.3 with httpd-2.2.3-22.el5.centos.x86_64 and php-5.1.6-23.2.el5_3.x86_64. When the logrotate scripts run and send the HUP signal to httpd, the httpd process quits instead of reloading. The only thing I can find in the logs is this: [Sun Apr 19 04:02:04 2009] [notice] seg fault or similar nasty error detected in the parent process There wasn't any segfault reported in dmesg and I couldn't find anything else in the other logs (messages, etc...) It's reproducable every time, when I send the HUP signal to the master httpd process the same thing happens. My configuration is nothing special, just the stock one, with a few unnecesary modules commented out and one virtual host. Thanks, Glenn

1 1

Re: [CentOS] httpd crashes after signal HUP
by RedShift 19 Apr '09

19 Apr '09

>----- Oorspronkelijk bericht ----- >Van : RedShift [mailto:redshift@pandora.be] >Verzonden : zondag , april 19, 2009 09:42 AM >Aan : centos(a)centos.org >Onderwerp : [CentOS] httpd crashes after signal HUP > >Hello > > >I'm running CentOS 5.3 with httpd-2.2.3-22.el5.centos.x86_64 and php-5.1.6-23.2.el5_3.x86_64. When the logrotate scripts run and send the HUP signal to httpd, the httpd process quits instead of reloading. The only thing I can find in the logs is this: > >[Sun Apr 19 04:02:04 2009] [notice] seg fault or similar nasty error detected in the parent process > >There wasn't any segfault reported in dmesg and I couldn't find anything else in the other logs (messages, etc...) > >It's reproducable every time, when I send the HUP signal to the master httpd process the same thing happens. > >My configuration is nothing special, just the stock one, with a few unnecesary modules commented out and one virtual host. > A follow-up, I cannot seem to reproduce this on my laptop (using i386 instead of x86_64) with the same configuration. Glenn

1 0

[centos] libata-core kernel errors
by Gordon McLellan 18 Apr '09

18 Apr '09

This is a repost of sorts, and for that I am sorry; I do not think my original posting subject was very clear, and I have more data about the problem. I'm experiencing lots of kernel errors when reading or writing to a disk that is part of an mdadm softraid-5 array. Since originally detecting this problem, I have isolated it to one disk, but I'm not sure what the cause of the error is. I have torn down the array and have been testing the actual device now. I tested the drive several times using smartctl and the tests came back OK / PASSED each time, and no kernel errors were logged. I tested the drive with the "badblocks" command, and there were no problems reported, and no kernel errors were logged. As soon as I try to write any substantial data to the device, kernel errors start pouring in: # dd if=/dev/zero of=/dev/sdg oflag=sync bs=8M count=100 The dd command does its thing, and eventually finishes without error, but at a very slow speed, most of my drives run this command at 65-75mb/sec, and sdg completes it at 13mb/sec. Apr 18 01:10:00 xenmaster kernel: BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: Call Trace: Apr 18 01:10:00 xenmaster kernel: <IRQ> [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd Apr 18 01:10:00 xenmaster kernel: [<ffffffff880782d0>] :scsi_mod:scsi_io_completion+0x14e/0x324 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880a57cd>] :sd_mod:sd_rw_intr+0x21d/0x257 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078565>] :scsi_mod:scsi_device_unbusy+0x67/0x81 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802389b8>] blk_done_softirq+0x67/0x75 Apr 18 01:10:00 xenmaster kernel: [<ffffffff80212880>] __do_softirq+0x8d/0x13b Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025fda4>] call_softirq+0x1c/0x278 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026d08e>] do_softirq+0x31/0x98 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026cf09>] do_IRQ+0xec/0xf5 Apr 18 01:10:00 xenmaster kernel: [<ffffffff803a6cca>] evtchn_do_upcall+0x13b/0x1fb Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025f8d6>] do_hypervisor_callback+0x1e/0x2c Apr 18 01:10:00 xenmaster kernel: <EOI> [<ffffffff8026df02>] monotonic_clock+0x35/0x7b Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026e4e5>] raw_safe_halt+0x84/0xa8 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026ba22>] xen_idle+0x38/0x4a Apr 18 01:10:00 xenmaster kernel: [<ffffffff8024a803>] cpu_idle+0x97/0xba Apr 18 01:10:00 xenmaster kernel: [<ffffffff80634b09>] start_kernel+0x21f/0x224 Apr 18 01:10:00 xenmaster kernel: [<ffffffff806341e5>] _sinittext+0x1e5/0x1eb Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: Call Trace: Apr 18 01:10:00 xenmaster kernel: <IRQ> [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd Apr 18 01:10:00 xenmaster kernel: [<ffffffff880782d0>] :scsi_mod:scsi_io_completion+0x14e/0x324 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880a57cd>] :sd_mod:sd_rw_intr+0x21d/0x257 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078565>] :scsi_mod:scsi_device_unbusy+0x67/0x81 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802389b8>] blk_done_softirq+0x67/0x75 Apr 18 01:10:00 xenmaster kernel: [<ffffffff80212880>] __do_softirq+0x8d/0x13b Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025fda4>] call_softirq+0x1c/0x278 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026d08e>] do_softirq+0x31/0x98 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026cf09>] do_IRQ+0xec/0xf5 Apr 18 01:10:00 xenmaster kernel: [<ffffffff803a6cca>] evtchn_do_upcall+0x13b/0x1fb Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025f8d6>] do_hypervisor_callback+0x1e/0x2c Apr 18 01:10:00 xenmaster kernel: <EOI> [<ffffffff8026df02>] monotonic_clock+0x35/0x7b Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026e4e5>] raw_safe_halt+0x84/0xa8 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026ba22>] xen_idle+0x38/0x4a Apr 18 01:10:00 xenmaster kernel: [<ffffffff8024a803>] cpu_idle+0x97/0xba Apr 18 01:10:00 xenmaster kernel: [<ffffffff80634b09>] start_kernel+0x21f/0x224 Apr 18 01:10:00 xenmaster kernel: [<ffffffff806341e5>] _sinittext+0x1e5/0x1eb Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: Call Trace: Apr 18 01:10:00 xenmaster kernel: <IRQ> [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd Apr 18 01:10:00 xenmaster kernel: [<ffffffff880782d0>] :scsi_mod:scsi_io_completion+0x14e/0x324 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880a57cd>] :sd_mod:sd_rw_intr+0x21d/0x257 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078565>] :scsi_mod:scsi_device_unbusy+0x67/0x81 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802389b8>] blk_done_softirq+0x67/0x75 Apr 18 01:10:00 xenmaster kernel: [<ffffffff80212880>] __do_softirq+0x8d/0x13b Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025fda4>] call_softirq+0x1c/0x278 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026d08e>] do_softirq+0x31/0x98 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026cf09>] do_IRQ+0xec/0xf5 Apr 18 01:10:00 xenmaster kernel: [<ffffffff803a6cca>] evtchn_do_upcall+0x13b/0x1fb Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025f8d6>] do_hypervisor_callback+0x1e/0x2c Apr 18 01:10:00 xenmaster kernel: <EOI> [<ffffffff8026df02>] monotonic_clock+0x35/0x7b Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026e4e5>] raw_safe_halt+0x84/0xa8 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026ba22>] xen_idle+0x38/0x4a Apr 18 01:10:00 xenmaster kernel: [<ffffffff8024a803>] cpu_idle+0x97/0xba Apr 18 01:10:00 xenmaster kernel: [<ffffffff80634b09>] start_kernel+0x21f/0x224 Apr 18 01:10:00 xenmaster kernel: [<ffffffff806341e5>] _sinittext+0x1e5/0x1eb Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: Call Trace: Apr 18 01:10:00 xenmaster kernel: <IRQ> [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd Apr 18 01:10:00 xenmaster kernel: [<ffffffff880782d0>] :scsi_mod:scsi_io_completion+0x14e/0x324 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880a57cd>] :sd_mod:sd_rw_intr+0x21d/0x257 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078565>] :scsi_mod:scsi_device_unbusy+0x67/0x81 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802389b8>] blk_done_softirq+0x67/0x75 Apr 18 01:10:00 xenmaster kernel: [<ffffffff80212880>] __do_softirq+0x8d/0x13b Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025fda4>] call_softirq+0x1c/0x278 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026d08e>] do_softirq+0x31/0x98 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026cf09>] do_IRQ+0xec/0xf5 Apr 18 01:10:00 xenmaster kernel: [<ffffffff803a6cca>] evtchn_do_upcall+0x13b/0x1fb Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025f8d6>] do_hypervisor_callback+0x1e/0x2c Apr 18 01:10:00 xenmaster kernel: <EOI> [<ffffffff8026df02>] monotonic_clock+0x35/0x7b Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026e4e5>] raw_safe_halt+0x84/0xa8 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026ba22>] xen_idle+0x38/0x4a Apr 18 01:10:00 xenmaster kernel: [<ffffffff8024a803>] cpu_idle+0x97/0xba Apr 18 01:10:00 xenmaster kernel: [<ffffffff80634b09>] start_kernel+0x21f/0x224 Apr 18 01:10:00 xenmaster kernel: [<ffffffff806341e5>] _sinittext+0x1e5/0x1eb Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Apr 18 01:10:00 xenmaster kernel: Apr 18 01:10:00 xenmaster kernel: Call Trace: Apr 18 01:10:00 xenmaster kernel: <IRQ> [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d Apr 18 01:10:00 xenmaster kernel: [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd Apr 18 01:10:00 xenmaster kernel: [<ffffffff880782d0>] :scsi_mod:scsi_io_completion+0x14e/0x324 Apr 18 01:10:00 xenmaster kernel: [<ffffffff880a57cd>] :sd_mod:sd_rw_intr+0x21d/0x257 Apr 18 01:10:00 xenmaster kernel: [<ffffffff88078565>] :scsi_mod:scsi_device_unbusy+0x67/0x81 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802389b8>] blk_done_softirq+0x67/0x75 Apr 18 01:10:00 xenmaster kernel: [<ffffffff80212880>] __do_softirq+0x8d/0x13b Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025fda4>] call_softirq+0x1c/0x278 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026d08e>] do_softirq+0x31/0x98 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026cf09>] do_IRQ+0xec/0xf5 Apr 18 01:10:00 xenmaster kernel: [<ffffffff803a6cca>] evtchn_do_upcall+0x13b/0x1fb Apr 18 01:10:00 xenmaster kernel: [<ffffffff8025f8d6>] do_hypervisor_callback+0x1e/0x2c Apr 18 01:10:00 xenmaster kernel: <EOI> [<ffffffff8026df02>] monotonic_clock+0x35/0x7b Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026e4e5>] raw_safe_halt+0x84/0xa8 Apr 18 01:10:00 xenmaster kernel: [<ffffffff8026ba22>] xen_idle+0x38/0x4a Apr 18 01:10:00 xenmaster kernel: [<ffffffff8024a803>] cpu_idle+0x97/0xba Apr 18 01:10:00 xenmaster kernel: [<ffffffff80634b09>] start_kernel+0x21f/0x224 Apr 18 01:10:00 xenmaster kernel: [<ffffffff806341e5>] _sinittext+0x1e5/0x1eb The machine in question is running 64bit Centos 5.3 Xen kernel and is Dom0: # uname -a Linux xenmaster.dimension-x.local 2.6.18-128.1.6.el5xen #1 SMP Wed Apr 1 09:53:14 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux This problem started about five days ago, when I upgraded from 5.2 to 5.3. I'm not sure if that was the cause or just a coincidence. Any suggestions? -Gordon

4 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss