3rd EIDE drive: "/dev/hdc: No such device"

3rd EIDE drive: "/dev/hdc: No such device"

Post by David Rober » Tue, 28 Mar 1995 21:30:29

*Some* E-IDE controllers (particularly ones with the SIS chips) do not activate
the secondary channel upon boot-up.  Rather, even though the jumpers are set to
enable the secondary channel, some software device drivers are required to
initialize and enable that channel.  I have a similiar situation with my
controller...I have to boot DOS (to enable the channel properly) and then do
the three finger salute to now boot Linux in order to get my HD's on the secondary
channel to work.


David Roberts          Dept. N09 - Bldg. 863-2    Phone:    (802) 769-5731
Associate Engineer     1000 River Road            Internet: zuk...@vnet.ibm.com
IBM Microelectronics   Essex Junction, VT 05452
In article <tgmD5yrxF....@netcom.com> t...@netcom.com (Thomas G. McWilliams) writes:

   Newsgroups: comp.os.linux.hardware
   From: t...@netcom.com (Thomas G. McWilliams)
   Organization: Jot-Em Down Store and Library
   Date: Fri, 24 Mar 1995 21:34:27 GMT

   Mark Juric (mju...@hawk.depaul.edu) wrote:
   : I get no nothing during bootup - no probe, no anything.  I just get no such
   : device when trying to access it.  I'm using the 1.2.0 kernel.
   :   Any thoughts anyone?
   : --
   : Mark Juric                                              DePaul University
   : Systems and Operations                                  mju...@hawk.depaul.edu

   Here's a start (from linux/drivers/block/README.ide):

   README.ide -- Information regarding ide.c and ide-cd.c (IDE driver in 1.2.x)
   Supported by:  ml...@bnr.ca           -- disks, interfaces, probing
                  sny...@fnald0.fnal.gov -- cdroms, ATAPI, audio

   (see description later on below for handling BIG IDE drives with >1024 cyls).

   Major features of ide.c & ide-cd.c:

      - support for up to two IDE interfaces on one or two IRQs
      - support for any mix of up to four disk and/or cdrom drives
      - support for reading IDE ATAPI cdrom drives (NEC,MITSUMI,VERTOS,SONY)
      - support for audio functions
      - auto-detection of interfaces, drives, IRQs, and disk geometries
        -- "single" drives should be jumpered as "master", not "slave"
      - support for BIOSs which report "more than 16 heads" on disk drives
      - uses LBA (slightly faster) on disk drives which support it
      - support for lots of fancy (E)IDE drive functions with hdparm utility
      - optional (compile time) support for 32-bit VLB data transfers
      - support for IDE multiple (block) mode (same as hd.c)
      - support for interrupt unmasking during I/O (better than hd.c)
      - improved handshaking and error detection/recovery
      - can co-exist with hd.c to control only the secondary interface

   Under construction:

      - support for interface speed selection on jumperless interfaces
      - improved detection of non-standard IDE ATAPI cdrom drives
      - support for non-standard 3rd/4th drive interface on Promise cards

   To access devices on the second interface, device entries must first be
   created in /dev for them.  To create such entries, simply run the included
   shell script:   MAKEDEV.ide1

   ide.c automatically probes for the primary and secondary interfaces,
   for the drives/geometries attached to those interfaces, and for the
   IRQ numbers being used by the interfaces (normally IRQ14 & IRQ15).

   The primary and secondary interfaces may share a single IRQ if necessary,
   at a slight performance penalty, whether on separate cards or a single VLB card.

   Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
   For really weird situations, the apparent (fdisk) geometry can also be specified
   on the kernel "command line" using LILO.  The format of such lines is:

   or   hdx=cdrom

   where hdx can be any of {hda,hdb,hdc,hdd}, or simply hd, for the "next" drive
   in sequence.  Only the first three parameters are required (cyls,heads,sects),
   and wpcom is ignored for IDE drives.  For example:

      hdc=1050,32,64 hdd=cdrom

   If an irq number is given, it will apply to both drives on the same interface,
   either {hda,hdb} or {hdc,hdd}.  The results of successful auto-probing may
   override the physical geometry/irq specified, though the "original" geometry
   is retained as the "logical" geometry for partitioning purposes (fdisk).

   If the auto-probing during boot time confuses a drive (ie. the drive works
   with hd.c but not with ide.c), then an command line option may be specified
   for each drive for which you'd like the drive to skip the hardware
   probe/identification sequence.  For example:


   Note that when only one IDE device is attached to an interface,
   it must be jumpered as "single" or "master", *not* "slave".
   Many folks have had "trouble" with cdroms because of this requirement
   of the ATA (IDE) standard.

   Courtesy of Scott Snyder, the driver now supports ATAPI cdrom drives
   such as the NEC-260 and the new MITSUMI triple/quad speed drives.
   Such drives will be identified at boot time, as hda,hdb,hdc or hdd,
   just like a harddisk.

   If for some reason your cdrom drive is *not* found at boot time, you can force
   the probe to look harder by supplying a kernel command line parameter
   via LILO, such as:  hdc=cdrom

   For example, a GW2000 system might have a harddrive on the primary
   interface (/dev/hda) and an IDE cdrom drive on the secondary interface
   (/dev/hdc).  To mount a CD in the cdrom drive, one would use something like:

      ln -sf /dev/hdc /dev/cdrom
      mkdir /cd
      mount /dev/cdrom /cd -t iso9660 -o ro

   Please pass on any feedback on the cdrom stuff to the author & maintainer,
   Scott Snyder (sny...@fnald0.fnal.gov).

   The kernel is now be able to execute binaries directly off of the cdrom,
   provided it is mounted with the default block size of 1024.

   The hdparm.c program for controlling various IDE features is now packaged
   separately.  Look for it on popular linux FTP sites.


   Some Terminology
   IDE = Integrated Drive Electronics, meaning that each drive has a built-in
   controller, which is why an "IDE interface card" is not a "controller card".

   IDE drives are designed to attach almost directly to the ISA bus of an AT-style
   computer.  The typical IDE interface card merely provides I/O port address
   decoding and tri-state buffers, although several newer localbus cards go much
   beyond the basics.  When purchasing a localbus IDE interface, avoid cards with
   an onboard BIOS and those which require special drivers.  Instead, look for a
   card which uses hardware switches/jumpers to select the interface timing speed,
   to allow much faster data transfers than the original 8Mhz ISA bus allows.

   ATA = AT (the old IBM 286 computer) Attachment Interface, a draft American
   National Standard for connecting hard drives to PCs.  This is the official
   name for "IDE".

   The latest standards define some enhancements, known as the ATA-2 spec,
   which grew out of vendor-specific "Enhanced IDE" (EIDE) implementations.

   ATAPI = ATA Packet Interface, a new protocol for controlling the drives,
   similar to SCSI protocols, created at the same time as the ATA2 standard.
   ATAPI is currently used for controlling CDROM and TAPE devices, and will
   likely also soon be used for Floppy drives, removable R/W cartridges,
   and for high capacity hard disk drives.

   How To Use *Big* ATA/IDE drives with Linux
   The ATA Interface spec for IDE disk drives allows a total of 28 bits
   (8 bits for sector, 16 bits for cylinder, and 4 bits for head) for addressing
   individual disk sectors of 512 bytes each (in "Linear Block Address" (LBA)
   mode, there is still only a total of 28 bits available in the hardware).
   This "limits" the capacity of an IDE drive to no more than 128GB (Giga-bytes).
   All current day IDE drives are somewhat smaller than this upper limit, and
   within a few years, ATAPI disk drives will raise the limit considerably.

   All IDE disk drives "suffer" from a "16-heads" limitation:  the hardware has
   only a four bit field for head selection, restricting the number of "physical"
   heads to 16 or less.  Since the BIOS usually has a 63 sectors/track limit,
   this means that all IDE drivers larger than 504MB (528Meg) must use a "physical"
   geometry with more than 1024 cylinders.

      (1024cyls * 16heads * 63sects * 512bytes/sector) / (1024 * 1024) == 504MB

   (Some BIOSs (and controllers with onboard BIOS) pretend to allow "32" or "64"
    heads per drive (discussed below), but can only do so by playing games with
    the real (hidden) geometry, which is always limited to 16 or fewer heads).

   This presents two problems to most systems:

      1. The INT13 interface to the BIOS only allows 10-bits for cylinder
      addresses, giving a limit of 1024cyls for programs which use it.

      2. The physical geometry fields of the disk partition table only
      allow 10-bits for cylinder addresses, giving a similar limit of 1024
      cyls for operating systems that do not use the "sector count" fields
      instead of the physical Cyl/Head/Sect (CHS) geometry fields.

   Neither of these limitations affects Linux itself, as it (1) does not use the
   BIOS for disk access, and it (2) is clever enough to use the "sector count"
   fields of the partition table instead of the physical CHS geometry fields.

      a) Most folks use LILO to load linux.  LILO uses the INT13 interface
      to the BIOS to load the kernel

