xpt related hang on sparc64

[Kurt Lidl]

Greetings.

I updated my dual-processor V240 the other day:

FreeBSD 12.0-CURRENT #26 r311929: Wed Jan 11 18:52:46 EST 2017
l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64

It works fine.

I update a uniprocessor V120 today, to a slightly newer tree,
and it hangs when attempting to boot the new kernel:

FreeBSD 12.0-CURRENT #27 f72e57262fe(master): Fri Jan 13 17:25:40 EST 2017
l...@ton.pix.net:/usr/obj/usr/src/sys/V120 sparc64
uhub0: 4 ports with 4 removable, self powered
uhub1: 4 ports with 4 removable, self powered
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config

GIT hash f72e57262fe == svn r312003

I haven't had a chance to look into this any more deeply...

-Kurt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ABI differences between stable/10 and head?

[Kurt Lidl]

Yesterday, I upgraded the kernel on my sparc64 to -head,
so I was running a mis-matched kernel and userland.
The userland was a recent (as of two days ago) stable/10.

In the nightly report, I noticed the following:


Network interface status:
NameMtu Network   Address  Ipkts Ierrs IdropOpkts Oerrs 
 Coll  Drop
bge0  -   00:03:ba:e0:ce:070 64691 00 0 
11494817 2025493932409880576
bge0  - fe80::203:baf fe80::203:baff:fe0 - -0 - 
- -
bge0  - spork.pix.net 2001:470:e254:10:0 - -0 - 
- -
bge0  - 192.168.16.0  spork0 - -0 - 
- -
bge1  -   00:03:ba:e0:ce:080 0 00 0 
0 4040291828690585088
bge2  -   00:03:ba:e0:ce:090 0 00 0 
0 4040291832985552384
bge3  -   00:03:ba:e0:ce:0a0 0 00 0 
0 4040291837582442496
lo0   -    074 00 0 
38794 2025493932409880576
lo0   - localhost ::1  0 - -0 - 
- -
lo0   - fe80::1%lo0   fe80::1%lo0  0 - -0 - 
- -
lo0   - your-net  localhost0 - -0 - 
- -


As you can see, the "drop" column for the host has
completely outrageous values.

When representing those numbers as binary, there's
an awful lot of zeros in the low order bits, like
some structure is being referenced off by a word or
two.

lidl@torb-142: bc -l
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=2
2025493932409880576
111011100

I also find it more than slightly curious that the "drop" values for
bge0 and lo0 are identical.

Do we have some subtle ABI differences between the two systems
(stable/10 vs -head)?

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

installworld of r311444 fails

[Kurt Lidl]

Today's build of -head (r3111444) fails to install
on my sparc64 (upgrading from stable/10, which was
just updated yesterday).

The kernel installation and reboot worked fine.
The installation of the user bits failed:

===> usr.bin/bsdcat/tests (install)
install  -o root  -g wheel -m 555  functional_test 
/usr/tests/usr.bin/bsdcat/functional_test
install: /usr/tests/usr.bin/bsdcat/functional_test: No such file or 
directory

*** Error code 71

Stop.
bmake[6]: stopped in /usr/src/usr.bin/bsdcat/tests
*** Error code 1

Looks like the target directory creation was forgotten.

FWIW, there is no /etc/src.conf on the machine, so it's a completely
stock build.

-Kurt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: caution required with updates using custom kernels

[Kurt Lidl]

Am Fri, 24 Jun 2016 15:51:11 +
Brooks Davis  schrieb:


On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote:
> Am Thu, 23 Jun 2016 21:07:51 +
> Brooks Davis  schrieb:
>
> > Kernel config minimalists and those running aarch64 and riscv systems will
> > want to head this UPDATING message.
> >
> > In practice, if you're fairly up to date, doing installworld before
> > installkernel will also work (I've tested that case from ALPHA4), but is
> > always somewhat risky.
> >
> > -- Brooks
> >
> > - Forwarded message from Brooks Davis  -
> >
> > Date: Thu, 23 Jun 2016 21:02:05 + (UTC)
> > From: Brooks Davis 
> > To: src-committers at freebsd.org, svn-src-all at freebsd.org,
> >   svn-src-head at freebsd.org
> > Subject: svn commit: r302152 - head
> >
> > Author: brooks
> > Date: Thu Jun 23 21:02:05 2016
> > New Revision: 302152
> > URL: https://svnweb.freebsd.org/changeset/base/302152
> >
> > Log:
> >   Add an UPDATING entry for the pipe() -> pipe2() transition.
> >
> >   Approved by:re (gjb)
> >   Sponsored by:   DARPA, AFRL
> >
> > Modified:
> >   head/UPDATING
> >
> > Modified: head/UPDATING
> > 
==
> > --- head/UPDATING Thu Jun 23 20:59:13 2016(r302151)
> > +++ head/UPDATING Thu Jun 23 21:02:05 2016(r302152)
> > @@ -31,6 +31,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11
> >   disable the most expensive debugging functionality run
> >   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> >
> > +20160622:
> > + The the libc stub for the pipe(2) system call has been replaced with
> > + a wrapper which calls the pipe2(2) system call and the pipe(2) is now
> > + only implemented by the kernels which include "options
> > + FREEBSD10_COMPAT" in their config file (this is the default).
> > + Users should ensure that this option is enabled in their kernel
> > + or upgrade userspace to r302092 before upgrading their kernel.
> > +
> >  20160527:
> >   CAM will now strip leading spaces from SCSI disks' serial numbers.
> >   This will effect users who create UFS filesystems on SCSI disks using
> >
> >
> > - End forwarded message -
>
> Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10 in 
kernel and
> updated kernel __before___ world?:

You must include COMPAT_FREEBSD10 or have a new userspace.  Otherwise
things like your shell are unlikely to work.

-- Brooks



How can I fix this?

On two boxes, I'm like a dead man in the water now.


Having just worked out how to recover from this on a mips64 host
(edgerouter lite), here's more or less what I did (minus all the
experimentation to get to a working solution).  What follows worked
for me - but no warranty is implied or given.

My machine with the new kernel, but old user binaries, failed to
reboot properly, and was left at a single user prompt:

start_init: trying /sbin/init
pid 23 (sh), uid 0: exited on signal 12
Jun 24 18:17:54 init: /bin/sh on /etc/rc terminated abnormally, going to 
single user mode

Enter full pathname of shell or RETURN for /bin/sh:

I hit return, and got a shell, albeit one that cannot call pipe().

If you cannot get to a single-user shell on the console, I don't
have any recommendations for recovering your system.

You will need to be able to get access to the /usr/src and /usr/obj
filesystems that you compiled from.  In my case, those filesystems
are NFS mounted, so I had to get some networking going, and then
mount those filesystems.  Commands I typed are after the $ prompts:

$ ifconfig octe0 192.168.16.138/24
$ ifconfig octe0

On the ERL, the Ethernet autoconfig is a bit unstable, until you
tickle the interface with the second 'ifconfig', the interface stays
down.  You probably don't need to do the second ifconfig

$ mount -u /
$ mount /boot
$ mount /tmp

Start some daemons needed for NFS.

$ rpcbind
$ rpc.lockd
$ rpc.statd

Mount the remote filesystems.

$ mount /usr/src
$ mount /usr/obj

At this point, I have access to the new user binaries, but 'make'
does not work (it calls pipe() a lot), so let's get it working:

First, fixup /sbin/init for the next reboot.  Note the rename into
/sbin/init.bak, which is one of the backup names for init that the
kernel knows about.

$ chflags noschg /sbin/init
$ cd /usr/obj/usr/src/sbin/init
$ mv /sbin/init /sbin/init.bak
$ cp -p init /sbin/init

Next, get the new /bin/sh installed.

$ cp -p /bin/sh /bin/sh.old
$ cd /usr/obj/usr/src/bin/sh
$ cp -p sh /bin/sh.new
$ mv /bin/sh.new /bin/sh

The tricky part: atomically replace the libc.so shared library.

$ chflags noschg /lib/libc.so.7
$ cp -p /lib/libc.so.7 /lib/libc.so.7.old
$ cd /usr/obj/usr/src/lib/libc
$ cp -p libc.so.7 /lib/libc.so.7.new
$ mv /lib/libc.so.7.new /lib/libc.so.7

If you system is still responding now, you're probably going to
make it!

Fixup make next:

$ cd /usr/obj/usr/src/usr.bin/bmake
$ mv /usr/bin/make /usr/bin/make.old
$ 

Re: head is broken after recent sys_pipe changes

[Kurt Lidl]

On 6/23/16 12:46 AM, Kurt Lidl wrote:

On 6/23/16 12:45 AM, Glen Barber wrote:

On Thu, Jun 23, 2016 at 04:44:06AM +, Glen Barber wrote:

On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote:

As of this commit:

r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4
lines

revert error commit from previous commit. my bad!

Approved by:re (implicit)

Head still doesn't compile doing:

make -k -s -j24 tinderbox TARGETS="amd64 sparc64"

Tinderbox failed:
amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for
details

===> lib/csu/amd64 (obj)
===> lib/csu/amd64 (all)
===> lib/csu/amd64 (install)
bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring
stale
.depend
 for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S
cc: error: no such file or directory:
'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S'
cc: error: no input files
--- pipe.So ---
*** [pipe.So] Error code 1

bmake[6]: stopped in /p/fbsd/GIT/lib/libcr302114
cc: error: no such file or directory:
'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S'
cc: error: no input files
--- pipe.o ---
*** [pipe.o] Error code 1



What revision?  It builds for me on r302113.



I see you mentioned the revision, sorry for not noticing.

I think you hit a bug that brooks fixed later, which should build fine
now.

Glen



OK, I'll update and try again.  This spoiled all my builds on my sparc64
machines too.

-Kurt


I updated to r302114, deleted my /usr/obj tree for the amd64 build, and
this time it successfully built.

Sorry for the false alarm.

I'll kick off my native sparc64 builds again.

-Kurt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head is broken after recent sys_pipe changes

[Kurt Lidl]

On 6/23/16 12:45 AM, Glen Barber wrote:

On Thu, Jun 23, 2016 at 04:44:06AM +, Glen Barber wrote:

On Thu, Jun 23, 2016 at 12:42:20AM -0400, Kurt Lidl wrote:

As of this commit:

r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 lines

revert error commit from previous commit. my bad!

Approved by:re (implicit)

Head still doesn't compile doing:

make -k -s -j24 tinderbox TARGETS="amd64 sparc64"

Tinderbox failed:
amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for details

===> lib/csu/amd64 (obj)
===> lib/csu/amd64 (all)
===> lib/csu/amd64 (install)
bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring stale
.depend
 for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S
cc: error: no such file or directory:
'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S'
cc: error: no input files
--- pipe.So ---
*** [pipe.So] Error code 1

bmake[6]: stopped in /p/fbsd/GIT/lib/libc
cc: error: no such file or directory:
'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S'
cc: error: no input files
--- pipe.o ---
*** [pipe.o] Error code 1



What revision?  It builds for me on r302113.



I see you mentioned the revision, sorry for not noticing.

I think you hit a bug that brooks fixed later, which should build fine
now.

Glen



OK, I'll update and try again.  This spoiled all my builds on my sparc64
machines too.

-Kurt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

head is broken after recent sys_pipe changes

[Kurt Lidl]

As of this commit:

r302106 | adrian | 2016-06-22 21:15:35 -0400 (Wed, 22 Jun 2016) | 4 lines

revert error commit from previous commit. my bad!

Approved by:re (implicit)

Head still doesn't compile doing:

make -k -s -j24 tinderbox TARGETS="amd64 sparc64"

Tinderbox failed:
amd64.amd64 buildworld failed, check _.amd64.amd64.buildworld for details

===> lib/csu/amd64 (obj)
===> lib/csu/amd64 (all)
===> lib/csu/amd64 (install)
bmake[6]: /usr/obj/p/fbsd/GIT/lib/libc/.depend.pipe.o, 5: ignoring stale 
.depend

 for /p/fbsd/GIT/lib/libc/amd64/sys/pipe.S
cc: error: no such file or directory: 
'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S'

cc: error: no input files
--- pipe.So ---
*** [pipe.So] Error code 1

bmake[6]: stopped in /p/fbsd/GIT/lib/libc
cc: error: no such file or directory: 
'/p/fbsd/GIT/lib/libc/amd64/sys/pipe.S'

cc: error: no input files
--- pipe.o ---
*** [pipe.o] Error code 1

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

arm64 diagnostic when running 'make tinderbox'

[Kurt Lidl]

Greetings all -

I periodically run the following on one of my hosts
(an amd64 machine, running 10.3+patches), to make sure
that I haven't broken the build for clang and gcc 4.2.1
based architectures before committing.

I've noticed that I *always* get a diagnostic message
about arm64, even though I'm not compiling for it...

  root@hydra-892: make -k -s -j 24 tinderbox TARGETS="sparc64 amd64"
  --
  >>> Building an up-to-date bmake(1)
  --
  --
  >>> make universe started on Fri Jun 10 09:40:53 EDT 2016
  --
  >> arm64 skipped - install aarch64-binutils port or package to build
^
  >> amd64 started on Fri Jun 10 09:40:53 EDT 2016
  >> sparc64 started on Fri Jun 10 09:40:53 EDT 2016
  >> amd64.amd64 buildworld started on Fri Jun 10 09:40:53 EDT 2016
  >> sparc64.sparc64 buildworld started on Fri Jun 10 09:40:53 EDT 2016

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build failed in Jenkins: FreeBSD_HEAD #220

[Kurt Lidl]

On 4/30/16 2:57 AM, Jung-uk Kim wrote:

On 04/29/16 05:46 PM, Jung-uk Kim wrote:

On 04/29/16 05:17 PM, John Baldwin wrote:

You'll have to talk to the Intel guy who broke this to find out how he'd
like to fix it (not hardcode 32, or fix the AccessWidth).


I notified Intel guys and they will take care of it.  Once they patch
the bug, I'll merge the fix ASAP.


It seems it is taking longer than I expected.  I reverted the commits
from our tree for now (r298838) until we have a proper fix.

Sorry for the breakage.

Jung-uk Kim



I rebuilt the world on my VirtualBox host after the ACPI commit was
reverted.

I was able to installkernel / installworld without issue, and the
VirtualBox host has been running without issue since then.

I'll spin up a new build when the fixed version is re-committed.

Thanks!

-Kurt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

failure with latest merged ACPI on virtualbox

[Kurt Lidl]

I have a virtual machine running freebsd-current under VirtualBox (on Mac OS X).

It's been running with no issue for the last month.  Today, I updated to the
current version.

# old version (worked well)
@(#)FreeBSD 11.0-CURRENT #0 991d92a(master): Sat Mar 26 08:59:33 EDT 2016
FreeBSD 11.0-CURRENT #0 991d92a(master): Sat Mar 26 08:59:33 EDT 2016
l...@testvm.pix.net:/usr/obj/usr/src/sys/GENERIC

Current version, which fails:
# uname -a
FreeBSD testvm.pix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 88a00cf(blacklist): 
Wed Apr 13 00:39:24 EDT 2016 
l...@testvm.pix.net:/usr/obj/usr/src/sys/GENERIC  amd64

It's shutdown twice (without warning), logging the following to the messages 
file:

Apr 28 17:08:14 testvm kernel: ACPI Error: No installed handler for fixed event 
- PM_Timer (0), disabling (20160422/evevent-323)
Apr 28 17:08:14 testvm kernel: ACPI Error: No installed handler for fixed event 
- RealTimeClock (4), disabling (20160422/evevent-323)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 01, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 03, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 04, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 05, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 06, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 07, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: .

In both cases, I was in the middle of running 'mergemaster', just after having
done a 'make installworld'.

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

issue with /etc/rc.d/mountd script

[Kurt Lidl]

Greetings all.

I saw something the other day on a machine running 10/stable
(but the same code exists in -current), when it was rebooting.

The machine acts as a NFS fileserver (to support diskless booting
of a few test machines).  It only has ZFS filesystems, and only
has filesystems that are exported via ZFS properties.

So, it has /etc/zfs/exports, but no /etc/exports.

When mountd is started up, it emits a error, because the
required_files is set to /etc/exports.

I think the correct thing is to either remove the required_files
setting, or build it from /etc/exports and/or /etc/zfs/exports
and only fail if neither of those files exists.

(Yes, I could just create an empty /etc/exports file, but that's
kinda lame.)

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

sparc64 linker scripts get installed and removed during upgrade

[Kurt Lidl]

I have a sparc64 host running stable/10.

I have noticed on the last several updates that I've
done (basic list of operations below):
checkout current stable/10 sources
make buildworld
make buildkernel
make installkernel
reboot
mergemaster -p
make installworld
mergemaster
make delete-old

I get a bunch of sparc64 linker scripts that get installed
each time, and then are removed during the 'make delete-old'
operation.

root@gatekeeper-372: make delete-old && make delete-old-libs

>>> Removing old files (only deletes safe to delete libs)
remove /usr/libdata/ldscripts/elf64_sparc.x? y
remove /usr/libdata/ldscripts/elf64_sparc.xbn? y
remove /usr/libdata/ldscripts/elf64_sparc.xn? y
remove /usr/libdata/ldscripts/elf64_sparc.xr? y
remove /usr/libdata/ldscripts/elf64_sparc.xs? y
remove /usr/libdata/ldscripts/elf64_sparc.xu? y
remove /usr/libdata/ldscripts/elf64_sparc.xc? y
remove /usr/libdata/ldscripts/elf64_sparc.xsc? y
remove /usr/libdata/ldscripts/elf32_sparc.x? y
remove /usr/libdata/ldscripts/elf32_sparc.xbn? y
remove /usr/libdata/ldscripts/elf32_sparc.xn? y
remove /usr/libdata/ldscripts/elf32_sparc.xr? y
remove /usr/libdata/ldscripts/elf32_sparc.xs? y
remove /usr/libdata/ldscripts/elf32_sparc.xu? y
remove /usr/libdata/ldscripts/elf32_sparc.xc? y
remove /usr/libdata/ldscripts/elf32_sparc.xsc? y

I would think these shouldn't be installed at all, if they
are not needed or obsolete.

Thanks.

-Kurt


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sparc64 traps during probe (r293243)

[Kurt Lidl]

On 1/8/16 3:45 PM, Kurt Lidl wrote:

On 1/8/16 1:58 PM, Marius Strobl wrote:

On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote:

I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:



<...>


-- data access exception sfar=0xfcf821ca0218 sfsr=0x41029
%o7=0xc06165e8 --


What code line does 0xc06165e8 translate to?

Marius


Unfortunately, I cannot tell you.  I managed to destroy the
/usr/lib/debug/boot/kernel directory for the kernel that didn't
work properly.

As noted in a different reply, a cross-built r293425 kernel
did boot, and I'm now re-building a native r293425 world on
the sparc64 host.

If it the native build doesn't work, I'll get the information
you wanted from that build.


I was able to install and boot the natively built r293426 tree
successfully.

So whatever the problem was, it was transient, or at least has not
shown up on the machine running the natively compiled version of
everything.

-Kurt


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sparc64 traps during probe (r293243)

[Kurt Lidl]

On 1/8/16 1:58 PM, Marius Strobl wrote:

On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote:

I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:



<...>


-- data access exception sfar=0xfcf821ca0218 sfsr=0x41029
%o7=0xc06165e8 --


What code line does 0xc06165e8 translate to?

Marius


Unfortunately, I cannot tell you.  I managed to destroy the
/usr/lib/debug/boot/kernel directory for the kernel that didn't
work properly.

As noted in a different reply, a cross-built r293425 kernel
did boot, and I'm now re-building a native r293425 world on
the sparc64 host.

If it the native build doesn't work, I'll get the information
you wanted from that build.

Thanks.

-Kurt


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sparc64 traps during probe (r293243)

[Kurt Lidl]

On 1/8/16 11:57 AM, Mark Cave-Ayland wrote:

On 08/01/16 15:42, Kurt Lidl wrote:


I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #4 r293243M: Thu Jan  7 13:50:04 EST 2016
 l...@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
real memory  = 2147483648 (2048 MB)
avail memory = 2063785984 (1968 MB)
cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU)

[...]

da0 at sym0 bus 0 scbus2 target 0 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: Serial Number UPL3P310365J
da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da0: Command Queueing enabled
da0: 34732MB (71132959 512 byte sectors)
cd0 at ata2 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: 393MB (201600 2048 byte sectors)
da1 at sym0 bus 0 scbus2 target 1 lun 0
da1:  Fixed Direct Access SCSI-3 device
da1: Serial Number UPL3P3506STC
da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da1: Command Queueing enabled
da1: 34732MB (71132959 512 byte sectors)
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from zfs:sys/ROOT/default []...
GEOM_MIRROR: Device mirror/gswap launched (2/2).
[ thread pid 1 tid 12 ]
Stopped at  tl0_utrap+0x20: ldx [%l0 + %l1], %l0
db> bt
Tracing pid 1 tid 12 td 0xf800016164d0
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- data access exception sfar=0xfcf821ca0218 sfsr=0x41029
%o7=0xc06165e8 --
sched_clock() at sched_clock+0x94
statclock_cnt() at statclock_cnt+0x1c0
handleevents() at handleevents+0x138
timercb() at timercb+0x410
tick_intr() at tick_intr+0x220
-- interrupt level=0xe pil=0 %o7=0xc09c6c20 --
-- kernel stack fault %o7=0xc00b1288 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- kernel stack fault %o7=0xc011f8f0 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc

And then the stack backtrace just keeps repeating.


This looks amazingly similar to what I get trying to boot FreeBSD under
QEMU, i.e. pointing at sched_clock():


Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 1eb7424(master): Thu Sep 24 06:41:18 BST 2015

