Discuss April 2009

discuss@lists.centos.org

291 participants
340 discussions

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

Threading and CentOS mailing list digest
by David G. Miller 18 Apr '09

18 Apr '09

Kai Schaetzl <maillists(a)conactive.com> wrote: > John R Pierce wrote on Fri, 17 Apr 2009 04:34:49 -0700: >> > odder, I don't see a "In-Reply-To:" header, so I dunno HOW it appears >> > threaded just fine. >> > > It's been put in the thread according to the time sequence because the > header you mention is missing. So, it just *appears* to be threaded, but > the node where it gets put as a reply is random (here it is put as a reply > to me, that is why I noticed there is something wrong). That header is > missing from all of David's postings, now that I look, and he's been using > several older versions of Thunderbird which can't all be broken. So, I > assume he's using a broken mail gateway which strips these headers. > > Kai Rather than continue to hijack the original thread regarding dual booting, let's move this discussion to it's own thread. The version of T-Bird I use is *always* the current version for CentOS. My mailer is sendmail again kept to the current version for CentOS. I somehow doubt that either are broken. What is happening is I get the CentOS mailing list in digest form. That is, I get one e-mail each day with all of the previous day's posts. If I notice a topic that I feel I can contribute to, I cut and paste an appropriate e-mail from the digest and "reply" to the list setting the subject appropriately (i.e., "Re: <original subject>). This is somewhat of a pain but it is more than made up for by the convenience of getting the list traffic in digest form. Your complaint is the first I've heard that this creates a problem for anyone. Unfortunately, I don't see a way to set the "in reply to" mail header element though T-Bird. If anyone has a reasonable (meaning doesn't take significantly more of my time than my current approach) alternative, I'm more than wiling to change how I'm posting. Giving up getting the list traffic in digest form is not acceptable. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce

5 6

Bind - zone delegation
by Gopinath Achari 18 Apr '09

18 Apr '09

