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,

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

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: writin

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

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 filesyste

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   |FUN

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:

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