Linux Experts
  • Content Count

  • Joined

  • Last visited

About jcl

  • Rank

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Location
    The Internet

Previous Fields

  • Operating System

Recent Profile Visitors

19316 profile views
  1. I have no idea. I've never had any reason to learn how to troubleshoot USB. Anyway, if it is a kernel issue, you'd probably have to replace the kernel to fix it. If that's not option, I'm not sure what you could do even if you knew the cause.
  2. 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.
  3. [ 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.
  4. It's Chrome OS this week. It was Android a few months ago. I'm not sure which I'd want less.
  5. AV vendors would release software for rocks if they thought people would pay for it.
  6. This process also works in reverse. Still, the iPad is the only tablet I've seen that I'd even consider paying for.
  7. 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.
  8. jcl

    Qt Help

    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.
  9. WANT! But can't have without a Linux- or Windows-based SDK.
  10. Dunno. Probably in the neighborhood of 50 MiB/month.
  11. I pay $6/month for unlimited data and tethering on T-Mobile. I think I'm glad I don't use AT&T or Verizon.
  12. There are no HTML/CSS certifications. No, wait, never mind, I'm sure there are. Probably dozens. Damn it.
  13. If you're using Compiz, you might be able to force the window to the desired position using the Fixed Window Placement settings from the Place Windows plugin.
  14. If the file was unreadable, I'd expect an open error or read error instead of a parse error. It sounds like it's corrupt.
  15. 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.