hi all, i have configured a local dns master server test.com the same server is responsible for zone delegation for child.test.com. But starting the named service it displays out of zone data in log file. Same configuration works fine on centos 4.xx but the below configuration is not working on centos 5.2, i have attached the zone file of master server for domain test.com below, $TTL 86400 @ IN SOA test.com. root.test.com. ( 1997022700 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS test.com. child.test.com. IN NS name1.child.test.com. 101 IN PTR test.com. @ IN A 192.168.1.101 www IN A 192.168.1.101 name1.child.test.com. IN A 192.168.1.222 222 IN PTR name1.child.test.com. sys1 IN A 192.168.1.220 ~ ~ when dig command is used reponse comes for hosts entries of test.com but not child.test.com. Any suggestions , please help me out.

1 0

Re: [CentOS] 5.3 and XFS (fwd)
by James A. Peltier 18 Apr '09

18 Apr '09

Doesn't look like my reply hit the list for some reason. -- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier(a)sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca http://blogs.sfu.ca/people/jpeltier MSN : subatomic_spam(a)hotmail.com The point of the HPC scheduler is to keep everyone equally unhappy. ---------- Forwarded message ---------- Date: Fri, 17 Apr 2009 13:35:20 -0700 (PDT) From: James A. Peltier <jpeltier(a)cs.sfu.ca> To: CentOS mailing list <centos(a)centos.org> Subject: Re: [CentOS] 5.3 and XFS On Thu, 16 Apr 2009, Ross Walker wrote: > I think it's worth while to keep xfs updated for a while until ext4 > has made enough of an in-road to say xfs should be depreciated in > favor of ext4. > > -Ross Considering that it still takes several minutes to format a partition with EXT4 vs the couple of seconds for XFS, I don't see XFS depricated *any* time soon. -- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier(a)sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca http://blogs.sfu.ca/people/jpeltier MSN : subatomic_spam(a)hotmail.com The point of the HPC scheduler is to keep everyone equally unhappy.

2 2

Re: [CentOS] Dual-boot with WinXP, CentOS already installed
by Guy Boisvert 17 Apr '09

17 Apr '09

Sorin Srbu wrote: > > Apparantely Windows can bork up after a while if the system files aren't on > C:. I was thinking the Windows installer will see the linux partitions and > try to name them C: and D: etc, thus Windows will be installed on E: or F:, > which might not go down well with some programs. > Unless you install Linux on FAT, Winblows won't see it. Guy Boisvert, ing IngTegration inc.

4 4

problem with 5.3 upgrade or just bad timing?
by Gordon McLellan 17 Apr '09

17 Apr '09

I've been experiencing delays access data off my file server since I upgraded to 5.3... either I hosed something, have bad hardware or very unlikely, found a bug. When reading or writing data, the stream to the hdd's stops every 5-10 min and %iowait goes through the roof. I checked the logs and they are filled with this diagnostic data that I can't readily decipher. my setup involves two md raid5 devices, 9+1 sata drives total, five of them are on the internal intel sata (i5000) controller, five of them on an external super micro (marvell) controller. I need to do some more testing to see which of (or is it both?) of the md devices is generating these errors. system is running centos 5.3 64bit: # 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 # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md1 : active raid5 sdk1[2] sdj1[4] sdi1[3] sdh1[0] sdg1[1] 976783616 blocks level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] md0 : active raid5 sdf1[3] sde1[1] sdd1[4](S) sdc1[0] sdb1[2] 2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU] unused devices: <none> here is what dmesg has to say: (some of it looks like repeats but some of it is very slightly different too) BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Call Trace: [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c [<ffffffff8025c62a>] generic_unplug_device+0x22/0x37 [<ffffffff8835c060>] :raid456:unplug_slaves+0x60/0x9b [<ffffffff8836122f>] :raid456:raid5d+0x17c/0x187 [<ffffffff802639f9>] _spin_lock_irqsave+0x9/0x14 [<ffffffff803fed01>] md_thread+0xf8/0x10e [<ffffffff80299fec>] autoremove_wake_function+0x0/0x2e [<ffffffff803fec09>] md_thread+0x0/0x10e [<ffffffff80233483>] kthread+0xfe/0x132 [<ffffffff8025fb2c>] child_rip+0xa/0x12 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff80233385>] kthread+0x0/0x132 [<ffffffff8025fb22>] child_rip+0x0/0x12 BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Call Trace: [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c [<ffffffff8025c62a>] generic_unplug_device+0x22/0x37 [<ffffffff8835c060>] :raid456:unplug_slaves+0x60/0x9b [<ffffffff8836122f>] :raid456:raid5d+0x17c/0x187 [<ffffffff802639f9>] _spin_lock_irqsave+0x9/0x14 [<ffffffff803fed01>] md_thread+0xf8/0x10e [<ffffffff80299fec>] autoremove_wake_function+0x0/0x2e [<ffffffff803fec09>] md_thread+0x0/0x10e [<ffffffff80233483>] kthread+0xfe/0x132 [<ffffffff8025fb2c>] child_rip+0xa/0x12 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff80233385>] kthread+0x0/0x132 [<ffffffff8025fb22>] child_rip+0x0/0x12 BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Call Trace: [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff8033949e>] cfq_kick_queue+0x0/0x89 [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c [<ffffffff80339514>] cfq_kick_queue+0x76/0x89 [<ffffffff8024ee1e>] run_workqueue+0x94/0xe4 [<ffffffff8024b727>] worker_thread+0x0/0x122 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff8024b817>] worker_thread+0xf0/0x122 [<ffffffff80286daf>] default_wake_function+0x0/0xe [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff80233483>] kthread+0xfe/0x132 [<ffffffff8025fb2c>] child_rip+0xa/0x12 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff8026df02>] monotonic_clock+0x35/0x7b [<ffffffff80233385>] kthread+0x0/0x132 [<ffffffff8025fb22>] child_rip+0x0/0x12 BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Call Trace: [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c [<ffffffff8025c62a>] generic_unplug_device+0x22/0x37 [<ffffffff8835c060>] :raid456:unplug_slaves+0x60/0x9b [<ffffffff8836122f>] :raid456:raid5d+0x17c/0x187 [<ffffffff802639f9>] _spin_lock_irqsave+0x9/0x14 [<ffffffff803fed01>] md_thread+0xf8/0x10e [<ffffffff80299fec>] autoremove_wake_function+0x0/0x2e [<ffffffff803fec09>] md_thread+0x0/0x10e [<ffffffff80233483>] kthread+0xfe/0x132 [<ffffffff8025fb2c>] child_rip+0xa/0x12 [<ffffffff80299dd4>] keventd_create_kthread+0x0/0xc4 [<ffffffff80233385>] kthread+0x0/0x132 [<ffffffff8025fb22>] child_rip+0x0/0x12 BUG: warning at drivers/ata/libata-core.c:4923/ata_qc_issue() (Tainted: G ) Call Trace: <IRQ> [<ffffffff880b6625>] :libata:ata_qc_issue+0x61/0x4a9 [<ffffffff880bacf3>] :libata:ata_scsi_rw_xlat+0x119/0x188 [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff880babda>] :libata:ata_scsi_rw_xlat+0x0/0x188 [<ffffffff880baea2>] :libata:ata_scsi_translate+0x140/0x16d [<ffffffff880735a6>] :scsi_mod:scsi_done+0x0/0x18 [<ffffffff880bda72>] :libata:ata_scsi_queuecmd+0x1b4/0x1d4 [<ffffffff88073c83>] :scsi_mod:scsi_dispatch_cmd+0x290/0x322 [<ffffffff880790e2>] :scsi_mod:scsi_request_fn+0x2c5/0x39c [<ffffffff8025e2f2>] blk_run_queue+0x41/0x72 [<ffffffff88078016>] :scsi_mod:scsi_next_command+0x2d/0x39 [<ffffffff88078174>] :scsi_mod:scsi_end_request+0xbf/0xcd [<ffffffff880782d0>] :scsi_mod:scsi_io_completion+0x14e/0x324 [<ffffffff880a57cd>] :sd_mod:sd_rw_intr+0x21d/0x257 [<ffffffff88078565>] :scsi_mod:scsi_device_unbusy+0x67/0x81 [<ffffffff802389b8>] blk_done_softirq+0x67/0x75 [<ffffffff80212880>] __do_softirq+0x8d/0x13b [<ffffffff8025fda4>] call_softirq+0x1c/0x278 [<ffffffff8026d08e>] do_softirq+0x31/0x98 [<ffffffff8026cf09>] do_IRQ+0xec/0xf5 [<ffffffff803a6cca>] evtchn_do_upcall+0x13b/0x1fb [<ffffffff8025f8d6>] do_hypervisor_callback+0x1e/0x2c <EOI> [<ffffffff8026df02>] monotonic_clock+0x35/0x7b [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 [<ffffffff802063aa>] hypercall_page+0x3aa/0x1000 [<ffffffff8026e4e5>] raw_safe_halt+0x84/0xa8 [<ffffffff8026ba22>] xen_idle+0x38/0x4a [<ffffffff8024a803>] cpu_idle+0x97/0xba var/log/messages has the same info, with timestamps - this error repeats itself several times a second for several minutes at a time all suggestions are appreciated! -Gordon

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
34
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss April 2009