mca@freebsd:/usr/home/mca/obj/sparc64.sparc64/usr/home/mca/src/sys/GENERIC
sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
real memory  = 134217728 (128 MB)
avail memory = 98312192 (93 MB)
cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU)
random: entropy device external interface
kbd0 at kbdmux0
nexus0: 
nexus0: : incomplete
pcib0:  mem 0x1fe-0x1fe01ff irq
2032,2030,2031,2021 on nexus0
pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz
pcib0: DVMA map: 0xc000 to 0xc3ff 8192 entries
pcib0: [GIANT-LOCKED]
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pcib2:  at device 1.1 on pci0
pci2:  on pcib2
ebus0:  port 0x4000-0x7fff mem 0x300-0x3ff at
device 3.0 on pci0
vgapci0:  mem
0x100-0x1ff,0x200-0x2000fff at device 2.0 on pci0
vgapci0: Boot video device
eeprom0:  addr 0x142000-0x143fff on ebus0
eeprom0: model mk48t59
ebus0:  addr 0 (no driver attached)
uart0: <16550 or compatible> addr 0x1403f8-0x1403ff irq 43 on ebus0
uart0: console (9600,n,8,1)
ebus0:  addr 0x140060-0x140067 (no driver attached)
pci0: <network, ethernet> at device 4.0 (no driver attached)
atapci0:  port
0x8100-0x8107,0x8180-0x8183,0x8200-0x8207,0x8280-0x8283,0x8300-0x830f at
device 5.0 on pci0
ata2:  at channel 0 on atapci0
ata3:  at channel 1 on atapci0
cryptosoft0:  on nexus0
nexus0:  type unknown (no driver attached)
Timecounter "tick" frequency 1 Hz quali

sparc64 traps during probe (r293243)

[Kurt Lidl]

I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #4 r293243M: Thu Jan  7 13:50:04 EST 2016
l...@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
real memory  = 2147483648 (2048 MB)
avail memory = 2063785984 (1968 MB)
cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU)

[...]

da0 at sym0 bus 0 scbus2 target 0 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: Serial Number UPL3P310365J
da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da0: Command Queueing enabled
da0: 34732MB (71132959 512 byte sectors)
cd0 at ata2 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: 393MB (201600 2048 byte sectors)
da1 at sym0 bus 0 scbus2 target 1 lun 0
da1:  Fixed Direct Access SCSI-3 device
da1: Serial Number UPL3P3506STC
da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da1: Command Queueing enabled
da1: 34732MB (71132959 512 byte sectors)
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from zfs:sys/ROOT/default []...
GEOM_MIRROR: Device mirror/gswap launched (2/2).
[ thread pid 1 tid 12 ]
Stopped at  tl0_utrap+0x20: ldx [%l0 + %l1], %l0
db> bt
Tracing pid 1 tid 12 td 0xf800016164d0
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- data access exception sfar=0xfcf821ca0218 sfsr=0x41029 
%o7=0xc06165e8 --

sched_clock() at sched_clock+0x94
statclock_cnt() at statclock_cnt+0x1c0
handleevents() at handleevents+0x138
timercb() at timercb+0x410
tick_intr() at tick_intr+0x220
-- interrupt level=0xe pil=0 %o7=0xc09c6c20 --
-- kernel stack fault %o7=0xc00b1288 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- kernel stack fault %o7=0xc011f8f0 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc

And then the stack backtrace just keeps repeating.

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

New LOR in zfs?

[Kurt Lidl]

I installed a build of r291086 on a machine today
(previously, the machine had been running 10/stable).

I ran the following two commands just after rebooting
with the new user-land bits:

root@ton-95: df
Filesystem   1K-blocksUsedAvail Capacity  Mounted on
sys/ROOT/default  18061924  804940 17256984 4%/
devfs1   10   100%/dev
tmpfs65536   865528 0%/tmp
sys/home  17257108 124 17256984 0%/home
sys/local 17283924   26940 17256984 0%/usr/local
sys/obj.4 19440624 2183640 1725698411%/usr/obj
sys/obj.1 19440440 2183456 1725698411%/usr/obj.1
sys/obj.2 19588696 2331712 1725698412%/usr/obj.2
sys/obj.3 19588636 2331652 1725698412%/usr/obj.3
sys/ports 17257080  96 17256984 0%/usr/ports
sys/src   19740468 2483484 1725698413%/usr/src
sys/var   17358024  101040 17256984 1%/var
root@ton-96: zfs set mountpoint=/usr/obj.4 sys/obj.4

I got a LOR (new to me, at any rate) on the console:
lock order reversal:
 1st 0xf8000612da38 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1224
 2nd 0xf8000612d4b0 zfs_gfs (zfs_gfs) @ 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494

stack backtrace:
#0 0xc05b1e3c at __lockmgr_args???=?-~+0xa3c
#1 0xc06a9118 at vop_std???=?-~lock+0x38
#2 0xc09e8164 at VOP_???=?-~LOCK1_APV+0x104
#3 0xc06d125c a???=?-~t _vn_lock+0x9c
#4 0xc12a7b04 a???=?-~t gfs_file_create+0x64
#5 0xc12???=?-~a7c14 at gfs_dir_create+0x14
#6???=?-~ 0xc139fc14 at zfsctl_mknode_sn???=?-~apdir+0x54
#7 0xc12a82bc at gfs???=?-~_dir_lookup+0x31c
#8 0xc139f6cc???=?-~ at zfsctl_root_lookup+0x12c
#9???=?-~ 0xc139f7b4 at zfsctl_umount_sn???=?-~apshots+0x54
#10 0xc13bb44c at ???=?-~zfs_umount+0x4c
#11 0xc06b34a8 ???=?-~at dounmount+0xbc8
#12 0xc06b38???=?-~f0 at sys_unmount+0x410
#13 0xc???=?-~09de004 at syscall+0x3c4

The machine in question is a sparc4u machine, but I do not think
it matters.

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic in zfs on reboot

[Kurt Lidl]

I updated my machine that tracks head and rebooted it,
and it panic'd during the 'shutdown -r' execution.

  Panic String: solaris assert: zrl->zr_refcount == 0 (0x2 == 0x0), 
file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c, 
line: 64


(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:221
#1  0x80708ec5 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:364
#2  0x8070949b in vpanic (fmt=,
ap=) at /usr/src/sys/kern/kern_shutdown.c:757
#3  0x807094e3 in panic (fmt=0x0)
at /usr/src/sys/kern/kern_shutdown.c:688
#4  0x81b3c25f in assfail3 (a=,
lv=, op=,
rv=, f=, l=optimized out>)

at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91
#5  0x8187fe54 in zrl_destroy (zrl=0xf8001d429820)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c:64
#6  0x81804432 in dnode_special_close (dnh=0xf8001d429820)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c:1005
#7  0x817fa608 in dmu_objset_evict_done (os=0xf8001d429800)
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:726

#8  0x8180f191 in dsl_dataset_evict (dbu=0xf8000f957000)
at 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:287

#9  0x80756ae0 in taskqueue_run_locked (queue=0xf8000d00cd00)
at /usr/src/sys/kern/subr_taskqueue.c:430
#10 0x807575f8 in taskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_taskqueue.c:683
#11 0x806cf6b4 in fork_exit (
callout=0x80757570 ,
arg=0xf8000d01e020, frame=0xfe085c058ac0)
at /usr/src/sys/kern/kern_fork.c:1011
#12 0x809ae70e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:609
#13 0x in ?? ()

I have a vmcore for this panic.  I have saved off the installed kernel
directory for future examination.

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic in zfs on reboot

[Kurt Lidl]

On 11/6/15 1:12 PM, Kurt Lidl wrote:

I updated my machine that tracks head and rebooted it,
and it panic'd during the 'shutdown -r' execution.

   Panic String: solaris assert: zrl->zr_refcount == 0 (0x2 == 0x0),
file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c,
line: 64

(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:221
#1  0x80708ec5 in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:364
#2  0x8070949b in vpanic (fmt=,
 ap=) at /usr/src/sys/kern/kern_shutdown.c:757
#3  0x807094e3 in panic (fmt=0x0)
 at /usr/src/sys/kern/kern_shutdown.c:688
#4  0x81b3c25f in assfail3 (a=,
 lv=, op=,
 rv=, f=, l=)
 at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91
#5  0x8187fe54 in zrl_destroy (zrl=0xf8001d429820)
 at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c:64
#6  0x81804432 in dnode_special_close (dnh=0xf8001d429820)
 at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c:1005
#7  0x817fa608 in dmu_objset_evict_done (os=0xf8001d429800)
 at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:726
#8  0x8180f191 in dsl_dataset_evict (dbu=0xf8000f957000)
 at
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:287
#9  0x80756ae0 in taskqueue_run_locked (queue=0xf8000d00cd00)
 at /usr/src/sys/kern/subr_taskqueue.c:430
#10 0x807575f8 in taskqueue_thread_loop (arg=)
 at /usr/src/sys/kern/subr_taskqueue.c:683
#11 0x806cf6b4 in fork_exit (
 callout=0x80757570 ,
 arg=0xf8000d01e020, frame=0xfe085c058ac0)
 at /usr/src/sys/kern/kern_fork.c:1011
#12 0x809ae70e in fork_trampoline ()
 at /usr/src/sys/amd64/amd64/exception.S:609
#13 0x in ?? ()

I have a vmcore for this panic.  I have saved off the installed kernel
directory for future examination.

-Kurt


I should have copied in the whole info.2 file:

Dump header from device: /dev/gpt/swap0
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 1404231680
  Blocksize: 512
  Dumptime: Fri Nov  6 12:10:25 2015
  Hostname: busybox.pix.net
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 11.0-CURRENT #86 r290447M: Fri Nov  6 
11:00:18 EST 2015

l...@busybox.pix.net:/usr/obj/usr/src/sys/BUSYBOX
  Panic String: solaris assert: zrl->zr_refcount == 0 (0x2 == 0x0), 
file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zrlock.c, 
line: 64

  Dump Parity: 375889703
  Bounds: 2
  Dump Status: good

The only delta in my source tree on this machine is a patch
to the pagezero.S file, which I've been running for several months,
so I know it's not that.

