Is this data really stored in the RAM? - Ubuntu

This is a discussion on Is this data really stored in the RAM? - Ubuntu ; Moe Trin wrote: >> ct@wimp:~$ cat /proc/interrupts >> CPU0 CPU1 >> 0: 6135094 0 IO-APIC-edge timer >> 5: 0 0 IO-APIC-edge MPU401 UART >> 7: 0 0 IO-APIC-edge parport0 >> 8: 3 0 IO-APIC-edge rtc >> 14: 638957 0 IO-APIC-edge ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 38 of 38

Thread: Is this data really stored in the RAM?

  1. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    >> ct@wimp:~$ cat /proc/interrupts
    >> CPU0 CPU1
    >> 0: 6135094 0 IO-APIC-edge timer
    >> 5: 0 0 IO-APIC-edge MPU401 UART
    >> 7: 0 0 IO-APIC-edge parport0
    >> 8: 3 0 IO-APIC-edge rtc
    >> 14: 638957 0 IO-APIC-edge ide0
    >> 15: 4042908 0 IO-APIC-edge ide1
    >> 169: 1 0 IO-APIC-level acpi
    >> 177: 1124384 0 IO-APIC-level libata, ide2, uhci_hcd:usb3,
    >>

    > ohci1394, ohci_hcd:usb7
    >
    >> 185: 16473094 0 IO-APIC-level uhci_hcd:usb1,
    >>

    > ohci_hcd:usb6, skge, nvidia
    >
    >> 193: 0 0 IO-APIC-level uhci_hcd:usb2
    >> 201: 3 0 IO-APIC-level ehci_hcd:usb4
    >> 209: 77 0 IO-APIC-level ehci_hcd:usb5, bttv0
    >> 217: 122690 0 IO-APIC-level Intel 82801DB-ICH4
    >> 225: 3711236 0 IO-APIC-level saa7133[0], saa7133[0]
    >> NMI: 0 0
    >>

    >
    > Holy Sh!t, something is rotten in Denmark! Look at IRQ 0. That's the
    > system timer, which is normally running at 100, 500, or 1000 interrupts
    > per second. Try manually running the command 'grep 0: /proc/interrupts'
    > as close as you can to ten seconds apart. That will tell you which rate
    > it's set at. Now come up with a reason why the second IDE controller
    > is banging away at a rate ~2/3 as often, never mind why IRQ 185 is
    > screaming away 2.7 times as fast as the timer. IRQ 225 is also on the
    > high side (though I've no idea what that may be), and IRQ 14 (the
    > primary IDE controller) is on the high side.
    >
    > Old guy
    >



    Moe, aren't these figures possibly representing a count, instead of a speed?

    I have IRQ0 reports into the millions and billions on several machines
    that have a high uptime and are operating fine. For instance (highest to
    lowest):

    An AMD-K6 233 w/64 MB RAM running Debian 3.1r0a:

    john@noc0:~$ ssh ns0
    Password:
    Linux ns0 2.4.27-2-386 #1 Wed Aug 17 09:33:35 UTC 2005 i586 GNU/Linux

    The programs included with the Debian GNU/Linux system are free software;
    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.
    No mail.

    Last login: Mon Feb 25 20:09:05 2008 from noc0.my.net
    john@ns0:~$ uptime
    20:18:44 up 470 days, 10:59, 2 users, load average: 0.00, 0.00, 0.00
    john@ns0:~$ cat /proc/interrupts
    CPU0
    0: 4064763443 XT-PIC timer
    1: 17826 XT-PIC keyboard
    2: 0 XT-PIC cascade
    8: 4 XT-PIC rtc
    11: 51781412 XT-PIC eth0
    14: 7787532 XT-PIC ide0


    ------------------------------------------------------------------------

    An AMD-K6 266 w/128 MB RAM running Debian 3.1r0a:

    john@noc0:~$ ssh news7
    Password:
    Linux news7 2.4.27-2-386 #1 Wed Aug 17 09:33:35 UTC 2005 i586 GNU/Linux

    The programs included with the Debian GNU/Linux system are free software;
    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.
    No mail.

    Last login: Mon Feb 25 20:09:42 2008 from noc0.my.net
    john@news7:~$ uptime
    20:24:40 up 290 days, 22:00, 2 users, load average: 0.00, 0.00, 0.00
    john@news7:~$ cat /proc/interrupts
    CPU0
    0: 2513524357 XT-PIC timer
    1: 23258 XT-PIC keyboard
    2: 0 XT-PIC cascade
    8: 4 XT-PIC rtc
    11: 27168639 XT-PIC eth0
    14: 22924593 XT-PIC ide0


    ------------------------------------------------------------------------

    An AMD Duron 1.4 GHz w/512 MB RAM running Debian 4.0:

    john@noc0:~$ ssh noc1
    john@noc1's password:
    Linux noc1 2.6.18-6-486 #1 Wed Jan 23 02:46:42 UTC 2008 i686

    The programs included with the Debian GNU/Linux system are free software;
    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.
    No mail.
    Last login: Mon Feb 25 20:04:47 2008 from noc0.my.net
    john@noc1:~$ uptime
    20:22:06 up 18 days, 10:17, 2 users, load average: 0.00, 0.00, 0.00
    john@noc1:~$ cat /proc/interrupts
    CPU0
    0: 398038480 IO-APIC-edge timer
    1: 12 IO-APIC-edge i8042
    6: 5 IO-APIC-edge floppy
    7: 2 IO-APIC-edge parport0
    8: 1 IO-APIC-edge rtc
    9: 1 IO-APIC-level acpi
    12: 372102 IO-APIC-edge i8042
    14: 203634 IO-APIC-edge ide0
    15: 15079793 IO-APIC-edge ide1
    169: 0 IO-APIC-level libata
    177: 1110 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2,
    uhci_hcd:usb3, uhci_hcd:usb4, ehci_hcd:usb5
    185: 582035 IO-APIC-level eth0
    193: 0 IO-APIC-level VIA8237
    201: 94729933 IO-APIC-level via@pci:0000:01:00.0
    NMI: 0
    LOC: 398031183
    ERR: 0
    MIS: 0


    ------------------------------------------------------------------------

    Finally, an AMD Duron 1.8 GHz w/1 GB RAM running Ubuntu 6.06 LTS:

    john@n0c0:~$ uptime
    20:43:08 up 8 days, 18:50, 3 users, load average: 0.40, 0.41, 0.38
    john@n0c0:~$ cat /proc/interrupts
    CPU0
    0: 189757277 XT-PIC timer
    1: 128355 XT-PIC i8042
    2: 0 XT-PIC cascade
    5: 2664268 XT-PIC aic7xxx, eth0
    7: 0 XT-PIC parport0
    8: 3 XT-PIC rtc
    9: 0 XT-PIC acpi
    10: 0 XT-PIC MPU401 UART
    11: 36556605 XT-PIC ohci_hcd:usb2, ohci_hcd:usb3, SiS SI7012
    12: 3 XT-PIC ehci_hcd:usb1
    14: 1201450 XT-PIC ide0
    15: 6788306 XT-PIC ide1


    ------------------------------------------------------------------------

    The last two had a kernel update 18 and 8 days ago. The first two aren't
    broke, so I don't fixem. ;-)

    As I said, these figures are much higher than Clay's, but I'm having
    absolutely no issues with slowness. That makes me suspect the figures
    are not IRQs/time, but a running count from "who -b" perhaps?

    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  2. Re: Is this data really stored in the RAM?



    "clay" wrote in message
    news:TUIwj.2801$fX7.1874@nlpi061.nbdc.sbc.com...
    > dennis@home wrote:
    >>...
    >>>>
    >>>> Are you sure your mythTV recordings continue when its in this state as
    >>>> you indicated earlier?...
    >>>
    >>> Yep.
    >>> MythTV (and Linux in general, it would seem) is not bothered by trivial
    >>> things such as restarts.
    >>> If it is recording a show and the computer is restarted it starts a new
    >>> recording of the same program. It displays recording start and end times
    >>> so I can see there were approx. two minutes missed between the two
    >>> recordings.

    >>
    >> That wasn't what I meant. 8-(

    >
    > You asked:
    >
    >> Are you sure your mythTV recordings continue when its in this state as
    >> you indicated earlier?
    >> It sounds like the hardware is locking up but it can't be if the
    >> recordings continue.
    >> Unless you can confirm the recordings do continue I would check the
    >> hardware carefully for things like loose heat sinks, cables, chips, etc.
    >> before delving into debugging the software. But then I am a hardware guy.
    >> ;-)

    >
    > If you didn't mean was I sure the recordings continued (Which I am sure
    > of, and explained how I confirmed that... the computer was locked for more
    > than ten minutes yet the only break in recording was two minutes prior to
    > the restart. Roughly the length of time a restart takes.)
    > Then I really don't understand your question...
    >


    Well in part of your posts I read it as saying everything was none
    responding for ten minutes but in another you only lost two minutes of
    recording. I may have misunderstood.


  3. Re: Is this data really stored in the RAM?

    dennis@home wrote:
    >
    >
    > "clay" wrote in message
    > news:TUIwj.2801$fX7.1874@nlpi061.nbdc.sbc.com...
    >> dennis@home wrote:
    >>> ...
    >>>>>
    >>>>> Are you sure your mythTV recordings continue when its in this state
    >>>>> as you indicated earlier?...
    >>>>
    >>>> Yep.
    >>>> MythTV (and Linux in general, it would seem) is not bothered by
    >>>> trivial things such as restarts.
    >>>> If it is recording a show and the computer is restarted it starts a
    >>>> new recording of the same program. It displays recording start and
    >>>> end times so I can see there were approx. two minutes missed between
    >>>> the two recordings.
    >>>
    >>> That wasn't what I meant. 8-(

    >>
    >> You asked:
    >>
    >>> Are you sure your mythTV recordings continue when its in this state
    >>> as you indicated earlier?
    >>> It sounds like the hardware is locking up but it can't be if the
    >>> recordings continue.
    >>> Unless you can confirm the recordings do continue I would check the
    >>> hardware carefully for things like loose heat sinks, cables, chips,
    >>> etc. before delving into debugging the software. But then I am a
    >>> hardware guy. ;-)

    >>
    >> If you didn't mean was I sure the recordings continued (Which I am
    >> sure of, and explained how I confirmed that... the computer was locked
    >> for more than ten minutes yet the only break in recording was two
    >> minutes prior to the restart. Roughly the length of time a restart
    >> takes.)
    >> Then I really don't understand your question...
    >>

    >
    > Well in part of your posts I read it as saying everything was none
    > responding for ten minutes but in another you only lost two minutes of
    > recording. I may have misunderstood.


    Apps that I was running, Pan, Thunderbird, Firefox, etc., stopped
    responding.
    MythTV slave backend starts on bootup and runs in the background.
    I know pan stopped downloading because the last rar downloaded was ~20
    minutes before the restart.
    Firefox knew it died because it asked to restore the session after the
    restart.
    MythTV may have simply time stamped the end of the recording when I
    restarted. I didn't actually watch the recording to see if it played up
    to the time index so it might not have been actually recording. This
    particular recording was a rain delay during the NASCAR race, nothing
    worth watching. I did look at the filesize and it was several gigs, what
    I'd expect for a recording that length.
    Guess I should have seen some HDD activity if it were writing to the
    disk. The LED should have blinked once in a while... Maybe I blinked and
    missed it.



  4. Re: Is this data really stored in the RAM?



    "clay" wrote in message
    news:RDYwj.7887$Ru4.4509@newssvr19.news.prodigy.ne t...

    8<

    > Apps that I was running, Pan, Thunderbird, Firefox, etc., stopped
    > responding.
    > MythTV slave backend starts on bootup and runs in the background.
    > I know pan stopped downloading because the last rar downloaded was ~20
    > minutes before the restart.
    > Firefox knew it died because it asked to restore the session after the
    > restart.
    > MythTV may have simply time stamped the end of the recording when I
    > restarted. I didn't actually watch the recording to see if it played up to
    > the time index so it might not have been actually recording. This
    > particular recording was a rain delay during the NASCAR race, nothing
    > worth watching. I did look at the filesize and it was several gigs, what
    > I'd expect for a recording that length.
    > Guess I should have seen some HDD activity if it were writing to the disk.
    > The LED should have blinked once in a while... Maybe I blinked and missed
    > it.
    >
    >


    Ok.
    That is 100% clear. 8-)
    I now think its a hardware problem.. but I also think your file system is
    corrupt as it isn't reading from RAM when you grep "password" if the grep
    command doesn't show up. This could have been caused during a previous
    lock-up.




  5. Re: Is this data really stored in the RAM?

    dennis@home wrote:
    >
    >
    > "clay" wrote in message
    > news:RDYwj.7887$Ru4.4509@newssvr19.news.prodigy.ne t...
    >
    > 8<
    >
    >> Apps that I was running, Pan, Thunderbird, Firefox, etc., stopped
    >> responding.
    >> MythTV slave backend starts on bootup and runs in the background.
    >> I know pan stopped downloading because the last rar downloaded was ~20
    >> minutes before the restart.
    >> Firefox knew it died because it asked to restore the session after the
    >> restart.
    >> MythTV may have simply time stamped the end of the recording when I
    >> restarted. I didn't actually watch the recording to see if it played
    >> up to the time index so it might not have been actually recording.
    >> This particular recording was a rain delay during the NASCAR race,
    >> nothing worth watching. I did look at the filesize and it was several
    >> gigs, what I'd expect for a recording that length.
    >> Guess I should have seen some HDD activity if it were writing to the
    >> disk. The LED should have blinked once in a while... Maybe I blinked
    >> and missed it.
    >>
    >>

    >
    > Ok.
    > That is 100% clear. 8-)
    > I now think its a hardware problem.. but I also think your file system
    > is corrupt as it isn't reading from RAM when you grep "password" if the
    > grep command doesn't show up. This could have been caused during a
    > previous lock-up.
    >
    >
    >

    probably hardware... if you saw some system specs in a earlier thread.
    plus the mishmash of cards and crap on it, it's amazing it runs at all.

    jane doa explained why grep doesn't show up earlier in this thread.
    I bought it.
    Do you see grep in your ram when you grep
    sudo strings /dev/mem | less ?

  6. Re: Is this data really stored in the RAM?



    "clay" wrote in message
    news:s5_wj.12630$J41.5833@newssvr14.news.prodigy.n et...
    > dennis@home wrote:



    >>

    > probably hardware... if you saw some system specs in a earlier thread.
    > plus the mishmash of cards and crap on it, it's amazing it runs at all.
    >
    > jane doa explained why grep doesn't show up earlier in this thread.
    > I bought it.
    > Do you see grep in your ram when you grep
    > sudo strings /dev/mem | less ?


    I saw that explanation but I don't see how it can be.
    To do that the pipe would have to be executed sequentially.. take all the
    strings out and buffer them.. then start grep.. which isn't the way Unix
    works. Unix would start the processes more or less at the same time so grep
    should be running while the strings command is running. I suppose it is
    possible to engineer a condition where it could happen sequentially but it
    wouldn't be what I would expect.



  7. Re: Is this data really stored in the RAM?

    On Tue, 26 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    , John F. Morse
    wrote:

    >Moe Trin wrote:


    >> Holy Sh!t, something is rotten in Denmark! Look at IRQ 0. That's
    >> the system timer, which is normally running at 100, 500, or 1000
    >> interrupts per second. Try manually running the command 'grep 0:
    >> /proc/interrupts' as close as you can to ten seconds apart. That
    >> will tell you which rate it's set at. Now come up with a reason why
    >> the second IDE controller is banging away at a rate ~2/3 as often,
    >> never mind why IRQ 185 is screaming away 2.7 times as fast as the
    >> timer. IRQ 225 is also on the high side (though I've no idea what
    >> that may be), and IRQ 14 (the primary IDE controller) is on the high
    >> side.


    >Moe, aren't these figures possibly representing a count, instead of a
    >speed?


    Yes - but at what speed are they accumulating? The count could be
    incrementing at 100 times a second or 1000. Thus,

    ]>> 0: 6135094 0 IO-APIC-edge timer

    the value of 6135094 could represent 17 or 1.7 hours. However, the
    point I was making is that his IRQ 15, 185, and 225 (and to a lesser
    extent 14) are running nearly as often. Is your hard drive causing
    interrupts 66 or 660 times per second? If so, you might want to see
    why.

    >I have IRQ0 reports into the millions and billions on several machines
    >that have a high uptime and are operating fine.


    Yes, but that's not the point.

    >john@ns0:~$ uptime
    > 20:18:44 up 470 days, 10:59, 2 users, load average: 0.00, 0.00, 0.00
    >john@ns0:~$ cat /proc/interrupts
    > CPU0
    > 0: 4064763443 XT-PIC timer


    [compton ~]$ echo "470*87600" | bc
    41172000
    [compton ~]$ echo "4064763443/41172000" | bc
    98
    [compton ~]$

    You might be blocking some interrupts there, but your IRQ 0 is running
    at 100 Hertz.

    > 11: 51781412 XT-PIC eth0
    > 14: 7787532 XT-PIC ide0


    and while your Ethernet is seeing a moderate amount of traffic, your
    hard drive isn't being banged on as hard as the O/P.

    By the way, don't you believe in keeping your systems up to date?
    Debian has released "a few" kernel updates in the past year ;-)
    and you're still running the same kernel as you were 15 1/2 months
    ago. (Actually, the /etc/issue.net appears to be showing the uname -a
    output which says the kernel is even older than that.)

    >The last two had a kernel update 18 and 8 days ago. The first two aren't
    >broke, so I don't fixem. ;-)


    Well, ns0 and news7 both seem to be running 2.4.27 which is a wee bit
    on the ancient side.

    [compton ~]$ finger kernel@kernel.org
    [kernel.org]
    The latest stable version of the Linux kernel is: 2.6.24.3
    The latest prepatch for the stable Linux kernel tree is: 2.6.25-rc3
    The latest snapshot for the stable Linux kernel tree is: 2.6.25-rc3-git1
    The latest 2.4 version of the Linux kernel is: 2.4.36.2
    The latest 2.2 version of the Linux kernel is: 2.2.26
    The latest prepatch for the 2.2 Linux kernel tree is: 2.2.27-rc2
    The latest -mm patch to the stable Linux kernels is: 2.6.25-rc2-mm1
    [compton ~]$

    As long as they are not visible from a potentially hostile world, that'
    OK. I've actually got several systems at work that are still running a
    1.2.13 kernel from 1995, but they are isolated from the company nets,
    and absolutely not visible from outside the facility, never mind from
    the world.

    >As I said, these figures are much higher than Clay's, but I'm having
    >absolutely no issues with slowness. That makes me suspect the figures
    >are not IRQs/time, but a running count from "who -b" perhaps?


    They are a running count, but why are the IRQs for the USB and IDE
    controllers so high _compared_ to the timer interrupts?

    Old guy

  8. Re: Is this data really stored in the RAM?

    Moe Trin wrote:

    >> Moe, aren't these figures possibly representing a count, instead of a
    >> speed?
    >>

    >
    > Yes - but at what speed are they accumulating? The count could be
    > incrementing at 100 times a second or 1000. Thus,
    >
    > ]>> 0: 6135094 0 IO-APIC-edge timer
    >
    > the value of 6135094 could represent 17 or 1.7 hours. However, the
    > point I was making is that his IRQ 15, 185, and 225 (and to a lesser
    > extent 14) are running nearly as often. Is your hard drive causing
    > interrupts 66 or 660 times per second? If so, you might want to see
    > why.
    >
    >
    >> I have IRQ0 reports into the millions and billions on several machines
    >> that have a high uptime and are operating fine.
    >>

    >
    > Yes, but that's not the point.
    >
    >
    >> john@ns0:~$ uptime
    >> 20:18:44 up 470 days, 10:59, 2 users, load average: 0.00, 0.00, 0.00
    >> john@ns0:~$ cat /proc/interrupts
    >> CPU0
    >> 0: 4064763443 XT-PIC timer
    >>

    >
    > [compton ~]$ echo "470*87600" | bc
    > 41172000
    > [compton ~]$ echo "4064763443/41172000" | bc
    > 98
    > [compton ~]$
    >
    > You might be blocking some interrupts there, but your IRQ 0 is running
    > at 100 Hertz.
    >



    Thanks, Moe. I see that I had a suspicion of this and you verified it.
    Maybe I'm not thinking up to speed. ;-)

    Like you, I'm laying in bed with pneumonia, diagnosed on Feb. 15, which
    won't go away. Coughing my head off to the point I have a bloody nose
    (and I'm on Plavix). No fun.


    >> 11: 51781412 XT-PIC eth0
    >> 14: 7787532 XT-PIC ide0
    >>

    >
    > and while your Ethernet is seeing a moderate amount of traffic, your
    > hard drive isn't being banged on as hard as the O/P.
    >
    > By the way, don't you believe in keeping your systems up to date?
    > Debian has released "a few" kernel updates in the past year ;-)
    > and you're still running the same kernel as you were 15 1/2 months
    > ago. (Actually, the /etc/issue.net appears to be showing the uname -a
    > output which says the kernel is even older than that.)
    >



    I don't think Debian has released any kernel updates for Sarge in a long
    time, but I have updated Etch several times on those boxen. I'll get
    around to the BIND9/ntpd/Stunnel/Fetchmail and INN servers someday....

    Some testing will need to be done first to see if a newer distro will
    even install on these old boxen. I can't afford to upgrade hardware. My
    health in the past nine months, heart attack, two stents, severe
    allergic reaction to (probably) Plavix, a burst appendix, which a month
    later was found to have cancer on it, the flu in the fall, and now
    pneumonia, have kept me from spending as much time as I want with the
    servers. I reckon I'm fixin' to die, muhhumm. ;-)


    >> The last two had a kernel update 18 and 8 days ago. The first two aren't
    >> broke, so I don't fixem. ;-)
    >>

    >
    > Well, ns0 and news7 both seem to be running 2.4.27 which is a wee bit
    > on the ancient side.
    >
    > [compton ~]$ finger kernel@kernel.org
    > [kernel.org]
    > The latest stable version of the Linux kernel is: 2.6.24.3
    > The latest prepatch for the stable Linux kernel tree is: 2.6.25-rc3
    > The latest snapshot for the stable Linux kernel tree is: 2.6.25-rc3-git1
    > The latest 2.4 version of the Linux kernel is: 2.4.36.2
    > The latest 2.2 version of the Linux kernel is: 2.2.26
    > The latest prepatch for the 2.2 Linux kernel tree is: 2.2.27-rc2
    > The latest -mm patch to the stable Linux kernels is: 2.6.25-rc2-mm1
    > [compton ~]$
    >
    > As long as they are not visible from a potentially hostile world, that'
    > OK. I've actually got several systems at work that are still running a
    > 1.2.13 kernel from 1995, but they are isolated from the company nets,
    > and absolutely not visible from outside the facility, never mind from
    > the world.
    >
    >
    >> As I said, these figures are much higher than Clay's, but I'm having
    >> absolutely no issues with slowness. That makes me suspect the figures
    >> are not IRQs/time, but a running count from "who -b" perhaps?
    >>

    >
    > They are a running count, but why are the IRQs for the USB and IDE
    > controllers so high _compared_ to the timer interrupts?
    >
    > Old guy
    >



    It's certainly difficult to troubleshot without a "hands-on"
    environment, even without remote access via ssh.


    --
    John

    No Microsoft, Apple, Intel, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  9. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    >...
    >
    > Holy Sh!t, something is rotten in Denmark! Look at IRQ 0. That's the
    > system timer, which is normally running at 100, 500, or 1000 interrupts
    > per second. Try manually running the command 'grep 0: /proc/interrupts'
    > as close as you can to ten seconds apart


    roughly 10 cursorblinks apart (with one spazm*):

    ct@wimp:/tmp/orbit-ct$ cat /home/ct/junk/interrupt10x
    0: 49393675 0 IO-APIC-edge timer
    0: 49396584 0 IO-APIC-edge timer
    0: 49399577 0 IO-APIC-edge timer
    0: 49402665 0 IO-APIC-edge timer*
    0: 49402859 0 IO-APIC-edge timer
    0: 49406008 0 IO-APIC-edge timer
    0: 49409233 0 IO-APIC-edge timer
    looks like ~ 300/sec.

    How high does it go before it starts over?

  10. Re: Is this data really stored in the RAM?

    On 2008-02-26, dennis@home wrote:
    >
    >
    > "clay" wrote in message
    > news:s5_wj.12630$J41.5833@newssvr14.news.prodigy.n et...
    >> dennis@home wrote:

    >
    >
    >>>

    >> probably hardware... if you saw some system specs in a earlier thread.
    >> plus the mishmash of cards and crap on it, it's amazing it runs at all.
    >>
    >> jane doa explained why grep doesn't show up earlier in this thread.
    >> I bought it.
    >> Do you see grep in your ram when you grep
    >> sudo strings /dev/mem | less ?

    >
    > I saw that explanation but I don't see how it can be.
    > To do that the pipe would have to be executed sequentially.. take all the
    > strings out and buffer them.. then start grep.. which isn't the way Unix
    > works. Unix would start the processes more or less at the same time so grep
    > should be running while the strings command is running.


    So the absence of the string "grep" in "strings /dev/mem |grep grep"
    would suggest that the processor is storing the search string
    internally. That would make sense as it is faster than continually
    retrieving the search criteria from ram.

    If sent to ram, at what point does the data in /dev/mem become
    static for the above command, if at all ... is it possible to
    create an endless loop? I guess I'm missing something.

    > I suppose it is
    > possible to engineer a condition where it could happen sequentially but it
    > wouldn't be what I would expect.
    >


    Thanks for the feedback. I'm way out of my depth already but
    appreciate input. :%

    --
    l'air du temps


  11. Re: Is this data really stored in the RAM?



    "jane doa" wrote in message
    news:v24g95-1ll.ln1@elfin.perfumed.lan...
    > On 2008-02-26, dennis@home wrote:
    >>
    >>
    >> "clay" wrote in message
    >> news:s5_wj.12630$J41.5833@newssvr14.news.prodigy.n et...
    >>> dennis@home wrote:

    >>
    >>
    >>>>
    >>> probably hardware... if you saw some system specs in a earlier thread.
    >>> plus the mishmash of cards and crap on it, it's amazing it runs at all.
    >>>
    >>> jane doa explained why grep doesn't show up earlier in this thread.
    >>> I bought it.
    >>> Do you see grep in your ram when you grep
    >>> sudo strings /dev/mem | less ?

    >>
    >> I saw that explanation but I don't see how it can be.
    >> To do that the pipe would have to be executed sequentially.. take all the
    >> strings out and buffer them.. then start grep.. which isn't the way Unix
    >> works. Unix would start the processes more or less at the same time so
    >> grep
    >> should be running while the strings command is running.

    >
    > So the absence of the string "grep" in "strings /dev/mem |grep grep"
    > would suggest that the processor is storing the search string
    > internally. That would make sense as it is faster than continually
    > retrieving the search criteria from ram.


    The processor part doesn't have enough storage to contain the search string
    at all, it can only store stuff in its registers and the 8086 family doesn't
    have many.
    However most processor chips have cache memory on them and I would expect
    the search string and most of the program to reside in there. However this
    is a cache and reflects a small bit or the system RAM so if its in the
    cache.. it is (in virtually all non-fault circumstances) in the RAM.

    >
    > If sent to ram, at what point does the data in /dev/mem become
    > static for the above command, if at all ... is it possible to
    > create an endless loop? I guess I'm missing something.


    If its in RAM it is available, there is no delay or anything like that. The
    engineered case I am thinking about below is where you page the RAM to disk
    as it is in virtual memory rather than real RAM so it wouldn't show up until
    later when the page is reloaded. You would know if the system was doing this
    as it would be extremely slow and probably wouldn't record the video
    properly.
    >
    >> I suppose it is
    >> possible to engineer a condition where it could happen sequentially but
    >> it
    >> wouldn't be what I would expect.
    >>

    >
    > Thanks for the feedback. I'm way out of my depth already but
    > appreciate input. :%


    That OK I find it hard to get down to a level where most people can
    understand anyway, but feel free to ask and I will try again if you want. I
    guess when you have been designing computer systems for decades that what
    you think is basic can be way over someone else's head. You see it all the
    time in IT all jargon and often the TLAs have multiple meanings.
    >
    > --
    > l'air du temps
    >


  12. Re: Is this data really stored in the RAM?

    On Wed, 27 Feb 2008 Usenet newsgroup alt.os.linux.ubuntu, in article
    , John F. Morse
    wrote:

    >Thanks, Moe. I see that I had a suspicion of this and you verified it.
    >Maybe I'm not thinking up to speed. ;-)
    >
    >Like you, I'm laying in bed with pneumonia, diagnosed on Feb. 15, which
    >won't go away. Coughing my head off to the point I have a bloody nose
    >(and I'm on Plavix). No fun.


    I'm not in bed at the moment, although I'm finding it useful to take a
    nap rather frequently. I've got a nine inch long incision that they
    just got around to yanking all of the staples that were holding it
    closed. but I still don't even want to think about coughing (although
    the swelling is pretty much gone down). ACK the bloody nose and
    Plavix - you have my sympathy. The bruising on both arms, wrists, and
    back of the hands has finally gone away - five days after them stopped
    poking me there.

    >> By the way, don't you believe in keeping your systems up to date?
    >> Debian has released "a few" kernel updates in the past year ;-)


    >I don't think Debian has released any kernel updates for Sarge in a
    >long time, but I have updated Etch several times on those boxen.


    http://www.debian.org/News/2007/20071228 says there was an update
    released at the end of December, but if you are still using a 2.4.x
    kernel, there was a security fix in the change from 2.4.36 to 2.4.36.1
    at kernel.org about 11 days ago which may or may not be important.

    >Some testing will need to be done first to see if a newer distro will
    >even install on these old boxen.


    I suspect the updates will still work, as Sarge isn't that old.

    >I can't afford to upgrade hardware. My health in the past nine months,
    >heart attack, two stents, severe allergic reaction to (probably) Plavix,
    >a burst appendix, which a month later was found to have cancer on it,
    >the flu in the fall, and now pneumonia, have kept me from spending as
    >much time as I want with the servers.


    It's hell getting old, isn't it. They found I had high blood pressure
    about 14 years ago as part of a routine physical, and now I'm taking
    eight different pills every morning. Have you been referred to an
    oncologist, and if so, has he done a PET (Positron Emission Tomography)
    scan? If there is anything "hot", the PET scan should find it if they
    scan that area. They put me through that last year after some biopsies
    turned up hints of a problem post surgery. I'm not on Plavix (they did
    a scope job on me 18 months ago after they found Diovan was giving me
    an irregular heartbeat under minor stress testing - and found no
    arterial problems), but they just up'ed the dose of aspirin due to
    concerns of clotting from the present surgery. Of course, that may
    also be because they haven't billed me yet. They were quick enough to
    get the "How well did we treat you" survey out to me, and I haven't
    gotten the one from the Fed's yet.

    >I reckon I'm fixin' to die, muhhumm. ;-)


    Yup - it happens to everyone sooner or later. But these are the cards
    we were dealt, and all we can do is play them.

    >> They are a running count, but why are the IRQs for the USB and IDE
    >> controllers so high _compared_ to the timer interrupts?


    >It's certainly difficult to troubleshot without a "hands-on"
    >environment, even without remote access via ssh.


    Yeah, all you can do is suggest things to look at. But this is an
    interesting sounding problem.

    Old guy

  13. Re: Is this data really stored in the RAM?

    On Tue, 26 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    , clay wrote:

    >Moe Trin wrote:


    >> Holy Sh!t, something is rotten in Denmark! Look at IRQ 0. That's the
    >> system timer, which is normally running at 100, 500, or 1000 interrupts
    >> per second. Try manually running the command 'grep 0: /proc/interrupts'
    >> as close as you can to ten seconds apart


    >roughly 10 cursorblinks apart (with one spazm*):


    But is that ten seconds? ;-)

    >ct@wimp:/tmp/orbit-ct$ cat /home/ct/junk/interrupt10x
    > 0: 49393675 0 IO-APIC-edge timer
    > 0: 49396584 0 IO-APIC-edge timer
    > 0: 49399577 0 IO-APIC-edge timer
    > 0: 49402665 0 IO-APIC-edge timer*
    > 0: 49402859 0 IO-APIC-edge timer
    > 0: 49406008 0 IO-APIC-edge timer
    > 0: 49409233 0 IO-APIC-edge timer


    2909, 2993, 3088, 194, 3149, 3225 - averages 3073 - which doesn't
    match any of the values I'd expect.

    >looks like ~ 300/sec.


    What does 'uname -a' show? This rate is a kernel compile time option,
    and most of the systems I've tested are running at 100 Hz (the old
    standard value), 1000 Hz (the standard value for 2.4.x and earlier
    2.6.x kernels), and 250 Hz (2.6.13 and later). In line with the all
    to common philosophy of "we know better", some distributions have
    decided to use other values. Also, SMP kernels may do things differently.

    >How high does it go before it starts over?


    Depends on the kernel type, but that's an "unsigned int" which in a
    32 bit system would be 0 - 4,294,967,295. If your timer is really
    running at 300 Hertz, this would be ~163.4 days.

    So, what is flogging the interrupts on (apparently) your hard drives
    (your IRQ 15, 185 and 225 - and to a lesser extent 14)? That was
    really my concern.

    Old guy

  14. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    > ...
    >
    >> roughly 10 cursorblinks apart (with one spazm*):

    >
    > But is that ten seconds? ;-)
    >
    >> ct@wimp:/tmp/orbit-ct$ cat /home/ct/junk/interrupt10x
    >> 0: 49393675 0 IO-APIC-edge timer
    >> 0: 49396584 0 IO-APIC-edge timer
    >> 0: 49399577 0 IO-APIC-edge timer
    >> 0: 49402665 0 IO-APIC-edge timer*
    >> 0: 49402859 0 IO-APIC-edge timer
    >> 0: 49406008 0 IO-APIC-edge timer
    >> 0: 49409233 0 IO-APIC-edge timer

    >
    > 2909, 2993, 3088, 194, 3149, 3225 - averages 3073 - which doesn't
    > match any of the values I'd expect.


    ok. this time 10 seconds by the clock.
    0: 12177790 0 IO-APIC-edge timer
    0: 12180294 0 IO-APIC-edge timer
    0: 12182809 0 IO-APIC-edge timer
    0: 12185309 0 IO-APIC-edge timer
    0: 12187844 0 IO-APIC-edge timer
    0: 12190334 0 IO-APIC-edge timer
    0: 12192845 0 IO-APIC-edge timer
    0: 12195367 0 IO-APIC-edge timer

    2504, 2515, 2500, 2535, 2490, 2511, 2522 averages to 2511

    > What does 'uname -a' show?


    ct@wimp:~$ uname -a
    Linux wimp 2.6.17-12-generic #2 SMP Tue Feb 12 01:17:37 UTC 2008 i686
    GNU/Linux

    re: IRQ 15, 185, 225...
    Probably related to recording HD. saa7133 is my dvb card.
    Here's with no recording in process.
    ct@wimp:~$ cat /proc/interrupts
    CPU0 CPU1
    0: 12482696 0 IO-APIC-edge timer
    14: 557112 0 IO-APIC-edge ide0
    15: 8352224 0 IO-APIC-edge ide1
    185: 3479999 0 IO-APIC-level uhci_hcd:usb1,
    ohci_hcd:usb6, skge, nvidia
    225: 0 0 IO-APIC-level saa7133[0], saa7133[0]

    Here's ~ five minutes into a HD recording:

    ct@wimp:~$ cat /proc/interrupts
    CPU0 CPU1
    0: 12605598 0 IO-APIC-edge timer
    14: 568366 0 IO-APIC-edge ide0
    15: 8434705 0 IO-APIC-edge ide1
    185: 3858203 0 IO-APIC-level uhci_hcd:usb1,
    ohci_hcd:usb6, skge, nvidia
    225: 89060 0 IO-APIC-level saa7133[0], saa7133[0]

    This is all fun, and I very much appreciate the education. Not sure if
    we can debug it this way.
    I'm going to learn about core files and see if they will tell us something.


  15. Re: Is this data really stored in the RAM?

    On Thu, 28 Feb 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    , clay wrote:

    >Moe Trin wrote:


    >> But is that ten seconds? ;-)


    >ok. this time 10 seconds by the clock.


    >2504, 2515, 2500, 2535, 2490, 2511, 2522 averages to 2511


    Much milder! That's the default rate for a 2.6.13 or later kernel.
    In answer to the previous post - rollover ~196 days.

    >> What does 'uname -a' show?

    >
    >ct@wimp:~$ uname -a
    >Linux wimp 2.6.17-12-generic #2 SMP Tue Feb 12 01:17:37 UTC 2008 i686
    >GNU/Linux


    OK, a generic SMP kernel. Good.

    >re: IRQ 15, 185, 225...
    >Probably related to recording HD. saa7133 is my dvb card.
    >Here's with no recording in process.
    >ct@wimp:~$ cat /proc/interrupts
    > CPU0 CPU1
    > 0: 12482696 0 IO-APIC-edge timer
    > 14: 557112 0 IO-APIC-edge ide0
    > 15: 8352224 0 IO-APIC-edge ide1
    > 185: 3479999 0 IO-APIC-level uhci_hcd:usb1,
    > ohci_hcd:usb6, skge, nvidia
    > 225: 0 0 IO-APIC-level saa7133[0], saa7133[0]
    >
    >Here's ~ five minutes into a HD recording:
    >
    >ct@wimp:~$ cat /proc/interrupts
    > CPU0 CPU1
    > 0: 12605598 0 IO-APIC-edge timer
    > 14: 568366 0 IO-APIC-edge ide0
    > 15: 8434705 0 IO-APIC-edge ide1
    > 185: 3858203 0 IO-APIC-level uhci_hcd:usb1,
    > ohci_hcd:usb6, skge, nvidia
    > 225: 89060 0 IO-APIC-level saa7133[0], saa7133[0]


    OK (12605598-12482696)/250 is 491.6 seconds - and in that time, you
    had 568366-557112 = 11254 ide0 interrupts (22.9 per second), 82481 ide1
    interrupts (167.8 interrupts/second), 378204 #185 interrupts (769.3
    interrupts/second), and 89060 #225 interrupts (181.2 interrupts/second).

    The IRQ rate on ide0 isn't that bad, and ide1 vs your dvb card seems
    related (though perhaps higher than I'd expect), but what's going on
    with IRQ 185? Network card (skge)? Video card (nvidia)? Something on
    the USB bus?

    My concern is that this is rather busy, and may be causing the lockups.
    What does 'uptime' show for a load when the system is goofing off, as
    compared to recording as above. ('uptime' will show a single snapshot,
    as opposed to 'top' which shows considerably more data, but may add
    significantly to the load on an already heavily loaded system.)

    Old guy

  16. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    >...and ide1 vs your dvb card seems
    > related (though perhaps higher than I'd expect),

    ide1 is where all the recordings go so if it's recording a show and
    commercial flagging another, it might get busy?

    but what's going on
    > with IRQ 185? Network card (skge)? Video card (nvidia)? Something on
    > the USB bus?

    Nothing on the USB but a keyboard and mouse. Maybe the NIC (skge)
    streaming HD content to the frontend and downloading from Usenet at the
    same time...

    >
    > My concern is that this is rather busy, and may be causing the lockups.
    > What does 'uptime' show for a load when the system is goofing off, as
    > compared to recording as above...


    ct@wimp:~$ uptime
    13:41:54 up 3 days, 6:18, 4 users, load average: 0.44, 0.50, 0.60

    ct@wimp:~$ uptime
    14:21:06 up 3 days, 6:57, 4 users, load average: 5.94, 4.75, 3.11

    I can throw in an unrar job and a transcode or two and get it up to 7.00
    or so, then things start getting poky.

  17. Re: Is this data really stored in the RAM?

    On Sat, 01 Mar 2008, in the Usenet newsgroup alt.os.linux.ubuntu, in article
    <7mlyj.17346$0w.8313@newssvr27.news.prodigy.net>, clay wrote:

    >Moe Trin wrote:


    >>...and ide1 vs your dvb card seems
    >> related (though perhaps higher than I'd expect),


    >ide1 is where all the recordings go so if it's recording a show and
    >commercial flagging another, it might get busy?


    That might be true. Even the old fashion analog television (NTSC) uses
    a lot of bits just for the video.

    >> but what's going on with IRQ 185? Network card (skge)? Video card
    >> (nvidia)? Something on the USB bus?


    >Nothing on the USB but a keyboard and mouse. Maybe the NIC (skge)
    >streaming HD content to the frontend and downloading from Usenet at the
    >same time...


    /sbin/ifconfig -a about 10 seconds apart, and compare the figures
    for RX and TX packet counts.

    >> My concern is that this is rather busy, and may be causing the lockups.
    >> What does 'uptime' show for a load when the system is goofing off, as
    >> compared to recording as above...

    >
    >ct@wimp:~$ uptime
    > 13:41:54 up 3 days, 6:18, 4 users, load average: 0.44, 0.50, 0.60
    >
    >ct@wimp:~$ uptime
    > 14:21:06 up 3 days, 6:57, 4 users, load average: 5.94, 4.75, 3.11


    Call on line one from "The Society For The Prevention Of Cruelty To
    Computers" - something about an abuse issue.

    The load average is the number of processes waiting for CPU cycles
    averaged over the last one, five, and fifteen minutes. It would
    appear that you have this box pretty heavily loaded, and my concern
    is that this is causing it (though interrupt blocking) to trip over
    it's own feet.

    >I can throw in an unrar job and a transcode or two and get it up to
    >7.00 or so, then things start getting poky.


    Depends on the kernel, but I prefer not to see my systems running much
    above 3 for any length of time. In the state you had it at 14:21:06,
    run 'top' for about 10 seconds, preferably in a terminal that is 80
    character (or slightly more) wide, by at least 30 lines high, and let's
    hope this doesn't drive the system into the ground. (On this system, top
    is run niced to +19 - which is to say lowest priority, but it's still
    eating a significant amount of resources.) What is the top (most CPU
    intensive) processes.

    Old guy

  18. Re: Is this data really stored in the RAM?

    Moe Trin wrote:
    >...
    >
    >>> My concern is that this is rather busy, and may be causing the lockups.
    >>> What does 'uptime' show for a load when the system is goofing off, as
    >>> compared to recording as above...

    >> ct@wimp:~$ uptime
    >> 13:41:54 up 3 days, 6:18, 4 users, load average: 0.44, 0.50, 0.60
    >>
    >> ct@wimp:~$ uptime
    >> 14:21:06 up 3 days, 6:57, 4 users, load average: 5.94, 4.75, 3.11

    >
    > Call on line one from "The Society For The Prevention Of Cruelty To
    > Computers" - something about an abuse issue.
    >
    > The load average is the number of processes waiting for CPU cycles
    > averaged over the last one, five, and fifteen minutes. It would
    > appear that you have this box pretty heavily loaded, and my concern
    > is that this is causing it (though interrupt blocking) to trip over
    > it's own feet.
    >
    >> I can throw in an unrar job and a transcode or two and get it up to
    >> 7.00 or so, then things start getting poky.

    >
    > Depends on the kernel, but I prefer not to see my systems running much
    > above 3 for any length of time. In the state you had it at 14:21:06,
    > run 'top' for about 10 seconds, preferably in a terminal that is 80
    > character (or slightly more) wide, by at least 30 lines high, and let's
    > hope this doesn't drive the system into the ground. (On this system, top
    > is run niced to +19 - which is to say lowest priority, but it's still
    > eating a significant amount of resources.) What is the top (most CPU
    > intensive) processes.
    >


    ct@wimp:~$ uptime
    21:56:28 up 3 days, 14:32, 5 users, load average: 11.91, 10.89, 7.47

    22037 ct 18 0 8300 1480 1088 D 11 0.1 1:58.85 unrar

    142 root 15 0 0 0 0 D 3 0.0 6:30.02 kswapd0

    20920 root 10 -5 0 0 0 S 1 0.0 0:33.52 saa7133[0]
    dvb
    5863 mythtv 15 0 278m 32m 13m S 1 3.2 7:20.36
    mythbackend
    5152 root 15 0 192m 169m 9580 S 0 16.7 54:42.75 Xorg

    21918 ct 15 0 150m 53m 19m S 0 5.3 1:11.91 firefox-bin

    22402 ct 16 0 2372 1172 848 R 0 0.1 0:00.68 top

    22481 root 15 0 0 0 0 D 0 0.0 0:00.05 pdflush

    1 root 16 0 1632 540 448 S 0 0.1 0:01.17 init

    2 root RT 0 0 0 0 S 0 0.0 0:00.04
    migration/0
    3 root 34 19 0 0 0 S 0 0.0 0:00.12
    ksoftirqd/0
    4 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/0

    5 root RT 0 0 0 0 S 0 0.0 0:00.00
    migration/1
    6 root 34 19 0 0 0 S 0 0.0 0:00.00
    ksoftirqd/1
    7 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/1

    8 root 10 -5 0 0 0 S 0 0.0 0:00.96 events/0

    9 root 10 -5 0 0 0 S 0 0.0 0:00.00 events/1

    10 root 10 -5 0 0 0 S 0 0.0 0:00.00 khelper

    11 root 10 -5 0 0 0 S 0 0.0 0:00.03 kthread

    14 root 10 -5 0 0 0 S 0 0.0 0:11.16 kblockd/0

    15 root 10 -5 0 0 0 S 0 0.0 0:00.06 kblockd/1

    16 root 13 -5 0 0 0 S 0 0.0 0:00.00 kacpid

    17 root 13 -5 0 0 0 S 0 0.0 0:00.00
    kacpi_notify
    107 root 10 -5 0 0 0 S 0 0.0 0:00.00 kseriod

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2