gmane.os.netbsd.ports.i386

ahc hangs when booting NetBSD 6.1 on old SMP machine (PCD-5T)

Felix Deichmann — 2013-05-19T18:37:49

Hi,

I took my Siemens-Nixdorf PCD-5T (dual Pentium 100, EISA and PCI) out
of its long sleep (sorry I didn't have the time earlier before 6.1).
Around 10 years ago, NetBSD 2.0 with SMP panicked because of a not yet
implemented SMP variant (see PR #26366). This seems to be implemented
now, but I still have no luck booting this nice machine with SMP and
NetBSD 6.1...

An Adaptec AHA-2940 PCI adapter seems to be the problem. The machine
hangs after a "card dump".
I also have an Adaptec AHA-2740/42W for EISA bus, which gives a
similar "card dump" like the PCI adapter (I first thought the EISA
adapter or EISA-specific driver part was to blame, but no)!

When booting the machine with SMP disabled (boot -1), everything seems fine.

dmesg dumps for SMP and non-SMP boots follow... Would be great to have
NetBSD running on this machine finally after such a long time of
waiting ;) Any clue?

Regards
Felix


==================== SMP ====================
[...]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 6.1 (GENERIC)
total memory = 127 MB
avail memory = 112 MB
mainbus0 (root)
mainbus0: MP default configuration 6
acpi_probe: failed to initialize tables
mainbus0: Intel MP Specification (Version 1.1)
mainbus0: MP default configuration 6
cpu0 at mainbus0 apid 0: Intel 586-class, 80MHz, id 0x526
cpu1 at mainbus0 apid 1: Intel 586-class, id 0x2526
ioapic0 at mainbus0 apid 0
pci0 at mainbus0 bus 0: configuration mode 2
pchb0 at pci0 dev 0 function 0: vendor 0x8086 product 0x04a3 (rev. 0x11)
pceb0 at pci0 dev 1 function 0
pceb0: vendor 0x8086 product 0x0482 (rev. 0x05)
pciide0 at pci0 dev 2 function 0: vendor 0x1042 product 0x1000 (rev. 0x01)
pciide0: I/O access disabled at device
ahc1 at pci0 dev 13 function 0: Adaptec 2940 SCSI adapter
ahc1: interrupting at irq 14
ahc1: aic7870: Single Channel A, SCSI Id=7, 16/253 SCBs
scsibus0 at ahc1: 8 targets, 8 luns per target
epic0 at pci0 dev 15 function 0: SMC 83c170 Fast Ethernet (rev. 0x08)
epic0: interrupting at irq 15
epic0: SMC9432TX, Ethernet address 00:e0:29:45:a6:85
qsphy0 at epic0 phy 3: QS6612 10/100 media interface, rev. 1
qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
eisa0 at pceb0
eisa0: can't map I/O space for slot 14
isa0 at pceb0
lpt0 at isa0 port 0x378-0x37b irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
attimer0 at isa0 port 0x40-0x43
vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
wsdisplay0 at vga0 kbdmux 1
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
isapnp0 at isa0 port 0x279
npx0 at isa0 port 0xf0-0xff
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
attimer0: attached to pcppi0
scsibus0: waiting 2 seconds for devices to settle...
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
ahc1:SCB 0xf - timed out
ahc1: Dumping Card State in Message-out phase, at SEQADDR 0x14e
Card was paused
ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xc0, ARG_2 = 0x3
HCNT = 0x0 SCBPTR = 0x0
SCSISIGI[0xb6] ERROR[0x0] SCSIBUSL[0x1] LASTPHASE[0xa0]
SCSISEQ[0x12] SBLKCTL[0x0] SCSIRATE[0x0] SEQCTL[0x10]
SEQ_FLAGS[0x40] SSTAT0[0x7] SSTAT1[0x3] SSTAT2[0x0]
SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xac] SXFRCTL0[0x88]
DFCNTRL[0x4] DFSTATUS[0x6d]
STACK: 0xca 0x0 0x0 0x178
SCB count = 16
Kernel NEXTQSCB = 14
Card NEXTQSCB = 14
QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sequencer SCB Info:
  0 SCB_CONTROL[0x40] SCB_SCSIID[0x7]
SCB_LUN[0x0] SCB_TAG[0xf]
  1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
Pending list:
 15 SCB_CONTROL[0x40] SCB_SCSIID[0x7]
SCB_LUN[0x0]
Kernel Free SCB list: 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Untagged Q(0): 15

<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
sg[0] - Addr 0x7e50c86 : Length 36
ahc1:BDR message in message buffer
ahc1:SCB 0xf - timed out
ahc1: Dumping Card State in Message-out phase, at SEQADDR 0x14e
Card was paused
ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xc0, ARG_2 = 0x3
HCNT = 0x0 SCBPTR = 0x0
SCSISIGI[0xb6] ERROR[0x0] SCSIBUSL[0x3] LASTPHASE[0xa0]
SCSISEQ[0x12] SBLKCTL[0x0] SCSIRATE[0x0] SEQCTL[0x10]
SEQ_FLAGS[0x40] SSTAT0[0x7] SSTAT1[0x3] SSTAT2[0x0]
SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xac] SXFRCTL0[0x88]
DFCNTRL[0x4] DFSTATUS[0x6d]
STACK: 0xca 0x0 0x0 0x178
SCB count = 16
Kernel NEXTQSCB = 14
Card NEXTQSCB = 14
QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sequencer SCB Info:
  0 SCB_CONTROL[0x40] SCB_SCSIID[0x7]
SCB_LUN[0x0] SCB_TAG[0xf]
  1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
  9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
SCB_LUN[0xff] SCB_TAG[0xff]
Pending list:
 15 SCB_CONTROL[0x40] SCB_SCSIID[0x7]