read more »


3rd EIDE drive: "/dev/hdc: No such device"

Post by Peter Herweij » Thu, 30 Mar 1995 04:00:00

 >  [...] I have to boot DOS (to enable the channel properly) and then do
 >the three finger salute to now boot Linux in order to get my HD's on the
 >secondary channel to work.

Supposed you use DOS6, why don't you just use a config.sys boot menu?
That way, you can load the driver to initialise the interface and loadlin
to boot Linux, like this:

   loadlin c:\linux\zimage.122 ro <other_options>

No messing with Lilo anymore. Only one boot menu. Works fine for me.

 - Peter Herweijer


1. how to kill "mt" or make "/dev/rmt/..." device NOT BUSY?

Hi everybody,

I'm using an Exabyte 8mm tape drive through "/dev/rmt/0lbn" unser Solaris 2.4.

If something goes wrong with the tape during execution of "mt ..." command,
this command hangs in a state in which it can't be interrupted or killed.
The device remains busy even if I can manually eject the tape. The only
way to get the access to the tape is to reboot the system.

Is it possible to kill "mt" somehow or make the tape device NOT BUSY some
other way? Are there any timeouts defined for the "mt"/device (if so,
can they be made shorter) ?

any help will be appreciated,

regards, Michal.


  Al. Ujazdowskie 4                   Voice:    48-22-294011 ext 23
  00-478 Warszawa, POLAND             FAX:      48-22-294967

2. X-Server for MSDos

3. GETSERVBYNAME()????????????????????"""""""""""""

4. TCP/IP tuning

5. Second drive (/dev/fd1) won't "DO IT" and "DO IT"

6. Apache and DSO via dlload etc.

7. Second drive (dev/fd1) won't "DO IT" and "DO IT"

8. LOCAL: Boulder area Linux Users Group

9. syslogd: "/" in "/dev//dev/tty"

10. Why "fdisk /dev/hdb1" works but not "fdisk /dev/hdb"!?

11. """"""""My SoundBlast 16 pnp isn't up yet""""""""""""

12. PATCH: eisa reports "0 device" not "0 devices"

13. Always "Unable to open /dev/hdc" (Help.......)