Announcement

Collapse
No announcement yet.

Blank screen while copying

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    Blank screen while copying

    The weirdest things can happen...

    Whenever i copy/move large amounts of data on my harddisk or copy a CD on the fly the my monitor goes blank. Copying from CD to HD or burning from HD to CDRW works flawlessly. I fear that the primary IDE bus is damaged, but i don't know how to check. Any ideas?

    I'm running Debian SID on an Epox mainboard with VIA KX133 chipset and an old 750 MHz Athlon. I'm using the onboard AC97 codec and have a Realtek 8029(AS) PCI NIC and an G400 16MB SH. The drives are a Maxtor 40 GB (hda), a Lite-On 12x/8x/40x cd-writer (hdc) and a LG 12x/40x DVD (hdb) - all three use DMA33.

    I'm totally stumped, i don't even know where to start looking!
    Tags: None
  • #2
    Hmm, I wonder if it's some weird power management issue... is the screen going into a powersave mode?

    Perhaps the console or X screensaver is activating too early. I remember (ages ago) a few people on the kernel mailing list were having problems with the system time running very fast and causing problems like this. I can't remember what the problem was or how it was resolved. You might want to search through the archives.

    VIA chipsets have a reputation for bugs, particularly with their IDE controllers. You could try building yourself a kernel and enabling the 'PCI Quirks' option.

    But to be honest, I'm as stumped as you are...
    Blah blah blah nick blah blah confusion, blah blah blah blah frog.

    Comment

    • #3
      Thanks for your answer!

      I don't think its a powersafe issue, because the screen turns back on after the transfer is finished. Also, i forgot this in the first post, the screen "flashes" which means that the monitor turns on and off and on again during the transfer but at an arbitrary rate and sometimes it doesn't do so at all. The monitor itself shows no signs of being in powersafe mode.

      For now i will try the "PCI quirks" option and search the kernel list archive. I will report back when i have something new.

      Comment

      • #4
        Are things sharing interrupts? Moving data to CD drives is nowhere near as intensive as HD/HD copying.
        Gigabyte P35-DS3L with a Q6600, 2GB Kingston HyperX (after *3* bad pairs of Crucial Ballistix 1066), Galaxy 8800GT 512MB, SB X-Fi, some drives, and a Dell 2005fpw. Running WinXP.

        Comment

        • #5
          Wombat: No, there are no shared IRQSs The devices are on the usual IDE IRQs, 14 and 15. The G400 is sitting on 10, the NIC on 11 and the Sound Codec doesn't need one.

          Anyhow, i experimented a little and put the IRQ handling into the kernel domain, so the BIOS isn't involved after initial boot. BTW, i took the opportunity to upgrade to 2.4.20 - don't worry, i am using ext3 ordered mode - and i have news to report.

          Apperently i was wrong and Ribbit was right. It seems to be connected to powersaving features! I was fooled by the fact that the status led of the monitor did not start flashing, but it does now. I compiled the kernel with all troubleshooting and compatibility options (though there is no PCI Quirks option) on and switched the BIOS APM support off. Halting and rebooting is still working like a charm.

          Whatever, there are some new hints. During CD copying to CDRW (using XCDRoast) the monitor still blanks after sending CUE but _sometimes_ i can bring it back with wake up actions like mouse movement or keypresses. The erratic behaviour does not end after the copy action but becomes less and less frequent and seems to cease completely after about 30 minutes (may this be a heat issue? Proc shows neat 25 to 27 degree C).
          However, it doesn't blank anymore during HD to HD ops and it seems to be confined to X now. I managed to copy a CD with cdw (on a tty of course) without blanking once.

          I'm still totally flabbergasted and i wonder if there are some more options i could use to debug this situation. I haven't turned on any of the debugging options in the kernel, because i don't know which one are appropiate and i want to avoid unnecessary bulk.

          So far so good. At least i can copy in the background using a console. But still i would like to fix this issue.

          Thanks again to all of you. Be back soon.

          Comment

          • #6
            Looks like some deep-seated problem, but since it seems to be confined to X, you might try xset -dpms and xset s off to turn off the DPMS and screensaver (also make sure you're not running any screensaver programs) and try again. Just to be sure.
            Blah blah blah nick blah blah confusion, blah blah blah blah frog.

            Comment

            • #7
              Most excellent! I just completed a CD copy action and no blanking! Seems that you have found a workaround, but the actual reason still evades me :-(

              Thank you very much. Good work.

              Comment

              • #8
                OK, that means something is/was activating the X screensaver early. I can't imagine what, but you could try running xclock -update 1 and see if your clock does run fast during burning as I suggested earlier. If it doesn't, you probably want to take this problem to the XFree86 guys and see if they can help. If it does, try the kernel list (or its archives).
                Blah blah blah nick blah blah confusion, blah blah blah blah frog.

                Comment

                • #9
                  Since i'm using Oroborus as a WM i have a xclock running anyway (at 3 sec interval). And it seems to run fast. At one time i witnessed a discrepancy of over an hour, but it always jumped back to the right time after a few minutes. Anyway, i'm off to the kernel-list... Thanks again!

                  Comment

                  Previous template Next
                  Working...
                  X