jcl

Linux Experts
  • Content Count

    1299
  • Joined

  • Last visited

Posts posted by jcl

  1. From what I gather, it's usually caused by USB controllers (and possibly devices) disconnecting for whatever reason. However, I think there have been kernel bugs with similar, if not identical, symptoms and since it's easier to deal with the kernel than defective hardware, I'd start there. So, try a different kernel. Probably the easiest way would be to grab a live CD of a very up-to-date distro.

  2. [  177.170759] INFO: task khubd:546 blocked for more than 120 seconds.
    [ 177.170771] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 177.170780] khubd D f776bc00 0 546 2
    [ 177.170791] f77d35a0 00000046 f8855131 f776bc00 00000292 f77d372c c180bfc0 00000000
    [ 177.170810] f8857f80 fffef437 f7490ac0 fffffffe 00000000 00000000 00000000 000000ff
    [ 177.170828] f7490ac0 f7490ac0 f7909ea8 f7909ef0 f88a80bb 00000000 f77d35a0 c0131a20
    [ 177.170846] Call Trace:
    [ 177.170867] [<f8855131>] start_ed_unlink+0x11/0x4c [ohci_hcd]
    [ 177.170907] [<f88a80bb>] usb_kill_urb+0x90/0xbb [usbcore]
    [ 177.171005] [<c0131a20>] autoremove_wake_function+0x0/0x2d
    [ 177.171032] [<f88a8947>] usb_start_wait_urb+0x5d/0x89 [usbcore]
    [ 177.171077] [<f88a8371>] usb_init_urb+0x1a/0x26 [usbcore]
    [ 177.171120] [<f88a8b36>] usb_control_msg+0xae/0xc8 [usbcore]
    [ 177.171169] [<f88a42bb>] hub_port_init+0x223/0x4ef [usbcore]
    [ 177.171225] [<f88a5f7f>] hub_thread+0x572/0xb04 [usbcore]
    [ 177.171281] [<c0131a20>] autoremove_wake_function+0x0/0x2d
    [ 177.171298] [<f88a5a0d>] hub_thread+0x0/0xb04 [usbcore]
    [ 177.171339] [<c013195f>] kthread+0x38/0x5d
    [ 177.171350] [<c0131927>] kthread+0x0/0x5d
    [ 177.171361] [<c01044f7>] kernel_thread_helper+0x7/0x10

    and so on. It appears that the USB hub daemon thread (khubd) keeps hanging. No khubd, no USB drives.

  3. It all starts with I would never use a apple product they're evil and control everything. Then you use something made by apple and you think, this is too easy I don't trust anything this simple. Then it happens this ipad is kind of fun to use, "don't tell anyone I said that". Wow some of these free app are great maybe I'll spend a dollar or two on a app. Next thing you know you have 100 apps on the ipad and start thinking maybe I'll try a Mac. Hey OS X is't nearly as bad as I thought but again it is way to simple. If I use this to long I'll become one of them mac users who know nothing about tech... stupid simpletons. Thats when it happens you're posting on a forum and write something positive about Apple. And all of a sudden you are branded Mac Fanboy.

    This process also works in reverse.

    Still, the iPad is the only tablet I've seen that I'd even consider paying for.

  4. Assuming the old machine works (at all), has rsync installed, and the new drive is mounted under /mnt:

    # rsync -aHA --exclude=/mnt/ --exclude=/dev/ --exclude=/proc/ --exclude=/sys/ / /mnt

    should create a copy of the entire system, sans excluded directories, under /mnt/. You might have to fiddle with the options a bit to get exactly what you want. If you're sure that everything you need is under /etc, /home, and /var, you can --exclude everything else or just rsync each of those directories individually:

    # rsync -aHA /var /mnt
    # rsync -aHA /etc /mnt
    # rsync -aHA /home /mnt

    Note that leading and trailing slashes on the directories in all of these rsync commands are important. Also, the -H and -A options probably aren't necessary and slow down the process but I included them just in case.

    If the system goes down while the copy in progress, you can just run the same command again and rsync will pick up where it left off.

    If rsync isn't installed or you don't want to deal with it, you can kind of do the same thing with cp -a. The main problem is that cp might not deal with a sudden shutdown as well as rsync; while cp does take -u option that tells it update the destination instead of blindly copying everything, I don't think it'll catch files that were only partially copied (it only checks timestamps whereas rsync checks timestamps, file sizes, and optionally checksums doesn't matter, it looks like the timestamps aren't reset until the copy is complete, so cp won't even try to update the partial files).

    If you want to use tar you'll have to figure it out yourself ;) I haven't used tar in ages. You might need to build up the tarball(s) incrementally as the system reboots.

    You might want to dump any databases, for example with mysqldump, just on the off chance that something goes wrong, if you can do it quickly enough.

    Once the data is safely copied you'll have to fix the file owners. You can either set the user and group id numbers on the new system to match the old system or run around chowning everything. If you prefer the second option,

    # find /mnt/ -printf "%p\t%u:%g\n"

    will print the symbolic owner and group of all of the copied files in tab-separated format for reference.

  5. rID = http.get("/index.html",pdev);

    pdev is null here, so http returns the data via signals. You need to move

    QTextStream stream(&file);
    pdev = stream.device();

    above the call to QHttp::get() or just pass file to get() instead.

  6. First thing I'd do is log out, log back in, and check ~/.xsession-errors and the system logs (/var/log/Xorg.0.log -- really, everything under /var/log/) and see if X or the NVIDIA driver are complaining about anything.

    If there's nothing in the log, you could flail around a bit. Three approaches come to mind. (You don't have to log out while you're doing any of this, but you do have log out and back in for the changes to take effect.)

    First, you could move (not copy!) your xorg.conf somewhere safe (I usually just rename it xorg.conf.bak) and then run nvidia-xconfig as root to generate a fresh xorg.conf. If the new files works, you can copy anything not related to the display that looks important from the old xorg.conf to the new one.

    Second, you could delete or comment out (by adding a # to the beginning of each line) everything related to display settings in xorg.conf and see if correct resolution is auto-detected. IME auto-detection works very well these days.

    Third, you could try to force X to use the correct resolution. It's been years since I've done that but I think you could get away with editing the Device, Monitor, and Screen sections in xorg.conf like so

    Section "Device"
    Identifier "Device0"
    Driver "nvidia"
    EndSection

    Section "Monitor"
    Identifier "Monitor0"
    EndSection

    Section "Screen"
    Identifier "Screen0"
    Device "Device0"
    Monitor "Monitor0"
    DefaultDepth 24

    Subsection "Display"
    Depth 24
    Modes "1280x960"
    EndSubsection
    EndSection

    You might also have to edit to the Screen section to add

        Option "ModeValidation" "NoEdidModes"

    or

        Option "UseEdid" "FALSE"

    to order the NVIDIA driver to ignore the display when determining what modes are available.

    Incidentally, if you aren't using multiple displays, you might want to add

        Option "DynamicTwinView" "FALSE"

    to the Screen section to disable TwinView. When TwinView is enabled the driver lies about the screen refresh rate, which, as I recall, breaks vsync.

  7. Well for us Tamiflu was perhaps a welcome placebo effect.

    My daughter had violent chest pain, nausea, fever, etc...all the classic symptoms of H1N1, and the condition was rapidly getting worse. When she took the Tamiflu she quickly recovered.

    Tamiflu is supposed to be an effective treatment for the flu itself.

  8. Well I never really expected it to impact the "complications" since most of them are caused by secondary infections (pneumonia, staph ....).

    It is designed to slow the replication of the virus so that the immune system can deal with it and win faster

    ... in order to prevent complications. There's little reason to treat the flu itself.

    I saw on a special on H1N1 that they have identified a portion of the flu virus which appears to be common to all flu strains . If they can develop a vaccine that targets that we could have a single shot that grants long term immunity to all strains rather than an annual vaccine for what they feel will be most common.

    Yeah. IIRC there's at least one universal vaccine in clinical trials.