Jump to content

AOC-SASLP-MV8 firmware


spl147

Recommended Posts

Manual is located here.  http://www.supermicro.com/manuals/other/AOC-SASLP-MV8.pdf

 

3-4 Getting Firmware Downloads

 

Firmware for the AOC-SASLP-MV8 add-on card can only be obtained through

contacting Supermicro Technical Support for instructions and assistance to obtain

firmware downloads.

 

3-5 Flashing Firmware

 

Follow the procedure below to flash firmware to the BIOS.

Flashing Firmware:

 

1. Boot the system to DOS.

2. Flash the BIOS using the mvf.exe file with the following command at the DOS

prompt (where *** represents the name of the bin file used):

a:\>mvf ***.bin

This automatically flashes the BIOS.

3. When the flashing is completed, reboot the system.

The new firmware is now flashed to your system’s BIOS.

 

 

Link to comment

Look for grub4dos, which can then boot a freedos floppy image.

Let me know if you need more from that.

 

You can also use syslinux's memdisk which can load a memdisk kernel which then loads a floppy image.  This is the most common method I've seen, especially with PXE boot images.

I got rid of my floppies years ago and went to a PXEboot image method along with a bootable flashkey that can load images.

Link to comment

Thanks.. looks like there's a a couple workable solutions without having to remove the cards.  It would be nice if we could flash these across a LAN.  Seems like booting to DOS is a failry antiquated method..

 

I appreciate the response WeeboTech!

 

 

 

Look for grub4dos, which can then boot a freedos floppy image.

Let me know if you need more from that.

 

You can also use syslinux's memdisk which can load a memdisk kernel which then loads a floppy image.  This is the most common method I've seen, especially with PXE boot images.

I got rid of my floppies years ago and went to a PXEboot image method along with a bootable flashkey that can load images.

Link to comment

Thanks.. looks like there's a a couple workable solutions without having to remove the cards.  It would be nice if we could flash these across a LAN.  Seems like booting to DOS is a failry antiquated method..

 

Actually you can boot from across the lan with PXEboot.

 

An advanced DHCP server can communicate to and support PXE, which allows you to load PXElinux, memdisk and then a floppy image.

 

So all you have to do is create a floppy image, drop it on your tftp server, set dhcp for the mac address and optional boot parameter and you're on your way.

 

 

Yeah, it's a few steps to get this set up.

Once it's set up, you can take any floppy image, dd it, put it on the tftp server directory, update pxelinux.cfg and you're off.

 

It's probably easier to work with syslinux, memdisk and floppy image on the boot flash.

 

There's a windows program called winimage which can be used to build a floppy image file.

This floppy image file can be booted by vmware, dd'ed to a floppy, transfered to your tftp pxe directory or loaded directly with memdisk.

 

Once you have an image, you can mount it on unraid with

 

mkdir /mnt/floppyimage

mount -o loop floppy.img /mnt/floppyimage

 

then populate it with what you need.

 

Keep in mind, you need to start with a bootable floppy image first.

So check out freedos, I believe they have some image files around.

 

winimage can be used to convert it to a 2.88 image which provides more room for tools.

 

 

Examples.

 

