DAC960, 2.4.19 alpha problems

DAC960, 2.4.19 alpha problems

[T. Weyergraf]

Hi,
i failed to get a Mylex controller running in my alpha system.
Details:
Controller: Mylex eXtremeraid 3000 ( dual channel FC-AL )
System: Alpha UP2000 ( dp264-machine, dual CPU, 2gig RAM )
Kernels: 2.4.20-rc2 and 2.4.19
Compiler: 2.95.2
Debian potato with enhancements for the use of 2.4.x
according to Documentation/Changes

Compiling the DAC960 driver on alpha, using 2.95.2 fails,
since the optimizer apparently stumbles. In my naive/novice
attempts to get the driver compiling, I changed all
function declarations from "static inline" to "static"
The driver then compiles and is linked to the kernel, rather
than compiled as a module. ( Leaving some static inline 
declarations avoid compile-time warnings, so no
warnings are given ).
Proper device-nodes exist.

Upon boot, the driver emits the following message:
DAC960: ***** DAC960 RAID Driver Version 2.4.11 of 11 October 2001 *****
DAC960: Copyright 1998-2001 by Leonard N. Zubkoff <lnz@dandelion.com>
DAC960#0: Unable to Enable Memory Mailbox Interface for Controller at
DAC960#0: PCI Bus 1 Device 8 Function 0 I/O Address N/A PCI Address 0xA000000

This applies to 2.4.19 and 2.4.20-rc2

In addition, I have tried the following, all with no change in result:
- turn on/off Mylex' BIOS
- move Mylex accoss PCI-buses ( the machine has two )
- move Mylex from 64 to 32bit slot

Additional info:
PCI device database reports the following:
PCI: dev Mylex Corporation eXtremeRAID 2000/3000 support Device type 64-bit

/proc/pci reports the following:
Bus  1, device   8, function  0:
RAID bus controller: Mylex Corporation eXtremeRAID 2000/3000 support Device (rev 0).
IRQ 27.
Master Capable.  Latency=32.  
Non-prefetchable 32 bit memory at 0xa000000 [0xbffffff].
I/O at 0x9000 [0x907f].
Prefetchable 64 bit memory at 0x10000000 [0x1fffffff].

My questions:
Are there any fixes to this problem ?
Why does the driver report "I/O Adress N/A", while there seems to be
a valid I/O range in /proc/pci ?
Are there any fixes to the DAC960, which makes it compile using 2.95.2 ?

Please note, that i am aware, that the alpha will not boot from that device,
since it's firmware does not see the controller. It will not be used for
booting. Upgrading to a newer/different distro ist problematic, since the system
cannot be taken out of service easily ( I can reboot it for testing purposes ).

I would have reported this problem the "proper way" to the maintainer of the
driver, but in this case, it's Leonard Zubkoff, who unfortunatelt died in an
accident.

Thanks in advance for any advice/help. I am willing/happy to test any proposed
patches. In order to avoid cluttering the list, i did not send any .config's and
friends. I will on request, of course.

Regards,
T. Weyergraf


-- 
Thomas Weyergraf                                                kirk@colinet.de
My Favorite IA64 Opcode-guess ( see arch/ia64/lib/memset.S )
"br.ret.spnt.few" - got back from getting beer, did not spend a lot.

Re: DAC960, 2.4.19 alpha problems

[Alan Cox]

On Tue, 2002-11-19 at 11:06, T. Weyergraf wrote:
> Please note, that i am aware, that the alpha will not boot from that device,
> since it's firmware does not see the controller. It will not be used for
> booting. Upgrading to a newer/different distro ist problematic, since the system
> cannot be taken out of service easily ( I can reboot it for testing purposes ).

Does the firmware need to run to make the card work however ? Thats a
problem on some other raid cards that prevents them running on non x86
platforms

Re: DAC960, 2.4.19 alpha problems

[T. Weyergraf]

Hi,

[....]
 
> Does the firmware need to run to make the card work however ? Thats a
> problem on some other raid cards that prevents them running on non x86
> platforms

That is something, I honestly don't know. I've asked on the debian-alpha
mailing-list first and did not get any explanatory response. I've checked
the card in a x86-machine ( just to very it's working and to configure
RAID drives ). In this machine, the card posts a banner, saying it's
a Mylex and - depending on the BIOS enable/disable setting - posting
some keypress options to start the build-in firmware.
That i don't see on my alpha, which does not necessarily mean something.

The SRM firmware contains a small x86-emulator, being capable to at
least run the POST-routines of normal PCI cards. AFAIK, this emulator
works on a lot of cards, but is not capable of doing any screen/terminal
I/O. For example, if you use Matrox vga cards ( quite common on alphas )
you get a working grafics device, but yoy won't see any matrox banner
on the screen. Newer firmware's even support a "run_bios" command,
that allows to start configuration routines, like the RAID setup.
Unfortunately, a version of this newer firmware does not exist for
my machine.

Mylex OEM'd some earlier DAC-models to DEC for use as a RAID
controller. These came with their own firmwaer, which allowed ppl
to setup logical RAID-drives. I can't tell, if the firmware handles any
other POST stuff.

The controller comes with a SA-110 processor running it's own firmware.
I would assume, that the SA-110 handles POST - but that's honestly
just a wild guess.

