January 2010 - Arch-general - lists.archlinux.org

[arch-general] high CPU temperature with 2.6.32
by Dimitrios Apostolou 07 Jan '10

07 Jan '10

Hello, pacman just brought kernel 2.6.32 for my old laptop (P3 500MHz). A strange thing I noticed is that the fan won't go off when CPU is idling like it used to. Using powertop I can see more than 100K wakeups/s (extra_timer_interrupt is first on the list but I think it's irrelevant since it only shows about 100 wakeups), and the CPU is not going into C2 mode at all. Strangely however the cpu is 99% idle, and top doesn't show "system" or "user" cpu usage. Anyone else seeing such behaviour? Thanks in advance, Dimitris

6 10

Re: [arch-general] [arch-dev-public] Cron
by Jim Pryor 07 Jan '10

07 Jan '10

On Mon, Jan 04, 2010 at 09:52:45AM -0600, Aaron Griffin wrote: > On Mon, Jan 4, 2010 at 9:51 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > > On Sun, Jan 3, 2010 at 9:28 PM, Allan McRae <allan(a)archlinux.org> wrote: > >> Paul Mattal wrote: > >>> > >>> We've got several bugs relating to choosing a new default cron daemon, > >>> and/or supporting other alternatives. > >> > >> <snip> > >> > >> I thought we decided on fcron with the small adjustment/script needed to > >> support /etc/cron.d in the last round of discussion about this. bcron was > >> also popular (+1 from me...) but then we need an anacron replacement too > >> (i.e. fcron). > >> > >> Aaron has repeatedly called for someone to deal with this and we have had a > >> total of zero volunteers to do so... So if you are going to do this then it > >> would be great. (also have a look at mailman in svn trunk if you have time > >> :P ) > > > > Allan is correct here. We looked it over and based on the responses > > from all devs at the time, decided that fcron is the best in terms of > > modernizing our cron. > > > > If anyone would like to upgrade our cron to something better, let's go > > with fcron. Please check the mail archives and bug reports for all the > > discussion about alternative crons and why fcron was decided. I don't > > recall all the reasons, but I know they are all there. > > Though, I must admit, I did not see this email until after I replied. > yacron was not evaluated when we looked into this... Hi this is the author of yacron again. I've just heard from Matt Dillon, he says he's happy for me to take over development and maintainership of dcron. So what I'll do is create a release version of yacron, and rename it to dcron 4.0. Of course that doesn't mean Arch has to keep using dcron; you may still decide fcron is better for core. But if you do want to stay with dcron, its development will now continue with the features I had forked as yacron. -- Jim Pryor profjim(a)jimpryor.net

6 6

[arch-general] How does dmraid handle the development of a bad block on 1 drive in an array??
by David C. Rankin 06 Jan '10

06 Jan '10

