It is neither here not there, but I just looked up my SATA controller. It is an "Intel ESB2 SATA 3.0Gbps Controller". Supermicro's tech support swore to me when I configured these three system, that I could hot swap. Again, neither hear nor there.

What I need is a way to check if the drive is in the sleeve and the power is on that does not rely on previous information gathered by the kernel when it boots up. (And a timer that does not go foobar when it fires off.)

-T

If, as you conjecture, the kernel is relying on information stored at boot, then, clearly, the kernel must somehow get the information from the hardware. (Otherwise the kernel would have nothing to store.)

If this is so, than the BIOS or the device controller must make the information available. So, in principle, all you need to do is look at your (detailed) device driver specifications and BIOS specifications to see what you need to read from the driver or BIOS to find out if there is, in fact, a drive in the sleeve. According to the Supermicro site, you need to ask you vendor for the information since Supermicro apparently believes that its customers are its vendors, not the product end-users.

But you should be able to find that information, and, once you get it, you should be able to query your system before issuing the mount command.

I'm sorry I can't be more helpful, but, hey, I'm not even an end user.

lshal ?
I use this for checking that a cd is inserted, might work..

Try looking for changes in the content of one of these directories:

Interesting idea. Those are, I believe, maintained by udev, so there might be some property that udev could use to trigger an automatic mount when the sleeve was filled, and an unmount when you pulled the drive.

The problem is, I suspect, that udev is waiting for a device interrupt before doing anything, and -- from the apparent problem -- no interrupt seems to be processed for "change of sleeve state." The more I think about it, the more I'm inclined to the belief that the problem is in the device driver being used.

Todd, what device driver are you using, and is it specific for a "hot swap enabled" SATA drive, or just the "generic" SATA driver that's shipped with CentOS? If it's the later, perhaps you could check Intel to see if they provide a Linux driver for your hardware.

It is whatever CentOS 5.2 sends out.

No difference with the drive powered up or down. Rats!

No difference power on or off. Rats!

Have you looked at the rescan SCSI utility.
http://www.garloff.de/kurt/linux/

With the drive powered off, the scan goes to the point where it states "NEW" and my system instantly freezes. No two second wait this time. Rats!

Thank you for the suggestion.

-T

This is probably not what you want to hear, but . . .

I went to the Intel site to see if they had a Linux driver for the SATA RAID controller in the 5000V chipset (which they,of course,don't -- apparently Intel hasn't heard much about Linux). I ended up in their Matrix Storage Manager Release Notes section. When I looked at the list of "Known Issues" with the Windows driver, I noticed issue #2662524:which suggests that even the "supported" OS may have a "hot swap" problem with the SATA controller on your board.

Hi All,

I have been doing a bunch of research and have been
corresponding with the folks over at kernel.org as
well as here. This is what I have found:

1) my motherboard's bios is corked. Supermicro has
since added all kinds of ACHI support to the BIOS.
(I will be ordering new BIOS chips "Today".)

2) You only "automatically" load the ACHI drivers
at installation time. No auto detect after the fact.
(But, you can do it manually.)

3) From my /etc/modprobe.conf

alias scsi_hostadapter sata_sil
alias scsi_hostadapter1 megaraid_mbox
alias scsi_hostadapter2 ata_piix

The "ata_piix" driver is the WRONG driver for
"ACHI Hot Pluggable" devices. The driver I
need, but did not get, due to my crappy BIOS,
at install time, should be

alias scsi_hostadapter2 ahci

Which won't work properly until I get my new
BIOS chips. When working correctly, I should
be able to comment out the "ata_piix" driver
completely. (And, the ACHI driver should work
fine with my SATA DVD/CD writer.)

Thanks to all who helped me finally figure all
this out!

-T

Just curious: Several times you mentioned new BIOS chips. That implies that the Supermicro BIOS is not on a EPROM chip, and you're going to have to physically replace the BIOS chips. While I haven't seen everything, I was not aware that any motherboard manufacturer (except for "high security" or "hostile environment" applications) was putting their BIOS on ROM chips, and, for those that did use ROM chips, that the chips were not soldered into the board.

The implication of your getting new ROM chips is that your board has socketted ROM BIOS chips.

All Supermicro motherboards have socketed EEPROM chips. For around $30.00 or so, Supermicro will burn you a new one. You can flash them yourself, if you want, but I would only do it on a motherboard you don't mind being a worthless piece of junk for a week while you wait for Supermicro to ship you a new chip.

I have had the experience already. Flashing your BIOS chip yourself is quick and easy, but the self flashes do occasionally go terribly wrong. I have had my own server down for a week because of this . So $30 vs a week of outage on a server. Hmmmm. I will pay the $30. If things go wrong, I can always pop the old chip back in.

Chalk this one up to "you live and you learn". Don't repeat my mistakes.

-T

Hi All,

Hallelujah!

An update. I got my first server's BIOS chip changed. Updating initrd was way simpler than I had feared. (I am lucky in that my boot device is a RAID controller, which does not require ahci or ata_piix to operate: I can still boot if I goof ahci or ata_piix.) Both my CD/DVD burner and my removable SATA drive work perfectly. The new BIOS still has some problems, such as you having to have the removable SATA drive as the last item in the boot order, or you can not boot with the removable drive powered off. Weird.

Anyway, the removable drive acts perfectly as a Hot Plugging device, just like its USB and Firewire Hot Plugging cousins. If you put a tail on "messages"
su -c "tail -f /var/log/messages"
you can see /dev/sdb go in and get removed as you power on and (unmount and ) power off the device. Very, very cool. And best yet, you just get an error message if you try to mount the thing when it is removed.

Many thanks to everyone for all their tips and suggestions!

-T