weebotech@gatekeeper: /var/tftpboot > ls -l
total 1936
drwxr-xr-x    3 root     sysadmin     4096 May 30  2004 boot
-rw-rw-r--    1 root     sysadmin      164 Jun  2  2004 BOOTMSG.TXT
lrwxrwxrwx    1 root     sysadmin       20 Oct  3  2009 default -> pxelinux.cfg/default
drwxr-xr-x    2 root     root         4096 Jan  8  2008 image
drwxrwxr-x    2 root     sysadmin     4096 May 16 22:21 images
-r--r--r--    1 root     sysadmin   365509 May 29  2004 initrd.img
-r--r--r--    1 root     sysadmin    20056 Dec 30  2007 memdisk
-r--r--r--    1 root     sysadmin    14848 Jul 27  2002 memdisk-1.75
-r--r--r--    1 root     sysadmin    14336 Dec 30  2007 memdisk-2.0
-r--r--r--    1 root     sysadmin    20056 Dec 30  2007 memdisk-3.50
-r--r--r--    1 root     sysadmin       30 Jun  2  2004 memdisk.cfg
-r--r--r--    1 root     sysadmin   123104 Jun  2  2004 nbgrub
-rw-rw-r--    1 root     sysadmin     1694 Feb 27 04:07 options.txt
-r--r--r--    1 root     sysadmin   124128 Jun  2  2004 pxeboot.test
-r--r--r--    1 root     sysadmin   124128 May 30  2004 pxegrub
-rw-rw-r--    1 root     sysadmin    13940 Dec 30  2007 pxelinux.0
-r--r--r--    1 root     sysadmin    10052 Jul 27  2002 pxelinux.0-1.75
-rw-r--r--    1 root     sysadmin    10820 Dec 30  2007 pxelinux.0-2.0
-rw-rw-r--    1 root     sysadmin    13940 Dec 30  2007 pxelinux.0-3.50
-rw-r--r--    1 root     sysadmin    13940 Dec 30  2007 pxelinux.bin-3.50
drwxrwxr-x    2 root     sysadmin     4096 May 16 22:22 pxelinux.cfg
-r--r--r--    1 root     sysadmin     1536 May 30  2004 pxeloader
-r--r--r--    1 root     sysadmin  1030147 May 29  2004 vmlinuz

weebotech@gatekeeper: /var/tftpboot > more default 
DEFAULT  local
IMPLICIT 1
PROMPT   1
DISPLAY  BOOTMSG.TXT
# TIMEOUT  300

LABEL local
        LOCALBOOT 0

LABEL floppy
        LOCALBOOT 0x00

LABEL harddrive
        LOCALBOOT 0x80

LABEL next     
        LOCALBOOT -1   

LABEL win98se 
    KERNEL memdisk
    APPEND initrd=images/win98se.img

LABEL win98se-bios
    KERNEL memdisk
    APPEND initrd=images/win98se-bios.img
...
There is more, but I cut it out.

a chunk in my dhcpd.conf file. 

host test.cotrone.com {
        hardware ethernet 00:02:b3:c0:bd:61;
        fixed-address 192.168.1.99;
        option routers 192.168.1.1;
        option domain-name-servers 192.168.1.253, 192.168.1.179;
        option domain-name "cotrone.com";
        filename "pxelinux.0";
}

 

 

 

 

Link to comment

In the unraid server I just built and is now running I installed an internal 120G EIDE Hard drive.  Almost every motherboard in the world will contain an IDE controller.

 

I Formatted the hdd to three internal partitions, Windows, Ubuntu and Ubuntu swap. I then set up GRUB as the boot loader.

 

