Bug 56036 - Wrong init of scsi disks when starting pcmcia services
Wrong init of scsi disks when starting pcmcia services
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel-pcmcia-cs (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-11 10:13 EST by Alfredo Ferrari
Modified: 2015-01-04 17:01 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-25 03:15:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alfredo Ferrari 2001-11-11 10:13:15 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-13.1 i686)

Description of problem:
When the pcmcia services start, they properly recognize an external scsi
disk attached thru an apa1480a (aix7xxx_mod) but they do not apparently
read the partition table (or similar). As a result, mounting a partition
using the label never works until whichever operation is performed on the
scsi bus.

Ie:
boot the machine and get:
  Vendor: SEAGATE   Model: ST318416N         Rev: 0010
  Type:   Direct-Access                      ANSI SCSI revision: 03
blk: queue cfaf4418, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: FUJITSU   Model: M2513A            Rev: 2000
  Type:   Optical Device                     ANSI SCSI revision: 02
blk: queue cfaf4c18, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: YAMAHA    Model: CRW4416S          Rev: 1.0j
  Type:   CD-ROM                             ANSI SCSI revision: 02
blk: queue c1ba9018, I/O limit 4095Mb (mask 0xffffffff)
scsi1:0:2:0: Tagged Queuing enabled.  Depth 253

try to mount the second partition of the harddrive (label /disk2)
defined in fstab as:
LABEL=/disk2    /disk2  ext2    user,noauto,dev,exec,suid 0 0


[root@pceet215 log]# mount /disk2
mount: no such partition found

make a "fake" operation on the scsi bus, ie
 hdparm -tT /dev/sda
or
  fdisk /dev/sda
or whatever else, then you see on the logs:

Nov 11 16:03:06 pceet215 kernel: Attached scsi disk sda at scsi1, channel
0, id 2, lun 0
Nov 11 16:03:06 pceet215 kernel: Attached scsi removable disk sdb at scsi1,
channel 0, id 5, lun 0
Nov 11 16:03:06 pceet215 kernel: (scsi1:A:2): 20.000MB/s transfers
(20.000MHz, offset 15)
Nov 11 16:03:06 pceet215 kernel: SCSI device sda: 35885168 512-byte hdwr
sectors (18373 MB)
Nov 11 16:03:06 pceet215 kernel:  sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
Nov 11 16:03:06 pceet215 kernel: (scsi1:A:5): 10.000MB/s transfers
(10.000MHz, offset 10)
Nov 11 16:03:06 pceet215 kernel: SCSI device sdb: 310352 2048-byte hdwr
sectors (636 MB)
Nov 11 16:03:06 pceet215 kernel: sdb: Write Protect is off
Nov 11 16:03:11 pceet215 kernel:  sdb: unknown partition table

and from now on everything works fine, ie:

[root@pceet215 log]# mount /disk2
[root@pceet215 log]# df /disk2
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda2              4901956   3860424    792528  83% /disk2

It seems part of the initialization is delayed and does not occur until an
operation is issued. this is also causing problems with the cdrom and the
MO unit. The problem is there in RH7.1 as well, exactly the same


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.boot with a scsi HD attached to a scsi pcmcia controller with a partition
with a label
2.try to mount that partition thru the label and not the device
3.make whichever operation on the scsi bus and try again
	

Actual Results:  The partition is not found until some other operation
successfully completes on the scsi bus (not necessarily on the same disk)

Expected Results:  the partition should mount fine

Additional info:

Dell latitude C800 with an Adaptec APA1480a with a scsi HD, a MO hd and a
CDR/W (see above), running RH7.2 with all updates. Same problem with the
same hardware under RH7.1
Comment 1 Need Real Name 2002-10-31 16:36:36 EST
The "fake" operation is causing the SCSI disk driver module (sd) to be loaded.  
I'm not sure if this is really a bug; it is a "feature" of the Linux SCSI 
architecture that the driver that knows about SCSI disk drives doesn't get 
loaded until you ask for it, rather than being loaded when a SCSI disk drive is 
detected.  You could add a line to /etc/modules.conf to say that the sd module 
should always be loaded after aic7xxx.

-- Dave Hinds


Note You need to log in before you can comment on or make changes to this bug.