Difference between revisions of "User:Pi3832"

From ThinkWiki
Jump to: navigation, search
Line 100: Line 100:
Transclude info from [http://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-45884].
Transclude info from [http://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-45884].

Revision as of 20:42, 2 February 2012

My T30

T30 Main Page

Installing Hardware

Ultrabay SATA HDD Caddy

Using an after-market caddy causes the kernel to complain that it was "limited to UDMA/33 due to 40-wire cable". But I was able to over-ride that by adding libata.force=2:80c to /boot/grub/grub.conf. Now connects at UDMA5, 100 MB/s.


Fedora is not automagically noticing that I'm ejecting the caddy and shutting down the drive. There is a page here in ThinkWiki on setting this up properly: How to hotswap Ultrabay devices. I'm not a huge fan of the script there, because it's trying to be all things to all people. I'd rather roll-my-own, so that I can come up with something simpler.

I was also baffled by the udev stuff. I've never done anything with that before. So, here is what I've figured out so far:

  • The Ultrabay (on a T30) is /sys/devices/platform/dock.2
    • dock.0 is the docking-bay (the thing onna desk you attach a laptop to)
    • dock.1 is the main battery bay
  • When you flip the release on the arm that lets you pull out the Ultrabay device, the computer knows
    • /sys/devices/platform/dock.2/flags changes from 32 to 34
    • If you change your mind, and stick the extraction-arm back in, the flag stays 34! There's no going back on an ejection event.

The udev rule given on the "How to hotswap Ultrabay devices" page should work, since it's just looking for ACTION=="change", but I may use ATTR{flags}=="34", just because I can. I wonder if there's some way to tell if I've got the HDD caddy or the battery in there? (To get all the udev stuff

And the ugly way to eject a HDD, once you've unmounted all the partitions, is to put the drive to sleep, then tell the ACPI system that you're about to undock

#hdparm -Y /dev/sdb
#echo 1 > /sys/devices/platform/dock.2/undock

Knowing me, I'll just do it by hand for the next 6 months before I bother getting around to automating the process.

The udev info can be had with:

# udevadm info -a -p /sys/devices/platform/dock.2

And then there's this helpful page: Writing udev Rules


Then again, I may be doing it the hard way. The util "udisks" may do all of this stuff for you.

USB 2.0 Ports

I added a PCMCIA card with 2 USB 2.0 parts on it. Automagically identified and configured. Write testing showed it 4 times faster than stock USB 1.0 ports. Command for write testing:
$ tiotest -t 1 -f 700
Read testing wasn't working right. I may just use a stopwatch.

PCMCIA CompactFlash card reader

I'm trying to get a generic PCMCIA CF-card reader to work. It's automagically seen and configured, but it's forced to PIO0 mode, which is slower than erosion. The CF card I'm using, TS8GCF133, purportedly supports DMA modes, but I can't seem to get the system to recognize that. I also can't get any PIO mode other than 0 to work. It may be the no-name adapter I'm using.


This isn't good news:

ValenceParadigm wrote on Windows 7 IT Pro Forums:
The Compact Flash card, while UDMA ready, lacks the logic for Bus Mastering. Without a bus mastering controller, the UDMA modes are not possible. What is needed is a 68-pin to 50-pin adapter with the bus mastering controller built in. Delkin used to produce one of these, as did Kodak and a select few others.

These adapter cards with the built-in controllers are RARE now, and if you have one, you can stand to make some money selling it if it is no longer needed. The manufacturer of the controller chips used in the adapters is no longer in business, so companies like Kodak and Delkin couldn't manufacture more adapters even if you promised them your first-born-child.

Does this also mean that mwdma is right out? Can I at least get a better PIO mode than 0?


I can't read c code for crap, but I think that pio0 mode might actually be hard-coded into the pata_pcmcia driver. The kernel consistently identifies the CF card correctly, and says it will do pio4, then steadfastly refuses to make that ata port anything other than pio0.

And yet the USB card operates as EHCI just fine.


I installed a second 1 GB stick of RAM. System recognized it and seems to be happy with it. That makes a total of 2 GB.

Using It

Connecting Cell Phone

I couldn't connect my Samsung SGH-T669 as a Mass Storage device, despite having set the phone to MTP mode.


usb 2-2: new full speed USB device using uhci_hcd and address 10
usb 2-2: New USB device found, idVendor=04e8, idProduct=f000
usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=3
usb 2-2: Product: Qualcomm Configuration
usb 2-2: Manufacturer: Qualcomm, Incorporated
usb 2-2: SerialNumber: [serialnumber]
scsi8 : usb-storage 2-2:1.0
mtp-probe: checking bus 2, device 10: "/sys/devices/pci0000:00/0000:00:1d.1/usb2/2-2"
mtp-probe: bus: 2, device: 10 was not an MTP device
usb_modeswitch: switching 04e8:f000 (Qualcomm, Incorporated: Qualcomm Configuration)

The problem is usb_modeswitch. It's trying to do something fancy with setting up the phone to be a modem. I disabled usb_modeswitch, and the phone connected like a USB mass storage device. (Well, the microSD card connected, which is all I wanted.)

I went to /etc/usb_modeswitch.conf and changed "DisableSwitching=0" to "DisableSwitching=1". Viola!

At some point I should see if I can figure out what the usb_modeswitch stuff should be and send it off to the developers.


Link in stuff from the Lenovo Support site about "under linux".

Transclude info from [1].