Fedora resources
hawkwynd
nflug at afourthdimension.com
Thu Jul 7 06:09:52 EDT 2005
Got the card installed - turns out I was trying to use IRQ10 which was
being used by the 2nd nic (which is dormant) so I removed it from the
machine, shut off the USB ports in the bios, and disabled the VGA
assignment to an IRQ to free up some resources. I then set IRQ 10 to ISA
in the bios, to reserve it for the card, and modprobe gleefully
installed the driver for the aha1520 card.
Whee! Now my hardware browser lists 7 CDROM drives /dev/scd1-7 however I
can only mount 4 of them. Still working on that, as it may be a simple
matter that I've overlooked. Gotta play about with the mount commands a
bit more to find out what's going on with that.
One question: How do I initiate MODPROBE on boot to recognize the
Adaptec aha1520, so I don't have to manually install the card each time?
Thank you for your help,
Scott
Cyber Source wrote:
> "less /proc/interrupts" will show the interrupts in use. Is that
> controller doing a hardware raid? Can you successfully see your card
> and devices from the cards bios? i.e. ctrl-A at boot.
>
> hawkwynd wrote:
>
>> Im running ( as per system log ):
>>
>> Linux version 2.4.22-1.2199.nptl (bhcompile at tweety.build.redhat.com)
>> (gcc version 3.2.3 20030422 (Red Hat Linux 3.2.3-6)) #1 Wed Aug 4
>> 12:29:42 EDT 2004
>>
>> Being noviced, I thing this FC1, not entirely sure. Does this
>> matter? Do I have to wipe the machine clean and download FC3?
>>
>> I've set the jumpers on the card to 0x140 and tried IRQ 9, 10, 11,
>> 12, consecutively. Each time, the following error is presented in dmesg:
>>
>>> Jul 5 23:32:51 Cavetroll kernel: aha152x: BIOS test: passed,
>>> detected 1 controller(s)
>>> Jul 5 23:32:51 Cavetroll kernel: aha152x: resetting bus...
>>> Jul 5 23:32:51 Cavetroll kernel: aha152x1: vital data: rev=1,
>>> io=0x140 (0x140/0x140), irq=10, scsiid=7, reconnect=enabled,
>>> parity=enabled, synchronous=disabled, delay=1000, extended
>>> translation=disabled
>>> Jul 5 23:32:51 Cavetroll kernel: aha152x1: trying software
>>> interrupt, lost.
>>> Jul 5 23:32:51 Cavetroll kernel: aha152x1: IRQ 10 possibly wrong.
>>> Please verify.
>>
>>
>>
>>
>> Is there a way in FC to show the free IRQ's? I'm having a dillio of
>> time with this. I had it running fine under windows, and getting
>> stonewalled in 'nix land..
>>
>> Any other suggestions would be appreciated as well.
>>
>> Scott
>>
>>
>>
>> Cyber Source wrote:
>>
>>> I'm going to assume you have FC3. My FC3 box running kernel
>>> 2.6.11-1.14_FC3 had the attached file in the kernel docs for the
>>> Adaptec 1520. I would try "/sbin/modprobe aha152x" as root and see
>>> if you can load the module. You could also try booting your system
>>> with the card in with a rescue cd and see what modules get loaded,
>>> then compare them against your running system.
>>>
>>> hawkwynd wrote:
>>>
>>>> Greetings,
>>>>
>>>> My Fedora box has been running flawlessly now for a month - without
>>>> a reboot. I've gotten all the things I need it to do (network with
>>>> my windows machines, share my printer, Xampp etc.) and now I'm
>>>> ready to get the last item nailed down. The scsi card.
>>>>
>>>> I have an AAA-131 Adaptec raid controller, which Fedora saw, and
>>>> installed on discovery. I also have a legacy ISA adaptec 1520b
>>>> card, that Fedora doesn't see, and even though I set the proper
>>>> settings when running the mod, it gives an error. It's been a while
>>>> since I've worked on this problem, but because I now need to use my
>>>> plextor 7-drive scsi cdrom tower, I am revisiting this issue.
>>>>
>>>> Some pointers to get it working would be most helpful.
>>>>
>>>> Thank you - Oh, BTW, I don't want to use a different card, because
>>>> then I'd have to go out to buy another cable, if I can help it.
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> $Id: README.aha152x,v 1.2 1999/12/25 15:32:30 fischer Exp fischer $
>>> Adaptec AHA-1520/1522 SCSI driver for Linux (aha152x)
>>>
>>> Copyright 1993-1999 Jürgen Fischer <fischer at norbit.de>
>>> TC1550 patches by Luuk van Dijk (ldz at xs4all.nl)
>>>
>>>
>>> In Revision 2 the driver was modified a lot (especially the
>>> bottom-half handler complete()).
>>>
>>> The driver is much cleaner now, has support for the new
>>> error handling code in 2.3, produced less cpu load (much
>>> less polling loops), has slightly higher throughput (at
>>> least on my ancient test box; a i486/33Mhz/20MB).
>>>
>>>
>>> CONFIGURATION ARGUMENTS:
>>>
>>> IOPORT base io address (0x340/0x140)
>>> IRQ interrupt level (9-12;
>>> default 11)
>>> SCSI_ID scsi id of controller (0-7;
>>> default 7)
>>> RECONNECT allow targets to disconnect from the bus (0/1;
>>> default 1 [on])
>>> PARITY enable parity checking (0/1;
>>> default 1 [on])
>>> SYNCHRONOUS enable synchronous transfers (0/1;
>>> default 1 [on])
>>> DELAY: bus reset delay (default 100)
>>> EXT_TRANS: enable extended translation (0/1:
>>> default 0 [off])
>>> (see NOTES)
>>>
>>> COMPILE TIME CONFIGURATION (go into AHA152X in drivers/scsi/Makefile):
>>>
>>> -DAUTOCONF
>>> use configuration the controller reports (AHA-152x only)
>>>
>>> -DSKIP_BIOSTEST
>>> Don't test for BIOS signature (AHA-1510 or disabled BIOS)
>>>
>>> -DSETUP0="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS,
>>> DELAY, EXT_TRANS }"
>>> override for the first controller
>>> -DSETUP1="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS,
>>> DELAY, EXT_TRANS }"
>>> override for the second controller
>>>
>>> -DAHA152X_DEBUG
>>> enable debugging output
>>>
>>> -DAHA152X_STAT
>>> enable some statistics
>>>
>>>
>>> LILO COMMAND LINE OPTIONS:
>>>
>>> aha152x=<IOPORT>[,<IRQ>[,<SCSI-ID>[,<RECONNECT>[,<PARITY>[,<SYNCHRONOUS>[,<DELAY>
>>> [,<EXT_TRANS]]]]]]]
>>>
>>> The normal configuration can be overridden by specifying a command
>>> line.
>>> When you do this, the BIOS test is skipped. Entered values have to be
>>> valid (known). Don't use values that aren't supported under normal
>>> operation. If you think that you need other values: contact me.
>>> For two controllers use the aha152x statement twice.
>>>
>>>
>>> SYMBOLS FOR MODULE CONFIGURATION:
>>>
>>> Choose from 2 alternatives:
>>>
>>> 1. specify everything (old)
>>>
>>> aha152x=IOPORT,IRQ,SCSI_ID,RECONNECT,PARITY,SYNCHRONOUS,DELAY,EXT_TRANS
>>> configuration override for first controller
>>>
>>>
>>> aha152x1=IOPORT,IRQ,SCSI_ID,RECONNECT,PARITY,SYNCHRONOUS,DELAY,EXT_TRANS
>>>
>>> configuration override for second controller
>>>
>>> 2. specify only what you need to (irq or io is required; new)
>>>
>>> io=IOPORT0[,IOPORT1]
>>> IOPORT for first and second controller
>>>
>>> irq=IRQ0[,IRQ1]
>>> IRQ for first and second controller
>>>
>>> scsiid=SCSIID0[,SCSIID1]
>>> SCSIID for first and second controller
>>>
>>> reconnect=RECONNECT0[,RECONNECT1]
>>> allow targets to disconnect for first and second controller
>>>
>>> parity=PAR0[PAR1]
>>> use parity for first and second controller
>>>
>>> sync=SYNCHRONOUS0[,SYNCHRONOUS1]
>>> enable synchronous transfers for first and second controller
>>>
>>> delay=DELAY0[,DELAY1]
>>> reset DELAY for first and second controller
>>>
>>> exttrans=EXTTRANS0[,EXTTRANS1]
>>> enable extended translation for first and second controller
>>>
>>>
>>> If you use both alternatives the first will be taken.
>>>
>>>
>>> NOTES ON EXT_TRANS:
>>> SCSI uses block numbers to address blocks/sectors on a device.
>>> The BIOS uses a cylinder/head/sector addressing scheme (C/H/S)
>>> scheme instead. DOS expects a BIOS or driver that understands this
>>> C/H/S addressing.
>>>
>>> The number of cylinders/heads/sectors is called geometry and is
>>> required
>>> as base for requests in C/H/S addressing. SCSI only knows about the
>>> total capacity of disks in blocks (sectors).
>>>
>>> Therefore the SCSI BIOS/DOS driver has to calculate a logical/virtual
>>> geometry just to be able to support that addressing scheme. The
>>> geometry
>>> returned by the SCSI BIOS is a pure calculation and has nothing to
>>> do with the real/physical geometry of the disk (which is usually
>>> irrelevant anyway).
>>>
>>> Basically this has no impact at all on Linux, because it also uses
>>> block
>>> instead of C/H/S addressing. Unfortunately C/H/S addressing is also
>>> used
>>> in the partition table and therefore every operating system has to know
>>> the right geometry to be able to interpret it.
>>>
>>> Moreover there are certain limitations to the C/H/S addressing scheme,
>>> namely the address space is limited to upto 255 heads, upto 63 sectors
>>> and a maximum of 1023 cylinders.
>>>
>>> The AHA-1522 BIOS calculates the geometry by fixing the number of heads
>>> to 64, the number of sectors to 32 and by calculating the number of
>>> cylinders by dividing the capacity reported by the disk by 64*32 (1
>>> MB).
>>> This is considered to be the default translation.
>>>
>>> With respect to the limit of 1023 cylinders using C/H/S you can only
>>> address the first GB of your disk in the partition table. Therefore
>>> BIOSes of some newer controllers based on the AIC-6260/6360 support
>>> extended translation. This means that the BIOS uses 255 for heads,
>>> 63 for sectors and then divides the capacity of the disk by 255*63
>>> (about 8 MB), as soon it sees a disk greater than 1 GB. That results
>>> in a maximum of about 8 GB addressable diskspace in the partition table
>>> (but there are already bigger disks out there today).
>>>
>>> To make it even more complicated the translation mode might/might
>>> not be configurable in certain BIOS setups.
>>>
>>> This driver does some more or less failsafe guessing to get the
>>> geometry right in most cases:
>>>
>>> - for disks<1GB: use default translation (C/32/64)
>>>
>>> - for disks>1GB:
>>> - take current geometry from the partition table
>>> (using scsicam_bios_param and accept only `valid' geometries,
>>> ie. either (C/32/64) or (C/63/255)). This can be extended
>>> translation
>>> even if it's not enabled in the driver.
>>>
>>> - if that fails, take extended translation if enabled by override,
>>> kernel or module parameter, otherwise take default translation and
>>> ask the user for verification. This might on not yet partitioned
>>> disks.
>>>
>>>
>>> REFERENCES USED:
>>>
>>> "AIC-6260 SCSI Chip Specification", Adaptec Corporation.
>>>
>>> "SCSI COMPUTER SYSTEM INTERFACE - 2 (SCSI-2)", X3T9.2/86-109 rev. 10h
>>>
>>> "Writing a SCSI device driver for Linux", Rik Faith (faith at cs.unc.edu)
>>>
>>> "Kernel Hacker's Guide", Michael K. Johnson (johnsonm at sunsite.unc.edu)
>>>
>>> "Adaptec 1520/1522 User's Guide", Adaptec Corporation.
>>>
>>> Michael K. Johnson (johnsonm at sunsite.unc.edu)
>>>
>>> Drew Eckhardt (drew at cs.colorado.edu)
>>>
>>> Eric Youngdale (eric at andante.org)
>>> special thanks to Eric Youngdale for the free(!) supplying the
>>> documentation on the chip.
>>>
>>>
>>
>
>
>
More information about the nflug
mailing list