(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199151 for the
delta, if you care.  I need to benchmark this more fully, but just
haven't gotten around to doing it yet.)

-Kurt



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: sparc64 backend for llvm/clang imported

[Kurt Lidl]

Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100:

In r262613 I have merged the clang-sparc64 branch back to head.  This
imports an updated sparc64 backend for llvm and clang, allowing clang to
bootstrap itself on sparc64, and to completely build world.  To be able
to build the GENERIC kernel, there is still one patch to be finalized,
see below.

If you have any sparc64 hardware, and are not afraid to encounter rough
edges, please try out building and running your system with clang.  To
do so, update to at least r262613, and enable the following options in
e.g. src.conf, or in your build environment:

WITH_CLANG=y
WITH_CLANG_IS_CC=y
WITH_LIBCPLUSPLUS=y  (optional)

Alternatively, if you would rather keep gcc as /usr/bin/cc for the
moment, build world using just WITH_CLANG, enabling clang to be built
(by gcc) and installed.  After installworld, you can then set CC=clang,
CXX=clang++ and CPP=clang-cpp for building another world.

For building the sparc64 kernel, there is one open issue left, which is
that sys/sparc64/include/pcpu.h uses global register variables, and this
is not supported by clang.  A preliminary patch for this is attached,
but it may or may not blow up your system, please beware!

The patch changes the pcpu and curpcb global register variables into
inline functions, similar to what is done on other architectures.
However, the current approach is not optimal, and the emitted code is
slightly different from what gcc outputs.  Any improvements to this
patch are greatly appreciated!

Last but not least, thanks go out to Roman Divacky for his work with
llvm/clang upstream in getting the sparc64 backend into shape.


Ok, I have a new pcpu patch to try.  I have only compile tested it.

It is available here:
https://www.funkthat.com/~jmg/sparc64.pcpu.patch

I've also attached it.

Craig, do you mind testing it?

This patch also removes curpcb as it appears to not be used by any
sparc64 C code.  A GENERIC kernel compiles fine, and fxr only turns up
curpcb used in machdep code, and no references to it under sparc64.

This is not a proper solution in that
it can mean counters/stats can be copied/moved to other cpus overwriting
the previous values if a race happens...  We use
PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's
no worse than what we were previously using..

Until we get a proper fix which involves mapping all the cpu's PCPU
data on all CPUs, this will have to sufice..

This patch is based upon, I believe, a patch from Marius and possibly
modified by rdivacky.

Thanks for testing..


The above message was posted a while ago, and I decided that I would
give the patch a test run on a spare sparc that I have, now that the
instability problem with multiprocessor sparc64 machines has been
resolved.

So, I have an up-to-date stable/10 V240 (2x1.5Ghz cpus, 8GB of memory),
running a completely stock r286861.  That all seems to work just fine.

I applied the patch referenced in the email:

https://www.funkthat.com/~jmg/sparc64.pcpu.patch

(it applied cleanly), and then rebuilt the kernel on the machine,
using the stock gcc 4.2.1 compiler.

When rebooting with that kernel, the machine panics pretty early
in the boot:

FreeBSD 10.2-STABLE #3 r286861M: Wed Aug 19 14:28:45 EDT 2015
l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
real memory  = 8589934592 (8192 MB)
avail memory = 8379719680 (7991 MB)
cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU)
cpu1: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
random device not loaded; using insecure entropy
panic: trap: illegal instruction (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc05750e0 at panic+0x20
#1 0xc08db9f8 at trap+0x558
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
timeout shutting down CPUs.

So, the patch to get rid of the pcpu usage (as a prereq to poking
at the clang compiler issues) does not work properly.

-Kurt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Connected sanitizer libraries to the build (for x86)

[Kurt Lidl]

This apparently breaks the build when compiling on a
system that has WITHOUT_IPFILTER= in /etc/src.conf:

--- depend_subdir_libclang_rt ---
In file included from 
/usr/src/lib/libclang_rt/asan/../../../contrib/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:59:
/usr/obj/usr/src/tmp/usr/include/sys/timeb.h:42:2: warning: this file 
includes sys/timeb.h which is deprecated [-W#warnings]

#warning this file includes sys/timeb.h which is deprecated
 ^
/usr/src/lib/libclang_rt/asan/../../../contrib/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:100:11: 
fatal error: 'netinet/ip_compat.h' file not found

# include netinet/ip_compat.h
  ^
-Kurt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: pkg 1.4 freeze please test test test!

[Kurt Lidl]

I upgraded one of my machines to have pkg-devel on it
(1.4.0.alpha4), and attempted to recreate my test repo with it.

Version : 1.4.0.alpha4
PKG_DBDIR = /tmp/pkg.tmp.67648;
PKG_CACHEDIR = /var/cache/pkg;
PORTSDIR = /usr/ports;
INDEXDIR = ;
INDEXFILE = INDEX-9;
HANDLE_RC_SCRIPTS = false;
ASSUME_ALWAYS_YES = true;
REPOS_DIR [
/usr/local/etc/pkg/repos,
]
PLIST_KEYWORDS_DIR = ;
SYSLOG = true;
ABI = FreeBSD:9:amd64;
ALTABI = freebsd:9:x86:64;
DEVELOPER_MODE = false;
VULNXML_SITE = http://vuxml.freebsd.org/freebsd/vuln.xml.bz2;;
FETCH_RETRY = 3;
PKG_PLUGINS_DIR = /usr/local/lib/pkg/;
PKG_ENABLE_PLUGINS = true;
PLUGINS [
]
DEBUG_SCRIPTS = false;
PLUGINS_CONF_DIR = /usr/local/etc/pkg/;
PERMISSIVE = false;
REPO_AUTOUPDATE = false;
NAMESERVER = ;
EVENT_PIPE = ;
FETCH_TIMEOUT = 30;
UNSET_TIMESTAMP = false;
SSH_RESTRICT_DIR = ;
PKG_ENV {
}
PKG_SSH_ARGS = ;
DEBUG_LEVEL = 0;
ALIAS {
}
CUDF_SOLVER = ;
SAT_SOLVER = ;
RUN_SCRIPTS = true;
CASE_SENSITIVE_MATCH = false;
LOCK_WAIT = 1;
LOCK_RETRIES = 5;
SQLITE_PROFILE = false;
WORKERS_COUNT = 0;
READ_LOCK = false;
PLIST_ACCEPT_DIRECTORIES = false;
IP_VERSION = 0;
AUTOMERGE = true;


Repositories:
  X: {
url : pkg+http://X/FreeBSD:9:amd64/latest;,
enabled : yes,
mirror_type : SRV
  }
Updating X repository catalogue...
Fetching meta.txz... done
Fetching packagesite.txz... done
Processing entries... done
X repository update completed. 506 packages processed
pkg: sqlite error while executing INSERT INTO pkg_search SELECT id, name 
|| '-' || version, origin FROM packages;CREATE INDEX packages_origin ON 
packages(origin COLLATE NOCASE);CREATE INDEX packages_name ON 
packages(name COLLATE NOCASE);CREATE INDEX packages_uid_nocase ON 
packages(name COLLATE NOCASE, origin COLLATE NOCASE);CREATE INDEX 
packages_version_nocase ON packages(name COLLATE NOCASE, version);CREATE 
INDEX packages_uid ON packages(name, origin);CREATE INDEX 
packages_version ON packages(name, version);CREATE UNIQUE INDEX 
packages_digest ON packages(manifestdigest); in file pkgdb.c:2246: 
UNIQUE constraint failed: packages.manifestdigest
Creating repository in 
/usr/obj/usr/src/release/packages/FreeBSD:9:amd64... done

Packing files for repository... done
Creating repository in 
/usr/obj/usr/src/release/packages/FreeBSD:9:amd64... done

Packing files for repository... done

-Kurt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

10.1-BETA2 ZFS boot failure on sparc64

[Kurt Lidl]

I downloaded the 10.1-BETA disc1 iso image for
sparc64, and burned it to media. I then used that
media to attempt an installation onto a spare
sparc64 machine that I have.

Using UFS as the filesystem, and more or less just
following the prompts, the system got installed OK,
and boots off of ZFS OK.

I then reinstalled onto a system that I manually
configured for ZFS.  This installation fails to boot
from the hard disk, dying like this:

 snip, snip 
ok reset
Res
LOM event: +487d+12h37m31s host reset
etting ... 

?
Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard
OpenBoot 4.0, 4096 MB memory installed, Serial #53476432.
Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50.

Boot device: disk0  File and args:
 
 FreeBSD/sparc64 ZFS boot block
   Boot path:   /pci@1f,0/pci@1/scsi@8/disk@0,0:a
Consoles: Open Firmware console  
Memory Address not Aligned
ok 

 snip, snip 

I have used my exact procedure in the past to install onto a ZFS
only sparc without issue.

Has anyone else tried booting a ZFS only sparc64 installation
recently?

-Kurt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ipv6 network aliases not set after upgrade to 9.3

[Kurt Lidl]

On 9/10/14, 6:10 AM, Andrey V. Elsukov wrote:

On 04.09.2014 18:16, Kurt Lidl wrote:

Greetings all:

I have a host that recently was upgraded from FreeBSD 9.1
to FreeBSD 9.3.  After the upgrade, the IPv6 aliases that
I was setting on vlan'd interfaces, no longer get set:

The section of my /etc/rc.conf, which worked under 9.1:

# inside network (gigabit connected)
ifconfig_bce1=up
vlans_bce1=16 17
ifconfig_bce1_16=192.168.16.4/24
ifconfig_bce1_16_ipv6=inet6 accept_rtadv
ifconfig_bce1_16_alias0=inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig_bce1_17=192.168.17.4/24
ifconfig_bce1_17_ipv6=inet6 accept_rtadv
ifconfig_bce1_17_alias0=inet6 2001:470:e254:0011::4 prefixlen 64 alias

When I use the same configuration file under 9.3, I get the
vlan'd interfaces created, and they get an auto-assigned
IPv6 interface, but the aliases do not get assigned.

If I manually run:

ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias

Then the aliased addresses get assigned.  Did the syntax for
specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1?

I did not see anything calling out this change in either the 9.2 or 9.3
release notes.


Hi,

I can confirm this, please, fill a bug report.



This bug has already been fixed in stable/9, apparently:


r269028 | dteske | 2014-07-23 18:10:34 -0400 (Wed, 23 Jul 2014) | 7 lines

MFC r267812 (hrs): Fix ifname normalization. ifconfig_IF_alias{es,N} did not
work if ifname has any of [.-/+].

PR: conf/191961
Spotted by: jhay
MFC after:  3 days



Personally, given that this a regression of prior behavior,
I'd love to see it go into a patch release of 9.3.  Since its
not a security concern, I think this is unlikely to happen.

I have tested the patch in that revision (kindly send to me by
Hiroki Sato), and it resolves the issue I was seeing.

-Kurt


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

ipv6 network aliases not set after upgrade to 9.3

[Kurt Lidl]

Greetings all:

I have a host that recently was upgraded from FreeBSD 9.1
to FreeBSD 9.3.  After the upgrade, the IPv6 aliases that
I was setting on vlan'd interfaces, no longer get set:

The section of my /etc/rc.conf, which worked under 9.1:

# inside network (gigabit connected)
ifconfig_bce1=up
vlans_bce1=16 17
ifconfig_bce1_16=192.168.16.4/24
ifconfig_bce1_16_ipv6=inet6 accept_rtadv
ifconfig_bce1_16_alias0=inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig_bce1_17=192.168.17.4/24
ifconfig_bce1_17_ipv6=inet6 accept_rtadv
ifconfig_bce1_17_alias0=inet6 2001:470:e254:0011::4 prefixlen 64 alias

When I use the same configuration file under 9.3, I get the
vlan'd interfaces created, and they get an auto-assigned
IPv6 interface, but the aliases do not get assigned.

If I manually run:

ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias
ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias

Then the aliased addresses get assigned.  Did the syntax for
specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1?

I did not see anything calling out this change in either the 9.2 or 9.3
release notes.

Thanks!

-Kurt


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: diskid documentation

[Kurt Lidl]

On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanjude at freebsd.org wrote:

It also tends to sometimes hide the gpt label provider on me (not sure
in which cases it does this, but it is annoying)


This happens when something (e.g. zfs) happens to open the diskid
provider instead of the gpt label.  For me this ended up being a bit
more than annoying; my swap was mounted in /etc/fstab via a gpt label
so I silently lost my swap when I did an upgrade.


I have seen this too, starting from a fresh install.

The install process for stable/10 writes a /dev/gpt style label
into /etc/fstab for the swap space, and that never gets used,
because the /dev/diskid/ stuff appears to take precedence.

I put the following into /boot/loader.conf to make the system more
sane:

kern.geom.label.disk_ident.enable=0

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: panic on sparc64 running 10-beta4

[Kurt Lidl]

On 12/27/13 1:42 PM, Marius Strobl wrote:

On Sun, Dec 08, 2013 at 02:50:23PM +0100, Marius Strobl wrote:

On Wed, Dec 04, 2013 at 11:01:30AM -0500, Kurt Lidl wrote:

I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4
install image today.

Installation went fine.  I rebooted the machine, and then went to get
a fresh ports tree, and the machine panic'd:

root@host:/usr/ports # portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching public key from your-org.portsnap.freebsd.org... done.
Fetching snapshot tag from your-org.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Tue Dec  3 19:06:18 EST 2013:
43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of   69 MB 3225 kBps
00m22s
Extracting snapshot... done.
Verifying snapshot integrity... panic: trap: illegal instruction (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc08836d4 at trap+0x554
Uptime: 6m59s
Dumping 4096 MB (4 chunks)
chunk at 0: 1073741824 bytes ... ok
chunk at 0x4000: 1073741824 bytes ... ok
chunk at 0x8000: 1073741824 bytes ... ok
chunk at 0xc000: 1073741824 bytes ... ok

Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...

And then it panic'd again when attempting to run 'savecore'!
(I typed a ctrl-t after it printed out the line about
writing the core file, that's where the load: 0.72 ... line
came from...)


Hrm, I don't seem to be able to reproduce this with an installation
built from sources and also can't remember a commit between BETA3 and
BETA4 which should be able to cause this. I currently can't test the
10-BETA4 install image, though. Was the machine in question running
FreeBSD before, i. e. is it known good hardware? Did savecore eventually
succeed on writing out a dump?


Yes, this machine was successfully running 9/stable before this.
Yes, I did ultimately get a successful savecore to run.  The
trick seems to be not to use ctrl-t to check the status of the
machine.

I loaded the RC1 build too, and restrained myself to not check
via ctrl-t during the installation and unpacking of the OS, and
again when doing a portsnap fetch  portsnap unpack.

I think the problem hinges on ctrl-t corrupting something that
causes the panic soon thereafter.



FYI, I tried again with a machine installed from the 10.0-RC3 binary
image and couldn't reproduce that problem either.


I just tried it again with a freshly fetched and burned RC3 image, and
was able to get it to panic while verifying the snapshot. My comments
are in [square brackets].

root@dna:~ # portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching public key from your-org.portsnap.freebsd.org... done.
Fetching snapshot tag from your-org.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Thu Dec 26 19:11:40 EST 2013:

[ I did several ctrl-t operations during the fetch, no problem ]

Extracting snapshot...
[ctrl-t]
load: 0.55  cmd: bsdtar 1355 [runnable] 6.33r 1.39u 3.78s 37% 5384k
In: 11851934 bytes, compression 23%;  Out: 5320 files, 15471104 bytes
Current: 
snap/3d543fc157d97d1617eeb20832bf2cb37d04aeb2bf068bd0a07533e5b67c02fe.gz 
(1152 bytes)

[ctrl-t]
load: 0.83  cmd: bsdtar 1355 [runnable] 11.43r 2.36u 6.55s 51% 5384k
In: 19288110 bytes, compression 24%;  Out: 9299 files, 25624576 bytes
Current: 
snap/1856dcdc8799dd2b5a19d2d4720452bc77b4084088dd9ac5bd190da5ac211c4b.gz 
(101014 bytes)

done.
Verifying snapshot integrity...
[ a bunch of rapid ctrl-t keystrokes ]
load: 2.23  cmd: sha256 1370 [runnable] 0.49r 0.32u 0.00s 3% 2064k
load: 2.21  cmd: sh 1539 [runnable] 0.04r 0.00u 0.00s 2% 0k
load: 1.93  cmd: sha256 5705 [runnable] 0.02r 0.00u 0.00s 15% 1880k
load: 1.93  cmd: sh 5715 [runnable] 0.03r 0.00u 0.00s 15% 3136k
load: 1.93  cmd: gunzip 5728 [runnable] 0.01r 0.00u 0.00s 16% 1200k
load: 1.93  cmd: gunzip 5737 [runnable] 0.02r 0.00u 0.01s 16% 2144k
load: 1.93  cmd: sh 5749 [runnable] 0.00r 0.00u 0.00s 16% 3136k
load: 1.93  cmd: sh 1391 [runnable] 68.71r 0.58u 5.18s 15% 3136k
panic: trap: fast data access mmu miss (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc0883954 at trap+0x554
Uptime: 1h1m23s
Dumping 4096 MB (4 chunks)
  chunk at 0: 1073741824 bytes ... ok
  chunk at 0x4000: 1073741824 bytes ... ok
  chunk at 0x8000: 1073741824 bytes ... ok
  chunk at 0xc000: 1073741824 bytes ... ok

Dump complete

Here's the backtrace from the recovered crashdump, 'core.txt.0':

Unread portion of the kernel message buffer:
panic: trap: fast data access mmu miss (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc0883954 at trap+0x554
Uptime: 1h1m23s
Dumping 4096 MB (4 chunks)
  chunk at 0: 1073741824 bytes

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from

Re: makefs enhancement for better rock-ridge support

[Kurt Lidl]

 
 On 18 December 2013 09:27, Kurt Lidl l...@pix.net wrote:
  A while ago, it was reported that the ISO images that FreeBSD generates
  have a variety of problems (thread starts here):
 
  http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073050.html
 
  And again for the 10.0 releases:
 
  http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076284.html
 
  Looking into this, it appears that the various bugs in the Rock Ridge
  extensions have been fixed, except for the actual lack of recording
  the serial numbers in the correct place of the Rock Ridge data.
 
  As it turns out, it is almost trivial to fix this.
 
  Patch is attached to this message, which will probably be stripped
  out by the mailing list, but should be available as an attachment
  from the mail server.

 On Wed, Dec 18, 2013 at 11:41:49PM -0800, Adrian Chadd wrote:
 Would you mind filing a PR?
 
 -a

This was filed as:

http://www.freebsd.org/cgi/query-pr.cgi?pr=185138

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

makefs enhancement for better rock-ridge support

[Kurt Lidl]

A while ago, it was reported that the ISO images that FreeBSD generates
have a variety of problems (thread starts here):

http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073050.html

And again for the 10.0 releases:

http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076284.html

Looking into this, it appears that the various bugs in the Rock Ridge
extensions have been fixed, except for the actual lack of recording
the serial numbers in the correct place of the Rock Ridge data.

As it turns out, it is almost trivial to fix this.

Patch is attached to this message, which will probably be stripped
out by the mailing list, but should be available as an attachment
from the mail server.

-Kurt
diff --git a/usr.sbin/makefs/cd9660/iso9660_rrip.c 
b/usr.sbin/makefs/cd9660/iso9660_rrip.c
--- a/usr.sbin/makefs/cd9660/iso9660_rrip.c
+++ b/usr.sbin/makefs/cd9660/iso9660_rrip.c
@@ -629,28 +629,29 @@ cd9660_createSL(cd9660node *node)
}
}
}
 }
 
 int
 cd9660node_rrip_px(struct ISO_SUSP_ATTRIBUTES *v, fsnode *pxinfo)
 {
-   v-attr.rr_entry.PX.h.length[0] = 36;
+   v-attr.rr_entry.PX.h.length[0] = 44;
v-attr.rr_entry.PX.h.version[0] = 1;
cd9660_bothendian_dword(pxinfo-inode-st.st_mode,
v-attr.rr_entry.PX.mode);
cd9660_bothendian_dword(pxinfo-inode-st.st_nlink,
v-attr.rr_entry.PX.links);
cd9660_bothendian_dword(pxinfo-inode-st.st_uid,
v-attr.rr_entry.PX.uid);
cd9660_bothendian_dword(pxinfo-inode-st.st_gid,
v-attr.rr_entry.PX.gid);
+   cd9660_bothendian_dword(pxinfo-inode-st.st_ino,
+   v-attr.rr_entry.PX.serial);
 
-   /* Ignoring the serial number for now */
return 1;
 }
 
 int
 cd9660node_rrip_pn(struct ISO_SUSP_ATTRIBUTES *pn_field, fsnode *fnode)
 {
pn_field-attr.rr_entry.PN.h.length[0] = 20;
pn_field-attr.rr_entry.PN.h.version[0] = 1;
diff --git a/usr.sbin/makefs/cd9660/iso9660_rrip.h 
b/usr.sbin/makefs/cd9660/iso9660_rrip.h
--- a/usr.sbin/makefs/cd9660/iso9660_rrip.h
+++ b/usr.sbin/makefs/cd9660/iso9660_rrip.h
@@ -98,17 +98,17 @@
 #define SL_FLAGS_ROOT  8
 
 typedef struct {
ISO_SUSP_HEADER  h;
u_char mode [ISODCL(5,12)];
u_char links[ISODCL(13,20)];
u_char uid  [ISODCL(21,28)];
u_char gid  [ISODCL(29,36)];
-   u_char serial   [ISODCL(37,44)];/* Not used */
+   u_char serial   [ISODCL(37,44)];
 } ISO_RRIP_PX;
 
 typedef struct {
ISO_SUSP_HEADER  h;
u_char high [ISODCL(5,12)];
u_char low  [ISODCL(13,20)];
 } ISO_RRIP_PN;
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

panic with deactivated geom mirror (both 9.2 and 10.0-RC2)

[Kurt Lidl]

Greetings all -

I've got a completely reproducible panic when issuing a
'gmirror status' command on a recently deactivated gmirror.

NOTE:  This only happens on a machine with more than 1 CPU.

I filed a bug report on it:

http://www.freebsd.org/cgi/query-pr.cgi?pr=184985

Script to reproduce the panic:
(assumes /dev/ada0p3 is a scratch partition)

while :
do
  gmirror label -v scratch /dev/ada0p3
  newfs /dev/mirror/scratch
  mount /dev/mirror/scratch /mnt
  umount -f /mnt
  gmirror deactivate scratch /dev/ada0p3
  gmirror status scratch
done

I've attached the core.txt.0 file from the crash under 10.0-RC2.
Probably stripped by the mailing list. A copy is at
http://www.pix.net/staff/lidl/freebsd/core.txt.0

-Kurt
b524-fbsd10rc2.pix.net dumped core - see /var/crash/vmcore.0

Wed Dec 18 23:23:12 UTC 2013

FreeBSD b524-fbsd10rc2.pix.net 10.0-RC2 FreeBSD 10.0-RC2 #0 r259404: Sun Dec 15 
08:18:20 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...

Unread portion of the kernel message buffer:
GEOM_MIRROR: Device scratch: provider ada0p3 disconnected.
GEOM_MIRROR: Device scratch: provider mirror/scratch destroyed.
GEOM_MIRROR: Device scratch destroyed.


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x378
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808b78c6
stack pointer   = 0x28:0xfe001ddfea10
frame pointer   = 0x28:0xfe001ddfeab0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (g_event)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0x808e7d60 at kdb_backtrace+0x60
#1 0x808af845 at panic+0x155
#2 0x80c8e612 at trap_fatal+0x3a2
#3 0x80c8e8e9 at trap_pfault+0x2c9
#4 0x80c8e076 at trap+0x5e6
#5 0x80c75312 at calltrap+0x8
#6 0x808b7442 at _sx_xlock+0x62
#7 0x81a371bf at g_mirror_dumpconf+0x12f
#8 0x8081a35c at g_conf_specific+0x14c
#9 0x8081acd6 at g_run_events+0x166
#10 0x8088191a at fork_exit+0x9a
#11 0x80c7584e at fork_trampoline+0xe
Uptime: 33s
Dumping 78 out of 487 MB:..21%..41%..61%..82%

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done.
Loaded symbols for /boot/kernel/geom_mirror.ko.symbols
#0  doadump (textdump=value optimized out) at pcpu.h:219
219 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=value optimized out) at pcpu.h:219
#1  0x808af4c0 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2  0x808af884 in panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:754
#3  0x80c8e612 in trap_fatal (frame=value optimized out, 
eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:882
#4  0x80c8e8e9 in trap_pfault (frame=0xfe001ddfe960, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:699
#5  0x80c8e076 in trap (frame=0xfe001ddfe960)
at /usr/src/sys/amd64/amd64/trap.c:463
#6  0x80c75312 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#7  0x808b78c6 in _sx_xlock_hard (sx=0xf80018321240, 
tid=18446735277652013056, opts=value optimized out, 
file=0x2beff0 Address 0x2beff0 out of bounds, line=0)
at /usr/src/sys/kern/kern_sx.c:556
#8  0x808b7442 in _sx_xlock (sx=0x2beff0, opts=0, 
file=value optimized out, line=2879472) at sx.h:152
#9  0x81a371bf in g_mirror_dumpconf (sb=0xf80018310540, 
indent=0x80ea9f7d \t, gp=value optimized out, 
cp=value optimized out, pp=value optimized out)
at 
/usr/src/sys/modules/geom/geom_mirror/../../../geom/mirror/g_mirror.c:3202
#10 0x8081a35c in g_conf_specific (sb=0xf80018310540, mp=0x0, 
gp=0x0, pp=0x0, cp=0x0) at /usr/src/sys/geom/geom_dump.c:238
#11 0x8081acd6 in g_run_events ()
at /usr/src/sys/geom/geom_event.c:257
#12 0x8088191a in fork_exit (
callout=0x8081c8e0 g_event_procbody, arg=0x0, 
frame=0xfe001ddfec00) at /usr/src/sys/kern/kern_fork.c:995
#13 0x80c7584e in fork_trampoline ()