In my BIOS I set as the boot order the following:  (1) CD-ROM (My raid case has a slim CD/DVD ROM drive; (2) USB Flash drive; (3) IDE HDD.  If there is no CD in the CD drive and the flash  memory is plugged in it boots unRaid (the normal case). If there is a CD in the drive it boots from that CD, and lastly if there is no CD in the drive and and the flash drive is not plugged in, then it boots from the hdd which is GRUB and gives me the choice of Win XP PRO or Ubuntu.  

Link to comment

[red]How the hell do you boot an Unraid system to DOS?[/red]

1. Download the syslinux package

http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-3.86.zip

2. Extract the memdisk file from that zip package.  Put memdisk on your unRAID flash disk.

3. Download FreeDOS.  Put the .iso file on your unRAID flash disk.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdbasecd.iso

4. Add a FreeDOS entry to the unRAID boot menu by adding these three lines to your syslinux.cfg (on your flash disk)

default menu.c32

menu title Lime Technology LLC

prompt 0

timeout 20

 

label unRAID OS

 menu default

 kernel bzimage

 append initrd=bzroot vga=5

 

label FreeDOS

 kernel memdisk

 append iso initrd=fdbasecd.iso

 

label Memtest86+

 kernel memtest

 

5. Download the firmware-flashing program, and put that too on your unRAID flash disk.

6. Reboot.  

7. From the boot menu select "FreeDOS".  Once in FreeDOS "Safe Mode", your flash disk will be seen as "C:"

8. Proceed with flashing, as instructed by Supermicro.

 

Note: You don't need to unplug your flash disk from your server.  All the steps above (except #7) can be done over the network.

 

The trick described above is not just for FreeDOS.  The same way you can boot from almost any bootable .iso file, just like as if you're booting from a real CD.  No need to burn the .iso to a CD first, or to even have a CDROM drive.

 

Link to comment
  • 4 months later...

Firmware 3.1.0.21 is now available here.

 

ftp://ftp.supermicro.com/driver/SAS/Marvell/MV8/Firmware/3.1.0.21/

 

Both my cards came with 3.1.0.15N. I have no idea what the difference is. As usual, flashing firmware is a bad idea unles you have a really good reason to do it. In this case I certainly don't know what that reason would be. I did some searching but could not find an explanation of the new firmware anywhere.

Link to comment
  • 1 month later...

I installed the .21 version of the firmware today.  Have been having very occasional errors that require a hard boot to recover from.

 

Not sure this firmware update will help or not.

 

Couple of notes:

 

1 - There is a backup option of the mvf command that allows you to backup the current version of the firmware.  (I did this just in case I wanted to revert).

 

2 - The new firmware is almost double the size of the old one.  Not sure what this means, but hope bigger is better.

 

The following is the problem I am seeing in my syslog.  It repeats about every 30 seconds.  I was not doing heavy I/O when this occurred, just testing unmenu/mymain enhancements.

 

Although the computer didn't lock up, powerdown, sync, and unRaid "stop" from emhttp all hung.  Poweroff would not take the machine down.  Eventually had to hit big red switch.

 

On reboot, one drive had been kicked from array.  Used trust procedure (32 parity errors right at the beginning).

 

Will report back if I see any recurrance.  Like I said, this has happened twice.  I have a P5B VM DO motherboard, an Adaptec 1430sa, and a Supermicro AOC-SASLP-MV8.

 

Nov 21 12:02:05 Tower kernel: sas: command 0xdecf0300, task 0xc3eb2a00, timed out: BLK_EH_NOT_HANDLED
Nov 21 12:02:05 Tower kernel: sas: Enter sas_scsi_recover_host
Nov 21 12:02:05 Tower kernel: sas: trying to find task 0xc3eb2a00
Nov 21 12:02:05 Tower kernel: sas: sas_scsi_find_task: aborting task 0xc3eb2a00
Nov 21 12:02:05 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1701:mvs_abort_task:rc= 5
Nov 21 12:02:05 Tower kernel: sas: sas_scsi_find_task: querying task 0xc3eb2a00
Nov 21 12:02:05 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1645:mvs_query_task:rc= 5
Nov 21 12:02:05 Tower kernel: sas: sas_scsi_find_task: task 0xc3eb2a00 failed to abort
Nov 21 12:02:05 Tower kernel: sas: task 0xc3eb2a00 is not at LU: I_T recover
Nov 21 12:02:05 Tower kernel: sas: I_T nexus reset for dev 0400000000000000
Nov 21 12:02:05 Tower kernel: sas: I_T 0400000000000000 recovered
Nov 21 12:02:05 Tower kernel: sas: --- Exit sas_scsi_recover_host
Nov 21 12:02:36 Tower kernel: sas: command 0xdecf0300, task 0xc3eb2a00, timed out: BLK_EH_NOT_HANDLED
Nov 21 12:02:36 Tower kernel: sas: Enter sas_scsi_recover_host
Nov 21 12:02:36 Tower kernel: sas: trying to find task 0xc3eb2a00
Nov 21 12:02:36 Tower kernel: sas: sas_scsi_find_task: aborting task 0xc3eb2a00
Nov 21 12:02:36 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1701:mvs_abort_task:rc= 5
Nov 21 12:02:36 Tower kernel: sas: sas_scsi_find_task: querying task 0xc3eb2a00
Nov 21 12:02:36 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1645:mvs_query_task:rc= 5
Nov 21 12:02:36 Tower kernel: sas: sas_scsi_find_task: task 0xc3eb2a00 failed to abort
Nov 21 12:02:36 Tower kernel: sas: task 0xc3eb2a00 is not at LU: I_T recover
Nov 21 12:02:36 Tower kernel: sas: I_T nexus reset for dev 0400000000000000
Nov 21 12:02:36 Tower kernel: sas: I_T 0400000000000000 recovered
Nov 21 12:02:36 Tower kernel: sas: --- Exit sas_scsi_recover_host
Nov 21 12:03:07 Tower kernel: sas: command 0xdecf0300, task 0xc4506280, timed out: BLK_EH_NOT_HANDLED
Nov 21 12:03:07 Tower kernel: sas: Enter sas_scsi_recover_host
Nov 21 12:03:07 Tower kernel: sas: trying to find task 0xc4506280
Nov 21 12:03:07 Tower kernel: sas: sas_scsi_find_task: aborting task 0xc4506280
Nov 21 12:03:07 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1701:mvs_abort_task:rc= 5
Nov 21 12:03:07 Tower kernel: sas: sas_scsi_find_task: querying task 0xc4506280
Nov 21 12:03:07 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1645:mvs_query_task:rc= 5
Nov 21 12:03:07 Tower kernel: sas: sas_scsi_find_task: task 0xc4506280 failed to abort
Nov 21 12:03:07 Tower kernel: sas: task 0xc4506280 is not at LU: I_T recover
Nov 21 12:03:07 Tower kernel: sas: I_T nexus reset for dev 0400000000000000
Nov 21 12:03:07 Tower kernel: sas: I_T 0400000000000000 recovered
Nov 21 12:03:07 Tower kernel: sas: --- Exit sas_scsi_recover_host
Nov 21 12:03:37 Tower kernel: sas: command 0xdecf0300, task 0xc3eb23c0, timed out: BLK_EH_NOT_HANDLED
Nov 21 12:03:37 Tower kernel: sas: Enter sas_scsi_recover_host
Nov 21 12:03:37 Tower kernel: sas: trying to find task 0xc3eb23c0
Nov 21 12:03:37 Tower kernel: sas: sas_scsi_find_task: aborting task 0xc3eb23c0
Nov 21 12:03:37 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1701:mvs_abort_task:rc= 5
Nov 21 12:03:37 Tower kernel: sas: sas_scsi_find_task: querying task 0xc3eb23c0
Nov 21 12:03:37 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1645:mvs_query_task:rc= 5
Nov 21 12:03:37 Tower kernel: sas: sas_scsi_find_task: task 0xc3eb23c0 failed to abort
Nov 21 12:03:37 Tower kernel: sas: task 0xc3eb23c0 is not at LU: I_T recover
Nov 21 12:03:37 Tower kernel: sas: I_T nexus reset for dev 0400000000000000
Nov 21 12:03:37 Tower kernel: sas: I_T 0400000000000000 recovered
Nov 21 12:03:37 Tower kernel: sas: --- Exit sas_scsi_recover_host

Link to comment

I have had two similar crashes in the last two days. The server still responds to pings, and is accessible via console, but it won't power down cleanly.

 

I already had the .21 firmware, so that isn't the fix.

 

Yep - look just like what happens here.  But only occasionally and not related to disk activity.

 

I did some research and think there are some issues with the SAS driver that are being addressed in later kernel releases.

Link to comment

I was having issues with crashes (running rc3 now), my problem seemed to go away after I followed a suggestion of ensuring proper power to my drives.  I have 3 of these cards in a system using a Norco 4224 case.  I was getting errors and crashes regularly and it was suggested that some drives may not be getting sufficient power (the backplane has two power connectors for each set of 4 drives, only one is needed according to Norco, but people have found that both should be connected).  If you don't have a Norco you probably have a different problem, but I thought I'd share just in case.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...