SCB_LUN[0x0]
Kernel Free SCB list: 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Untagged Q(0): 15

<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
sg[0] - Addr 0x7e50c86 : Length 36
probe(ahc1:0:0:0): ahc1: no longer in timeout, status = 0
ahc1: Issued Channel A Bus Reset. 1 SCBs aborted


==================== non-SMP ====================
[...]
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 6.1 (GENERIC)
total memory = 127 MB
avail memory = 112 MB
mainbus0 (root)
acpi_probe: failed to initialize tables
cpu0 at mainbus0: Intel 586-class, 100MHz, id 0x526
pci0 at mainbus0 bus 0: configuration mode 2
pchb0 at pci0 dev 0 function 0: vendor 0x8086 product 0x04a3 (rev. 0x11)
pceb0 at pci0 dev 1 function 0
pceb0: vendor 0x8086 product 0x0482 (rev. 0x05)
pciide0 at pci0 dev 2 function 0: vendor 0x1042 product 0x1000 (rev. 0x01)
pciide0: I/O access disabled at device
ahc1 at pci0 dev 13 function 0: Adaptec 2940 SCSI adapter
ahc1: interrupting at irq 14
ahc1: aic7870: Single Channel A, SCSI Id=7, 16/253 SCBs
scsibus0 at ahc1: 8 targets, 8 luns per target
epic0 at pci0 dev 15 function 0: SMC 83c170 Fast Ethernet (rev. 0x08)
epic0: interrupting at irq 15
epic0: SMC9432TX, Ethernet address 00:e0:29:45:a6:85
qsphy0 at epic0 phy 3: QS6612 10/100 media interface, rev. 1
qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
eisa0 at pceb0
eisa0: can't map I/O space for slot 14
isa0 at pceb0
lpt0 at isa0 port 0x378-0x37b irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
attimer0 at isa0 port 0x40-0x43
vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
wsdisplay0 at vga0 kbdmux 1
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
isapnp0 at isa0 port 0x279
npx0 at isa0 port 0xf0-0xff
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
attimer0: attached to pcppi0
scsibus0: waiting 2 seconds for devices to settle...
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
sd0 at scsibus0 target 0 lun 0: <IBM, DCAS-32160, S65A> disk fixed
sd0: 2046 MB, 8188 cyl, 3 head, 170 sec, 512 bytes/sect x 4192000 sectors
sd0: sync (100.00ns offset 15), 8-bit (10.000MB/s) transfers, tagged queueing
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs
Sun May 19 23:20:28 CEST 2013
[...]

Re: Changing the default i387 precision

Dennis Ferguson — 2013-05-13T05:00:11

On 6 May, 2013, at 04:59 , Greg Troxel <gdt< at >ir.bbn.com> wrote:

I don't know what this is about but it is quite possible that what
you are seeing are symptoms of the problem the x87 precision change
he wants to make will fix.  The behaviour of long double arithmetic
on NetBSD at run time matches neither the description of the type
in <float.h> or the assumptions of NetBSD compilers (gcc and clang,
at least).  The compilation environment assumes that arithmetic
in the long double type behaves like the IEEE754 10-byte extended format,
but the actual run time behaviour of this type does not for either of
the x86 architectures.

For amd64 this problem is only a problem for programs which actually
use the long double type.  For the default i386 behaviour, however,
this problem effects all floating point arithmetic since on the i386
all floating point arithmetic is explicitly evaluated with long double
precision, so the fact that long double is broken potentially effects
everything.