panic on sparc64 running 10-beta4

[Kurt Lidl]

I installed a sparc V120 (4GB memory, dual 72GB disks) with the 10-beta4
install image today.

Installation went fine.  I rebooted the machine, and then went to get
a fresh ports tree, and the machine panic'd:

root@host:/usr/ports # portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching public key from your-org.portsnap.freebsd.org... done.
Fetching snapshot tag from your-org.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Tue Dec  3 19:06:18 EST 2013:
43b6803c6d94efd5b2e2bc9df0b66a84b75417fa3c1728100% of   69 MB 3225 kBps 
00m22s

Extracting snapshot... done.
Verifying snapshot integrity... panic: trap: illegal instruction (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc08836d4 at trap+0x554
Uptime: 6m59s
Dumping 4096 MB (4 chunks)
  chunk at 0: 1073741824 bytes ... ok
  chunk at 0x4000: 1073741824 bytes ... ok
  chunk at 0x8000: 1073741824 bytes ... ok
  chunk at 0xc000: 1073741824 bytes ... ok

Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...

And then it panic'd again when attempting to run 'savecore'!
(I typed a ctrl-t after it printed out the line about
writing the core file, that's where the load: 0.72 ... line
came from...)

savecore: reboot after panic: trap: illegal instruction (kernel)
Dec  4 10:49:45 host savecore: reboot after panic: trap: illegal 
instruction (kernel)

savecore: writing core to /var/crash/vmcore.0
load: 0.72  cmd: savecore 906 [physrd] 13.66r 2.75u 2.31s 27% 3192k
vmcore.0 6.5%
panic: trap: fast data access mmu miss (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc08836d4 at trap+0x554
Uptime: 1m58s
Dumping 4096 MB (4 chunks)
  chunk at 0: 1073741824 bytes ... ok
  chunk at 0x4000: 1073741824 bytes ... ok
  chunk at 0x8000: 1073741824 bytes ... ok
  chunk at 0xc000: 1073741824 bytes ... ok

Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...

Something's rotten with the 10-beta4 binaries for sparc64.

-Kurt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu

[Kurt Lidl]

On Wednesday, November 06, 2013 19:18:31 UTC Baldwin, John wrote:

On Wednesday, November 06, 2013 10:22:44 am Teske, Devin wrote:


On Nov 6, 2013, at 1:18 AM, Lars Engels wrote:

 Am 05.11.2013 18:06, schrieb Kurt Lidl:

 Well, I'd probably be in support of this change - it sure beats having
 to interrupt the normal boot sequence and typing:
   unload
   load /boot/kernel.old/kernel
   load /boot/kernel.old/opensolaris.ko
   load /boot/kernel.old/zfs.ko
   boot

 To load an older kernel I always just type

 boot kernel.old


 Doesn't that unload the currently loaded kernel automatically?

Actually... it does.

Thanks for pointing that out (forgot about that).


The only thing that it doesn't do which I wish it did was fixup
module_path.  Right now if you break into the loader prompt and
do 'boot foo', you end up with module_path containing
/boot/kernel;/boot/modules;/boot/foo.  What I would like is to
be able to use 'boot foo' and get a proper module_path.


Yeah - I found this out the hard way when playing with incompatible
versions of zfs.ko.  I suppose the boot kernel.old method works
if kernel.old is close enough to kernel, as you'll get the
kernel.old/kernel file, and kernel/zfs.ko kernel/opensolaris.ko modules
loaded that way.

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu

[Kurt Lidl]

You can try enabling the beastie menu on sparc64 by editing
/boot/loader.rc:

=== Change #1 in /boot/loader.rc to enable beastie menu ===

Find:
\ Reads and processes loader.conf variables
\ NOTE: Change to `initialize' if you enable the below boot menu
start

Change start to initialize as shown below:
\ Reads and processes loader.conf variables
\ NOTE: Change to `initialize' if you enable the below boot menu
initialize

=== Change #2 in [same file] to enable beastie menu ===

Find:
\ Uncomment to enable boot menu
\ include /boot/beastie.4th
\ beastie-start

Uncomment beastie-start as shown below:
\ Uncomment to enable boot menu
\ include /boot/beastie.4th
beastie-start

==

If you find that making those two trivial changes, that you are able to load
the menu... then maybe it's time for us to start thinking about enabling the
beastie menu by-default for the sparc64 architecture.


Seems to work just fine.  I tested by booting, toggling through the
different kernel choices (/boot/kernel/kernel /boot/kernel.old/kernel)
and both worked correctly.

(Although I uncommented the include /boot/beastie.4th line too.)


Does anybody else have any thoughts on enabling it for sparc64?


Well, I'd probably be in support of this change - it sure beats having
to interrupt the normal boot sequence and typing:
   unload
   load /boot/kernel.old/kernel
   load /boot/kernel.old/opensolaris.ko
   load /boot/kernel.old/zfs.ko
   boot
When I need to get back to the prior version of the kernel.

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu

[Kurt Lidl]

On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote:

On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin Devin.Teske at fisglobal.com 
wrote:
Hi all,

Here's a chance to test out the kernel selection menu enhancements
to the boot loader menu before they go into HEAD.

Discussion welcome, feedback desired.

No recompile needed, just drop the new forth files onto a HEAD or
stable/9 box and reboot.
--
Cheers,
Devin

where are the forth files in question?



D'Oh!

Here they are:

http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/

Supplied as patches to either stable/9 or head.
--
Devin


Hmmm.  I saw no appreciable changes to behavior when I patched all
the files in /boot with these versions.  This was on a sparc64 host
running 10-BETA3 (compile this morning).

Notably, the kernel and modules still loaded before presenting me
with the option to tell it which kernel to load:

Executing last command: boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a
Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a  File and args:

 FreeBSD/sparc64 ZFS boot block
   Boot path:   /pci@1f,0/pci@1/scsi@8/disk@0,0:a
Consoles: Open Firmware console
\
FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0
(r...@snap.freebsd.org, Sun Oct 27 07:20:42 UTC 2013)
bootpath=zfs:sys/ROOT/default:
Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0x8d54c0+0x66180 syms=[0x8+0x954f0+0x8+0x8d7ef]
/boot/kernel/zfs.ko text=0x223328 data=0xa4e0+0x17fc0 
syms=[0x8+0x197b8+0x8+0x143f8]

loading required module 'opensolaris'
/boot/kernel/opensolaris.ko text=0x3130 data=0x2c8+0x2030 
syms=[0x8+0xd98+0x8+0x929]
/boot/kernel/geom_mirror.ko text=0x38430 data=0x5b0+0x20 
syms=[0x8+0x16b0+0x8+0x119e]


Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 9 seconds...


-Kurt


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [Heads Up] RCS removed from base

[Kurt Lidl]

On Tue, Oct 08, 2013 at 04:56:46PM -0400, Kurt Lidl wrote:

On 10/8/13 4:33 PM, Cy Schubert wrote:
 In message 52542687.7000100 at pix.net, Kurt Lidl writes:
 On 10/8/13, Julian Elischer wrote:
 On 10/7/13 11:06 PM, Steve Kargl wrote:
 On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote:
 Hey all,


Did it this morning

http://people.FreeBSD.org/~db/rcs.tgz

Or

http://www.db.net/~db/rcs.tgz



I notice in diff'ing your work vs my work, that I started with
newer revisions of some of the files than the ones you have:

 .\   $OpenBSD: ci.1,v 1.37 2011/07/14 16:31:34 sobrado Exp $
---
 .\   $OpenBSD: ci.1,v 1.38 2013/08/12 14:19:53 jmc Exp $

 /* $OpenBSD: ci.c,v 1.214 2013/01/18 11:21:09 guenther Exp $   */
---
 /* $OpenBSD: ci.c,v 1.215 2013/04/17 00:20:52 deraadt Exp $*/

 /* $OpenBSD: co.c,v 1.116 2010/12/03 19:44:58 chl Exp $*/
---
 /* $OpenBSD: co.c,v 1.117 2013/04/16 20:24:45 deraadt Exp $*/

 /* $OpenBSD: date.y,v 1.10 2010/07/31 08:54:42 ray Exp $   */
---
 /* $OpenBSD: date.y,v 1.11 2013/04/19 17:28:07 deraadt Exp $   */

 /* $OpenBSD: diff.c,v 1.33 2011/04/20 19:34:16 nicm Exp $  */
---
 /* $OpenBSD: diff.c,v 1.34 2013/05/16 12:44:48 stsp Exp $  */

 .\   $OpenBSD: ident.1,v 1.11 2011/04/19 21:17:30 jmc Exp $
---
 .\   $OpenBSD: ident.1,v 1.12 2013/06/29 09:08:41 jmc Exp $

 /* $OpenBSD: rcs.h,v 1.15 2011/07/06 15:36:52 nicm Exp $   */
---
 /* $OpenBSD: rcs.h,v 1.16 2013/06/03 17:04:35 jcs Exp $*/

 /* $OpenBSD: rcsparse.c,v 1.8 2012/02/04 21:22:32 tobias Exp $ */
---
 /* $OpenBSD: rcsparse.c,v 1.9 2013/06/03 17:04:35 jcs Exp $*/

 /* $OpenBSD: rcsutil.c,v 1.38 2010/12/06 22:52:55 chl Exp $*/
---
 /* $OpenBSD: rcsutil.c,v 1.39 2013/04/16 20:24:45 deraadt Exp $*/

 /* $OpenBSD: rlog.c,v 1.65 2011/07/14 16:38:39 sobrado Exp $   */
---
 /* $OpenBSD: rlog.c,v 1.66 2013/06/03 17:04:35 jcs Exp $   */

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [Heads Up] RCS removed from base

[Kurt Lidl]

On 10/8/13, Julian Elischer wrote:

On 10/7/13 11:06 PM, Steve Kargl wrote:

On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote:

Hey all,

RCS was removed from the base system in r256095.  If you still want to
use RCS please install either devel/rcs or devel/rcs57.  If not, be
sure to check out the alternatives (pun stolen and intended).


Perhaps, a note in src/UPDATING is appropriate?


ok so what is this, the secret cabal to make FreeBSD useless?
I'm ccing core as I believe this was not discussed enough in public
(in fact not discussed AT ALL in any forum I am watching)
and I officially request a backout of the removal of what I consider
to be core functionality.

My usual way of doing things is on install to ci EVERYTHING in /etc
to get a snapsot right the way back to install.

now I have to change things in /etc (and other places) BEFORE I can
check them in.
(i.e. get networking up and ports installed)
not a big thing but I believe that a lot of poeple use ci/co on /etc
becasue it is just there



+1 for keeping a RCS in base.  I too use to maintain a bunch of
files in /etc - I have for years and years.  I don't particularly
want the GPL'd version - I'd be happiest with the OpenRCS version
(BSD-licensed) from OpenBSD.

-Kurt



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [Heads Up] RCS removed from base

[Kurt Lidl]

On 10/8/13 4:33 PM, Cy Schubert wrote:

In message 52542687.7000...@pix.net, Kurt Lidl writes:

On 10/8/13, Julian Elischer wrote:

On 10/7/13 11:06 PM, Steve Kargl wrote:

On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote:

Hey all,

RCS was removed from the base system in r256095.  If you still want to
use RCS please install either devel/rcs or devel/rcs57.  If not, be
sure to check out the alternatives (pun stolen and intended).


Perhaps, a note in src/UPDATING is appropriate?


ok so what is this, the secret cabal to make FreeBSD useless?
I'm ccing core as I believe this was not discussed enough in public
(in fact not discussed AT ALL in any forum I am watching)
and I officially request a backout of the removal of what I consider
to be core functionality.

My usual way of doing things is on install to ci EVERYTHING in /etc
to get a snapsot right the way back to install.

now I have to change things in /etc (and other places) BEFORE I can
check them in.
(i.e. get networking up and ports installed)
not a big thing but I believe that a lot of poeple use ci/co on /etc
becasue it is just there



+1 for keeping a RCS in base.  I too use to maintain a bunch of
files in /etc - I have for years and years.  I don't particularly
want the GPL'd version - I'd be happiest with the OpenRCS version
(BSD-licensed) from OpenBSD.


I've started work on a port (not that this was my highest priority but
received a private email that I may want to do this instead of rcs57).
Would the majority here rather have it in base? Just finished schlepping
the OpenBSD source to my laptop (the link to the OpenRCS site returns a TCP
RST). I don't mind either way. It's the groups's and the Project's call.



I did the same thing this afternoon.  I grabbed the latest rcs sources
from the OpenBSD CVS server, and did a quick and dirty port to
FreeBSD.  There are some minor formatting diffs in the output of
'rlog', for example.

Diff should be attached (well, stripped from the mailing list, but still
available through the web interface to the mailing list).

-Kurt



diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -12,9 +12,9 @@ LINKS=${BINDIR}/rcs ${BINDIR}/ci ${BIND
${BINDIR}/rcs ${BINDIR}/rcsclean ${BINDIR}/rcs ${BINDIR}/rcsdiff \
${BINDIR}/rcs ${BINDIR}/rcsmerge ${BINDIR}/rcs ${BINDIR}/rlog
 
 CPPFLAGS+=-I${.CURDIR}
-CFLAGS+=-Wall
+CFLAGS+=-Wall -I${.CURDIR}
 CFLAGS+=-Wstrict-prototypes -Wmissing-prototypes
 CFLAGS+=-Wmissing-declarations
 CFLAGS+=-Wshadow -Wpointer-arith -Wcast-qual
 CFLAGS+=-Wsign-compare
diff --git a/ci.c b/ci.c
--- a/ci.c
+++ b/ci.c
@@ -909,9 +909,9 @@ checkin_keywordscan(BUF *data, RCSNUM **
buf_append(buf, start, len);
 
/* XXX - Not binary safe. */
buf_putc(buf, '\0');
-   checkin_parsekeyword(buf_get(buf), rev, date, author, state);
+   checkin_parsekeyword((char *)buf_get(buf), rev, date, author, 
state);
buf_free(buf);
 loopend:;
}
if (kwstr == NULL)
diff --git a/date.y b/date.y
--- a/date.y
+++ b/date.y
@@ -13,9 +13,9 @@
 */
 /* SUPPRESS 287 on yaccpar_sccsid *//* Unused static variable */
 /* SUPPRESS 288 on yyerrlab *//* Label unused */
 
-#include sys/timeb.h
+/* #include sys/timeb.h */
 
 #include ctype.h
 #include err.h
 #include string.h
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -426,10 +426,10 @@ files_differ(FILE *f1, FILE *f2)
 static void
 prepare(int i, FILE *fd, off_t filesize, int flags)
 {
struct line *p;
-   int j, h;
-   size_t sz;
+   int h;
+   size_t j, sz;
 
rewind(fd);
 
sz = (filesize = SIZE_MAX ? filesize : SIZE_MAX) / 25;
@@ -1141,9 +1141,9 @@ asciifile(FILE *f)
cnt = fread(buf, 1, sizeof(buf), f);
return (memchr(buf, '\0', cnt) == NULL);
 }
 
-#define begins_with(s, pre) (strncmp(s, pre, sizeof(pre)-1) == 0)
+#define begins_with(s, pre) (strncmp((const char *)s, pre, sizeof(pre)-1) == 0)
 
 static char *
 match_function(const long *f, int pos, FILE *fp)
 {
@@ -1160,9 +1160,9 @@ match_function(const long *f, int pos, F
nc = sizeof(buf) - 1;
nc = fread(buf, 1, nc, fp);
if (nc  0) {
buf[nc] = '\0';
-   buf[strcspn(buf, \n)] = '\0';
+   buf[strcspn((const char *)buf, \n)] = '\0';
if (isalpha(buf[0]) || buf[0] == '_' || buf[0] == '$') {
if (begins_with(buf, private:)) {
if (!state)
state =  (private);
@@ -1172,9 +1172,9 @@ match_function(const long *f, int pos, F
} else if (begins_with(buf, public:)) {
if (!state)
state =  (public);
} else

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Kurt Lidl]

5. I think some substantial part of the MBR code will blow up if you are
reinitalizing a previously formatted disk (the bsdlabel will be retasted
and come back from the dead).

Will not some combination of gpart destroy -F and (insert suggestion) work?


Yes, that will work just fine.


Actually, it will appear to work, and then viciously hurt (substitute
more graphic verb for hurt) you later, if you happen to repartition,
and are using a geom-mirror for your swap space.  At least if you manage
to get your old geom and new geom on the same physical location of the
disk.

To be safe, you really need to either zero out the space used by geom
before destroying the gpart label when it isn't in use, or run:

gmirror deactivate NAME provider1
gmirror deactivate NAME provider2

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI

[Kurt Lidl]

On 10/8/2013, Nathan Whitehorn wrote:

On 10/07/13 21:59, Allan Jude wrote:

Devin Teske and I have been working on a big patch to bsdinstall to
implement installing on a ZFS pool. It supports both GPT and MBR, the 4k
sector gnop trick, and optional GELI encryption. We would like to commit
this in time for 10.0-BETA1 so it needs some testing to work out any
obvious bugs before we send it off to re@ to get it committed.

It includes a single configuration menu that allows you to select all of
the required details, including which drives to use (gets details from
camcontrol, also includes an inspection utility that presents the
detailed output of camcontrol inquiry/identify, and gpart show), what
ZFS RAID level to use (taking in to consideration the selected number of
drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc.


Additional, it includes some other changes to bsdinstall:
1. Change the default to the 'non-standard keyboard mapping' prompt to no
2. Replace the 3 separate dialogs to configure an ipv4 address with just 1
3. Remove the dialog asking if you wish to enable crash dumps, this
feature has been combined into the regular 'services to enable' dialog
and enabled by default


You can browse the patches here:
http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/

I've built a bootonly.iso (10.0-ALPHA4) to make testing easier,
available compressed (48 MB) or uncompressed (211 MB):

http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz

http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso


We look forward to your feedback



Thanks for doing this! I had a few comments:
1. ZFS is not bootable on all architectures. Could you adjust that menu
item to only display for i386, amd64, and (I think?) sparc64. Use uname
-m, not -p, for this.
1a. The script is broken on sparc64 in any case, which uses VTOC8
instead of GPT.
2. Why are you using camcontrol? That is guaranteed not to work on
non-CAM systems. You should use the GEOM ident string if you need an ID.
3. Any plans to integrate this into the regular partition editor? ZFS
support is important enough that I will definitely not get in the way,
even as a bolt-on, but it would be a shame for it to stay that way. The
editor is also designed for ZFS to be added.
4. What is this gnop stuff for?
5. I think some substantial part of the MBR code will blow up if you are
reinitalizing a previously formatted disk (the bsdlabel will be retasted
and come back from the dead).
-Nathan


I wrote some support for adding ZFS to the partition editor a couple of
months ago, around the time that 9.2 was branched.  One of the biggest
things that I have not done is integrate setting up a zfs mirror between
any disks before creating the zpool.  Nor did I do the gnop hack to
create 4K disk blocks before creating the pool.

I more or less changed the partedit program to take an argument when
invoked with ufs (same as current behavior) or zfs, which knows
about zfs setup stuff.  The hookup to the actual scripts was, shall
we say, much less intrusive than what has been published here.

I guess it's time to dig out the patches and make them available to
others.

-Kurt




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

head fails to compile with WITHOUT_KERBEROS= in src.conf

[Kurt Lidl]

Greetings all.

My weekly update to the lastest freebsd-head failed to compile
this morning.  My src.conf has, among other things:

WITHOUT_HESIOD=
WITHOUT_KERBEROS=

# turn off stripping and enable dtrace
STRIP=
CFLAGS+=-fno-omit-frame-pointer

CC=clang
CXX=clang++
CPP=clang-cpp

My compile failed with:

--- secure/lib/libssh__L ---
In file included from 
/usr/src/secure/lib/libssh/../../../crypto/openssh/jpake.c:43:
/usr/src/secure/lib/libssh/../../../crypto/openssh/auth.h:42:10: fatal error: 
'krb5.h' file not found
#include krb5.h
 ^
1 error generated.
mkdep: compile failed
*** [.depend] Error code 1

make[4]: stopped in /usr/src/secure/lib/libssh
1 error

-Kurt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: expanding past 1 TB on amd64

[Kurt Lidl]

On 7/16/2013 2:12 PM, Alan Cox wrote:

... The Haswell line of CPUs is widely reported to

support DIMMs twice as large, and it's due in September.  That would
make the systems of late 2013 hold up to 1536GB of memory.


I'd point you at stuff like the Supermicro X8BQ6 series of mainboards.
QP E5-8800 systems with 1 TB of memory have been around since 2011.


That might have been true, but I did check SuperMicro's
motherboard matrix of available products before posting.

The largest listed memory configuration on
any of their current products is 768GB.

http://www.supermicro.com/products/motherboard/matrix/?cpuclass=allsorton=memory

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: expanding past 1 TB on amd64

[Kurt Lidl]

On 7/17/13 11:26 AM, Freddie Cash wrote:

On Wed, Jul 17, 2013 at 7:50 AM, Bob Bishop r...@gid.co.uk
mailto:r...@gid.co.uk wrote:

Hi,

On 17 Jul 2013, at 15:17, Kurt Lidl wrote:

  On 7/16/2013 2:12 PM, Alan Cox wrote:
  ... The Haswell line of CPUs is widely reported to
  support DIMMs twice as large, and it's due in September.  That
would
  make the systems of late 2013 hold up to 1536GB of memory.
 
  I'd point you at stuff like the Supermicro X8BQ6 series of
mainboards.
  QP E5-8800 systems with 1 TB of memory have been around since 2011.
 
  That might have been true, but I did check SuperMicro's
  motherboard matrix of available products before posting.
 
  The largest listed memory configuration on
  any of their current products is 768GB.
 
 

http://www.supermicro.com/products/motherboard/matrix/?cpuclass=allsorton=memory
 
  -Kurt

http://www.supermicro.com/products/motherboard/Xeon7000

Looks like their matrix is not up-to-date.


There's also several AMD motherboards that support 1 TB of RAM:
http://www.supermicro.com/products/nfo/AMD_G34.cfm?pg=MOBO

You know, the CPUs that started the 64-bit x86 support ... :)


Searching a bit harder, it looks like Intel is shipping a quad-socket
board that supports 1500GB of memory.

http://ark.intel.com/products/61033

So, 1500GB is now, and the next doubling will probably be soon,
assuming Intel revs their quad processor boards for Haswell, and that
support for 64GB DIMMs is there.

I'm not trying to find the biggest motherboard out there, I'm just
trying to say that Chris' patch for support up to 16TB isn't too
farfetched.  And within the next 5 year window, it's entirely likely
that  4TB systems will be available.

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: expanding past 1 TB on amd64

[Kurt Lidl]

On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek chris.torek at gmail.com wrote:


In src/sys/amd64/include/vmparam.h is this handy map:

 * 0x - 0x7fff   user map
 * 0x8000 - 0x7fff   does not exist (hole)
 * 0x8000 - 0x804020100fff   recursive page table (512GB
slot)
 * 0x804020101000 - 0xfdff   unused
 * 0xfe00 - 0xfeff   1TB direct map
 * 0xff00 - 0xff7f   unused
 * 0xff80 - 0x   512GB kernel map

showing that the system can deal with at most 1 TB of address space
(because of the direct map), using at most half of that for kernel
memory (less, really, due to the inevitable VM fragmentation).

New boards are coming soonish that will have the ability to go
past that (24 DIMMs of 64 GB each = 1.5 TB).  Or, if some crazy
people :-) might want to use a most of a 768 GB board (24 DIMMs of
32 GB each, possible today although the price is kind of
staggering) as wired-down kernel memory, the 512 GB VM area is
already a problem.

I have not wrapped my head around the amd64 pmap code but figured
I'd ask: what might need to change to support larger spaces?
Obviously NKPML4E in amd64/include/pmap.h, for the kernel start
address; and NDMPML4E for the direct map.  It looks like this
would adjust KERNBASE and the direct map appropriately.  But would
that suffice, or have I missed something?

For that matter, if these are changed to make space for future
expansion, what would be a good expansion size?  Perhaps multiply
the sizes by 16?  (If memory doubles roughly every 18 months,
that should give room for at least 5 years.)



Chris, Neel,

The actual data that I've seen shows that DIMMs are doubling in size at
about half that pace, about every three years.  For example, see
http://users.ece.cmu.edu/~omutlu/pub/mutlu_memory-scaling_imw13_invited-talk.pdfslide
#8.  So, I think that a factor of 16 is a lot more than we'll need in
the next five years.  I would suggest configuring the kernel virtual
address space for 4 TB.  Once you go beyond 512 GB, 4 TB is the net
plateau in terms of address translation cost.  At 4 TB all of the PML4
entries for the kernel virtual address space will reside in the same L2
cache line, so a page table walk on a TLB miss for an instruction fetch
will effectively prefetch the PML4 entry for the kernel heap and vice versa.


The largest commodity motherboards that are shipping today support
24 DIMMs, at a max size of 32GB per DIMM.  That's 768GB, right now.
(So FreeBSD is already out of bits in terms of supporting current
shipping hardware.) The Haswell line of CPUs is widely reported to
support DIMMs twice as large, and it's due in September.  That would
make the systems of late 2013 hold up to 1536GB of memory.

Using your figure of doubling in 3 years, we'll see 3072GB systems by
~2016.  And in ~2019, we'll see 6TB systems, and need to finally expand
to using more than a single cache line to hold all the PML4 entries.

Of course, that's speculating furiously about two generations out, and
assumes keeping the current memory architecture / board design
constraints.

-Kurt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] sysutils/bsdconfg (0.9.0) and sysutils/sysrc (5.2)

[Kurt Lidl]

In light of Devin's CFT, I offer the following, related code...

Greetings -

I've been asked to look at inserting ZFS support into the guided setup
for FreeBSD.

I've got a mostly working set of patches, but they are still a bit
ugly -- hard wired to use ZFS now, rather than UFS, but I'm to the point
where some external input is needed.

On of the issues that I've run into is the partedit command knows
that pretty much a partition equates to a filesystem.  While that
is true for UFS, it's not that way for ZFS.  A partition is more likely
a zpool, and that zpool can have as many filesystems as the user
wants.

Also, the bsdinstall framework (nice piece of work!) would need to
be extended to query for zfs vs ufs and also have some hook for
setting up the different zfs filesystems.  Right now, I just kludged
in a static list of filesystems to create in the mount script.
I suppose there should be filesystems script before mount that
lets a user muck about in terms of creating filesystems...

Anyway, attached should be a patch against a recent snapshot of
a -current source tree to add in this code.  It's not ready for
primetime, buy I would like some feedback about the approach I've
taken so far.

Thanks.

-Kurt

diff --git a/usr.sbin/bsdinstall/partedit/Makefile 
b/usr.sbin/bsdinstall/partedit/Makefile
--- a/usr.sbin/bsdinstall/partedit/Makefile
+++ b/usr.sbin/bsdinstall/partedit/Makefile
@@ -1,9 +1,11 @@
 # $FreeBSD$
+STRIP=
+CFLAGS+=-g
 
 BINDIR= /usr/libexec/bsdinstall
 PROG=  partedit
 LINKS= ${BINDIR}/partedit ${BINDIR}/autopart \
${BINDIR}/partedit ${BINDIR}/scriptedpart
 SYMLINKS= ${BINDIR}/partedit /usr/sbin/sade
 DPADD= ${LIBGEOM} ${LIBNCURSESW} ${LIBUTIL} ${LIBDIALOG} ${LIBM}
 LDADD= -lgeom -lncursesw -lutil -ldialog -lm
diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c 
b/usr.sbin/bsdinstall/partedit/gpart_ops.c
--- a/usr.sbin/bsdinstall/partedit/gpart_ops.c
+++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c
@@ -114,16 +114,56 @@ newfs_command(const char *fstype, char *
strcat(command, -O1 );
else if (strcmp(items[i].name, SU) == 0)
strcat(command, -U );
else if (strcmp(items[i].name, SUJ) == 0)
strcat(command, -j );
else if (strcmp(items[i].name, TRIM) == 0)
strcat(command, -t );
}
+   } else if (strcmp(fstype, freebsd-zfs) == 0) {
+   int i;
+   DIALOG_LISTITEM items[] = {
+   {fletcher4, checksum algorithm: fletcher4,
+   Use fletcher4 for data integrity checking. 
+   (default), 1 },
+   {fletcher2, checksum algorithm: fletcher2,
+   Use fletcher2 for data integrity checking. 
+   (not recommended), 0 },
+   {sha256, checksum algorithm: sha256,
+   Use sha256 for data integrity checking. 
+   (not recommended), 0 },
+   {atime, Update atimes for files,
+   Disable atime update, 0 },
+   };
+
+   if (!use_default) {
+   int choice;
+   choice = dlg_checklist(ZFS Options, , 0, 0, 0,
+   sizeof(items)/sizeof(items[0]), items, NULL,
+   FLAG_CHECK, i);
+   if (choice == 1) /* Cancel */
+   return;
+   }
+
+   strcpy(command, zpool create -o cachefile=/tmp/zpool.cache
+-O canmount=off -O mountpoint=none );
+   for (i = 0; i  (int)(sizeof(items)/sizeof(items[0])); i++) {
+   if (items[i].state == 0)
+   continue;
+   if (strcmp(items[i].name, fletcher4) == 0)
+   strcat(command, -O checksum=fletcher4 );
+   else if (strcmp(items[i].name, fletcher2) == 0)
+   strcat(command, -O checksum=fletcher2 );
+   else if (strcmp(items[i].name, sha256) == 0)
+   strcat(command, -O checksum=sha256 );
+   else if (strcmp(items[i].name, atime) == 0)
+   strcat(command, -O atime=off );
+   }
+   strcat(command, zroot ); /* XXX */
} else if (strcmp(fstype, fat32) == 0 || strcmp(fstype, efi) == 0) {
int i;
DIALOG_LISTITEM items[] = {
{FAT32, FAT Type 32,
Create a FAT32 filesystem (default), 1 },
{FAT16, FAT Type 16,
Create a FAT16 filesystem, 0 },
{FAT12, FAT Type 12,
@@ -339,30 +379,34 

sparc64 9.0-RC3 install failure

[Kurt Lidl]

I downloaded the 9.0-RC3 disc1 image for sparc64 and
attempted to install it onto a Netra-T1 105 that is
currently running FreeBSD 8.2-RELEASE.  (1024MB memory,
2x36GB scsi drives, quad-port HME card in the PCI slot)

It failed to install, but not before destroying my partitions.

   .Error...
   . The checksum for base.txz .
   . does not match. It may have   .
   . become corrupted, and should  .
   . be redownloaded.  .
   .
   . OK  .
   .

After I exited from the installer, I manually ran sha256 on all
the .txz files in /usr/freebsd-dist:
# sha256 *txz
SHA256 (base.txz) = 
23c116d439368f612d7a774435002075e9f11cfe7443190b22868b485a53
SHA256 (doc.txz) = 
ba5887aac341f5c21293d76df5debfaba812adcd9b65153e977b5db4a347afdc
SHA256 (games.txz) = 
0869a7fe76440247e12b915aa7811a7b04d5fa9c8d6d98f3c8defb4c78f390b2
SHA256 (kernel.txz) = 
5e9940390fa0ac93806ede8c955e50a5a46e1e8d631509de67f0635999ea9a57
SHA256 (ports.txz) = 
cd3f2365755bb6c0fe0e8fbec331cae2fd163112ab7fec35aed7ae837d761593
SHA256 (src.txz) = 
a4d515b25e3938da6c0fd1cf79c2c7057f77df3a8141d599d28373e838923d35

Sure enough, those checksums don't match the contents of the MANIFEST file.

I then took the CD-ROM that I burned, popped it into a amd64 machine
running FreeBSD 8.2-RELEASE, and after mounting the CD-ROM, ran sha256
on the same files.

This time, all the checksums for the .txz files match the contents
of the MANIFEST file.  So, the media that I burned is definately
good when I read it on the amd64 machine.

Has anyone successfully installed the sparc64-RC3 bits from the disc1
ISO onto a sparc64 machine?

-Kurt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org