Listmates (Tobias) I have a server that has 2 dmraid arrays (4 drives -> 2 arrays) that has been bullet-proof for years. A month ago (either coincidentally or due to a bug in the suse 11.2 kernel for client ssh/sftp sessions) I began experiencing sda errors on the array comprised of sda/sdc drives. The errors took the form of: Dec 5 20:48:48 nirvana sshd[30922]: error: ssh_msg_send: write Dec 5 20:49:10 nirvana sshd[30965]: Accepted keyboard-interactive/pam for legaleagle from 192.168.6.102 port 36 663 ssh2 Dec 5 20:50:12 nirvana kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Dec 5 20:50:12 nirvana kernel: ata3.00: BMDMA stat 0x25 Dec 5 20:50:12 nirvana kernel: ata3.00: cmd 25/00:08:33:0c:8c/00:00:34:00:00/e0 tag 0 cdb 0x0 data 4096 in Dec 5 20:50:12 nirvana kernel: res 51/40:00:39:0c:8c/40:00:34:00:00/e0 Emask 0x9 (media error) Dec 5 20:50:12 nirvana kernel: ata3.00: configured for UDMA/133 Dec 5 20:50:12 nirvana kernel: ata3: EH complete Dec 5 20:50:14 nirvana kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Dec 5 20:50:14 nirvana kernel: ata3.00: BMDMA stat 0x25 Dec 5 20:50:14 nirvana kernel: ata3.00: cmd 25/00:08:33:0c:8c/00:00:34:00:00/e0 tag 0 cdb 0x0 data 4096 in Dec 5 20:50:14 nirvana kernel: res 51/40:00:39:0c:8c/40:00:34:00:00/e0 Emask 0x9 (media error) Dec 5 20:50:14 nirvana kernel: ata3.00: configured for UDMA/133 Dec 5 20:50:14 nirvana kernel: ata3: EH complete Dec 5 20:50:16 nirvana kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Dec 5 20:50:16 nirvana kernel: ata3.00: BMDMA stat 0x25 Dec 5 20:50:16 nirvana kernel: ata3.00: cmd 25/00:08:33:0c:8c/00:00:34:00:00/e0 tag 0 cdb 0x0 data 4096 in Dec 5 20:50:23 nirvana kernel: res 51/40:00:39:0c:8c/40:00:34:00:00/e0 Emask 0x9 (media error) Dec 5 20:50:23 nirvana kernel: ata3.00: configured for UDMA/133 Dec 5 20:50:23 nirvana kernel: ata3: EH complete Dec 5 20:50:23 nirvana kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Dec 5 20:50:23 nirvana kernel: ata3.00: BMDMA stat 0x25 Dec 5 20:50:23 nirvana kernel: ata3.00: cmd 25/00:08:33:0c:8c/00:00:34:00:00/e0 tag 0 cdb 0x0 data 4096 in Dec 5 20:50:23 nirvana kernel: res 51/40:00:39:0c:8c/40:00:34:00:00/e0 Emask 0x9 (media error) Dec 5 20:50:23 nirvana kernel: ata3.00: configured for UDMA/133 Dec 5 20:50:23 nirvana kernel: ata3: EH complete Dec 5 20:50:23 nirvana kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Dec 5 20:50:23 nirvana kernel: ata3.00: BMDMA stat 0x25 Dec 5 20:50:23 nirvana kernel: ata3.00: cmd 25/00:08:33:0c:8c/00:00:34:00:00/e0 tag 0 cdb 0x0 data 4096 in Dec 5 20:50:23 nirvana kernel: res 51/40:00:39:0c:8c/40:00:34:00:00/e0 Emask 0x9 (media error) Dec 5 20:50:23 nirvana kernel: ata3.00: configured for UDMA/133 Dec 5 20:50:23 nirvana kernel: ata3: EH complete Dec 5 20:50:23 nirvana kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Dec 5 20:50:23 nirvana kernel: ata3.00: BMDMA stat 0x25 Dec 5 20:50:23 nirvana kernel: ata3.00: cmd 25/00:08:33:0c:8c/00:00:34:00:00/e0 tag 0 cdb 0x0 data 4096 in Dec 5 20:50:23 nirvana kernel: res 51/40:00:39:0c:8c/40:00:34:00:00/e0 Emask 0x9 (media error) Dec 5 20:50:23 nirvana kernel: ata3.00: configured for UDMA/133 Dec 5 20:50:23 nirvana kernel: sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK Dec 5 20:50:23 nirvana kernel: sd 2:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor] Dec 5 20:50:23 nirvana kernel: Descriptor sense data with sense descriptors (in hex): Dec 5 20:50:23 nirvana kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Dec 5 20:50:23 nirvana kernel: 34 8c 0c 39 Dec 5 20:50:23 nirvana kernel: sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed Dec 5 20:50:23 nirvana kernel: end_request: I/O error, dev sda, sector 881593401 Dec 5 20:50:23 nirvana kernel: ata3: EH complete Dec 5 20:50:23 nirvana kernel: sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB) Dec 5 20:50:23 nirvana kernel: sd 2:0:0:0: [sda] Write Protect is off Dec 5 20:50:23 nirvana kernel: sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 Dec 5 20:50:23 nirvana kernel: sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Booting from the install disk, assembling the arrays and fsck'ing -c -y the individual disks found a bad block on sda, corrected the problem and things were fine for a month. Then the same sda error appeared. Currently I have disabled dmraid and have the two disks running independently with zero errors. I'm keeping the contents mirrored with a cron job that basically does a 'cp -a / /mnt/sda' where sdc is the disk that is booted from and sda is mounted at /mnt/sda. This experience has raised a question that I can't find the answer to: "How does dmraid handle a bad block?" Also (hardware issues aside), is there anything from a kernel/drive controller standpoint that could be invoking the error? After running the disks independently for a week without a single error, I think I'll reassemble the array and rebuild it. Any other thoughts/suggestions? Obviously there was a bad block that developed on sda, but adding it to the bad block table fixed it. I have a pair of 750 G drives coming to replace this set, but I'm curious about the bad block handling with dmraid. If 1 bad block is enough to kill the array, then that's not a very robust system. The disks are both seagate 500G drives (ST3500641AS). The system hardware is: System Information Manufacturer: TYAN Computer Corp Product Name: S2865 BIOS Information Vendor: Phoenix Technologies, LTD Version: 6.00 PG Release Date: 06/20/2005 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 512 kB Characteristics: Processor Information Socket Designation: Socket 939 Type: Central Processor Family: Athlon 64 Manufacturer: AMD ID: 32 0F 02 00 FF FB 8B 17 Signature: Family 15, Model 35, Stepping 2 All thoughts welcomed... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 1