Regards, 
T.weyergraf


-- 
Thomas Weyergraf                                                kirk@colinet.de
My Favorite IA64 Opcode-guess ( see arch/ia64/lib/memset.S )
"br.ret.spnt.few" - got back from getting beer, did not spend a lot.

Re: DAC960, 2.4.19 alpha problems

[Dave Olien]

I've been tinkering with the DAC960 driver in linux 2.5.
But, I don't have an alpha, so I can only guess about
what's going on in that case.

First, I don't know whether running POST is necessary to make the
board work.  But even if you get past the POST issue, how
would you configure the disks on the controller into
logical drives, with RAID level, etc?  The DAC960 driver
in linux doesn't provide any way to do this (mostly because
Mylex won't provide specifications for implementing this).
So, the only way I know under Linux is to run the
controller's graphical BIOS utility.  Mylex has a global
array manager utility that is somehow supported on Linux.
I think it may work by using some pass-through ioctl commands
to the driver.  But, I dont' have any experience with it.

Beyond that... removing inline declarations should NOT be a problem
for functions in this driver.

The "I/O Adress N/A" report from the driver is correct for
this controller.  The driver looks for an I/O address range only
for some of the older Mylex controller cards.  I believe this is
referring to space in x86 IO space  (using inb/outb
instructions).  The driver never actually references this space.

At the time the driver fails for you, the driver has already
done some interacting with registers on the controller.
It's had to enable interrupts from the device, it's
polled the controller's hardware mailbox waiting for it to be
empty, it's written  a command to the controller's hardware
mailbox, waited for a response, and gotten one.  So I think the
firmware on the controller card is "alive".  But it may still
be waiting for some interaction from the POST BIOS before
it will function.

alpha is little-endian.  So the data passed between driver
and controller should be compatible.  The driver currently
does not do endian-conversions.

There's another possibility.
At what physical address do alpha systems begin their ram?
Some routines that talk with your
controller card (in DAC960.h) have an #ifdef __ia64__.
The ia64 part of the #ifdef does 64-bit writes to the
controller.  The driver ia32 case (ie NOT an ia64)
does only 32-bit writes to the controller.
On ia32, we know that the memory allocated for memory mailboxes
(using __get_free_pages()) will always be below 4-gig.
So a 32-bit write is sufficient.
Is this true on alpha?  if not, then the __ia64__ ifdefs in
DAC960.h need to be modified to do 64-bit writes on alpha
as well.

On Tue, Nov 19, 2002 at 01:23:30PM +0100, T. Weyergraf wrote:
> Hi,
> 
> [....]
>  
> > Does the firmware need to run to make the card work however ? Thats a
> > problem on some other raid cards that prevents them running on non x86
> > platforms
> 
> That is something, I honestly don't know. I've asked on the debian-alpha
> mailing-list first and did not get any explanatory response. I've checked
> the card in a x86-machine ( just to very it's working and to configure
> RAID drives ). In this machine, the card posts a banner, saying it's
> a Mylex and - depending on the BIOS enable/disable setting - posting
> some keypress options to start the build-in firmware.
> That i don't see on my alpha, which does not necessarily mean something.
> 
> The SRM firmware contains a small x86-emulator, being capable to at
> least run the POST-routines of normal PCI cards. AFAIK, this emulator
> works on a lot of cards, but is not capable of doing any screen/terminal
> I/O. For example, if you use Matrox vga cards ( quite common on alphas )
> you get a working grafics device, but yoy won't see any matrox banner
> on the screen. Newer firmware's even support a "run_bios" command,
> that allows to start configuration routines, like the RAID setup.
> Unfortunately, a version of this newer firmware does not exist for
> my machine.
> 
> Mylex OEM'd some earlier DAC-models to DEC for use as a RAID
> controller. These came with their own firmwaer, which allowed ppl
> to setup logical RAID-drives. I can't tell, if the firmware handles any
> other POST stuff.
> 
> The controller comes with a SA-110 processor running it's own firmware.
> I would assume, that the SA-110 handles POST - but that's honestly
> just a wild guess.
> 
> Regards, 
> T.weyergraf
> 
> 
> -- 
> Thomas Weyergraf                                                kirk@colinet.de
> My Favorite IA64 Opcode-guess ( see arch/ia64/lib/memset.S )
> "br.ret.spnt.few" - got back from getting beer, did not spend a lot.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: DAC960, 2.4.19 alpha problems

[Ivan Kokshaysky]

On Tue, Nov 19, 2002 at 11:37:31AM -0800, Dave Olien wrote:
> On ia32, we know that the memory allocated for memory mailboxes
> (using __get_free_pages()) will always be below 4-gig.

That was it, I guess.
virt_to_bus() is deprecated - driver *must* be converted
to the DMA mapping interface (see Documentation/DMA-mapping.txt).

virt_to_bus() on alpha works only for limited range of kernel addresses.
On dp264 valid range is 0x00000000-0x7fefffff (i.e. 2Gb - 1Mb).
Given the fact that __get_free_pages() returns highest possible
pages I'm not surprised that this driver doesn't work on a 2Gb machine.

Probably "mem=2047M" boot argument would help...

Ivan.