Without wanting to put words in his mouth I suspect a good goal might be
basic C99 compliance (I would even say C89 compliance, since long
double was required by that standard as well, but I no longer have
a copy so I don't know exactly what was required).  Support for the
long double type isn't optional, portable programs can rely on its
existence.  The C ABIs for both i386 and amd64 specify that the long
double type for those architectures is the 80-bit IEEE754 extended format,
and while NetBSD's long double looks like that too, its run time arithmetic
in the type does not behave like that IEEE754 format.  The latter is not
a problem for C99 compliance since C99 (prefers but) doesn't require
IEEE754 behaviour.  What is required by C99, however, is that <float.h>
describe the actual behaviour of the type, but on NetBSD it does not.
LDBL_EPSILON claims a precision more than 3 orders of magnitude better
than the run time math delivers, while LDBL_MIN, LDBL_MAX, LDBL_MIN_EXP
and LDBL_MAX_EXP are probably all similar lies.  C99 also requires that
the compiler evaluate constant expressions in a way which produces the
same result that a run time evaluation of the same expression would,
but since gcc and clang both apparently believe that long double math
is done with the full precision of the 80-bit format compile time
math produces different results than run time math.

This is broken.  Either <float.h> and the compilers need to be changed
to match the run time behaviour of the type, or NetBSD's run time behaviour
needs to be changed to match the assumptions of the compile environment.

There's one other interesting manifest constant defined in <float.h>,
that being FLT_EVAL_METHOD.  The C standard (section 5.2.4.2.2 in the
2005 draft I'm looking at) describes it thus:

  8 The values of operations with floating operands and values subject
    to the usual arithmetic conversions and of floating constants are
    evaluated to a format whose range and precision may be greater than
    required by the type. The use of evaluation formats is characterized
    by the implementation-defined value of FLT_EVAL_METHOD:

    -1 indeterminable;

    0 evaluate all operations and constants just to the range and precision
      of the type;

    1 evaluate operations and constants of type float and double to the range
      and precision of the double type, evaluate long double operations and
      constants to the range and precision of the long double type;

    2 evaluate all operations and constants to the range and precision of
      the long double type.

For amd64, the compiler sets FLT_EVAL_METHOD to 0 (it has SSE instructions).
Assuming this isn't a lie this means that the problem with long double only
effects programs which explicitly use long double.  It also should mean that
changing the x87 precision will fix the long double problem but have no effect
on existing programs which don't use the type.  This is a no-brainer change,
it should just be fixed.

For i386, unfortunately, the default compilation sets FLT_EVAL_METHOD to
2.  Since all math in all three floating point types is evaluated with long
double precision this means the compilers potentially screw up constant
expression evaluation (at least) for all floating point types (and if you look
at the paranoia.c program you may notice there is quite a bit in there that can
be done at compile time by a good compiler; with a FLT_EVAL_METHOD of 2, however,
anything computed by the compiler in any of the 3 types may be inconsistent with
the NetBSD run time behaviour).  Since everything is potentially screwed up here I
think it is even more imperative that this be fixed, either by making the compilers
and environment match the actual run time behaviour or by making the run time
behaviour match the expectations of the compiler, and of these choices changing
the x87 precision seems like the best thing to do as well.  It is way easier
than diddling the compilers, it provides an IEEE754-compliant long double type
and it makes match what some of the bigger users of those compilers (e.g.
Linux and FreeBSD) already do.  This should get done as well.

Note that Apple compilers set FLT_EVAL_METHOD to 0 on i386.  Apple can do this
since they've never shipped a product with an Intel CPU which lacked SSE
instructions.  NetBSD's default binaries, on the other hand, should run even on
CPUs too old to have SSE instructions, so NetBSD's compilers have no default
choice other than to do all floating point math with the x87.  Apple also
apparently uses a non-standard ABI for the i386 (I know sizeof(long double)
there is 16, while the standard ABI document says it should be 12), another
thing that NetBSD probably shouldn't do.

Finally, just to be clear, the fact that the i386 does type-promoted floating
point expression evaluation (except when compiled with -ffloat-store, probably)
is not a bug, is explicitly allowed by the C standard, and says nothing about
IEEE754 compliance or lack thereof.  If anything it is something of a feature if
it isn't cost anything, and if you are forced to use x87 instructions for
arithmetic it actually doesn't cost anything you aren't already paying.  If you
skip to the bottom of this essay

    http://www.cs.berkeley.edu/~wkahan/LOG10HAF.TXT

you'll see

    I wish the makers of  MATLAB,  recalling their roots,  would rededicate
    attention to their numerical underpinnings.  Among improvements needed:

          Declarable  4-byte,  8-byte  and  (10 or 16)-byte  variables   *
          but use old  Kernighan-Ritchie C  rather than  Java/Fortran
          rules for expression-evaluation.

Note that the difference he's drawing in the last bit relates to the fact
that Java and Fortran require that all floating point operations be done
with the precision of the type (i.e. a FLT_EVAL_METHOD of 0) while K&R C
did type-promoted floating point arithmetic exclusively (i.e. a FLT_EVAL_METHOD
of 1 or 2; they're probably equivalent in this context since K&R C had no
long double); he's asking for MATLAB to do type-promoted arithmetic.  He also
seems to think that having a working extended floating point format is useful.
The author, William Kahan, was primarily responsible for the design of IEEE754
and I think was an original author of paranoia.c.

The only problem i386/amd64 NetBSD has with IEEE754 compliance is the
behaviour of its long double type (since you express concern about the
former I don't know why you don't seem concerned about the latter).  I
think the problems with NetBSD C floating point have nothing to do with
IEEE754 compliance and everything to do with the difference between how the
compiler environment expects long double math to behave and how it actually
behaves at run time; for the i386 this problem may infect all floating
point arithmetic.  I believe both these things can be usefully fixed by
changing the x87 precision, and I don't think you should have to call a
non-standard, platform-specific function to fix it.  I think the x87
default should change, the function can be used by people who think there's
something good about the current behaviour (though I can't imagine what
that would be).

Dennis Ferguson

savecore: kvm_read: Bad address

Ray Phillips — 2013-05-08T07:46:58

I built a NetBSD/i386 6.0.1 system, then typed Ctl-Alt-Esc and typed 
`sync' at the db{0}> prompt.  dump succeeded but on the next reboot 
savecore produced errors, as shown below from /var/log/messages:

May  7 18:42:23 ct /netbsd: root on raid0a dumps on raid0b
May  7 18:42:23 ct /netbsd: /: replaying log to memory
May  7 18:42:23 ct /netbsd: root file system type: ffs
May  7 18:42:23 ct /netbsd: /: replaying log to disk
May  7 18:42:23 ct /netbsd: wsdisplay0: screen 1 added (80x25, vt100 emulation)
May  7 18:42:23 ct /netbsd: wsdisplay0: screen 2 added (80x25, vt100 emulation)
May  7 18:42:23 ct /netbsd: wsdisplay0: screen 3 added (80x25, vt100 emulation)
May  7 18:42:23 ct /netbsd: wsdisplay0: screen 4 added (80x25, vt100 emulation)
May  7 18:42:24 ct savecore: reboot after panic: dump forced via 
kernel debugger
May  7 18:42:24 ct savecore: system went down at Tue May  7 18:41:00 2013
May  7 18:42:24 ct savecore: writing compressed core to 
/var/crash/netbsd.1.core.gz
May  7 18:42:34 ct savecore: writing compressed kernel to 
/var/crash/netbsd.1.gz
May  7 18:42:34 ct savecore: kvm_read: kvm_read: Bad address
May  7 18:42:34 ct savecore: (null): Bad address

and /var/run/rc.log:

[failures]
The following components reported failures:
     /etc/rc.d/savecore
See /var/run/rc.log for more information.
[/etc/rc finished at Tue May  7 18:42:42 EST 2013]
[/etc/rc exiting with status 0]

The compressed core file in /var/crash tests OK, but not the compressed kernel:

# gzip -vt netbsd.1.*z
netbsd.1.core.gz:         OK
gzip: netbsd.1.gz: unexpected end of file
gzip: netbsd.1.gz: uncompress failed
netbsd.1.gz:      NOT OK
#

This seems like a potentially serious problem but I don't know how to 
fix it.  I've deleted the disk and reinstalled NetBSD and also tried 
on two other PCs with different disks but it's still happens, so I 
suspect I'm causing it somehow.

When installing NetBSD I used sysinst's suggested size for the swap 
partition--the same as the amount of RAM in the machines.  I believe 
the disks I used are healthy and they had plenty of free space.  Can 
anyone offer some guidance, please?


Ray

Re: Changing the default i387 precision

Greg Troxel — 2013-05-06T11:59:14

Joerg Sonnenberger <joerg< at >britannica.bec.de> writes:


I think that by default, programs should get behavior compliant with
IEEE754.

Anyone interesting in numerical issues should run
pkgsrc/benchmarks/paranoia, if they haven't already.  My impression is
that this program is widely viewed as the gold standard for correctness
of floating point implementations, and probably we ought to bring it
into our regression test framework.

On netbsd-6/i386 (and netbsd-5), the result is:

  No failures, defects nor flaws have been discovered.
  Rounding appears to conform to the proposed IEEE standard P754,
  except for possibly Double Rounding during Gradual Underflow.
  The arithmetic diagnosed appears to be Excellent!

I get that also on netbsd-5/amd64.  Note that paranoia in pkgsrc has
-ffloat-store.  When removing -ffloat-store on netbsd-5/amd64, the
results are still ok (presumably because of SSE).

When removing -ffloat-store on netbsd-6/i386 (and netbsd-5),
paranoia complains about many things.

On an intel mac (Core 2 Duo, 10.7), building i386 binaries (from pkgsrc
bootstrapped with -m32), the right answer is obtained with or without
float-store.


So it seems we don't set the default precision right on i386 as it
is, and that should be fixed.

I'm not really sure what your goal is.  I can see the appeal of having
"long double" have greater precision, but I think it's far more
important to have IEEE754-compliant behavior for programs that don't try
to set anything.   Can't a user set rounding/precision modes
intentionally if they are a long double user?

Re: FFSv2 vs FFSv1

Michael van Elst — 2013-05-05T18:03:22



You need a FFSv2 formatted superblock.



fsck_ffs(8) gives at least an overview.

FFS1 level 0 = inode 4.2/4.3BSD static table
FFS1 level 1 = dynamic table
FFS1 level 2 = 32bit UID/GID, compact symlinks
FFS1 level 3 = free segment maps
FFS1 level 4 = FFS2 style superblock (allows WAPBL)

FFS2 level 5 = 64bit addresses, 64bit timestamps, birthtime, ext attributes

If you format a new filesystem the default is now level 4 for FFS1
and level 5 for FFS2. I.e. the filesystem supports WAPBL.

If you have formatted a filesystem with an older NetBSD with level 3
then you can use fsck_ffs to upgrade the superblock and reach level 4.



dumpfs -s reports

| % dumpfs -s  /
| file system: /dev/rwd0a
| format  FFSv1
          ^ the filesystem format
| endian  little-endian
| magic   11954           time    Sun May  5 12:46:08 2013
| superblock location     8192    id      [ 4961db97 41fb0303 ]
| cylgrp  dynamic inodes  4.4BSD  sblock  FFSv2   fslevel 4
          ^ table format  ^ inode format  |       ^ the filesystem level
                                          ^ the superblock format

Older dumpfs -s show

% dumpfs -s /
file system: /dev/rraid0a
endian  little-endian
magic   11954 (UFS1)    time    Sun May  5 08:46:18 2013
               ^ the filesytem format
superblock location     8192    id      [ 441b1c12 2ebf670a ]
cylgrp  dynamic inodes  4.4BSD  sblock  FFSv2   fslevel 4
        ^ table format  ^ inode format  |       ^ the filesystem level
                                        ^ the superblock format

% dumpfs -s /d/0
file system: /dev/rraid1a
endian  little-endian
location 65536  (-b 128)
magic   19540119 (UFS2) time    Sun Apr  7 07:48:33 2013
                  ^ the filesytem format
superblock location     65536   id      [ 44133e26 3278a162 ]
cylgrp  dynamic inodes  FFSv2   sblock  FFSv2   fslevel 5
        ^ table format  ^ inode format  |       ^ the filesystem level
                                        ^ the superblock format

Re: FFSv2 vs FFSv1

Adrian Steinmann — 2013-05-05T14:09:02

as is mentioned in man installboot. I'll mention both in the handbook.
I thought file -s /dev/rwd0e was kinda cool ;-)

Ast

Re: FFSv2 vs FFSv1

Marc Balmer — 2013-05-05T13:31:08

Am 05.05.13 10:08, schrieb Ryo ONODERA:

And then there is also the dumpfs command, which shows the filesystem
type in its output.

Re: FFSv2 vs FFSv1

Adrian Steinmann — 2013-05-05T09:34:19

Yes

The installboot(8) manual page
http://netbsd.gw.com/cgi-bin/man-cgi?installboot++NetBSD-current
also mentions in the examples that Pre NetBSD 6.0 systems amd/i386
defaulted to FFSv1 so it's imortant to make sure one is installing
the correct ones, for which dumpfs(8) can be used.

If you file a PR I can see that
http://www.netbsd.org/docs/guide/en/chap-rf.html#chap-rf-setup-filesystems
gets some additional warnings regarding the FFSv1/v2 transition
pre/post NetBSD 6.0 on amd/i386.

Adrian

Re: FFSv2 vs FFSv1

Ryo ONODERA — 2013-05-05T08:08:23

Hi,

From: Ray Phillips <r.phillips< at >uq.edu.au>, Date: Sun, 5 May 2013 18:02:43 +1000


# file -s /dev/rwd0e
/dev/rwd0e: Unix Fast File system [v2] (little-endian) last mounted on /usr, last written at Sun May  5 08:05:50 2013, clean flag 2, readonly flag 0, number of blocks 20480040, number of data blocks 19855038, number of cylinder groups 217, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 5, TIME optimization

This example is done on NetBSD/amd64 current.
I believe "Unix Fast File system [v2]" means FFSv2.

--
Ryo ONODERA // ryo_on< at >yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

FFSv2 vs FFSv1

Ray Phillips — 2013-05-05T08:02:43

I noticed that 6.0.1's sysinst uses FFSv2 for the / file system, even 
on a 20 GB disk.

Is it true that FFSv2 is needed for WAPBL?

Is there a Web page or document somewhere that details the 
differences between FFSv1 and FFSv2?

I suppose references to FFSv1 in The Guide  Chapter 16. NetBSD 
RAIDframe  should be replaced with FFSv2, such as in 16.3.6:

Next, format the newly created / partition as a 4.2BSD FFSv2 File System:

# newfs -O 2 /dev/rraid0a

and 16.3.7 should say to install the FFSv2 boot loader:

On i386, install the boot loader into /dev/rwd1a:

# /usr/sbin/installboot -o timeout=30 -v /dev/rwd1a /usr/mdec/bootxx_ffsv2

Correct?

What's the most convenient way of seeing if an existing partition is 
FFSv1 or v2?


Ray

Re: Changing the default i387 precision

Martin Husemann — 2013-05-04T19:06:55

Precision, not rounding, right?

I.e. you are not talking about fpsetround() but the precision flags
that are also part of the i386 controll word (en_cw in struct env87)
and you want to change the __NetBSD_NPXCW__ value, which is assigned
to that in setregs(), so each new process starts with this setting.

My i387 fu is too weak to understand the full implications this has
for operations on the various length float/double/long double values
at the C level, could you please elaborate those a bit?

Thanks,

Martin

Re: Changing the default i387 precision

Greg Troxel — 2013-05-04T16:33:08

Joerg Sonnenberger <joerg< at >britannica.bec.de> writes:


I still cannot follow exactly what you are proposing to change.

Re: Changing the default i387 precision

Joerg Sonnenberger — 2013-05-04T13:31:07

Works fine here, besides, you are forcing a slower code path that
explicitly is known to have this problems. See also the options I
mentioned in the other mail. GCC decided against enabling them by
default because all the Phoronix folks and the like would complain
about the performance penalty associated with it...

Joerg

Re: Changing the default i387 precision

Matthias Drochner — 2013-05-04T13:02:41

On Sat, 4 May 2013 08:50:29 -0400
Greg Troxel <gdt< at >ir.bbn.com> wrote:

Here is a little test program which still fails on Linux/x86_64
(gcc 4.6.3) if compiled with -mfpmath=387 -O2.
So it is still the sad fact that you can't have full "long double"
support without compromising "double" accuracy. At least with gcc.
Would be interesting to see how clang does.

best regards
Matthias

Re: Changing the default i387 precision

Joerg Sonnenberger — 2013-05-04T11:53:01

That's already the case. long double computations always use the i387.
The point is that I want them to get the extended precision.


That is also somewhat independent and necessary for full C++11 support,
but with the current way it is almost useless as the only benefit is a
wider exponent range.

Joerg

Re: x86 pcitag_t change proposal/patch

David Young — 2013-04-30T18:46:25

Perhaps it is more complicated, but we may end up with more than one
chipset tag per domain, anyway.  Each domain will have some resources,
such as physical address regions, that need to be managed independently.
You can bundle all of those resources (and the methods for using them)
into the chipset tag.

Dave

Re: x86 pcitag_t change proposal/patch

Jonathan A. Kollasch — 2013-04-26T14:45:12

Oh, and here's the patch this time.
Index: sys/arch/x86/include/pci_machdep_common.h
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/include/pci_machdep_common.h,v
retrieving revision 1.11
diff -d -u -a -p -r1.11 pci_machdep_common.h
--- sys/arch/x86/include/pci_machdep_common.h9 Dec 2012 21:30:02 -00001.11
+++ sys/arch/x86/include/pci_machdep_common.h26 Apr 2013 13:20:02 -0000
< at >< at > -47,26 +47,24 < at >< at >
  *
  * Configuration tag; created from a {bus,device,function} triplet by
  * pci_make_tag(), and passed to pci_conf_read() and pci_conf_write().
- * We could instead always pass the {bus,device,function} triplet to
- * the read and write routines, but this would cause extra overhead.
- *
- * Mode 2 is historical and deprecated by the Revision 2.0 specification.
- *
- *
- * Mode 1 tag:
- * 31              24           16 15     11 10  8
- *+---------------------------------------------------------------+
- *|1|      0      |      BUS      |   DEV   |FUNC |       0       |
- *+---------------------------------------------------------------+
  */
-union x86_pci_tag_u {
-uint32_t mode1;
-struct {
-uint16_t port;
-uint8_t enable;
-uint8_t forward;
-} mode2;
-};
+
+#define X86_PCITAG_FUNC_BITS((uint32_t)__BITS( 2, 0))
+#define X86_PCITAG_DEV_BITS((uint32_t)__BITS( 7, 3))
+#define X86_PCITAG_DEVFUNC_BITS((uint32_t)__BITS( 7, 0))
+#define X86_PCITAG_BUS_BITS((uint32_t)__BITS(15, 8))
+#define X86_PCITAG_BDF_BITS((uint32_t)__BITS(15, 0))
+
+#define X86_PCITAG_FUNC(tag)__SHIFTOUT(tag, X86_PCITAG_FUNC_BITS)
+#define X86_PCITAG_DEV(tag)__SHIFTOUT(tag, X86_PCITAG_DEV_BITS)
+#define X86_PCITAG_DEVFUNC(tag)__SHIFTOUT(tag, X86_PCITAG_DEVFUNC_BITS)
+#define X86_PCITAG_BUS(tag)__SHIFTOUT(tag, X86_PCITAG_BUS_BITS)
+#define X86_PCITAG_BDF(tag)__SHIFTOUT(tag, X86_PCITAG_BDF_BITS)
+
+#define X86_PCITAG_MAKE(b, d, f) \
+    ((pcitag_t)(__SHIFTIN(f, X86_PCITAG_FUNC_BITS) | \
+__SHIFTIN(d, X86_PCITAG_DEV_BITS) | \
+__SHIFTIN(b, X86_PCITAG_BUS_BITS)))
 
 extern struct x86_bus_dma_tag pci_bus_dma_tag;
 #ifdef _LP64
< at >< at > -80,7 +78,7 < at >< at > struct pci_chipset_tag;
  * Types provided to machine-independent PCI code
  */
 typedef struct pci_chipset_tag *pci_chipset_tag_t;
-typedef union x86_pci_tag_u pcitag_t;
+typedef uint32_t pcitag_t;
 
 struct pci_chipset_tag {
 pci_chipset_tag_t pc_super;
Index: sys/arch/x86/pci/pci_machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/pci/pci_machdep.c,v
retrieving revision 1.56
diff -d -u -a -p -r1.56 pci_machdep.c
--- sys/arch/x86/pci/pci_machdep.c1 Mar 2012 20:16:27 -00001.56
+++ sys/arch/x86/pci/pci_machdep.c26 Apr 2013 13:20:02 -0000
< at >< at > -174,10 +174,20 < at >< at > struct pci_bridge_hook_arg {
 #definePCI_MODE2_ENABLE_REG0x0cf8
 #definePCI_MODE2_FORWARD_REG0x0cfa
 
-#define _tag(b, d, f) \
-{.mode1 = PCI_MODE1_ENABLE | ((b) << 16) | ((d) << 11) | ((f) << 8)}
+#define MODE2_SELECTOR_ENABLE_BITS((uint32_t)__BITS( 7, 0))
+#define MODE2_SELECTOR_FORWARD_BITS((uint32_t)__BITS(15, 8))
+
+#define MODE2_SELECTOR_ENABLE(sel) \
+__SHIFTOUT(sel, MODE2_SELECTOR_ENABLE_BITS)
+#define MODE2_SELECTOR_FORWARD(sel) \
+__SHIFTOUT(sel, MODE2_SELECTOR_FORWARD_BITS)
+
+#define MODE2_SELECTOR_COMPOSE(enab, forw) \
+(__SHIFTIN(enab, MODE2_SELECTOR_ENABLE_BITS) | \
+__SHIFTIN(forw, MODE2_SELECTOR_FORWARD_BITS))
+
 #define _qe(bus, dev, fcn, vend, prod) \
-{_tag(bus, dev, fcn), PCI_ID_CODE(vend, prod)}
+{X86_PCITAG_MAKE(bus, dev, fcn), PCI_ID_CODE(vend, prod)}
 const struct {
 pcitag_t tag;
 pcireg_t id;
< at >< at > -201,7 +211,6 < at >< at > const struct {
 /* VIA Technologies VX900 */
 _qe(0, 0, 0, PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VX900_HB)
 };
-#undef _tag
 #undef _qe
 
 /*
< at >< at > -316,18 +325,12 < at >< at > pci_conf_unlock(struct pci_conf_lock *oc
 static uint32_t
 pci_conf_selector(pcitag_t tag, int reg)
 {
-static const pcitag_t mode2_mask = {
-.mode2 = {
-  .enable = 0xff
-, .forward = 0xff
-}
-};
-
 switch (pci_mode) {
 case 1:
-return tag.mode1 | reg;
+return PCI_MODE1_ENABLE | (X86_PCITAG_BDF(tag) << 8) | reg;
 case 2:
-return tag.mode1 & mode2_mask.mode1;
+return MODE2_SELECTOR_COMPOSE(
+    0xf0 | (X86_PCITAG_FUNC(tag) << 1), X86_PCITAG_BUS(tag));
 default:
 panic("%s: mode not configured", __func__);
 }
< at >< at > -340,7 +343,7 < at >< at > pci_conf_port(pcitag_t tag, int reg)
 case 1:
 return PCI_MODE1_DATA_REG;
 case 2:
-return tag.mode2.port | reg;
+return 0xc000 | (X86_PCITAG_DEV(tag) << 8) | reg;
 default:
 panic("%s: mode not configured", __func__);
 }
< at >< at > -349,17 +352,16 < at >< at > pci_conf_port(pcitag_t tag, int reg)
 static void
 pci_conf_select(uint32_t sel)
 {
-pcitag_t tag;
 
 switch (pci_mode) {
 case 1:
 outl(PCI_MODE1_ADDRESS_REG, sel);
 return;
 case 2:
-tag.mode1 = sel;
-outb(PCI_MODE2_ENABLE_REG, tag.mode2.enable);
-if (tag.mode2.enable != 0)
-outb(PCI_MODE2_FORWARD_REG, tag.mode2.forward);
+outb(PCI_MODE2_ENABLE_REG, MODE2_SELECTOR_ENABLE(sel));
+if (MODE2_SELECTOR_ENABLE(sel) != 0)
+outb(PCI_MODE2_FORWARD_REG,
+    MODE2_SELECTOR_FORWARD(sel));
 return;
 default:
 panic("%s: mode not configured", __func__);
< at >< at > -399,7 +401,6 < at >< at > pcitag_t
 pci_make_tag(pci_chipset_tag_t pc, int bus, int device, int function)
 {
 pci_chipset_tag_t ipc;
-pcitag_t tag;
 
 for (ipc = pc; ipc != NULL; ipc = ipc->pc_super) {
 if ((ipc->pc_present & PCI_OVERRIDE_MAKE_TAG) == 0)
< at >< at > -408,25 +409,11 < at >< at > pci_make_tag(pci_chipset_tag_t pc, int b
     pc, bus, device, function);
 }
 
-switch (pci_mode) {
-case 1:
-if (bus >= 256 || device >= 32 || function >= 8)
-panic("%s: bad request", __func__);
-
-tag.mode1 = PCI_MODE1_ENABLE |
-    (bus << 16) | (device << 11) | (function << 8);
-return tag;
-case 2:
-if (bus >= 256 || device >= 16 || function >= 8)
-panic("%s: bad request", __func__);
+KASSERT(bus < 256);
+KASSERT(device < 32);
+KASSERT(function < 8);
 
-tag.mode2.port = 0xc000 | (device << 8);
-tag.mode2.enable = 0xf0 | (function << 1);
-tag.mode2.forward = bus;
-return tag;
-default:
-panic("%s: mode not configured", __func__);
-}
+return X86_PCITAG_MAKE(bus, device, function);
 }
 
 void
< at >< at > -443,26 +430,14 < at >< at > pci_decompose_tag(pci_chipset_tag_t pc, 
 return;
 }
 
-switch (pci_mode) {
-case 1:
-if (bp != NULL)
-*bp = (tag.mode1 >> 16) & 0xff;
-if (dp != NULL)
-*dp = (tag.mode1 >> 11) & 0x1f;
-if (fp != NULL)
-*fp = (tag.mode1 >> 8) & 0x7;
-return;
-case 2:
-if (bp != NULL)
-*bp = tag.mode2.forward & 0xff;
-if (dp != NULL)
-*dp = (tag.mode2.port >> 8) & 0xf;
-if (fp != NULL)
-*fp = (tag.mode2.enable >> 1) & 0x7;
-return;
-default:
-panic("%s: mode not configured", __func__);
-}
+if (fp != NULL)
+*fp = X86_PCITAG_FUNC(tag);
+if (dp != NULL)
+*dp = X86_PCITAG_DEV(tag);
+if (bp != NULL)
+*bp = X86_PCITAG_BUS(tag);
+
+return;
 }
 
 pcireg_t
< at >< at > -480,6 +455,11 < at >< at > pci_conf_read(pci_chipset_tag_t pc, pcit
 return (*ipc->pc_ov->ov_conf_read)(ipc->pc_ctx, pc, tag, reg);
 }
 
+if (__predict_false(reg >= PCI_CONF_SIZE ||
+    (pci_mode == 2 && X86_PCITAG_DEV(tag) >= 16))) {
+return 0xffffffff;
+}
+
 pci_conf_lock(&ocl, pci_conf_selector(tag, reg));
 data = inl(pci_conf_port(tag, reg));
 pci_conf_unlock(&ocl);
< at >< at > -502,6 +482,11 < at >< at > pci_conf_write(pci_chipset_tag_t pc, pci
 return;
 }
 
+if (__predict_false(reg >= PCI_CONF_SIZE ||
+    (pci_mode == 2 && X86_PCITAG_DEV(tag) >= 16))) {
+return;
+}
+
 pci_conf_lock(&ocl, pci_conf_selector(tag, reg));
 outl(pci_conf_port(tag, reg), data);
 pci_conf_unlock(&ocl);
< at >< at > -540,7 +525,7 < at >< at > pci_mode_detect(void)
 
 if (PCI_VENDOR(pcim1_quirk_tbl[i].id) == PCI_VENDOR_INVALID)
 continue;
-t.mode1 = pcim1_quirk_tbl[i].tag.mode1;
+t = pcim1_quirk_tbl[i].tag;
 idreg = pci_conf_read(NULL, t, PCI_ID_REG); /* needs "pci_mode" */
 if (idreg == pcim1_quirk_tbl[i].id) {
 #ifdef DEBUG
Index: sys/arch/xen/xen/xpci_xenbus.c
===================================================================
RCS file: /cvsroot/src/sys/arch/xen/xen/xpci_xenbus.c,v
retrieving revision 1.12
diff -d -u -a -p -r1.12 xpci_xenbus.c
--- sys/arch/xen/xen/xpci_xenbus.c5 Dec 2012 01:46:22 -00001.12
+++ sys/arch/xen/xen/xpci_xenbus.c26 Apr 2013 13:20:03 -0000
< at >< at > -384,12 +384,11 < at >< at > pci_bus_maxdevs(pci_chipset_tag_t pc, in
 pcitag_t
 pci_make_tag(pci_chipset_tag_t pc, int bus, int device, int function)
 {
-pcitag_t tag;
-KASSERT((function & ~0x7) == 0);
-KASSERT((device & ~0x1f) == 0);
-KASSERT((bus & ~0xff) == 0);
-tag.mode1 = (bus << 8) | (device << 3) | (function << 0);
-return tag;
+KASSERT(bus < 256);
+KASSERT(device < 32);
+KASSERT(function < 8);
+
+return X86_PCITAG_MAKE(bus, device, function);
 }
 
 void
< at >< at > -397,11 +396,11 < at >< at > pci_decompose_tag(pci_chipset_tag_t pc, 
     int *bp, int *dp, int *fp)
 {
 if (bp != NULL)
-*bp = (tag.mode1 >> 8) & 0xff;
+*bp = X86_PCITAG_BUS(tag);
 if (dp != NULL)
-*dp = (tag.mode1 >> 3) & 0x1f;
+*dp = X86_PCITAG_DEV(tag);
 if (fp != NULL)
-*fp = (tag.mode1 >> 0) & 0x7;
+*fp = X86_PCITAG_FUNC(tag);
 return;
 }
 
< at >< at > -433,15 +432,14 < at >< at > static int
 xpci_conf_read( pci_chipset_tag_t pc, pcitag_t tag, int reg, int size,
     pcireg_t *value)
 {
-int bus, dev, func;
 struct xen_pci_op op = {
 .cmd    = XEN_PCI_OP_conf_read,
 .domain = 0, /* XXX */
 };
-pci_decompose_tag(pc, tag, &bus, &dev, &func);
-DPRINTF(("pci_conf_read %d:%d:%d reg 0x%x", bus, dev, func, reg));
-op.bus = bus;
-op.devfn = (dev << 3) | func;
+DPRINTF(("xpci_conf_read %d:%d:%d reg 0x%x", X86_PCITAG_BUS(tag),
+    X86_PCITAG_DEV(tag), X86_PCITAG_FUNC(tag), reg));
+op.bus = X86_PCITAG_BUS(tag);
+op.devfn = X86_PCITAG_DEVFUNC(tag);
 op.offset = reg;
 op.size   = size;
 xpci_do_op(&op);
< at >< at > -489,15 +487,14 < at >< at > static int
 xpci_conf_write(pci_chipset_tag_t pc, pcitag_t tag, int reg, int size,
     pcireg_t data)
 {
-int bus, dev, func;
 struct xen_pci_op op = {
 .cmd    = XEN_PCI_OP_conf_write,
 .domain = 0, /* XXX */
 };
-pci_decompose_tag(pc, tag, &bus, &dev, &func);
-DPRINTF(("pci_conf_write %d:%d:%d reg 0x%x val 0x%x", bus, dev, func, reg, data));
-op.bus = bus;
-op.devfn = (dev << 3) | func;
+DPRINTF(("xpci_conf_write %d:%d:%d reg 0x%x", X86_PCITAG_BUS(tag),
+    X86_PCITAG_DEV(tag), X86_PCITAG_FUNC(tag), reg, data));
+op.bus = X86_PCITAG_BUS(tag);
+op.devfn = X86_PCITAG_DEVFUNC(tag);
 op.offset = reg;
 op.size   = size;
 op.value = data;

Re: Broken 6.0.1 RAIDframe

Ray Phillips — 2013-04-26T01:06:25

  >> It won't allow me to add wd1a as a spare Manuel:
  >>
  >> # raidctl -a /dev/wd1a raid0
  >> raidctl: ioctl (RAIDFRAME_ADD_HOT_SPARE) failed: Device busy
  >
  >that may be because the kernel autoconfigured it as another raid device
  >(2 disks with autoconfigure=YES and non-matching or out of sync raid
  >informations may be configured as different raid devices)
  >
  >what raid devices do you have configured ?
  >sysctl hw.disknames
  >should give you the list

# sysctl hw.disknames
hw.disknames = fd0 wd0 cd0 wd1 raid0 raid7
#

That's interesting, there are two RAID arrays.  The machine has been 
shutdown since my last email, and now raidctl says wd0a is a 
component of raid7 and wd1a is a component of raid0.

# raidctl -s raid0
Components:
            /dev/wd1a: optimal
           component1: failed
No spares.
Component label for /dev/wd1a:
    Row: 0, Column: 0, Num Rows: 1, Num Columns: 2
    Version: 2, Serial Number: 2013001, Mod Counter: 166
    Clean: No, Status: 0
    sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1
    Queue size: 100, blocksize: 512, numBlocks: 39100160
    RAID Level: 1
    Autoconfig: Yes
    Root partition: Yes
    Last configured as: raid0
component1 status is: failed.  Skipping label.
Parity status: clean
Reconstruction is 100% complete.
Parity Re-write is 100% complete.
Copyback is 100% complete.
#
# raidctl -s raid7
Components:
           component0: failed
            /dev/wd0a: optimal
No spares.
component0 status is: failed.  Skipping label.
Component label for /dev/wd0a:
    Row: 0, Column: 1, Num Rows: 1, Num Columns: 2
    Version: 2, Serial Number: 2013001, Mod Counter: 84
    Clean: No, Status: 0
    sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1
    Queue size: 100, blocksize: 512, numBlocks: 39100160
    RAID Level: 1
    Autoconfig: Yes
    Root partition: No
    Last configured as: raid7
Parity status: clean
Reconstruction is 100% complete.
Parity Re-write is 100% complete.
Copyback is 100% complete.
#

raid0 has the highest Mod Counter value.  Does that mean it's the 
"correct" one and I should unconfigure raid7, add wd0a as a hot spare 
to raid0 and start a reconstruction of raid0?


Ray

Re: Broken 6.0.1 RAIDframe

Manuel Bouyer — 2013-04-25T13:45:04

that may be because the kernel autoconfigured it as another raid device
(2 disks with autoconfigure=YES and non-matching or out of sync raid
informations may be configured as different raid devices)

what raid devices do you have configured ?
sysctl hw.disknames
should give you the list


I'm not sure what drive will be considered up to date by the kernel then ...

Re: Broken 6.0.1 RAIDframe

Martin Husemann — 2013-04-25T11:22:57

For raid-1: yes.

date: 2007/10/05 01:40:04;  author: oster;  state: Exp;  lines: +136 -6
Implement dumping kernel cores to RAID 1 sets.  The component used
for the dump is selected in this order of preference:
   1) the master
   2) a used_spare of the master
   3) the slave
   4) a used_spare of the slave


Martin

Re: Broken 6.0.1 RAIDframe

Patrick Welche — 2013-04-25T10:56:15

You didn't show us the disklabel of raid0...

Cheers,

Patrick