[arch-general] Strange outpu from latest qemu-kvm
by Damjan Georgievski 06 Jan '10

06 Jan '10

Just updated to qemu-kvm 0.12.1.2-1 here, and now when I start a VM I get this: $ qemu-kvm -m 384 -drive file=karmic.img,if=virtio,boot=on -vnc :0 -monitor unix:mon/karmick.sock,server,nowait -daemonize profiling:/home/tobias:Cannot create directory profiling:/home/tobias/Arch/svn/svn-packages/vde2/trunk/src/vde2-2.2.2/src/lib/.libs/libvdeplug.gcda:Skip profiling:/home/tobias:Cannot create directory profiling:/home/tobias/Arch/svn/svn-packages/vde2/trunk/src/vde2-2.2.2/src/common/.libs/cmdparse.gcda:Skip profiling:/home/tobias:Cannot create directory profiling:/home/tobias/Arch/svn/svn-packages/vde2/trunk/src/vde2-2.2.2/src/common/.libs/canonicalize.gcda:Skip profiling:/home/tobias:Cannot create directory profiling:/home/tobias/Arch/svn/svn-packages/vde2/trunk/src/vde2-2.2.2/src/lib/.libs/libvdeplug.gcda:Skip profiling:/home/tobias:Cannot create directory profiling:/home/tobias/Arch/svn/svn-packages/vde2/trunk/src/vde2-2.2.2/src/common/.libs/cmdparse.gcda:Skip profiling:/home/tobias:Cannot create directory profiling:/home/tobias/Arch/svn/svn-packages/vde2/trunk/src/vde2-2.2.2/src/common/.libs/canonicalize.gcda:Skip The VM seems to work fine otherwise. -- damjan

1 0

[arch-general] Tiny webserver to run as root
by RedShift 05 Jan '10

05 Jan '10

Hi all Does anyone have a suggestion for some software, a tiny webserver that is able to run as root and execute CGI scripts? It should be smaller than apache and preferably even smaller than lighttpd. It doesn't need a whole lot of features, it only needs to be able to execute CGI scripts. I have tried a few: nanoweb (which is written in php as well) but has some problems with CGI scripts and when it runs in multi process mode it brings the system load up to exactly 1.00. Nullhttpd, but it's old and unmaintained. Tinyhttpd isn't up for the job as well (kept crashing at times). Thanks, Best regards, Glenn

