/
ibmmca.txt
1402 lines (1281 loc) · 75.8 KB
/
ibmmca.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
-=< The IBM Microchannel SCSI-Subsystem >=-
for the IBM PS/2 series
Low Level Software-Driver for Linux
Copyright (c) 1995 Strom Systems, Inc. under the terms of the GNU
General Public License. Originally written by Martin Kolinek, December 1995.
Officially modified and maintained by Michael Lang since January 1999.
Version 4.0a
Last update: January 3, 2001
Before you Start
----------------
This is the common README.ibmmca file for all driver releases of the
IBM MCA SCSI driver for Linux. Please note, that driver releases 4.0
or newer do not work with kernel versions older than 2.4.0, while driver
versions older than 4.0 do not work with kernels 2.4.0 or later! If you
try to compile your kernel with the wrong driver source, the
compilation is aborted and you get a corresponding error message. This is
no bug in the driver; it prevents you from using the wrong source code
with the wrong kernel version.
Authors of this Driver
----------------------
- Chris Beauregard (improvement of the SCSI-device mapping by the driver)
- Martin Kolinek (origin, first release of this driver)
- Klaus Kudielka (multiple SCSI-host management/detection, adaption to
Linux Kernel 2.1.x, module support)
- Michael Lang (assigning original pun/lun mapping, dynamical ldn
assignment, rewritten adapter detection, this file,
patches, official driver maintenance and subsequent
debugging, related with the driver)
Table of Contents
-----------------
1 Abstract
2 Driver Description
2.1 IBM SCSI-Subsystem Detection
2.2 Physical Units, Logical Units, and Logical Devices
2.3 SCSI-Device Recognition and dynamical ldn Assignment
2.4 SCSI-Device Order
2.5 Regular SCSI-Command-Processing
2.6 Abort & Reset Commands
2.7 Disk Geometry
2.8 Kernel Boot Option
2.9 Driver Module Support
2.10 Multiple Hostadapter Support
2.11 /proc/scsi-Filesystem Information
2.12 /proc/mca-Filesystem Information
2.13 Supported IBM SCSI-Subsystems
2.14 Linux Kernel Versions
3 Code History
4 To do
5 Users' Manual
5.1 Commandline Parameters
5.2 Troubleshooting
5.3 Bug reports
5.4 Support WWW-page
6 References
7 Credits to
7.1 People
7.2 Sponsors & Supporters
8 Trademarks
9 Disclaimer
* * *
1 Abstract
----------
This README-file describes the IBM SCSI-subsystem low level driver for
Linux. The descriptions which were formerly kept in the source code have
been taken out of this file to simplify the codes readability. The driver
description has been updated, as most of the former description was already
quite outdated. The history of the driver development is also kept inside
here. Multiple historical developments have been summarized to shorten the
text size a bit. At the end of this file you can find a small manual for
this driver and hints to get it running on your machine.
2 Driver Description
--------------------
2.1 IBM SCSI-Subsystem Detection
--------------------------------
This is done in the ibmmca_detect() function. It first checks, if the
Microchannel-bus support is enabled, as the IBM SCSI-subsystem needs the
Microchannel. In a next step, a free interrupt is chosen and the main
interrupt handler is connected to it to handle answers of the SCSI-
subsystem(s). If the F/W SCSI-adapter is forced by the BIOS to use IRQ11
instead of IRQ14, IRQ11 is used for the IBM SCSI-2 F/W adapter. In a
further step it is checked, if the adapter gets detected by force from
the kernel commandline, where the I/O port and the SCSI-subsystem id can
be specified. The next step checks if there is an integrated SCSI-subsystem
installed. This register area is fixed through all IBM PS/2 MCA-machines
and appears as something like a virtual slot 10 of the MCA-bus. On most
PS/2 machines, the POS registers of slot 10 are set to 0xff or 0x00 if not
integrated SCSI-controller is available. But on certain PS/2s, like model
9595, this slot 10 is used to store other information which at earlier
stage confused the driver and resulted in the detection of some ghost-SCSI.
If POS-register 2 and 3 are not 0x00 and not 0xff, but all other POS
registers are either 0xff or 0x00, there must be an integrated SCSI-
subsystem present and it will be registered as IBM Integrated SCSI-
Subsystem. The next step checks, if there is a slot-adapter installed on
the MCA-bus. To get this, the first two POS-registers, that represent the
adapter ID are checked. If they fit to one of the ids, stored in the
adapter list, a SCSI-subsystem is assumed to be found in a slot and will be
registered. This check is done through all possible MCA-bus slots to allow
more than one SCSI-adapter to be present in the PS/2-system and this is
already the first point of problems. Looking into the technical reference
manual for the IBM PS/2 common interfaces, the POS2 register must have
different interpretation of its single bits to avoid overlapping I/O
regions. While one can assume, that the integrated subsystem has a fix
I/O-address at 0x3540 - 0x3547, further installed IBM SCSI-adapters must
use a different I/O-address. This is expressed by bit 1 to 3 of POS2
(multiplied by 8 + 0x3540). Bits 2 and 3 are reserved for the integrated
subsystem, but not for the adapters! The following list shows, how the
bits of POS2 and POS3 should be interpreted.
The POS2-register of all PS/2 models' integrated SCSI-subsystems has the
following interpretation of bits:
Bit 7 - 4 : Chip Revision ID (Release)
Bit 3 - 2 : Reserved
Bit 1 : 8k NVRAM Disabled
Bit 0 : Chip Enable (EN-Signal)
The POS3-register is interpreted as follows (for most IBM SCSI-subsys.):
Bit 7 - 5 : SCSI ID
Bit 4 - 0 : Reserved = 0
The slot-adapters have different interpretation of these bits. The IBM SCSI
adapter (w/Cache) and the IBM SCSI-2 F/W adapter use the following
interpretation of the POS2 register:
Bit 7 - 4 : ROM Segment Address Select
Bit 3 - 1 : Adapter I/O Address Select (*8+0x3540)
Bit 0 : Adapter Enable (EN-Signal)
and for the POS3 register:
Bit 7 - 5 : SCSI ID
Bit 4 : Fairness Enable (SCSI ID3 f. F/W)
Bit 3 - 0 : Arbitration Level
The most modern product of the series is the IBM SCSI-2 F/W adapter, it
allows dual-bus SCSI and SCSI-wide addressing, which means, PUNs may be
between 0 and 15. Here, Bit 4 is the high-order bit of the 4-bit wide
adapter PUN expression. In short words, this means, that IBM PS/2 machines
can only support 1 single integrated subsystem by default. Additional
slot-adapters get ports assigned by the automatic configuration tool.
One day I found a patch in ibmmca_detect(), forcing the I/O-address to be
0x3540 for integrated SCSI-subsystems, there was a remark placed, that on
integrated IBM SCSI-subsystems of model 56, the POS2 register was showing 5.
This means, that really for these models, POS2 has to be interpreted
sticking to the technical reference guide. In this case, the bit 2 (4) is
a reserved bit and may not be interpreted. These differences between the
adapters and the integrated controllers are taken into account by the
detection routine of the driver on from version >3.0g.
Every time, a SCSI-subsystem is discovered, the ibmmca_register() function
is called. This function checks first, if the requested area for the I/O-
address of this SCSI-subsystem is still available and assigns this I/O-
area to the SCSI-subsystem. There are always 8 sequential I/O-addresses
taken for each individual SCSI-subsystem found, which are:
Offset Type Permissions
0 Command Interface Register 1 Read/Write
1 Command Interface Register 2 Read/Write
2 Command Interface Register 3 Read/Write
3 Command Interface Register 4 Read/Write
4 Attention Register Read/Write
5 Basic Control Register Read/Write
6 Interrupt Status Register Read
7 Basic Status Register Read
After the I/O-address range is assigned, the host-adapter is assigned
to a local structure which keeps all adapter information needed for the
driver itself and the mid- and higher-level SCSI-drivers. The SCSI pun/lun
and the adapters' ldn tables are initialized and get probed afterwards by
the check_devices() function. If no further adapters are found,
ibmmca_detect() quits.
2.2 Physical Units, Logical Units, and Logical Devices
------------------------------------------------------
There can be up to 56 devices on the SCSI bus (besides the adapter):
there are up to 7 "physical units" (each identified by physical unit
number or pun, also called the scsi id, this is the number you select
with hardware jumpers), and each physical unit can have up to 8
"logical units" (each identified by logical unit number, or lun,
between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two
busses and provides support for 30 logical devices at the same time, where
in wide-addressing mode you can have 16 puns with 32 luns on each device.
This section describes the handling of devices on non-F/W adapters.
Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter
which means a lot of possible devices for such a small machine.
Typically the adapter has pun=7, so puns of other physical units
are between 0 and 6(15). On a wide-adapter a pun higher than 7 is
possible, but is normally not used. Almost all physical units have only
one logical unit, with lun=0. A CD-ROM jukebox would be an example of a
physical unit with more than one logical unit.
The embedded microprocessor of the IBM SCSI-subsystem hides the complex
two-dimensional (pun,lun) organization from the operating system.
When the machine is powered-up (or rebooted), the embedded microprocessor
checks, on its own, all 56 possible (pun,lun) combinations, and the first
15 devices found are assigned into a one-dimensional array of so-called
"logical devices", identified by "logical device numbers" or ldn. The last
ldn=15 is reserved for the subsystem itself. Wide adapters may have
to check up to 15 * 8 = 120 pun/lun combinations.
2.3 SCSI-Device Recognition and Dynamical ldn Assignment
--------------------------------------------------------
One consequence of information hiding is that the real (pun,lun)
numbers are also hidden. The two possibilities to get around this problem
are to offer fake pun/lun combinations to the operating system or to
delete the whole mapping of the adapter and to reassign the ldns, using
the immediate assign command of the SCSI-subsystem for probing through
all possible pun/lun combinations. An ldn is a "logical device number"
which is used by IBM SCSI-subsystems to access some valid SCSI-device.
At the beginning of the development of this driver, the following approach
was used:
First, the driver checked the ldn's (0 to 6) to find out which ldn's
have devices assigned. This was done by the functions check_devices() and
device_exists(). The interrupt handler has a special paragraph of code
(see local_checking_phase_flag) to assist in the checking. Assume, for
example, that three logical devices were found assigned at ldn 0, 1, 2.
These are presented to the upper layer of Linux SCSI driver
as devices with bogus (pun, lun) equal to (0,0), (1,0), (2,0).
On the other hand, if the upper layer issues a command to device
say (4,0), this driver returns DID_NO_CONNECT error.
In a second step of the driver development, the following improvement has
been applied: The first approach limited the number of devices to 7, far
fewer than the 15 that it could use, then it just mapped ldn ->
(ldn/8,ldn%8) for pun,lun. We ended up with a real mishmash of puns
and luns, but it all seemed to work.
The latest development, which is implemented from the driver version 3.0
and later, realizes the device recognition in the following way:
The physical SCSI-devices on the SCSI-bus are probed via immediate_assign-
and device_inquiry-commands, that is all implemented in a completely new
made check_devices() subroutine. This delivers an exact map of the physical
SCSI-world that is now stored in the get_scsi[][]-array. This means,
that the once hidden pun,lun assignment is now known to this driver.
It no longer believes in default-settings of the subsystem and maps all
ldns to existing pun,lun "by foot". This assures full control of the ldn
mapping and allows dynamical remapping of ldns to different pun,lun, if
there are more SCSI-devices installed than ldns available (n>15). The
ldns from 0 to 6 get 'hardwired' by this driver to puns 0 to 7 at lun=0,
excluding the pun of the subsystem. This assures, that at least simple
SCSI-installations have optimum access-speed and are not touched by
dynamical remapping. The ldns 7 to 14 are put to existing devices with
lun>0 or to non-existing devices, in order to satisfy the subsystem, if
there are less than 15 SCSI-devices connected. In the case of more than 15
devices, the dynamical mapping goes active. If the get_scsi[][] reports a
device to be existent, but it has no ldn assigned, it gets an ldn out of 7
to 14. The numbers are assigned in cyclic order, therefore it takes 8
dynamical reassignments on the SCSI-devices until a certain device
loses its ldn again. This assures that dynamical remapping is avoided
during intense I/O between up to 15 SCSI-devices (means pun,lun
combinations). A further advantage of this method is that people who
build their kernel without probing on all luns will get what they expect,
because the driver just won't assign everything with lun>0 when
multiple lun probing is inactive.
2.4 SCSI-Device Order
---------------------
Because of the now correct recognition of physical pun,lun, and
their report to mid-level- and higher-level-drivers, the new reported puns
can be different from the old, faked puns. Therefore, Linux will eventually
change /dev/sdXXX assignments and prompt you for corrupted superblock
repair on boottime. In this case DO NOT PANIC, YOUR DISKS ARE STILL OK!!!
You have to reboot (CTRL-D) with an old kernel and set the /etc/fstab-file
entries right. After that, the system should come up as errorfree as before.
If your boot-partition is not coming up, also edit the /etc/lilo.conf-file
in a Linux session booted on old kernel and run lilo before reboot. Check
lilo.conf anyway to get boot on other partitions with foreign OSes right
again. But there exists a feature of this driver that allows you to change
the assignment order of the SCSI-devices by flipping the PUN-assignment.
See the next paragraph for a description.
The problem for this is, that Linux does not assign the SCSI-devices in the
way as described in the ANSI-SCSI-standard. Linux assigns /dev/sda to
the device with at minimum id 0. But the first drive should be at id 6,
because for historical reasons, drive at id 6 has, by hardware, the highest
priority and a drive at id 0 the lowest. IBM was one of the rare producers,
where the BIOS assigns drives belonging to the ANSI-SCSI-standard. Most
other producers' BIOS does not (I think even Adaptec-BIOS). The
IBMMCA_SCSI_ORDER_STANDARD flag, which you set while configuring the
kernel enables to choose the preferred way of SCSI-device-assignment.
Defining this flag would result in Linux determining the devices in the
same order as DOS and OS/2 does on your MCA-machine. This is also standard
on most industrial computers and OSes, like e.g. OS-9. Leaving this flag
undefined will get your devices ordered in the default way of Linux. See
also the remarks of Chris Beauregard from Dec 15, 1997 and the followups
in section 3.
2.5 Regular SCSI-Command-Processing
-----------------------------------
Only three functions get involved: ibmmca_queuecommand(), issue_cmd(),
and interrupt_handler().
The upper layer issues a scsi command by calling function
ibmmca_queuecommand(). This function fills a "subsystem control block"
(scb) and calls a local function issue_cmd(), which writes a scb
command into subsystem I/O ports. Once the scb command is carried out,
the interrupt_handler() is invoked. If a device is determined to be
existant and it has not assigned any ldn, it gets one dynamically.
For this, the whole stuff is done in ibmmca_queuecommand().
2.6 Abort & Reset Commands
--------------------------
These are implemented with busy waiting for interrupt to arrive.
ibmmca_reset() and ibmmca_abort() do not work sufficiently well
up to now and need still a lot of development work. This seems
to be a problem with other low-level SCSI drivers too, however
this should be no excuse.
2.7 Disk Geometry
-----------------
The ibmmca_biosparams() function should return the same disk geometry
as the bios. This is needed for fdisk, etc. The returned geometry is
certainly correct for disks smaller than 1 gigabyte. In the meantime,
it has been proved, that this works fine even with disks larger than
1 gigabyte.
2.8 Kernel Boot Option
----------------------
The function ibmmca_scsi_setup() is called if option ibmmcascsi=n
is passed to the kernel. See file linux/init/main.c for details.
2.9 Driver Module Support
-------------------------
Is implemented and tested by K. Kudielka. This could probably not work
on kernels <2.1.0.
2.10 Multiple Hostadapter Support
---------------------------------
This driver supports up to eight interfaces of type IBM-SCSI-Subsystem.
Integrated-, and MCA-adapters are automatically recognized. Unrecognizable
IBM-SCSI-Subsystem interfaces can be specified as kernel-parameters.
2.11 /proc/scsi-Filesystem Information
--------------------------------------
Information about the driver condition is given in
/proc/scsi/ibmmca/<host_no>. ibmmca_proc_info() provides this information.
This table is quite informative for interested users. It shows the load
of commands on the subsystem and whether you are running the bypassed
(software) or integrated (hardware) SCSI-command set (see below). The
amount of accesses is shown. Read, write, modeselect is shown separately
in order to help debugging problems with CD-ROMs or tapedrives.
The following table shows the list of 15 logical device numbers, that are
used by the SCSI-subsystem. The load on each ldn is shown in the table,
again, read and write commands are split. The last column shows the amount
of reassignments, that have been applied to the ldns, if you have more than
15 pun/lun combinations available on the SCSI-bus.
The last two tables show the pun/lun map and the positions of the ldns
on this pun/lun map. This may change during operation, when a ldn is
reassigned to another pun/lun combination. If the necessity for dynamical
assignments is set to 'no', the ldn structure keeps static.
2.12 /proc/mca-Filesystem Information
-------------------------------------
The slot-file contains all default entries and in addition chip and I/O-
address information of the SCSI-subsystem. This information is provided
by ibmmca_getinfo().
2.13 Supported IBM SCSI-Subsystems
----------------------------------
The following IBM SCSI-subsystems are supported by this driver:
- IBM Fast/Wide SCSI-2 Adapter
- IBM 7568 Industrial Computer SCSI Adapter w/Cache
- IBM Expansion Unit SCSI Controller
- IBM SCSI Adapter w/Cache
- IBM SCSI Adapter
- IBM Integrated SCSI Controller
- All clones, 100% compatible with the chipset and subsystem command
system of IBM SCSI-adapters (forced detection)
2.14 Linux Kernel Versions
--------------------------
The IBM SCSI-subsystem low level driver is prepared to be used with
all versions of Linux between 2.0.x and 2.4.x. The compatibility checks
are fully implemented up from version 3.1e of the driver. This means, that
you just need the latest ibmmca.h and ibmmca.c file and copy it in the
linux/drivers/scsi directory. The code is automatically adapted during
kernel compilation. This is different from kernel 2.4.0! Here version
4.0 or later of the driver must be used for kernel 2.4.0 or later. Version
4.0 or later does not work together with older kernels! Driver versions
older than 4.0 do not work together with kernel 2.4.0 or later. They work
on all older kernels.
3 Code History
--------------
Jan 15 1996: First public release.
- Martin Kolinek
Jan 23 1996: Scrapped code which reassigned scsi devices to logical
device numbers. Instead, the existing assignment (created
when the machine is powered-up or rebooted) is used.
A side effect is that the upper layer of Linux SCSI
device driver gets bogus scsi ids (this is benign),
and also the hard disks are ordered under Linux the
same way as they are under dos (i.e., C: disk is sda,
D: disk is sdb, etc.).
- Martin Kolinek
I think that the CD-ROM is now detected only if a CD is
inside CD_ROM while Linux boots. This can be fixed later,
once the driver works on all types of PS/2's.
- Martin Kolinek
Feb 7 1996: Modified biosparam function. Fixed the CD-ROM detection.
For now, devices other than harddisk and CD_ROM are
ignored. Temporarily modified abort() function
to behave like reset().
- Martin Kolinek
Mar 31 1996: The integrated scsi subsystem is correctly found
in PS/2 models 56,57, but not in model 76. Therefore
the ibmmca_scsi_setup() function has been added today.
This function allows the user to force detection of
scsi subsystem. The kernel option has format
ibmmcascsi=n
where n is the scsi_id (pun) of the subsystem. Most likely, n is 7.
- Martin Kolinek
Aug 21 1996: Modified the code which maps ldns to (pun,0). It was
insufficient for those of us with CD-ROM changers.
- Chris Beauregard
Dec 14 1996: More improvements to the ldn mapping. See check_devices
for details. Did more fiddling with the integrated SCSI detection,
but I think it's ultimately hopeless without actually testing the
model of the machine. The 56, 57, 76 and 95 (ultimedia) all have
different integrated SCSI register configurations. However, the 56
and 57 are the only ones that have problems with forced detection.
- Chris Beauregard
Mar 8-16 1997: Modified driver to run as a module and to support
multiple adapters. A structure, called ibmmca_hostdata, is now
present, containing all the variables, that were once only
available for one single adapter. The find_subsystem-routine has vanished.
The hardware recognition is now done in ibmmca_detect directly.
This routine checks for presence of MCA-bus, checks the interrupt
level and continues with checking the installed hardware.
Certain PS/2-models do not recognize a SCSI-subsystem automatically.
Hence, the setup defined by command-line-parameters is checked first.
Thereafter, the routine probes for an integrated SCSI-subsystem.
Finally, adapters are checked. This method has the advantage to cover all
possible combinations of multiple SCSI-subsystems on one MCA-board. Up to
eight SCSI-subsystems can be recognized and announced to the upper-level
drivers with this improvement. A set of defines made changes to other
routines as small as possible.
- Klaus Kudielka
May 30 1997: (v1.5b)
1) SCSI-command capability enlarged by the recognition of MODE_SELECT.
This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which
allows data to be written from the system to the device. It is a
necessary step to be allowed to set blocksize of SCSI-tape-drives and
the tape-speed, without confusing the SCSI-Subsystem.
2) The recognition of a tape is included in the check_devices routine.
This is done by checking for TYPE_TAPE, that is already defined in
the kernel-scsi-environment. The markup of a tape is done in the
global ldn_is_tape[] array. If the entry on index ldn
is 1, there is a tapedrive connected.
3) The ldn_is_tape[] array is necessary to distinguish between tape- and
other devices. Fixed blocklength devices should not cause a problem
with the SCB-command for read and write in the ibmmca_queuecommand
subroutine. Therefore, I only derivate the READ_XX, WRITE_XX for
the tape-devices, as recommended by IBM in this Technical Reference,
mentioned below. (IBM recommends to avoid using the read/write of the
subsystem, but the fact was, that read/write causes a command error from
the subsystem and this causes kernel-panic.)
4) In addition, I propose to use the ldn instead of a fix char for the
display of PS2_DISK_LED_ON(). On 95, one can distinguish between the
devices that are accessed. It shows activity and easyfies debugging.
The tape-support has been tested with a SONY SDT-5200 and a HP DDS-2
(I do not know yet the type). Optimization and CD-ROM audio-support,
I am working on ...
- Michael Lang
June 19 1997: (v1.6b)
1) Submitting the extra-array ldn_is_tape[] -> to the local ld[]
device-array.
2) CD-ROM Audio-Play seems to work now.
3) When using DDS-2 (120M) DAT-Tapes, mtst shows still density-code
0x13 for ordinary DDS (61000 BPM) instead 0x24 for DDS-2. This appears
also on Adaptec 2940 adaptor in a PCI-System. Therefore, I assume that
the problem is independent of the low-level-driver/bus-architecture.
4) Hexadecimal ldn on PS/2-95 LED-display.
5) Fixing of the PS/2-LED on/off that it works right with tapedrives and
does not confuse the disk_rw_in_progress counter.
- Michael Lang
June 21 1997: (v1.7b)
1) Adding of a proc_info routine to inform in /proc/scsi/ibmmca/<host> the
outer-world about operational load statistics on the different ldns,
seen by the driver. Everybody that has more than one IBM-SCSI should
test this, because I only have one and cannot see what happens with more
than one IBM-SCSI hosts.
2) Definition of a driver version-number to have a better recognition of
the source when there are existing too much releases that may confuse
the user, when reading about release-specific problems. Up to know,
I calculated the version-number to be 1.7. Because we are in BETA-test
yet, it is today 1.7b.
3) Sorry for the heavy bug I programmed on June 19 1997! After that, the
CD-ROM did not work any more! The C7-command was a fake impression
I got while programming. Now, the READ and WRITE commands for CD-ROM are
no longer running over the subsystem, but just over
IM_OTHER_SCSI_CMD_CMD. On my observations (PS/2-95), now CD-ROM mounts
much faster(!) and hopefully all fancy multimedia-functions, like direct
digital recording from audio-CDs also work. (I tried it with cdda2wav
from the cdwtools-package and it filled up the harddisk immediately :-).)
To easify boolean logics, a further local device-type in ld[], called
is_cdrom has been included.
4) If one uses a SCSI-device of unsupported type/commands, one
immediately runs into a kernel-panic caused by Command Error. To better
understand which SCSI-command caused the problem, I extended this
specific panic-message slightly.
- Michael Lang
June 25 1997: (v1.8b)
1) Some cosmetic changes for the handling of SCSI-device-types.
Now, also CD-Burners / WORMs and SCSI-scanners should work. For
MO-drives I have no experience, therefore not yet supported.
In logical_devices I changed from different type-variables to one
called 'device_type' where the values, corresponding to scsi.h,
of a SCSI-device are stored.
2) There existed a small bug, that maps a device, coming after a SCSI-tape
wrong. Therefore, e.g. a CD-ROM changer would have been mapped wrong
-> problem removed.
3) Extension of the logical_device structure. Now it contains also device,
vendor and revision-level of a SCSI-device for internal usage.
- Michael Lang
June 26-29 1997: (v2.0b)
1) The release number 2.0b is necessary because of the completely new done
recognition and handling of SCSI-devices with the adapter. As I got
from Chris the hint, that the subsystem can reassign ldns dynamically,
I remembered this immediate_assign-command, I found once in the handbook.
Now, the driver first kills all ldn assignments that are set by default
on the SCSI-subsystem. After that, it probes on all puns and luns for
devices by going through all combinations with immediate_assign and
probing for devices, using device_inquiry. The found physical(!) pun,lun
structure is stored in get_scsi[][] as device types. This is followed
by the assignment of all ldns to existing SCSI-devices. If more ldns
than devices are available, they are assigned to non existing pun,lun
combinations to satisfy the adapter. With this, the dynamical mapping
was possible to implement. (For further info see the text in the
source code and in the description below. Read the description
below BEFORE installing this driver on your system!)
2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION.
3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID
(pun) of the accessed SCSI-device. This is now senseful, because the
pun known within the driver is exactly the pun of the physical device
and no longer a fake one.
4) The /proc/scsi/ibmmca/<host_no> consists now of the first part, where
hit-statistics of ldns is shown and a second part, where the maps of
physical and logical SCSI-devices are displayed. This could be very
interesting, when one is using more than 15 SCSI-devices in order to
follow the dynamical remapping of ldns.
- Michael Lang
June 26-29 1997: (v2.0b-1)
1) I forgot to switch the local_checking_phase_flag to 1 and back to 0
in the dynamical remapping part in ibmmca_queuecommand for the
device_exist routine. Sorry.
- Michael Lang
July 1-13 1997: (v3.0b,c)
1) Merging of the driver-developments of Klaus Kudielka and Michael Lang
in order to get a optimum and unified driver-release for the
IBM-SCSI-Subsystem-Adapter(s).
For people, using the Kernel-release >=2.1.0, module-support should
be no problem. For users, running under <2.1.0, module-support may not
work, because the methods have changed between 2.0.x and 2.1.x.
2) Added some more effective statistics for /proc-output.
3) Change typecasting at necessary points from (unsigned long) to
virt_to_bus().
4) Included #if... at special points to have specific adaption of the
driver to kernel 2.0.x and 2.1.x. It should therefore also run with
later releases.
5) Magneto-Optical drives and medium-changers are also recognized, now.
Therefore, we have a completely gapfree recognition of all SCSI-
device-types, that are known by Linux up to kernel 2.1.31.
6) The flag SCSI_IBMMCA_DEV_RESET has been inserted. If it is set within
the configuration, each connected SCSI-device will get a reset command
during boottime. This can be necessary for some special SCSI-devices.
This flag should be included in Config.in.
(See also the new Config.in file.)
Probable next improvement: bad disk handler.
- Michael Lang
Sept 14 1997: (v3.0c)
1) Some debugging and speed optimization applied.
- Michael Lang
Dec 15, 1997
- chrisb@truespectra.com
- made the front panel display thingy optional, specified from the
command-line via ibmmcascsi=display. Along the lines of the /LED
option for the OS/2 driver.
- fixed small bug in the LED display that would hang some machines.
- reversed ordering of the drives (using the
IBMMCA_SCSI_ORDER_STANDARD define). This is necessary for two main
reasons:
- users who've already installed Linux won't be screwed. Keep
in mind that not everyone is a kernel hacker.
- be consistent with the BIOS ordering of the drives. In the
BIOS, id 6 is C:, id 0 might be D:. With this scheme, they'd be
backwards. This confuses the crap out of those heathens who've
got a impure Linux installation (which, <wince>, I'm one of).
This whole problem arises because IBM is actually non-standard with
the id to BIOS mappings. You'll find, in fdomain.c, a similar
comment about a few FD BIOS revisions. The Linux (and apparently
industry) standard is that C: maps to scsi id (0,0). Let's stick
with that standard.
- Since this is technically a branch of my own, I changed the
version number to 3.0e-cpb.
Jan 17, 1998: (v3.0f)
1) Addition of some statistical info for /proc in proc_info.
2) Taking care of the SCSI-assignment problem, dealed by Chris at Dec 15
1997. In fact, IBM is right, concerning the assignment of SCSI-devices
to driveletters. It is conform to the ANSI-definition of the SCSI-
standard to assign drive C: to SCSI-id 6, because it is the highest
hardware priority after the hostadapter (that has still today by
default everywhere id 7). Also realtime-operating systems that I use,
like LynxOS and OS9, which are quite industrial systems use top-down
numbering of the harddisks, that is also starting at id 6. Now, one
sits a bit between two chairs. On one hand side, using the define
IBMMCA_SCSI_ORDER_STANDARD makes Linux assigning disks conform to
the IBM- and ANSI-SCSI-standard and keeps this driver downward
compatible to older releases, on the other hand side, people is quite
habituated in believing that C: is assigned to (0,0) and much other
SCSI-BIOS do so. Therefore, I moved the IBMMCA_SCSI_ORDER_STANDARD
define out of the driver and put it into Config.in as subitem of
'IBM SCSI support'. A help, added to Documentation/Configure.help
explains the differences between saying 'y' or 'n' to the user, when
IBMMCA_SCSI_ORDER_STANDARD prompts, so the ordinary user is enabled to
choose the way of assignment, depending on his own situation and gusto.
3) Adapted SCSI_IBMMCA_DEV_RESET to the local naming convention, so it is
now called IBMMCA_SCSI_DEV_RESET.
4) Optimization of proc_info and its subroutines.
5) Added more in-source-comments and extended the driver description by
some explanation about the SCSI-device-assignment problem.
- Michael Lang
Jan 18, 1998: (v3.0g)
1) Correcting names to be absolutely conform to the later 2.1.x releases.
This is necessary for
IBMMCA_SCSI_DEV_RESET -> CONFIG_IBMMCA_SCSI_DEV_RESET
IBMMCA_SCSI_ORDER_STANDARD -> CONFIG_IBMMCA_SCSI_ORDER_STANDARD
- Michael Lang
Jan 18, 1999: (v3.1 MCA-team internal)
1) The multiple hosts structure is accessed from every subroutine, so there
is no longer the address of the device structure passed from function
to function, but only the hostindex. A call by value, nothing more. This
should really be understood by the compiler and the subsystem should get
the right values and addresses.
2) The SCSI-subsystem detection was not complete and quite hugely buggy up
to now, compared to the technical manual. The interpretation of the pos2
register is not as assumed by people before, therefore, I dropped a note
in the ibmmca_detect function to show the registers' interpretation.
The pos-registers of integrated SCSI-subsystems do not contain any
information concerning the IO-port offset, really. Instead, they contain
some info about the adapter, the chip, the NVRAM .... The I/O-port is
fixed to 0x3540 - 0x3547. There can be more than one adapters in the
slots and they get an offset for the I/O area in order to get their own
I/O-address area. See chapter 2 for detailed description. At least, the
detection should now work right, even on models other than 95. The 95ers
came happily around the bug, as their pos2 register contains always 0
in the critical area. Reserved bits are not allowed to be interpreted,
therefore, IBM is allowed to set those bits as they like and they may
really vary between different PS/2 models. So, now, no interpretation
of reserved bits - hopefully no trouble here anymore.
3) The command error, which you may get on models 55, 56, 57, 70, 77 and
P70 may have been caused by the fact, that adapters of older design do
not like sending commands to non-existing SCSI-devices and will react
with a command error as a sign of protest. While this error is not
present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI
Adapters. Therefore, I implemented a workaround to forgive those
adapters their protests, but it is marked up in the statistics, so
after a successful boot, you can see in /proc/scsi/ibmmca/<host_number>
how often the command errors have been forgiven to the SCSI-subsystem.
If the number is bigger than 0, you have a SCSI subsystem of older
design, what should no longer matter.
4) ibmmca_getinfo() has been adapted very carefully, so it shows in the
slotn file really, what is senseful to be presented.
5) ibmmca_register() has been extended in its parameter list in order to
pass the right name of the SCSI-adapter to Linux.
- Michael Lang
Feb 6, 1999: (v3.1)
1) Finally, after some 3.1Beta-releases, the 3.1 release. Sorry, for
the delayed release, but it was not finished with the release of
Kernel 2.2.0.
- Michael Lang
Feb 10, 1999 (v3.1)
1) Added a new commandline parameter called 'bypass' in order to bypass
every integrated subsystem SCSI-command consequently in case of
troubles.
2) Concatenated read_capacity requests to the harddisks. It gave a lot
of troubles with some controllers and after I wanted to apply some
extensions, it jumped out in the same situation, on my w/cache, as like
on D. Weinehalls' Model 56, having integrated SCSI. This gave me the
decisive hint to move the code-part out and declare it global. Now
it seems to work far better and more stable. Let us see what
the world thinks of it...
3) By the way, only Sony DAT-drives seem to show density code 0x13. A
test with a HP drive gave right results, so the problem is vendor-
specific and not a problem of the OS or the driver.
- Michael Lang
Feb 18, 1999 (v3.1d)
1) The abort command and the reset function have been checked for
inconsistencies. From the logical point of thinking, they work
at their optimum, now, but as the subsystem does not answer with an
interrupt, abort never finishes, sigh...
2) Everything, that is accessed by a busmaster request from the adapter
is now declared as global variable, even the return-buffer in the
local checking phase. This assures, that no accesses to undefined memory
areas are performed.
3) In ibmmca.h, the line unchecked_isa_dma is added with 1 in order to
avoid memory-pointers for the areas higher than 16MByte in order to
be sure, it also works on 16-Bit Microchannel bus systems.
4) A lot of small things have been found, but nothing that endangered the
driver operations. Just it should be more stable, now.
- Michael Lang
Feb 20, 1999 (v3.1e)
1) I took the warning from the Linux Kernel Hackers Guide serious and
checked the cmd->result return value to the done-function very carefully.
It is obvious, that the IBM SCSI only delivers the tsb.dev_status, if
some error appeared, else it is undefined. Now, this is fixed. Before
any SCB command gets queued, the tsb.dev_status is set to 0, so the
cmd->result won't screw up Linux higher level drivers.
2) The reset-function has slightly improved. This is still planed for
abort. During the abort and the reset function, no interrupts are
allowed. This is however quite hard to cope with, so the INT-status
register is read. When the interrupt gets queued, one can find its
status immediately on that register and is enabled to continue in the
reset function. I had no chance to test this really, only in a bogus
situation, I got this function running, but the situation was too much
worse for Linux :-(, so tests will continue.
3) Buffers got now consistent. No open address mapping, as before and
therefore no further troubles with the unassigned memory segmentation
faults that scrambled probes on 95XX series and even on 85XX series,
when the kernel is done in a not so perfectly fitting way.
4) Spontaneous interrupts from the subsystem, appearing without any
command previously queued are answered with a DID_BAD_INTR result.
5) Taken into account ZP Gus' proposals to reverse the SCSI-device
scan order. As it does not work on Kernel 2.1.x or 2.2.x, as proposed
by him, I implemented it in a slightly derived way, which offers in
addition more flexibility.
- Michael Lang
Apr 23, 2000 (v3.2pre1)
1) During a very long time, I collected a huge amount of bug reports from
various people, trying really quite different things on their SCSI-
PS/2s. Today, all these bug reports are taken into account and should be
mostly solved. The major topics were:
- Driver crashes during boottime by no obvious reason.
- Driver panics while the midlevel-SCSI-driver is trying to inquire
the SCSI-device properties, even though hardware is in perfect state.
- Displayed info for the various slot-cards is interpreted wrong.
The main reasons for the crashes were two:
1) The commands to check for device information like INQUIRY,
TEST_UNIT_READY, REQUEST_SENSE and MODE_SENSE cause the devices
to deliver information of up to 255 bytes. Midlevel drivers offer
1024 bytes of space for the answer, but the IBM-SCSI-adapters do
not accept this, as they stick quite near to ANSI-SCSI and report
a COMMAND_ERROR message which causes the driver to panic. The main
problem was located around the INQUIRY command. Now, for all the
mentioned commands, the buffersize sent to the adapter is at
maximum 255 which seems to be a quite reasonable solution.
TEST_UNIT_READY gets a buffersize of 0 to make sure that no
data is transferred in order to avoid any possible command failure.
2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send
a REQUEST_SENSE in order to see where the problem is located. This
REQUEST_SENSE may have various length in its answer-buffer. IBM
SCSI-subsystems report a command failure if the returned buffersize
is different from the sent buffersize, but this can be suppressed by
a special bit, which is now done and problems seem to be solved.
2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on
2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes.
3) Commandline-parameters are recognized again, even under Kernel 2.3.x or
higher.
- Michael Lang
April 27, 2000 (v3.2pre2)
1) Bypassed commands get read by the adapter by one cycle instead of two.
This increases SCSI-performance.
2) Synchronous datatransfer is provided for sure to be 5 MHz on older
SCSI and 10 MHz on internal F/W SCSI-adapter.
3) New commandline parameters allow to force the adapter to slow down while
in synchronous transfer. Could be helpful for very old devices.
- Michael Lang
June 2, 2000 (v3.2pre5)
1) Added Jim Shorney's contribution to make the activity indicator
flashing in addition to the LED-alphanumeric display-panel on
models 95A. To be enabled to choose this feature freely, a new
commandline parameter is added, called 'activity'.
2) Added the READ_CONTROL bit for test_unit_ready SCSI-command.
3) Added some suppress_exception bits to read_device_capacity and
all device_inquiry occurrences in the driver code.
4) Complaints about the various KERNEL_VERSION implementations are
taken into account. Every local_LinuxKernelVersion occurrence is
now replaced by KERNEL_VERSION, defined in linux/version.h.
Corresponding changes were applied to ibmmca.h, too. This was a
contribution to all kernel-parts by Philipp Hahn.
- Michael Lang
July 17, 2000 (v3.2pre8)
A long period of collecting bug reports from all corners of the world
now lead to the following corrections to the code:
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
was that it is possible to disable Fast-SCSI for the external bus.
The feature-control command, where this crash appeared regularly, tried
to set the maximum speed of 10MHz synchronous transfer speed and that
reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
the feature-command probes down from maximum speed until the adapter
stops to complain, which is at the same time the maximum possible
speed selected in the reference program. So, F/W external can run at
5 MHz (slow-) or 10 MHz (fast-SCSI). During feature probing, the
COMMAND ERROR message is used to detect if the adapter does not complain.
2) Up to now, only combined busmode is supported, if you use external
SCSI-devices, attached to the F/W-controller. If dual bus is selected,
only the internal SCSI-devices get accessed by Linux. For most
applications, this should do fine.
3) Wide-SCSI-addressing (16-Bit) is now possible for the internal F/W
bus on the F/W adapter. If F/W adapter is detected, the driver
automatically uses the extended PUN/LUN <-> LDN mapping tables, which
are now new from 3.2pre8. This allows PUNs between 0 and 15 and should
provide more fun with the F/W adapter.
4) Several machines use the SCSI: POS registers for internal/undocumented
storage of system relevant info. This confused the driver, mainly on
models 9595, as it expected no onboard SCSI only, if all POS in
the integrated SCSI-area are set to 0x00 or 0xff. Now, the mechanism
to check for integrated SCSI is much more restrictive and these problems
should be history.
- Michael Lang
July 18, 2000 (v3.2pre9)
This develop rather quickly at the moment. Two major things were still
missing in 3.2pre8:
1) The adapter PUN for F/W adapters has 4-bits, while all other adapters
have 3-bits. This is now taken into account for F/W.
2) When you select CONFIG_IBMMCA_SCSI_ORDER_STANDARD, you should
normally get the inverse probing order of your devices on the SCSI-bus.
The ANSI device order gets scrambled in version 3.2pre8!! Now, a new
and tested algorithm inverts the device-order on the SCSI-bus and
automatically avoids accidental access to whatever SCSI PUN the adapter
is set and works with SCSI- and Wide-SCSI-addressing.
- Michael Lang
July 23, 2000 (v3.2pre10 unpublished)
1) LED panel display supports wide-addressing in ibmmca=display mode.
2) Adapter-information and autoadaption to address-space is done.
3) Auto-probing for maximum synchronous SCSI transfer rate is working.
4) Optimization to some embedded function calls is applied.
5) Added some comment for the user to wait for SCSI-devices being probed.
6) Finished version 3.2 for Kernel 2.4.0. It least, I thought it is but...
- Michael Lang
July 26, 2000 (v3.2pre11)
1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and
a model 9595. Asking around in the community, nobody except of me has
seen such errors. Weird, but I am trying to recompile everything on
the model 9595. Maybe, as I use a specially modified gcc, that could
cause problems. But, it was not the reason. The true background was,
that the kernel was compiled for i386 and the 9595 has a 486DX-2.
Normally, no troubles should appear, but for this special machine,
only the right processor support is working fine!
2) Previous problems with synchronous speed, slowing down from one adapter
to the next during probing are corrected. Now, local variables store
the synchronous bitmask for every single adapter found on the MCA bus.
3) LED alphanumeric panel support for XX95 systems is now showing some
alive rotator during boottime. This makes sense, when no monitor is
connected to the system. You can get rid of all display activity, if
you do not use any parameter or just ibmmcascsi=activity, for the
harddrive activity LED, existent on all PS/2, except models 8595-XXX.
If no monitor is available, please use ibmmcascsi=display, which works
fine together with the linuxinfo utility for the LED-panel.
- Michael Lang
July 29, 2000 (v3.2)
1) Submission of this driver for kernel 2.4test-XX and 2.2.17.
- Michael Lang
December 28, 2000 (v3.2d / v4.0)
1) The interrupt handler had some wrong statement to wait for. This
was done due to experimental reasons during 3.2 development but it
has shown that this is not stable enough. Going back to wait for the
adapter to be not busy is best.
2) Inquiry requests can be shorter than 255 bytes of return buffer. Due
to a bug in the ibmmca_queuecommand routine, this buffer was forced
to 255 at minimum. If the memory address, this return buffer is pointing
to does not offer more space, invalid memory accesses destabilized the
kernel.
3) version 4.0 is only valid for kernel 2.4.0 or later. This is necessary
to remove old kernel version dependent waste from the driver. 3.2d is
only distributed with older kernels but keeps compatibility with older
kernel versions. 4.0 and higher versions cannot be used with older
kernels anymore!! You must have at least kernel 2.4.0!!
4) The commandline argument 'bypass' and all its functionality got removed
in version 4.0. This was never really necessary, as all troubles were
based on non-command related reasons up to now, so bypassing commands
did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
5) Dynamic reassignment of ldns was again verified and analyzed to be
completely inoperational. This is corrected and should work now.
6) All commands that get sent to the SCSI adapter were verified and
completed in such a way, that they are now completely conform to the
demands in the technical description of IBM. Main candidates were the
DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
be transferred by bypassing the internal command buffer of the adapter
or else the response can be a random result. GET_POS_INFO would be more
safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
is not allowed by the technical references of IBM. (Sorry, folks, the
model 80 problem is still a task to be solved in a different way.)
7) v3.2d is still hold back for some days for testing, while 4.0 is
released.
- Michael Lang
January 3, 2001 (v4.0a)
1) A lot of complains after the 2.4.0-prerelease kernel came in about
the impossibility to compile the driver as a module. This problem is
solved. In combination with that problem, some unprecise declaration
of the function option_setup() gave some warnings during compilation.
This is solved, too by a forward declaration in ibmmca.c.
2) #ifdef argument concerning CONFIG_SCSI_IBMMCA is no longer needed and
was entirely removed.
3) Some switch statements got optimized in code, as some minor variables
in internal SCSI-command handlers.
- Michael Lang
4 To do
-------
- IBM SCSI-2 F/W external SCSI bus support in separate mode!
- It seems that the handling of bad disks is really bad -
non-existent, in fact. However, a low-level driver cannot help
much, if such things happen.
5 Users' Manual
---------------
5.1 Commandline Parameters
--------------------------
There exist several features for the IBM SCSI-subsystem driver.
The commandline parameter format is:
ibmmcascsi=<command1>,<command2>,<command3>,...
where commandN can be one of the following:
display Owners of a model 95 or other PS/2 systems with an
alphanumeric LED display may set this to have their
display showing the following output of the 8 digits:
------DA
where '-' stays dark, 'D' shows the SCSI-device id
and 'A' shows the SCSI hostindex, being currently
accessed. During boottime, this will give the message
SCSIini*
on the LED-panel, where the * represents a rotator,
showing the activity during the probing phase of the
driver which can take up to two minutes per SCSI-adapter.
adisplay This works like display, but gives more optical overview
of the activities on the SCSI-bus. The display will have
the following output:
6543210A
where the numbers 0 to 6 light up at the shown position,
when the SCSI-device is accessed. 'A' shows again the SCSI
hostindex. If display nor adisplay is set, the internal
PS/2 harddisk LED is used for media-activities. So, if
you really do not have a system with a LED-display, you
should not set display or adisplay. Keep in mind, that
display and adisplay can only be used alternatively. It
is not recommended to use this option, if you have some
wide-addressed devices e.g. at the SCSI-2 F/W adapter in
your system. In addition, the usage of the display for
other tasks in parallel, like the linuxinfo-utility makes
no sense with this option.
activity This enables the PS/2 harddisk LED activity indicator.
Most PS/2 have no alphanumeric LED display, but some
indicator. So you should use this parameter to activate it.
If you own model 9595 (Server95), you can have both, the
LED panel and the activity indicator in parallel. However,
some PS/2s, like the 8595 do not have any harddisk LED