Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
abcde hogging hard drive - but where?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Multimedia
View previous topic :: View next topic  
Author Message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Tue Dec 13, 2005 1:13 am    Post subject: abcde hogging hard drive - but where? Reply with quote

I just tried ripping a CD w/ abcde, for the first time in awhile. Before doing so I checked my disk space w/ df, which showed just under 1 GB of space left (86% of 6GB shown as used). When ripping the 3rd track w/ cdparanoia, abcde shut down, w/ a message that there was no more space left. Sure enough, when I ran df again, it now said that the Use% had jumped to 99. When I checked my home directory, the temporary abcde directory and the album directory containing the first 2 mp3s amounted to only about 20 MB (the mp3 of track 1 contained only the first minute, whereas track 2 was in its entirety, but that's antoher issue). My home directory as a whole has not expanded. I have checked cache and tmp directories (that I know about) and have found nothing. Where is the crap that's taking up nearly a GB of my space? Any ideas?
Back to top
View user's profile Send private message
AmosMutke
Apprentice
Apprentice


Joined: 24 Dec 2003
Posts: 235
Location: Akita, Japan.

PostPosted: Tue Dec 13, 2005 2:01 am    Post subject: Reply with quote

use "du" and just limit the max-depth. It will still give you the total for directories, but only give totals at a specified depth.

example
Code:
du -m --max-depth=1 /tmp
0       /tmp/rpm
0       /tmp/.ICE-unix
0       /tmp/20874
0       /tmp/orbit-shawn
0       /tmp/w3c-cache
0       /tmp/.X11-unix
0       /tmp/makewhatisa9lZuX
1       /tmp/mcop-shawn
0       /tmp/gconfd-root
0       /tmp/hsperfdata_root
0       /tmp/.reiserfs_priv
1       /tmp/gconfd-shawn
0       /tmp/hsperfdata_shawn
0       /tmp/.wine-1000
0       /tmp/plugtmp
1       /tmp/portage
0       /tmp/plugtmp-1
0       /tmp/plugtmp-2
0       /tmp/plugtmp-3
0       /tmp/plugtmp-4
86      /tmp


from this you can see that I have 86 MB in /tmp. Apparently 83Mb of which are files directly in /tmp

You can try this on /tmp, /var, /home, etc and then narrow it down from there if you find directory with "missing data"
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Tue Dec 13, 2005 7:02 am    Post subject: Reply with quote

Thanks. I've discovered that my /var/log directory is over 2 GB. A closer look reveals:

Code:

mike@kona ~ $ ls -l /var/log
total 2425060
-rw-r--r--  1 root    users       33727 Dec 13 01:35 Xorg.0.log
-rw-r--r--  1 root    users       33778 Dec 12 20:24 Xorg.0.log.old
-rw-r-----  1 root    root          460 Jul 14 22:02 acpid
-rw-r-----  1 root    adm        151097 Dec 13 01:35 auth.log
drwxr-xr-x  2 root    root         4096 Sep  5 08:58 cups
-rw-r--r--  1 root    root        95882 Dec 13 01:35 daemon.log
-rw-r--r--  1 root    root       602802 Dec 13 01:35 debug
-rw-------  1 root    root         2256 Dec  6 23:04 dispatch-conf.log
-rw-------  1 root    root        42848 Dec  6 23:03 dispatch-conf.log.old
-rw-r-----  1 root    root        10278 Dec 13 01:35 dmesg
-rw-rw----  1 portage portage    603934 Dec 11 16:38 emerge.log
-rw-r--r--  1 root    root            0 May 23  2005 imapd.log
-rw-r--r--  1 root    root    979280821 Dec 13 01:35 kern.log
-rw-r--r--  1 root    root       292292 Dec 13 01:35 lastlog
-rw-r--r--  1 root    root            0 May 23  2005 lpr.log
-rw-r--r--  1 root    root          242 Jul 16 10:02 mail.err
-rw-r--r--  1 root    root          242 Jul 16 10:02 mail.info
-rw-r--r--  1 root    root          242 Jul 16 10:02 mail.log
-rw-r--r--  1 root    root          242 Jul 16 10:02 mail.warn
-rw-r--r--  1 root    root    979022793 Dec 13 01:42 messages
drwxr-xr-x  2 root    root         4096 May 23  2005 news
-rw-r--r--  1 root    root       298557 Dec 13 01:42 ppp.log
drwxrwx---  2 root    portage      4096 Jul 31 22:15 sandbox
-rw-r-----  1 root    adm     282511181 Dec 13 01:42 syslog
-rw-r-----  1 root    adm     232588263 Dec 12 17:50 syslog.0
-rw-r-----  1 root    adm         10544 Jun 23 03:10 syslog.1.bz2
-rw-r-----  1 root    adm         10426 Dec 11 03:10 syslog.1.gz
-rw-r-----  1 root    adm          8080 Jun 22 08:10 syslog.2.bz2
-rw-r-----  1 root    adm          7834 Dec 10 10:30 syslog.2.gz
-rw-r-----  1 root    adm          1664 Jun 21 08:00 syslog.3.bz2
-rw-r-----  1 root    adm          1439 Dec  7 08:46 syslog.3.gz
-rw-r-----  1 root    adm          1135 Jun 20 03:10 syslog.4.bz2
-rw-r-----  1 root    adm       1025130 Dec  6 08:20 syslog.4.gz
-rw-r-----  1 root    adm          5976 Jun 19 11:30 syslog.5.bz2
-rw-r-----  1 root    adm          6379 Dec  5 01:31 syslog.5.gz
-rw-r-----  1 root    adm          9161 Jun 18 07:50 syslog.6.bz2
-rw-r-----  1 root    adm           952 Dec  1 14:50 syslog.6.gz
-rw-r--r--  1 root    root       146737 Dec 13 01:36 user.log
-rw-r--r--  1 root    root            0 May 23  2005 uucp.log
-rw-rw-r--  1 root    utmp      4157952 Dec 13 01:46 wtmp
-rw-r--r--  1 root    root         2094 Jun 23 00:08 xdm.log


The syslog.0 file was created at the time I was using abcde. That accounts for 222 MB. What is the function of syslog? What about the size of the kern.log and messages files? Is it safe to just delete them periodically, or is there some better way to control their size?
Back to top
View user's profile Send private message
AmosMutke
Apprentice
Apprentice


Joined: 24 Dec 2003
Posts: 235
Location: Akita, Japan.

PostPosted: Tue Dec 13, 2005 9:34 am    Post subject: Reply with quote

You have got many more (esp large) files in your log directory. I

/var/log/messages contains all the output from your system logger. Technically it's not needed, but it's good to have if you need to look back for some reason... like if you suspect someone tried to break into your system. I archive mine once a year.

I don't know what the kernel.log is exactly. is there a kernel logging feature in the kernel? (grep -i log /usr/src/linux/.config) didn't list anything suspicious... If there is, then you can prob disable this. You don't need it unless you're trying to do some debugging.

I don't know what's creating syslog either. (I dont' have it) what does
Code:
tail /var/log/syslog
do?

The syslog.X files are just auto backups of syslog or backups of old syslog files.
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Tue Dec 13, 2005 1:39 pm    Post subject: Reply with quote

Doing

Code:

tail /var/log/syslog


produced output which looked suspiciously like dmesg, and sure enough it is identical to the end of my dmesg. Guess I don't need that.

I too do not see anything revealing when running the grep command, only the following:

Code:

kona mike # grep -i log /usr/src/linux/.config
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
# Memory Technology Devices (MTD)
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_MOUSE_LOGIBM is not set
CONFIG_LOG_BUF_SHIFT=15


What are some of the other large files in /var/log I can do without or should back up/delete occasionally? Can anyone explain the various syslog .gz and .bz2 files?
Back to top
View user's profile Send private message
AmosMutke
Apprentice
Apprentice


Joined: 24 Dec 2003
Posts: 235
Location: Akita, Japan.

PostPosted: Tue Dec 13, 2005 2:56 pm    Post subject: Reply with quote

eduardo451 wrote:
Doing
What are some of the other large files in /var/log I can do without or should back up/delete occasionally? Can anyone explain the various syslog .gz and .bz2 files?


AmosMutke wrote:
The syslog.X files are just auto backups of syslog or backups of old syslog files.


and if you have varified that they just contain output from your system boots (dmesg), then I'd say scrap'm. I can't think of a good reason why you would ever need to know what happened when you booted your computer last April?

It might also be nice to try and figure out what's backing up this useless data. I'm not sure, but what do have running?
Code:
rc-update -s



can you give the output of
Code:
du --max-depth=2 /var


Let's see where the bulk of that 2Gig is located.
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Tue Dec 13, 2005 11:24 pm    Post subject: Reply with quote

Code:

rc-update -s
               acpid |
           alsasound |      default
                apmd |
            bootmisc | boot
             checkfs | boot
           checkroot | boot
               clock | boot
            coldplug | boot
         consolefont | boot
         crypto-loop |
               cupsd |      default
                dbus |
          domainname |      default
              esound |
                famd |
                 gpm |
              hdparm |
   hibernate-cleanup |
            hostname | boot
             hotplug |      default
             keymaps | boot
               local |      default nonetwork
          localmount | boot
             modules | boot
                 nas |
            net.eth0 |
              net.lo | boot
           net.wlan0 |      default
            netmount |      default
                nscd |
             numlock |
              pcmcia |      default
             portmap |
           rmnologin | boot
              rsyncd |
              serial | boot
                sshd |
            sysklogd |      default
             urandom | boot
          vixie-cron |      default
                 xdm |


and here's the du output

Code:

 du --max-depth=2 /var
63708   /var/db/pkg
63712   /var/db
4       /var/lib/misc
192     /var/lib/init.d
16      /var/lib/portage
28      /var/lib/dhcpc
12      /var/lib/xdm
8       /var/lib/xkb
8       /var/lib/run
4       /var/lib/dbus
3684    /var/lib/slocate
12      /var/lib/module-rebuild
20      /var/lib/net-scripts
3992    /var/lib
4       /var/log/news
932     /var/log/cups
4       /var/log/sandbox
2198592 /var/log
4       /var/run/console
8       /var/run/sudo
52      /var/run
4       /var/tmp/portage
3340    /var/tmp/f-prot
304     /var/tmp/kdecache-mike
244     /var/tmp/kdecache-root
4356    /var/tmp
4       /var/lock/subsys
8       /var/lock
94544   /var/cache/edb
472     /var/cache/man
96680   /var/cache
4       /var/empty
12      /var/spool/cron
4       /var/spool/mail
24      /var/spool/cups
8       /var/spool/cups-pdf
52      /var/spool
4       /var/state
20      /var/games/pinball
24      /var/games
2367480 /var


So there's 2Gig in /var/log, which as previously listed contains the messages and kern.log file, both of which are approximately 934MB. When I tail /var/log/kern.log, I get the same output as with tail /var/log/messages, so it's apparently a duplicate file. But I have no idea why there is the kern.log.

EDIT

When I did

Code:

grep -i log /var/log/messages


I got ouput like the following:

Code:

Dec 11 02:05:19 localhost kernel: Kernel logging (proc) stopped.
Dec 11 02:05:19 localhost kernel: Kernel log daemon terminating.
Dec 11 02:06:43 localhost syslogd 1.4.1: restart.
Dec 11 02:06:44 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 11 02:06:44 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 11 02:06:44 localhost kernel: input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
Dec 11 02:24:37 localhost kernel: Kernel logging (proc) stopped.
Dec 11 02:24:37 localhost kernel: Kernel log daemon terminating.
Dec 11 02:25:44 localhost syslogd 1.4.1: restart.
Dec 11 02:25:45 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 11 02:25:46 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 11 02:25:46 localhost kernel: input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
Dec 11 03:17:44 localhost syslogd 1.4.1: restart.
Dec 11 12:03:00 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 11 12:03:30 localhost kernel: Kernel logging (proc) stopped.
Dec 11 12:03:30 localhost kernel: Kernel log daemon terminating.
Dec 11 12:45:17 localhost syslogd 1.4.1: restart.
Dec 11 12:45:18 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 11 12:45:19 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 11 12:45:19 localhost kernel: input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
Dec 11 15:40:06 localhost kernel: Kernel logging (proc) stopped.
Dec 11 15:40:06 localhost kernel: Kernel log daemon terminating.
Dec 11 15:41:16 localhost syslogd 1.4.1: restart.
Dec 11 15:41:17 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 11 15:41:17 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 11 15:41:17 localhost kernel: input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
Dec 11 16:15:40 localhost kernel: Kernel logging (proc) stopped.
Dec 11 16:15:40 localhost kernel: Kernel log daemon terminating.
Dec 11 16:16:51 localhost syslogd 1.4.1: restart.
Dec 11 16:16:52 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 11 16:16:52 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 11 16:16:52 localhost kernel: input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
Dec 11 20:23:26 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 12 00:51:25 localhost kernel: Kernel logging (proc) stopped.
Dec 12 00:51:25 localhost kernel: Kernel log daemon terminating.
Dec 12 17:42:47 localhost syslogd 1.4.1: restart.
Dec 12 17:42:48 localhost kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 12 17:42:48 localhost kernel: logips2pp: Detected unknown logitech mouse model 56
Dec 12 17:42:48 localhost kernel: input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
Dec 12 17:56:07 localhost syslogd 1.4.1: restart.


It goes clear back to August, this is just the past couple of days. I do have sysklogd running at default level, is this responsible for the kern.log file? I'm sure I have sysklogd there only b/c the installation docs told me to.
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Wed Dec 14, 2005 1:09 am    Post subject: Reply with quote

I've found this thread here

[url]
https://forums.gentoo.org/viewtopic-t-357192-highlight-kern.html regarding kern.log
[/url]

From previous info I posted, I ran

Code:

grep -i irq /var/log/messages


The dates go by fairly fast from May to November, but then on Nov. 25, and again last night, there's a veeeeerrrrry long stretch of the following:

Code:

Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:31 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:31 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:40 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:40 localhost kernel:  [<c03d16fb>] preempt_schedule_irq+0x4b/0x80
Dec 12 18:12:43 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:43 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:43 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:43 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:43 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:43 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c01053fe>] do_IRQ+0x1e/0x30
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70
Dec 12 18:12:44 localhost kernel:  [<c012655d>] run_timer_softirq+0x14d/0x1f0
Dec 12 18:12:44 localhost kernel:  [<c013f4a0>] handle_IRQ_event+0x30/0x70


This is only a very small snippet, it literally takes minutes for it to scroll by on the screen. Abcde was running at this time. I don't know about Nov. 25.
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Wed Dec 14, 2005 2:02 am    Post subject: Reply with quote

I deleted my kern.log file, but when I run df there is no difference in available disk space.

Code:

 df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda4              6027468   5382096    339192  95% /
udev                     62668       112     62556   1% /dev
/dev/hda2                36598      4355     30353  13% /boot
none                     62668         0     62668   0% /dev/shm


I believe that before deleting kern.log, the Used amount was just over 6000000, so it seems that deleting kern.log brought down the Used amount without increasing the Available amount. Why didn't I reclaim the space?

EDIT

I compressed my /var/log/messages using gzip, and I now have:

Code:


Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda4              6027468   3192684   2528604  56% /
udev                     62668       112     62556   1% /dev
/dev/hda2                36598      4355     30353  13% /boot
none                     62668         0     62668   0% /dev/shm


Yay!
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Wed Dec 14, 2005 5:43 am    Post subject: Reply with quote

Ok, it's official. Abcde totally bloats my log files. When I compressed my /var/log/messages, I stopped sysklogd, and did not start it back up before ripping a cd. Ran abcde, no problem, plenty of room to spare. I start sysklogd back up, rip another cd, and half-way through I'm told I've run out of space. I discover that in /var/log, my messages, kern.log, and syslog files are 717MB each, and when I tail them I get the following:

Code:

Dec 14 00:31:14 localhost kernel:  [<c0145e3e>] __alloc_pages+0x2fe/0x480
Dec 14 00:31:14 localhost kernel:  [<c029f4c5>] idecd_ioctl+0x85/0x90
Dec 14 00:31:14 localhost kernel:  [<c026e552>] blkdev_driver_ioctl+0x52/0x90
Dec 14 00:31:14 localhost kernel:  [<c026e634>] blkdev_ioctl+0xa4/0x1b0
Dec 14 00:31:14 localhost kernel:  [<c0169b2b>] block_ioctl+0x2b/0x30
Dec 14 00:31:14 localhost kernel:  [<c01741be>] do_ioctl+0x8e/0xa0
Dec 14 00:31:14 localhost kernel:  [<c03d34b8>] do_page_fault+0x188/0x61d
Dec 14 00:31:14 localhost kernel:  [<c01743a5>] vfs_ioctl+0x65/0x1f0
Dec 14 00:31:14 localhost kernel:  [<c0174575>] sys_ioctl+0x45/0x70
Dec 14 00:31:14 localhost kernel:  [<c01030db>] sysenter_past_esp+0x54/0x75


Several months ago, shortly after I started using gentoo, I ripped some cds using abcde and did not experience this issue. Any thoughts? For now I'll just turn off sysklogd when ripping.
Back to top
View user's profile Send private message
yabbadabbadont
Advocate
Advocate


Joined: 14 Mar 2003
Posts: 4791
Location: 2 exits past crazy

PostPosted: Wed Dec 14, 2005 5:58 am    Post subject: Reply with quote

abcde is just a bash shell script. It must be cdparanoia that is filling up your logs. It looks suspiciously like debugging output to me. Did/do you have debug in your use flags and nostrip in your features when you emerged it?
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Wed Dec 14, 2005 6:35 am    Post subject: Reply with quote

I have never had debug in my use flags, and this is the first I've heard of nostrip. I'm pretty sure cdparanoia was just a standard install. Also, in my abcde.conf file, there is nothing listed for CDPARANOIAOPTS. Do you think it would help to try reemerging cdparanoia with -debug at the command line? I imagine I don't want to put -debug in my use flags.
Back to top
View user's profile Send private message
AmosMutke
Apprentice
Apprentice


Joined: 24 Dec 2003
Posts: 235
Location: Akita, Japan.

PostPosted: Wed Dec 14, 2005 9:22 am    Post subject: Reply with quote

if you use the -v option, it will tell you what use flages you used to install.

red flags are on, blue are off, if any flag is followed by a *, then it is different from when you installed,

i.e.
Code:
emerge -vp x11-terms/aterm

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] x11-terms/aterm-0.4.2-r11  +cjk* 0 kB