9 8

[arch-general] Shutdown Issue
by GTR 05 Jan '10

05 Jan '10

Hi I am using Gnome 2.28, and added the shutdown item to the panel. While using the shutdown button from the panel, the screen garbles up, and i don't see the normal shutdown messages, but the computer still shuts down normally. nothing is logged related to this. While using any other shutdown method (console, or even system -> shutdown), all the shutdown messages are displayed (the daemons switching off, etc) and the computer shuts down normally. I would like to know, what script does that button call, that probably leads to the above issue.

1 0

Re: [arch-general] [arch-dev-public] Cron
by Heiko Baums 04 Jan '10

04 Jan '10

Am Mon, 4 Jan 2010 09:52:45 -0600 schrieb Aaron Griffin <aaronmgriffin(a)gmail.com>: > Though, I must admit, I did not see this email until after I replied. > yacron was not evaluated when we looked into this... From Jim's explanations I think that it could be worth testing yacron, too. Greetings, Heiko

1 0

[arch-general] Replies on arch-general to dev emails (was: Cron)
by Dan McGee 04 Jan '10

04 Jan '10

On Mon, Jan 4, 2010 at 12:35 AM, Heiko Baums <lists(a)baums-on-web.de> wrote: > > I again answer to arch-general due to write permissions. > You realize you don't need to say this *every single time* you answer an email from arch-dev-public? We do this (restrict who can post to that list) quite on purpose, and this is the defined method of answering these emails. Every dev subscribes to this list too so it isn't like your email is getting lost. -Dan

5 5

Re: [arch-general] [arch-dev-public] Cron
by Heiko Baums 04 Jan '10

04 Jan '10

Answering to arch-general again. ;-) Am Mon, 4 Jan 2010 10:51:29 +0100 schrieb Dieter Plaetinck <dieter(a)plaetinck.be>: > When a crontab is missed due to system downtime, sometimes you want > the crontab to be done when the system boots up, but sometimes you do > not want that at all. (eg a cleanup crontab that should never run > during peak hours) > > would be nice if the choosen cron solution supports a certain marker > per cron entry where you can define the behavior you want. That's exactly what you can do with fcron. In crontab you have to explicitly tell fcron to run cronjobs which should have run during downtime at bootup. If I recall correctly you have to prefix these lines with an "@". Otherwise they are handled like in dcron. The scripts in /etc/cron.hourly etc. are executed at bootup if the system was down when they should be running. But you can delete or chmod 600 them or just comment the commands out. Greetings, Heiko

2 1

Re: [arch-general] [arch-dev-public] Cron
by Heiko Baums 04 Jan '10

04 Jan '10

Am Sun, 03 Jan 2010 23:23:28 -0500 schrieb Paul Mattal <paul(a)mattal.com>: > Is there also an issue we're trying to solve with anacron? Can't we > use bcron (or any other cron for that matter) and still use anacron > separately? > > I understand that fcron could theoretically do the work of both, but > don't see an inherent advantage over two separate tools which might > each be better at their own job. I again answer to arch-general due to write permissions. I vote for fcron because it has dcron and anacron features. Two separate packages is indeed a regression and not really KISS like because anacron can only do anacron and dcron can only do dcron while fcron can do both. And on a desktop system which doesn't run 24/7 you need both features at the same time. On servers which run 24/7 it doesn't harm if the cron daemon has anacron features, too. I'm using fcron since years and it just works. It runs every cronjob as soon as possible. If the system runs then it executes the cronjobs at that time which is configured. If the system is down then fcron will start the cronjobs as soon as possible, as soon as the system is up again. I don't know bcron and yacron but I doubt that they have anacron features. Also fcron supports the directories /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly. So it's very easy to configure cronjobs. No cryptical configuration file anymore. Just put a shell script into one of these directories and they will be executed regularly. The old configuration method is still possible. Greetings, Heiko

2 4