Adaptec AAC-364 RAID controller support
I see from the FreeBSD driver database at http://www.posi.net/freebsd/drivers that support for the Adaptec AAC-364 RAID controller (aka Dell PERC 2) has been proposed, but it is stalled waiting on documentation from Adaptec. For what it's worth, you can add us to the list of people who have these cards and would very much like to use them under FreeBSD. Is there someone at Adaptec I could contact to "encourage" them to release the documentation we require? At the very least, it might be worthwhile to let them know there's interest in using their cards with FreeBSD. Once the development is able to proceed, I'd be happy to lend a hand where possible, even if only to test development versions of the driver. We're currently running different arrays with: 1) DPT SmartRAID IV 2) AMI MegaRAID Enterprise 1200 3) Vinum (raid 10) The Adaptec card looks like it might provide a superior solution. What's best way to proceed when trying to get documentation support from vendors? -- Brad Chisholm SAS Institute, Inc. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
System crash on "vinum start"
I'm having a problem where the "vinum start" command crashes my system.
This happens regardless of whether it's being issued during bootup via
/etc/rc or from the command line on a running system.
Interestingly, however, if I issue the start command from the vinum
interactive prompt, it works properly with no crash.
I'm currently running on a snap built this morning (0924), but it was
also happening on a snap from 0914.
Crash info, vinum config, and disk info are below. Let me know if I
can provide any additional information.
Thanks,
Brad
# uname -a
FreeBSD 4.0-19990924-SNAP FreeBSD 4.0-19990924-SNAP #1: Fri Sep 24 15:49:04 EDT 1999
root@:/usr/src/sys/compile/PRISMDB i386
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 3878912
initial pcb at 332900
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x48
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018b64b
stack pointer = 0x10:0xc94f4bb0
frame pointer = 0x10:0xc94f4be0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 195 (vinum)
interrupt mask = bio
trap number = 12
panic: page fault
syncing disks... 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112
112 112 112 giving up
dumping to dev #wd/0x20001, offset 786432
dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108
107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53
52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
281 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
#1 0xc0169e80 in poweroff_wait (junk=0xc02fd44f, howto=-928026240)
at ../../kern/kern_shutdown.c:531
#2 0xc0272269 in trap_fatal (frame=0xc94f4b70, eva=72)
at ../../i386/i386/trap.c:907
#3 0xc0271f41 in trap_pfault (frame=0xc94f4b70, usermode=0, eva=72)
at ../../i386/i386/trap.c:800
#4 0xc0271beb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 512, tf_ebp = -917550112, tf_isp = -917550180, tf_ebx = 0,
tf_edx = 0, tf_ecx = 8, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072122293, tf_cs = 8, tf_eflags = 66118, tf_esp = -91755,
tf_ss = 512}) at ../../i386/i386/trap.c:426
#5 0xc018b64b in getblk (vp=0x0, blkno=8, size=4096, slpflag=0, slptimeo=0)
at ../../kern/vfs_bio.c:2109
#6 0xc018995a in bread (vp=0x0, blkno=8, size=4096, cred=0x0, bpp=0xc94f4c50)
at ../../kern/vfs_bio.c:477
#7 0xc0d65fcf in ?? ()
#8 0xc0d67072 in ?? ()
#9 0xc0d64e6d in ?? ()
#10 0xc0d64ec7 in ?? ()
#11 0xc0d6af94 in ?? ()
#12 0xc019dc47 in spec_ioctl (ap=0xc94f4e08)
at ../../miscfs/specfs/spec_vnops.c:513
#13 0xc019d4bd in spec_vnoperate (ap=0xc94f4e08)
at ../../miscfs/specfs/spec_vnops.c:124
#14 0xc023ef09 in ufs_vnoperatespec (ap=0xc94f4e08)
at ../../ufs/ufs/ufs_vnops.c:2313
#15 0xc0197f20 in vn_ioctl (fp=0xc0d29100, com=3288352320,
data=0xc0d59000 "read", p=0xc8af7180) at vnode_if.h:395
#16 0xc0176fcb in ioctl (p=0xc8af7180, uap=0xc94f4f80) at ../../sys/file.h:166
#17 0xc02724a6 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 5, tf_esi = -1077950456, tf_ebp = -1077949432,
tf_isp = -917549100, tf_ebx = 5, tf_edx = 134794277,
tf_ecx = -1077950407, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134659084, tf_cs = 31, tf_eflags = 582, tf_esp = -1077950488,
tf_ss = 47}) at ../../i386/i386/trap.c:1056
#18 0xc02654c6 in Xint0x80_syscall ()
#19 0x804cbc7 in ?? ()
#20 0x8048492 in ?? ()
#21 0x80482fd in ?? ()
#22 0x80480e9 in ?? ()
# vinum list
Configuration summary
Drives: 4 (8 configured)
Volumes:1 (4 configured)
Plexes: 1 (8 configured)
Subdisks: 4 (16 configured)
D d0State: up Device /dev/da0eAvail: 0/17366 MB (0%)
D d1State: up Device /dev/da1eAvail: 0/17366 MB (0%)
D d2State: up Device /dev/da2eAvail: 0/17366 MB (0%)
D d3State: up Device /dev/da3eAvail: 0/17366 MB (0%)
V raid5 State: up Plexes: 1 Size: 50 GB
P raid5.p0 R5 State: up Subdisks: 4 Size: 50 GB
S raid5.p0.s0 State: up PO:0 B Size: 16 GB
S raid5.p0.s1 State: up
Re: System crash on "vinum start"
> > I'm having a problem where the "vinum start" command crashes my system.
> > This happens regardless of whether it's being issued during bootup via
> > /etc/rc or from the command line on a running system.
> >
> > Interestingly, however, if I issue the start command from the vinum
> > interactive prompt, it works properly with no crash.
> >
> > I'm currently running on a snap built this morning (0924), but it was
> > also happening on a snap from 0914.
> >
> > Crash info, vinum config, and disk info are below. Let me know if I
> > can provide any additional information.
>
> Yes. Please read the instructions in vinum(4) about debugging panic
> dumps.
>
> I found a minor bug in 'vinum start' recently, but I doubt it's
> causing your problem. I'll commit it Real Soon Now.
>
Well, I believe I discovered the source of my problem. It turns out that
I did not have the correct devices configured in /dev for the component
drives. I had da[0-3]e, but not da[0-3]s1e. The documentation seemed to
indicate that the da?s1? devices were not required, but once I made them,
the crashes stopped.
It's interesting that I could bring the array up using the 'start'
command from the vinum interactive prompt, and things would work
properly with the missing devices, while issuing a direct 'vinum
start' would cause a panic.
Even though this may have been a stupid user error, it would be nice
if vinum could catch this without a system crash. To that end, I'm
including an updated traceback from my panic dump which has the vinum
calls included.
Thanks for providing such a useful piece of software!
-Brad
-- Crash dump traceback --
(kgdb) bt
#0 boot (howto=0x100) at ../../kern/kern_shutdown.c:281
#1 0xc0169e80 in poweroff_wait (junk=0xc02fd44f, howto=0xc8af7180) at
../../kern/kern_shutdown.c:531
#2 0xc0272269 in trap_fatal (frame=0xc94f4b70, eva=0x48) at ../../i386/i386/trap.c:907
#3 0xc0271f41 in trap_pfault (frame=0xc94f4b70, usermode=0x0, eva=0x48) at
../../i386/i386/trap.c:800
#4 0xc0271beb in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0x0,
tf_esi = 0x200,
tf_ebp = 0xc94f4be0, tf_isp = 0xc94f4b9c, tf_ebx = 0x0, tf_edx = 0x0, tf_ecx =
0x8, tf_eax = 0x0,
tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc018b64b, tf_cs = 0x8, tf_eflags =
0x10246, tf_esp = 0xc94f4c50,
tf_ss = 0x200}) at ../../i386/i386/trap.c:426
#5 0xc018b64b in getblk (vp=0x0, blkno=0x8, size=0x1000, slpflag=0x0, slptimeo=0x0)
at ../../kern/vfs_bio.c:2109
#6 0xc018995a in bread (vp=0x0, blkno=0x8, size=0x1000, cred=0x0, bpp=0xc94f4c50) at
../../kern/vfs_bio.c:477
#7 0xc0d65fcf in read_drive (drive=0xc0e28800, buf=0xc0e29000, length=0x2,
offset=0x1200)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:284
#8 0xc0d67072 in vinum_scandisk (devicename=0xc0d70b04, drives=0x5)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:959
#9 0xc0d64e6d in parse_config (cptr=0xc0d59000 "read", keyset=0xc0d709d0, update=0x0)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumconfig.c:1514
#10 0xc0d64ec7 in parse_user_config (cptr=0xc0d59000 "read", keyset=0xc0d709d0)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumconfig.c:1557
#11 0xc0d6af94 in vinumioctl (dev=0xc0d56480, cmd=0xc4004640, data=0xc0d59000 "read",
flag=0x3, p=0xc8af7180)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumioctl.c:110
#12 0xc019dc47 in spec_ioctl (ap=0xc94f4e08) at ../../miscfs/specfs/spec_vnops.c:513
#13 0xc019d4bd in spec_vnoperate (ap=0xc94f4e08) at
../../miscfs/specfs/spec_vnops.c:124
#14 0xc023ef09 in ufs_vnoperatespec (ap=0xc94f4e08) at ../../ufs/ufs/ufs_vnops.c:2313
#15 0xc0197f20 in vn_ioctl (fp=0xc0d29100, com=0xc4004640, data=0xc0d59000 "read",
p=0xc8af7180) at vnode_if.h:395
#16 0xc0176fcb in ioctl (p=0xc8af7180, uap=0xc94f4f80) at ../../sys/file.h:166
#17 0xc02724a6 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x5, tf_esi = 0xbfbfc808,
tf_ebp = 0xbfbfcc08, tf_isp = 0xc94f4fd4, tf_ebx = 0x5, tf_edx = 0x808cc25,
tf_ecx = 0xbfbfc839, tf_eax = 0x36,
tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x806bc0c, tf_cs = 0x1f, tf_eflags =
0x246, tf_esp = 0xbfbfc7e8,
tf_ss = 0x2f}) at ../../i386/i386/trap.c:1056
#18 0xc02654c6 in Xint0x80_syscall ()
#19 0x804cbc7 in ?? ()
#20 0x8048492 in ?? ()
#21 0x80482fd in ?? ()
#22 0x80480e9 in ?? ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