Total size of downloads: 0 kB


shows that if I emerge aterm now, I will have cjk on, but the * means that I stalled with it off.

re-emerging cdparinoia couldn't hurt. Another good questiong (that I can't answer) is "Why are your computer logging everything three times?"
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Wed Dec 14, 2005 4:41 pm    Post subject: Reply with quote

Quote:

Another good questiong (that I can't answer) is "Why are your computer logging everything three times?"


I know! Wtf!

When I did a practice emerge nothing extra showed up, and trying it w/ -debug didn't show any change. But it could be a situation like w/ firefox and cups - in order to print I had to put cups in my use flags even though it didn't show up as an option when emerging firefox. I will try reemerging cdparanoia when I get home from work tonight.
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Thu Dec 15, 2005 1:27 am    Post subject: Reply with quote

I've reemerged cdparanoia w/ -debug, but there's no change. It still fills up my log. But the good news is, it is now log instead of logs. I looked at my syslog.conf file for the fist time, and apparently kern.log and syslog are enabled by default. So I commented those lines, and now there's just /var/log/messages.
Back to top
View user's profile Send private message
AmosMutke
Apprentice
Apprentice


Joined: 24 Dec 2003
Posts: 235
Location: Akita, Japan.

PostPosted: Thu Dec 15, 2005 7:40 am    Post subject: Reply with quote

So at this point you have tackeled the duplicate logs problem and now it's a question of getting rid of all the extra output that seems to be dumped in /var/log/messages when you burn a cd.

Am I right?

If yes, then I can't help you. I don't use cdparanoia. Maybe list your cd drive info with
Code:
hdparm -i /dev/hd?


Then list your kernel version
Code:
uname -a


and cdparanoia version.

Sorry I can't help you more, but that should be enough info for someone to help you.
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Thu Dec 15, 2005 2:07 pm    Post subject: Reply with quote

You are correct. Now it's just a matter of getting rid of the extra output.

Here's the info:

Code:

kona mike # hdparm -i /dev/hdc

/dev/hdc:

 Model=TOSHIBA CD-ROM XM-7102B, FwRev=1908, SerialNo=
 Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=128kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no

 * signifies the current active mode


and

Code:

kona mike # uname -a
Linux kona 2.6.14-gentoo-r2 #3 SMP PREEMPT Sun Dec 11 02:17:27 GMT 2005 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux


Thank you so much for your time on this :D
Back to top
View user's profile Send private message
rpmohn
Tux's lil' helper
Tux's lil' helper


Joined: 26 Aug 2003
Posts: 116
Location: Vermont

PostPosted: Tue Dec 20, 2005 1:25 pm    Post subject: Same problem with Sound-Juicer Reply with quote

Hi, I just started having this problem myself while ripping a bunch of CDs using Sound-Juicer. I recently upgraded my kernel from 2.6.13-gentoo-r4 to 2.6.14-gentoo-r4 and I'm seriously wondering if this is something to do with the 2.6.14 sources?

I've been ripping CDs for years and haven't noticed anything like this. Now after just a few CDs the kern.log file gets unmanageably huge!

I wonder if I've recently upgraded syslog-ng as well. That is another possibility I will look into now...

-RPM
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Tue Dec 20, 2005 10:42 pm    Post subject: Reply with quote

Hi rpmohn. Welcome to the club!

I can tell you it is not syslog-ng, as I do not have it on my system. But I too have upgraded to 2.6.14, so that very well may be the issue. Have you tried going back to a different kernel yet?
Back to top
View user's profile Send private message
AmosMutke
Apprentice
Apprentice


Joined: 24 Dec 2003
Posts: 235
Location: Akita, Japan.

PostPosted: Wed Dec 21, 2005 2:07 am    Post subject: Reply with quote

I'm using gentoo-sources 2.6.14-r2 with no such trouble.

what ever is filling your /var/log/messages is probably repeating the same thing over and over.... can you cut a small sample and paste it here... Let us look at it and see if we can catch the criminal...
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Wed Dec 21, 2005 4:48 am    Post subject: Reply with quote

I've switched back to 2.6.13-r5 and the problem is gone. No more bloated log file. I have no idea why, but it worked for me. :D
Back to top
View user's profile Send private message
AmosMutke
Apprentice
Apprentice


Joined: 24 Dec 2003
Posts: 235
Location: Akita, Japan.

PostPosted: Wed Dec 21, 2005 4:59 am    Post subject: Reply with quote

I'm not a shell scriping guru, but I would ask the kind people who read this forum for a script that will give you a list of differences in the files... maybe you selected different options in the two kernel configs.

The "diff" command is probably what your looking for.
Back to top
View user's profile Send private message
rpmohn
Tux's lil' helper
Tux's lil' helper


Joined: 26 Aug 2003
Posts: 116
Location: Vermont

PostPosted: Wed Dec 21, 2005 3:05 pm    Post subject: Reply with quote

Great idea to try switching back to a 2.6.13 kernel. Sadly, I had removed my last 2.6.13 kernel just before reading your suggestion :( .

On a positive note, however, I've narrowed the problem down even further :) ! I ripped a new CD last night to try to get some examples of the error messsages, but when I checked the kern.log file, there were no errors! Now I was really confused, but then I remembered that the CDs I was ripping over the weekend were rather old and had been used quite a bit by my young son. There were even a few with patches that couldn't be read at all. So I put in an old Leadbelly CD to rip, and lo and behold, there were the errors choking up my kern.log file!!

So, the problem relates to bad reads from a CD device. I can't test if it has anything to do with the kernel version or not. Here are some choice lines from the /var/log/kern.log file:
Code:
Dec 20 23:42:15 porcupine cdrom: dropping to single frame dma
Dec 20 23:42:16 porcupine arq->state: 4
Dec 20 23:42:16 porcupine Badness in as_insert_request at drivers/block/as-iosched.c:1519
Dec 20 23:42:16 porcupine [<c02e0fc4>] as_insert_request+0x64/0x180
Dec 20 23:42:16 porcupine [<c02d6e78>] __elv_add_request+0x78/0xc0
Dec 20 23:42:16 porcupine [<c02d6f0c>] elv_add_request+0x4c/0x70
Dec 20 23:42:16 porcupine [<c02da5c8>] blk_execute_rq_nowait+0x48/0x60
Dec 20 23:42:16 porcupine [<c02da680>] blk_execute_rq+0xa0/0xd0
Dec 20 23:42:16 porcupine [<c02da960>] blk_end_sync_rq+0x0/0x40
Dec 20 23:42:16 porcupine [<c01673ed>] bio_phys_segments+0x2d/0x30
Dec 20 23:42:16 porcupine [<c02dbde7>] blk_rq_bio_prep+0x37/0xa0
Dec 20 23:42:16 porcupine [<c03389e7>] cdrom_read_cdda_bpc+0x187/0x1f0
Dec 20 23:42:16 porcupine [<c0338a94>] cdrom_read_cdda+0x44/0xb0
Dec 20 23:42:16 porcupine [<c0339e2d>] mmc_ioctl+0x55d/0xac0
Dec 20 23:42:16 porcupine [<c01331e0>] autoremove_wake_function+0x0/0x60
Dec 20 23:42:16 porcupine [<c01bd413>] pathrelse+0x23/0x40
Dec 20 23:42:16 porcupine [<c01331e0>] autoremove_wake_function+0x0/0x60
Dec 20 23:42:16 porcupine [<c02dec7d>] scsi_cmd_ioctl+0x7d/0x4d0
Dec 20 23:42:16 porcupine [<c01c8355>] do_journal_end+0x685/0xa50
Dec 20 23:42:16 porcupine [<c014b59d>] activate_page+0xad/0xb0
Dec 20 23:42:16 porcupine [<c011713a>] try_to_wake_up+0x2da/0x340
Dec 20 23:42:16 porcupine [<c033979c>] cdrom_ioctl+0xc9c/0xd40
Dec 20 23:42:16 porcupine [<c0145629>] buffered_rmqueue+0x119/0x230
Dec 20 23:42:16 porcupine [<c04243de>] schedule+0x66e/0xd50
Dec 20 23:42:16 porcupine [<c0145aee>] __alloc_pages+0x2fe/0x480
Dec 20 23:42:16 porcupine [<c03077c5>] idecd_ioctl+0x85/0x90
Dec 20 23:42:16 porcupine [<c02dcc92>] blkdev_driver_ioctl+0x52/0x90
Dec 20 23:42:16 porcupine [<c02dcd78>] blkdev_ioctl+0xa8/0x1b0
Dec 20 23:42:16 porcupine [<c0169d7b>] block_ioctl+0x2b/0x30
Dec 20 23:42:16 porcupine [<c017447e>] do_ioctl+0x8e/0xa0
Dec 20 23:42:16 porcupine [<c0174665>] vfs_ioctl+0x65/0x1f0
Dec 20 23:42:16 porcupine [<c0174857>] sys_ioctl+0x67/0x90
Dec 20 23:42:16 porcupine [<c01030db>] sysenter_past_esp+0x54/0x75
Dec 20 23:42:16 porcupine arq->state: 4
Dec 20 23:42:16 porcupine Badness in as_insert_request at drivers/block/as-iosched.c:1519
Dec 20 23:42:16 porcupine [<c02e0fc4>] as_insert_request+0x64/0x180
.
.
.
over and over again!

Should these really be in the kernel log? Can/should I stop/reduce them?
Thanks! -RPM
Back to top
View user's profile Send private message
eduardo451
Apprentice
Apprentice


Joined: 29 Apr 2005
Posts: 173
Location: Indianapolis, IN

PostPosted: Thu Dec 22, 2005 4:37 am    Post subject: Reply with quote

If it's really related to bad reads, then all of my CDs are messed up! But for me it didn't seem to matter what kind of shape my CDs were in, I still got output like you did. Are we sure it is truly "error" messages, and not just reporting every little thing happening?

As far as any differences between my kernels, I ran diff and found no true differences. There are some options that are simply not available in the other kernel, but that would not explain why we are experiencing this when others are not.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Multimedia All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum