Fedora Core 3 Linux on a T43p - slow Ultrabay slim HDD

T4x series specific matters only
Post Reply
Message
Author
eustonr
Posts: 2
Joined: Mon Sep 26, 2005 3:39 pm
Location: London

Fedora Core 3 Linux on a T43p - slow Ultrabay slim HDD

#1 Post by eustonr » Mon Sep 26, 2005 4:03 pm

Hi,

I have a shiny new T43p, and of course being a unix consultant, I installed Fedora core 4 onto it.

It went well, but after installing the thinkpad module onto it, I would get crashes whenever I moved the thinkpad. I think it has something to do with the hard disk protection. Anyway, I wasn't happy with FC4, so I downgraded to FC3.

Its been great - but there are a few outstanding issues. Some niggling (like the thinkpad module causes crashes if installed, same as FC4). Some not so nice - the the flgx linux driver for the ATI display doesn't seem to work proplerly. Although I get 2000 frames per second with glxgears, the display seems slower and more jerky than my old T41 with normal use.

But this aside, The main problem is the HDD caddy for the Ultabay drive - although it works, it doesn't work well.

I have a 60Gb drive as my main drive, and there's an 80Gb in the caddy.

Its very (very) slow, and if I do a large file transfer from the 2nd drive to the primary (or vice versa) , the system becomes unusable during the transfer. The mouse becomes jerky, and very slow, and all processes slow down to a slow crawl. This happened on FC4 as well.

Any ideas anyone? I think that it has something to do with the fact that the primary gets configured by Fedora as a SCSI drive (/dev/sda), while the drive caddy gets configured as an IDE drive (/dev/hdc)

I'm going to try and configure the drive caddy as a "pseudo" scsi device, same as the primary drive is - and I'll post the results here. Any thoughts in the mean time, let me know.

Robert

eustonr
Posts: 2
Joined: Mon Sep 26, 2005 3:39 pm
Location: London

answered my own question.....

#2 Post by eustonr » Mon Sep 26, 2005 4:45 pm

Its remarkable what you can do when you apply yourself....

I just fixed the problem. The answer was in the question.

After writing the above note, I looked in the boot log. I noticed at boot time, the kernel complains that the IDE port 0x1F7 is busy - thats ide0, the first drive. In the kernel log, it also says (when initialising the IDE driver) 0x1F7 is "in-use" and busy. That made sense, because the scsi driver was using the drive to boot from. ie, hard configured to boot the drive as a scsi.

A little further down, the log says ata: 0x170 IDE port busy

ata is the scsi driver, and 0x170 is the second device. Light goes on - there's two drivers - the ide and the scsi, both trying to control the 2 disks. Since the operating system is configured to boot the drive as scsi, hd0 is scsi. Because the ide driver loads first, before the ata module, it grabs the only free drive - hd1, but cant grab hd0, as its used by the kernel.... so when ata loads, it can only see the first disk, and IDE sees the 2nd...


The BEST solution would be for the kernel to initialise the ata drver BEFORE the ide one - so perhaps its a kernel issue.

But in the mean time, the fix is to disable the ide driver. ie, kernel options "hda=noprobe hdc=noprobe" . A quick edit of /etc/grub.conf, and added those 2 to the end of the kernel line, reboot ... and voila! Problem fixed. /dev/hdc is now seen as /dev/sdb

I mounted the drive, and did another large transfer..... What a difference! Wahoo!

Robert

Post Reply
  • Similar Topics
    Replies
    Views
    Last post

Return to “ThinkPad T4x Series”

Who is online

Users browsing this forum: No registered users and 6 guests