Your T400/T500/T410/T510 not suspending/hibernating under Ubuntu 10.10 Maverick Meerkat? Fix.

If your trusty Lenovo T[45][01]0 does not want to suspend/hibernate under Ubuntu 10.10, but just seems to do it and then comes back right away, blacklist a bunch of modules editing /etc/modprobe.d/blacklist.conf:

# suggested blacklist to fix lenovo suspend failure. lambertdw
blacklist parport
blacklist parport_pc
blacklist ppdev
blacklist lp
blacklist tpm_tis


Alternatively, just rmmod them for testing purposes (thanks to lambertdw). Offending module for me was tpm_tis, which handles the Trusted Platform Module. I don’t need it anyway. Supposedly this should be fixed in kernels >= 2.6.36.

Fixing vmware-tools vmhgfs on newer Linux kernels (probably anything >= 2.6.36)

If you’re trying to install vmware-tools inside a linux guest and get the dreaded
super.c:73: error: unknown field ‘clear_inode’ specified in initializer
error while compiling vmhgfs for shared folder support (which I use a lot), this will help (thanks to Anjo from German VMWare Forums):

• unpack /usr/lib/vmware-tools/modules/source/vmhgfs.tar to somewhere
• open vmhgfs-only/super.c in your favorite text editor
• edit from

  #ifndef VMW_USE_IGET_LOCKED
   .read_inode       = HgfsReadInode,
   #endif
   .clear_inode      = HgfsClearInode,
   .put_super        = HgfsPutSuper,
   .statfs              = HgfsStatfs,
   };
  

  to (note .clear_inode -> .evict_inode)

  #ifndef VMW_USE_IGET_LOCKED
     .read_inode    = HgfsReadInode,
  #endif
     .evict_inode   = HgfsClearInode,
     .put_super     = HgfsPutSuper,
     .statfs           = HgfsStatfs,
  };
  

• repack vmhgfs.tar including edited super.c
• execute vmware-config-tools.pl
• profit

“reset high speed USB device using ehci_hcd and address 3″, your syslog and what fixed it for me

If you use external USB drives (be it SD-Cards, Hard Disk or Thumbs) and your drive(s) seem to hang from time to time while spitting out ”[...] reset high speed USB device using ehci_hcd and address 3 [...]” in your syslogs, the following fixed it for me.

My one little 320GB 2.5″ external Western Digital USB hard drive had this issue, while the big ones didn’t – seems like it is somehow related to being powered by the bus itself or using a dedicated power supply. Anyway, the drive seemed to hang on large file transactions (like copying a big file) and then the kernel had to reset it, announcing it via the syslog. Very annoying, especially because SMB transfers always got interrupted and went totally  foobar. The fix was quite simple. max_sectors for the drive was set to its default 240 value, which the drive choked on for no apparent reason whatsoever. Issuing a quick
echo 128 > /sys/block/sdc/device/max_sectors
fixed it. YMMV. Of course replace sdc with the actual node of your drive.