Re: ZFS v28 is ready for wider testing.

[jhell]

On 09/02/2010 04:55, Rob Farmer wrote:
> 
> I tried applying the patch to r212087 to rule out recent changes to
> dtrace, but it made no difference. I used patch -E -p0 < patch.
> 

Hi Rob,

I see that in your build error are a bunch of things to do with atomic.h
and I recalled a patch from pjd@ on current@ that he sent in the same
thread. I attached the downloaded patch. Maybe you can write back and
site if it helped at all so people have a reference.


Regards,

-- 

 jhell,v
--- sys/cddl/compat/opensolaris/sys/atomic.h
+++ sys/cddl/compat/opensolaris/sys/atomic.h
@@ -39,10 +39,9 @@
 #ifndef __LP64__
 extern void atomic_add_64(volatile uint64_t *target, int64_t delta);
 extern void atomic_dec_64(volatile uint64_t *target);
-extern void *atomic_cas_ptr(volatile void *target, void *cmp,  void *newval);
 #endif
 #ifndef __sparc64__
-extern uint64_t atomic_cas_32(volatile uint32_t *target, uint32_t cmp,
+extern uint32_t atomic_cas_32(volatile uint32_t *target, uint32_t cmp,
 uint32_t newval);
 extern uint64_t atomic_cas_64(volatile uint64_t *target, uint64_t cmp,
 uint64_t newval);
@@ -119,21 +118,19 @@
 }
 
 #ifndef COMPAT_32BIT
-#if defined(__LP64__)
+#ifdef __LP64__
 static __inline void *
 atomic_cas_ptr(volatile void *target, void *cmp,  void *newval)
 {
-   return ((void *)atomic_cas_64((volatile uint64_t *)target, 
(uint64_t)cmp,
-   (uint64_t)newval));
+   return ((void *)atomic_cas_64(target, (uint64_t)cmp, (uint64_t)newval));
 }
 #else
 static __inline void *
 atomic_cas_ptr(volatile void *target, void *cmp,  void *newval)
 {
-   return ((void *)atomic_cas_32((volatile uint64_t *)target, 
(uint64_t)cmp,
-   (uint64_t)newval));
+   return ((void *)atomic_cas_32(target, (uint32_t)cmp, (uint32_t)newval));
 }
 #endif
-#endif
+#endif /* !COMPAT_32BIT */
 
 #endif /* !_OPENSOLARIS_SYS_ATOMIC_H_ */


signature.asc
Description: OpenPGP digital signature

Re: Trouble with a atapi-cam backup..

[Andriy Gapon]

on 02/09/2010 23:23 Randy Stewart said the following:
> Hi all:
> 
> So I finally upgraded my 7.3stable main server to 8.1stable...
> 
> And now my backup to atapi-cam is failing.. I get:
> 
> r...@lakerest /usr/tmp]# /usr/local/bin/growisofs -Z /dev/cd0 -R -J
> backup_init.08-31-2010.gz
> :-( unable to CAMGETPASSTHRU for /dev/cd0: Inappropriate ioctl for device

You can try to use DTrace to see where exactly in kernel the ioctl request 
fails.


-- 
Andriy Gapon
___
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: problem with wpa_supplicant

[Bernhard Schmidt]

On Friday, September 03, 2010 01:34:54 Davide Italiano wrote:
> Hi. I've been recently upgraded to -CURRENT (9.0).
> After
> # make buildworld
> # make buildkernel KERNCONF=MYKERNEL
> # make install kernel KERNCONF=MYKERNEL
> 
> I have rebooted to single-user mode, as suggested in the documentation.
> No more wireless connection. I've a intel 2200 bg wireless card,
> running using the kernel built-in iwi module.
> 
> In particular, when I run wpa_supplicant -i wlan0 -c
> /etc/wpa_supplicant.conf I get this:
> 
> CTRL-EVENT-SCAN-RESULTS
> CTRL-EVENT-SCAN-RESULTS
> CTRL-EVENT-SCAN-RESULTS
> ...
> 
> My wpa_supplicant.conf is:
> 
> ap_scan=1
> fast_reauth=1
> 
> network={
> ssid="MY_SSID"
> psk="MY_KEY"
> }
> 
> Also, my /boot/loader.conf contains
> 
> legal.intel_iwi.license_ack=1
> if_iwi_load="YES"
> 
> and my rc.conf
> 
> wlans_iwi0="wlan0"
> ifconfig_wlan0="WPA inet 192.168.1.110 netmask 0xff00"
> defaultrouter="192.168.1.1"
> 
> Again, it worked w/ freebsd 8.1 (stable). Also, I've read in the
> UPDATING file in /usr/src this:
> 
> Applications such as wpa_supplicant(8) may require a full world
> build without using NO_CLEAN in order to get synchronized with the
> new structure.
> 
> But, I've done a make buildworld before, isn't enough?
> 
> Thanks a lot

Did you also run make installworld?

-- 
Bernhard
___
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: Call for Documentation Contributors

[Adam Vande More]

On Thu, Sep 2, 2010 at 11:10 PM, Adam Vande More wrote:

> Wouldn't it be a lot easier to have a nice article on installing
> /usr/ports/misc/freebsd-doc-* from the date of the release of the installed
> system?  Or maybe offer archive web access to a handbook snapshot from that
> date(Django does something similar)?  Maintaining separate handbook branches
> seems unrealistic if there aren't enough doc contributors to maintain one to
> expectations, and IME discrepancies aren't very frequent.
>

I need to add to that installing release specific handbook/documentation via
sysinstall is the Easy Button.

-- 
Adam Vande More
___
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: Call for Documentation Contributors

[Adam Vande More]

On Thu, Sep 2, 2010 at 5:54 PM, Daniel Gerzo  wrote:

> I actually think there is some point in this idea. The problem is that many
> times we just leave notes or warnings specific for given releases, which can
> many times lead to confusion (or people just don't notice) and as time goes
> and we cut the support for given releases they get stale (e.g. We had many
> of those for 5.x).
>
> We could just maintain the handbook in separate branches like we do with
> src, keeping them all built online, and merge relevant things where
> appropriate. This will, however, add quite a lot (for my taste) of
> additional work for us.
>

Wouldn't it be a lot easier to have a nice article on installing
/usr/ports/misc/freebsd-doc-* from the date of the release of the installed
system?  Or maybe offer archive web access to a handbook snapshot from that
date(Django does something similar)?  Maintaining separate handbook branches
seems unrealistic if there aren't enough doc contributors to maintain one to
expectations, and IME discrepancies aren't very frequent.


-- 
Adam Vande More
___
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: Call for Documentation Contributors

[Daniel Gerzo]

I actually think there is some point in this idea. The problem is that many 
times we just leave notes or warnings specific for given releases, which can 
many times lead to confusion (or people just don't notice) and as time goes and 
we cut the support for given releases they get stale (e.g. We had many of those 
for 5.x).

We could just maintain the handbook in separate branches like we do with src, 
keeping them all built online, and merge relevant things where appropriate. 
This will, however, add quite a lot (for my taste) of additional work for us.

Daniel Gerzo

On 2.9.2010, at 5:02, Ed Schouten  wrote:

> * Mehmet Erol Sanliturk  wrote:
>> Please separate Handbook with respect to distributions , i.e. , maintain a
>> different Handbook for each distribution .
> 
> The problem with that is that it will cause documentation for older, but
> still supported releases, to become stale. Most doc changes apply to
> functionality provided by both releases, or at least functionality that
> is MFC'd.
> 
> -- 
> Ed Schouten 
> WWW: http://80386.nl/

___
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"

problem with wpa_supplicant

[Davide Italiano]

Hi. I've been recently upgraded to -CURRENT (9.0).
After
# make buildworld
# make buildkernel KERNCONF=MYKERNEL
# make install kernel KERNCONF=MYKERNEL

I have rebooted to single-user mode, as suggested in the documentation.
No more wireless connection. I've a intel 2200 bg wireless card,
running using the kernel built-in iwi module.

In particular, when I run wpa_supplicant -i wlan0 -c
/etc/wpa_supplicant.conf I get this:

CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
...

My wpa_supplicant.conf is:

ap_scan=1
fast_reauth=1

network={
ssid="MY_SSID"
psk="MY_KEY"
}

Also, my /boot/loader.conf contains

legal.intel_iwi.license_ack=1
if_iwi_load="YES"

and my rc.conf

wlans_iwi0="wlan0"
ifconfig_wlan0="WPA inet 192.168.1.110 netmask 0xff00"
defaultrouter="192.168.1.1"

Again, it worked w/ freebsd 8.1 (stable). Also, I've read in the
UPDATING file in /usr/src this:

Applications such as wpa_supplicant(8) may require a full world
build without using NO_CLEAN in order to get synchronized with the
new structure.

But, I've done a make buildworld before, isn't enough?

Thanks a lot

Davide
___
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"

Trouble with a atapi-cam backup..

[Randy Stewart]

Hi all:

So I finally upgraded my 7.3stable main server to 8.1stable...

And now my backup to atapi-cam is failing.. I get:

r...@lakerest /usr/tmp]# /usr/local/bin/growisofs -Z /dev/cd0 -R -J  
backup_init.08-31-2010.gz
:-( unable to CAMGETPASSTHRU for /dev/cd0: Inappropriate ioctl for  
device



Now atapi-cam I have built into the kernel (not a loaded module).. and  
so is scsibus.. and all

its friends. Cam control seems to see the device:

[r...@lakerest /usr/tmp]# camcontrol devlist
 at scbus0 target 1 lun 0 (cd0,pass0)

Any suggestions of what I left out of the kernel  would be most  
helpful..


Oh my kern.conf is:

*
include GENERIC
ident   mymachine
device  atapicam
options IPDIVERT
options IPFIREWALL
***

And its an i386

Thanks

R

-
Randall Stewart
rand...@lakerest.net




___
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: ZFS v28 is ready for wider testing.

[Pawel Jakub Dawidek]

On Tue, Aug 31, 2010 at 11:59:15PM +0200, Pawel Jakub Dawidek wrote:
[...]
> Ok, now that I know you read everything carefully, here is the patch:
> 
>   http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2

Now it is even easier to test new ZFS! :)

Here you can find VirtualBox Appliance (113MB) with
FreeBSD 9-CURRENT and ZFSv28:

http://people.freebsd.org/~pjd/misc/FreeBSD9_ZFSv28_0.1.tgz

Untar it, import it (zfsv28.ovf) to VirtualBox and have fun.

You can log in as root with no password (via virtual console or via SSH).
The system IP address is IP 192.168.56.66/24.
There are 16 ada(4) disks to play with. For example:

zfsv28:root:~# zpool create tank raidz3 ada{0,1,2,3,4,5,6,7} raidz3 
ada{8,9,10,11,12,13,14,15}
zfsv28:root:~# zpool status
  pool: tank
 state: ONLINE
 scan: none requested
config:

NAMESTATE READ WRITE CKSUM
tankONLINE   0 0 0
  raidz3-0  ONLINE   0 0 0
ada0ONLINE   0 0 0
ada1ONLINE   0 0 0
ada2ONLINE   0 0 0
ada3ONLINE   0 0 0
ada4ONLINE   0 0 0
ada5ONLINE   0 0 0
ada6ONLINE   0 0 0
ada7ONLINE   0 0 0
  raidz3-1  ONLINE   0 0 0
ada8ONLINE   0 0 0
ada9ONLINE   0 0 0
ada10   ONLINE   0 0 0
ada11   ONLINE   0 0 0
ada12   ONLINE   0 0 0
ada13   ONLINE   0 0 0
ada14   ONLINE   0 0 0
ada15   ONLINE   0 0 0

errors: No known data errors

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgp3nDIzwUUuC.pgp
Description: PGP signature

[head tinderbox] failure on powerpc/powerpc

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:57:06 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:57:06 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-09-02 17:57:06 - cleaning the object tree
TB --- 2010-09-02 17:57:23 - cvsupping the source tree
TB --- 2010-09-02 17:57:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2010-09-02 18:31:23 - building world
TB --- 2010-09-02 18:31:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 18:31:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 18:31:23 - TARGET=powerpc
TB --- 2010-09-02 18:31:23 - TARGET_ARCH=powerpc
TB --- 2010-09-02 18:31:23 - TZ=UTC
TB --- 2010-09-02 18:31:23 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 18:31:23 - cd /src
TB --- 2010-09-02 18:31:23 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep  2 18:31:24 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Sep  2 20:08:50 UTC 2010
TB --- 2010-09-02 20:08:50 - generating LINT kernel config
TB --- 2010-09-02 20:08:50 - cd /src/sys/powerpc/conf
TB --- 2010-09-02 20:08:50 - /usr/bin/make -B LINT
TB --- 2010-09-02 20:08:50 - building LINT kernel
TB --- 2010-09-02 20:08:50 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 20:08:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 20:08:50 - TARGET=powerpc
TB --- 2010-09-02 20:08:50 - TARGET_ARCH=powerpc
TB --- 2010-09-02 20:08:50 - TZ=UTC
TB --- 2010-09-02 20:08:50 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 20:08:50 - cd /src
TB --- 2010-09-02 20:08:50 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep  2 20:08:50 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Thu Sep  2 20:30:19 UTC 2010
TB --- 2010-09-02 20:30:19 - building GENERIC kernel
TB --- 2010-09-02 20:30:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 20:30:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 20:30:19 - TARGET=powerpc
TB --- 2010-09-02 20:30:19 - TARGET_ARCH=powerpc
TB --- 2010-09-02 20:30:19 - TZ=UTC
TB --- 2010-09-02 20:30:19 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 20:30:19 - cd /src
TB --- 2010-09-02 20:30:19 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Thu Sep  2 20:30:20 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/md5c.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/p1003_1b.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/kern/posix4_mib.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/al

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:58:41 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:58:41 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-09-02 17:58:41 - cleaning the object tree
TB --- 2010-09-02 17:58:59 - cvsupping the source tree
TB --- 2010-09-02 17:58:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2010-09-02 18:14:46 - building world
TB --- 2010-09-02 18:14:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 18:14:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 18:14:46 - TARGET=powerpc
TB --- 2010-09-02 18:14:46 - TARGET_ARCH=powerpc64
TB --- 2010-09-02 18:14:46 - TZ=UTC
TB --- 2010-09-02 18:14:46 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 18:14:46 - cd /src
TB --- 2010-09-02 18:14:46 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep  2 18:14:47 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Thu Sep  2 19:48:52 UTC 2010
TB --- 2010-09-02 19:48:53 - generating LINT kernel config
TB --- 2010-09-02 19:48:53 - cd /src/sys/powerpc/conf
TB --- 2010-09-02 19:48:53 - /usr/bin/make -B LINT
TB --- 2010-09-02 19:48:53 - building LINT kernel
TB --- 2010-09-02 19:48:53 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 19:48:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 19:48:53 - TARGET=powerpc
TB --- 2010-09-02 19:48:53 - TARGET_ARCH=powerpc64
TB --- 2010-09-02 19:48:53 - TZ=UTC
TB --- 2010-09-02 19:48:53 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 19:48:53 - cd /src
TB --- 2010-09-02 19:48:53 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep  2 19:48:53 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Thu Sep  2 20:12:45 UTC 2010
TB --- 2010-09-02 20:12:45 - WARNING: skipping GENERIC kernel
TB --- 2010-09-02 20:12:45 - building GENERIC64 kernel
TB --- 2010-09-02 20:12:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 20:12:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 20:12:45 - TARGET=powerpc
TB --- 2010-09-02 20:12:45 - TARGET_ARCH=powerpc64
TB --- 2010-09-02 20:12:45 - TZ=UTC
TB --- 2010-09-02 20:12:45 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 20:12:45 - cd /src
TB --- 2010-09-02 20:12:45 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64
>>> Kernel build for GENERIC64 started on Thu Sep  2 20:12:45 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/md5c.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/p1003_1b.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/kern/posix4_mib.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer

ZFS Cache & Log Device Failure Handling

[Jason J. W. Williams]

Hi Guys,

How well does ZFS on FreeBSD handle a dying/wedged log and/or cache
device? OpenSolaris handles this pretty well in my experience and will
fail through relatively quickly. But this tends to rely on FMA. Thank
you in advance.

-J
___
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: bge(4) problem on sparc64 between r204991M and r212097

[Pyun YongHyeon]

On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote:
> On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote:
> > I just updated world and kernel from r204991M to r212097 on sparc64.
> > 
> > Now I can't ping my gateway. If I boot kernel.old, then
> > the network works fine. As far as I could see mergemaster
> > didn't update any network files.
> > 
> > Please advise
> > 
> > In the meantime I'll try intermediate revisions.
> 
> I narrowed down the problem to between r212050 and r212080.
> Will continue tomorrow.
> 

Thanks for reporting. There was a big change in r212061, so try
backing out that revision and see whether this makes differences
or not.
___
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 tinderbox] failure on i386/pc98

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:34 - cvsupping the source tree
TB --- 2010-09-02 17:20:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/pc98/supfile
TB --- 2010-09-02 17:58:41 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:58:41 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:58:41 - 0.90 user 15.32 system 2320.53 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full
___
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 tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:38 - cvsupping the source tree
TB --- 2010-09-02 17:20:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/amd64/amd64/supfile
TB --- 2010-09-02 17:57:06 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:57:06 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:57:06 - 1.05 user 18.48 system 2225.61 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full
___
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 tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:35 - cvsupping the source tree
TB --- 2010-09-02 17:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/i386/supfile
TB --- 2010-09-02 17:56:30 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:56:30 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:56:30 - 0.98 user 16.30 system 2189.84 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full
___
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 tinderbox] failure on arm/arm

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for arm/arm
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:24 - cvsupping the source tree
TB --- 2010-09-02 17:20:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/arm/arm/supfile
TB --- 2010-09-02 17:54:12 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:54:12 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:54:12 - 0.60 user 9.23 system 2051.41 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full
___
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: bge(4) problem on sparc64 between r204991M and r212097

[Anton Shterenlikht]

On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote:
> I just updated world and kernel from r204991M to r212097 on sparc64.
> 
> Now I can't ping my gateway. If I boot kernel.old, then
> the network works fine. As far as I could see mergemaster
> didn't update any network files.
> 
> Please advise
> 
> In the meantime I'll try intermediate revisions.

I narrowed down the problem to between r212050 and r212080.
Will continue tomorrow.

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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: One-shot-oriented event timers management

[Alexander Motin]

b. f. wrote:
> In:
> http://people.freebsd.org/~mav/timers_oneshot7.patch
> 
> you need to offset the declaration of 'cpu' in getnextevent() on line
> 256 of src/sys/kern/kern_clocksource.c by #ifdef SMP, because it is
> not used otherwise, and will break UP kernel builds with our default
> warnings and -Werror.

Thanks.

> Incidentally, do you intend to commit the tm6292_idle.patch along with
> the new timer code, after testing is satisfactory?  Or is this not
> appropriate for general use?  If it isn't suitable for all users,
> perhaps some of the periods of the events in that patch can be
> abstracted and made tunable, so that we can make it possible to
> conserve power, and also keep others happy?

No, I am not going to commit it in present form. It is mostly made for
technology preview. May be some parts of it could be committed as-is,
but most of others are dirty hacks. I hope they should be safe enough,
but they made with assumption of some tradeoffs and require proper
rework or at least reevaluating. It would be nice if people aware with
these areas (SCHED_ULE, TCP, CPU time resources, yarrow, console, GEOM)
could review and reimplement them properly.

-- 
Alexander Motin
___
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: problem with amd64 minidump

[Andriy Gapon]

on 02/09/2010 13:10 Andriy Gapon said the following:
> 
> Not sure if this is some local issue or a problem in FreeBSD code.
> I remember minidumps working perfectly well for me, but now I can not get data
> from them.
> Example:
> dmesg -M /var/crash/vmcore.4
> dmesg: _kvm_vatop: direct map address 0xff012fe0 not in minidump
> dmesg: kvm_read: invalid address (0xff012fe0)

Not sure if it can help, but it seems that this virtual address in DMAP
corresponds to a physical address in the last page of RAM.
Do we use that for anything special?  Message buffer?
I had a quick look at getmemsize() function in sys/amd64/amd64/machdep.c and it
looks like the following code in the function could be doing just that:

Maxmem = atop(phys_avail[pa_indx]);

/* Trim off space for the message buffer. */
phys_avail[pa_indx] -= round_page(MSGBUF_SIZE);

/* Map the message buffer. */
msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);

Oh, and yeah:
(gdb) p msgbufp
$4 = (struct msgbuf *) 0xff012fe0

But we do dump the message buffer.
But somehow its dmap address is not resolved correctly.

This should ring a bell for someone knowledgeable of minidump and libkvm code, I
believe.

> Needless to say kgdb refuses to work with that core too.
> 
> With kgdb on live system I can access that address:
> (gdb) x/a 0xff012fe0
> 0xff012fe0: 0xff012ffe



-- 
Andriy Gapon
___
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: One-shot-oriented event timers management

[b. f.]

In:

http://people.freebsd.org/~mav/timers_oneshot7.patch

you need to offset the declaration of 'cpu' in getnextevent() on line
256 of src/sys/kern/kern_clocksource.c by #ifdef SMP, because it is
not used otherwise, and will break UP kernel builds with our default
warnings and -Werror.

Incidentally, do you intend to commit the tm6292_idle.patch along with
the new timer code, after testing is satisfactory?  Or is this not
appropriate for general use?  If it isn't suitable for all users,
perhaps some of the periods of the events in that patch can be
abstracted and made tunable, so that we can make it possible to
conserve power, and also keep others happy?

Regards,
  b.
___
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: Call for Documentation Contributors

[Gabor PALI]

Hello,


On Thu, Sep 2, 2010 at 11:45 AM, Niclas Zeising
 wrote:
> would it be possible to move that site to the wiki, where
> most other stuff related to FreeBSD development is?

Almost all parts are on the FreeBSD wiki already.  Only the main
coordination page (which is only a single HTML page), the Mercurial
repository, and the generated PR list are outside of that.


> Also, a list of open tasks would probably be valuable.

Yes, indeed.


> For instance a list where people who find errors or discrepancies in the docs 
> can add them so
> other people find them and can work on them.

There is one already [1].


:g

[1] http://wiki.freebsd.org/ContribDoc/Tasks
___
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: One-shot-oriented event timers management

[Ian FREISLICH]

Alexander Motin wrote:
> Ian FREISLICH wrote:
> > On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin  wrote:
> >> Brandon Gooch wrote:
> >>> This latest patch causes an interrupt storm with the HPET timer on my
> >>> system. The machine took about 8 minutes to boot and bring me to a
> >>> login prompt. System interactivity (i.e. input from keyboard, output
> >>> on console) was fine, but after checking the output of `systat vmstat
> >>> -1`, I saw the interrupt rate on each HPET entry was over 120k!
> >>>
> >>> Can I provide any useful detail? Of course, test patches are always welco
m
> > e :)
> >> I was able to reproduce alike storm in some situations.
> >>
> >> Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch
> > 
> > Interrupt rates are definitely reduced.
> > 
> > [mini] /usr/home/ianf $ vmstat -i
> > interrupt  total   rate
> > irq1: atkbd01154  1
> > irq9: acpi010829 15
> > irq16: ath0 uhci3+ 16226 23
> > irq18: uhci2  16  0
> > irq19: uhci1+   7090 10
> > irq20: hpet0  169288240
> > irq23: uhci0 ehci064  0
> > irq256: hdac0187  0
> > Total 204854291
> 
> Nice. But 240 still quite a lot. Have you applied tm6292_idle.patch and
> was this system idle at the moment?

No, I didn't.  It was reasonably idle.  I missed that in the first
post - because I became interested in this when Brandon Gooch
reported lower power consumption.  I've compiled now with this patch
as well.  There was one rejection:

--- 2182,2189 
 * Ticks is updated asynchronously on a single cpu.  Check here to
 * avoid incrementing ts_ticks multiple times in a single tick.
 */
+ //if (ts->ts_incrtick == ticks)
+ //return;
/* Adjust ticks for pctcpu */
ts->ts_ticks += 1 << SCHED_TICK_SHIFT;
ts->ts_ltick = ticks;

But, it appears to have already been applied by timers_oneshot7.patch.

The vmstat -i output is the rate since boot.  Currently at 240/s
since boot, the instantaneous rate when idle is about 60.

> > [mini] /usr/home/ianf $ sysctl dev.cpu |grep usage
> > dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us
> > dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us
> 
> It is the first time I see in practice system reporting 4 different ACPI
> C-states. What is this system? What CPU is there? Could you show me full
> `sysctl dev.cpu` output?

It's a compaq mini-110:
CPU: Intel(R) Atom(TM) CPU N270   @ 1.60GHz (1596.22-MHz 686-class CPU)

dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.P001
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1600
dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11000 
933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250 100/625
dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% last 379us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.P002
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/17 C4/57
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% 0.00% last 4335us

Ian

-- 
Ian Freislich
___
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: One-shot-oriented event timers management

[Alexander Motin]

Ian FREISLICH wrote:
> On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin  wrote:
>> Brandon Gooch wrote:
>>> This latest patch causes an interrupt storm with the HPET timer on my
>>> system. The machine took about 8 minutes to boot and bring me to a
>>> login prompt. System interactivity (i.e. input from keyboard, output
>>> on console) was fine, but after checking the output of `systat vmstat
>>> -1`, I saw the interrupt rate on each HPET entry was over 120k!
>>>
>>> Can I provide any useful detail? Of course, test patches are always welcom
> e :)
>> I was able to reproduce alike storm in some situations.
>>
>> Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch
> 
> Interrupt rates are definitely reduced.
> 
> [mini] /usr/home/ianf $ vmstat -i
> interrupt  total   rate
> irq1: atkbd01154  1
> irq9: acpi010829 15
> irq16: ath0 uhci3+ 16226 23
> irq18: uhci2  16  0
> irq19: uhci1+   7090 10
> irq20: hpet0  169288240
> irq23: uhci0 ehci064  0
> irq256: hdac0187  0
> Total 204854291

Nice. But 240 still quite a lot. Have you applied tm6292_idle.patch and
was this system idle at the moment?

> [mini] /usr/home/ianf $ sysctl dev.cpu |grep usage
> dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us
> dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us

It is the first time I see in practice system reporting 4 different ACPI
C-states. What is this system? What CPU is there? Could you show me full
`sysctl dev.cpu` output?

-- 
Alexander Motin
___
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: Call for Documentation Contributors

[Niclas Zeising]

On 2010-09-02 00:46, Gabor PALI wrote:

Hello there,

I am looking for volunteers who are interested in writing
documentation, i.e. working with the FreeBSD Handbook and the
documentation set.  Many of our great documentation writers have
decided to retire from their work over the last years, which means the
FreeBSD Documentation Project is in need of talented, skilled,
determined, and ambitious people who would help to maintain the
tradition of producing high quality documentation for the FreeBSD
operating system.

The documentation set is prepared in DocBook that might seem a bit
complicated at first sight, but I can assure you it can be learned
quickly.  All you need is good writing skills in English, some
knowledge of FreeBSD systems, and willingness to learn even more about
them.  To coordinate and encourage the efforts, I have created a site
[1] called "The FreeBSD Contributor's Documentation Project" that
contains the necessary information.  Note that there are many ways of
contribution: you can comment open Problem Reports or write patches
(by using Mercurial Queues for example), etc. depending on your free
time.  I can help with anything at the regular weekly IRC meetings,
and you can contact me via email directly any time, and hopefully
other documentation developers will also join me.


Thank you for any help in advance.

:g

[1] http://doc.hu.freebsd.org/


Hi!
Just a nitpick, would it be possible to move that site to the wiki, 
where most other stuff related to FreeBSD development is? It's not meant 
as critique towards your work, just a suggestion.
Also, a list of open tasks would probably be valuable. For instance a 
list where people who find errors or discrepancies in the docs can add 
them so other people find them and can work on them. I know this is what 
the PR system is built for, but the PR system might be a bid cumbersome 
for just making annotations and stuff like that.
Just some suggestions on how to make this flow better. Hopefully I will 
have some time to actually do some of the work involved too. :)

Keep up the good work!
Best Regards!
//Niclas
___
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 in get_next_dirent

[Andriy Gapon]

on 02/09/2010 13:01 Andriy Gapon said the following:
> 
> Brian,
> 
> after I upgraded my kernel from beginning of July version to end of August
> version I started to get panics in get_next_dirent under parallel FS load, 
> like
> e.g. during buildworld with -jN.
> 
> Is this something that might have been broken by accident and then fixed 
> later?
> I've seen that you were making some changes in the related code while working 
> on
> your NFS problem.
> 
> I am upgrading kernel to the latest version now to see if that helps.
>

Update to r212138 seems to have helped.
Sorry if my report is useless.

> Here is panic information:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0xff80151b8abb
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x803f6f54
> stack pointer   = 0x28:0xff8124353580
> frame pointer   = 0x28:0xff8124353650
> 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 = 12295 (sh)
> trap number = 12
> panic: page fault
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x801b84ba = db_trace_self_wrapper+0x2a
> kdb_backtrace() at 0x803a2c62 = kdb_backtrace+0x32
> panic() at 0x8036cb54 = panic+0x1b4
> trap_fatal() at 0x805471ad = trap_fatal+0x39d
> trap_pfault() at 0x805473bd = trap_pfault+0x1ed
> trap() at 0x805479a4 = trap+0x484
> calltrap() at 0x80531428 = calltrap+0x8
> --- trap 0xc, rip = 0x803f6f54, rsp = 0xff8124353580, rbp =
> 0xff8124353650 ---
> get_next_dirent() at 0x803f6f54 = get_next_dirent+0x164
> vop_stdvptocnp() at 0x803f749a = vop_stdvptocnp+0x31a
> VOP_VPTOCNP_APV() at 0x805a3af8 = VOP_VPTOCNP_APV+0xe8
> vn_vptocnp_locked() at 0x803f339c = vn_vptocnp_locked+0x1fc
> vn_fullpath1() at 0x803f36b8 = vn_fullpath1+0x1e8
> kern___getcwd() at 0x803f3b4a = kern___getcwd+0xda
> __getcwd() at 0x803f3cd4 = __getcwd+0x14
> syscallenter() at 0x803b088e = syscallenter+0x26e
> syscall() at 0x80547432 = syscall+0x42
> Xfast_syscall() at 0x80531702 = Xfast_syscall+0xe2
> --- syscall (326, FreeBSD ELF64, __getcwd), rip = 0x800939cfc, rsp =
> 0x7fffe0b8, rbp = 0x800c2a208 ---
> 


-- 
Andriy Gapon
___
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"

problem with amd64 minidump

[Andriy Gapon]

Not sure if this is some local issue or a problem in FreeBSD code.
I remember minidumps working perfectly well for me, but now I can not get data
from them.
Example:
dmesg -M /var/crash/vmcore.4
dmesg: _kvm_vatop: direct map address 0xff012fe0 not in minidump
dmesg: kvm_read: invalid address (0xff012fe0)

Needless to say kgdb refuses to work with that core too.

With kgdb on live system I can access that address:
(gdb) x/a 0xff012fe0
0xff012fe0: 0xff012ffe

Looks like perhaps we do not include something that we should into the dump?
Thanks!
-- 
Andriy Gapon
___
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 in get_next_dirent

[Andriy Gapon]

Brian,

after I upgraded my kernel from beginning of July version to end of August
version I started to get panics in get_next_dirent under parallel FS load, like
e.g. during buildworld with -jN.

Is this something that might have been broken by accident and then fixed later?
I've seen that you were making some changes in the related code while working on
your NFS problem.

I am upgrading kernel to the latest version now to see if that helps.

Here is panic information:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0xff80151b8abb
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x803f6f54
stack pointer   = 0x28:0xff8124353580
frame pointer   = 0x28:0xff8124353650
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 = 12295 (sh)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at 0x801b84ba = db_trace_self_wrapper+0x2a
kdb_backtrace() at 0x803a2c62 = kdb_backtrace+0x32
panic() at 0x8036cb54 = panic+0x1b4
trap_fatal() at 0x805471ad = trap_fatal+0x39d
trap_pfault() at 0x805473bd = trap_pfault+0x1ed
trap() at 0x805479a4 = trap+0x484
calltrap() at 0x80531428 = calltrap+0x8
--- trap 0xc, rip = 0x803f6f54, rsp = 0xff8124353580, rbp =
0xff8124353650 ---
get_next_dirent() at 0x803f6f54 = get_next_dirent+0x164
vop_stdvptocnp() at 0x803f749a = vop_stdvptocnp+0x31a
VOP_VPTOCNP_APV() at 0x805a3af8 = VOP_VPTOCNP_APV+0xe8
vn_vptocnp_locked() at 0x803f339c = vn_vptocnp_locked+0x1fc
vn_fullpath1() at 0x803f36b8 = vn_fullpath1+0x1e8
kern___getcwd() at 0x803f3b4a = kern___getcwd+0xda
__getcwd() at 0x803f3cd4 = __getcwd+0x14
syscallenter() at 0x803b088e = syscallenter+0x26e
syscall() at 0x80547432 = syscall+0x42
Xfast_syscall() at 0x80531702 = Xfast_syscall+0xe2
--- syscall (326, FreeBSD ELF64, __getcwd), rip = 0x800939cfc, rsp =
0x7fffe0b8, rbp = 0x800c2a208 ---

-- 
Andriy Gapon
___
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"

bge(4) problem on sparc64 between r204991M and r212097

[Anton Shterenlikht]

I just updated world and kernel from r204991M to r212097 on sparc64.

Now I can't ping my gateway. If I boot kernel.old, then
the network works fine. As far as I could see mergemaster
didn't update any network files.

Please advise

In the meantime I'll try intermediate revisions.

many thanks
anton


-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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 in get_next_dirent

[Andriy Gapon]

Brian,

after I upgrade from beginning-of-June kernel to end-of-August one (r211758) I
get a panic in get_next_dirent which happens during parallel access to FS like
during buildworld with -jN.
I am upgrading kernel to the latest revision as of today.

Could this be something that you accidentally broke and then fixed while
pursuing your NFS issue?

-- 
Andriy Gapon
___
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: One-shot-oriented event timers management

[Ian FREISLICH]

On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin  wrote:
> Brandon Gooch wrote:
>> This latest patch causes an interrupt storm with the HPET timer on my
>> system. The machine took about 8 minutes to boot and bring me to a
>> login prompt. System interactivity (i.e. input from keyboard, output
>> on console) was fine, but after checking the output of `systat vmstat
>> -1`, I saw the interrupt rate on each HPET entry was over 120k!
>>
>> Can I provide any useful detail? Of course, test patches are always welcom
e :)
>
> I was able to reproduce alike storm in some situations.
>
> Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch

Interrupt rates are definitely reduced.

[mini] /usr/home/ianf $ vmstat -i
interrupt  total   rate
irq1: atkbd01154  1
irq9: acpi010829 15
irq16: ath0 uhci3+ 16226 23
irq18: uhci2  16  0
irq19: uhci1+   7090 10
irq20: hpet0  169288240
irq23: uhci0 ehci064  0
irq256: hdac0187  0
Total 204854291

[mini] /usr/home/ianf $ sysctl dev.cpu |grep usage
dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us
dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us

Ian

-- 
Ian Freislich
___
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: ZFS v28 is ready for wider testing.

[Rob Farmer]

On Tue, Aug 31, 2010 at 2:59 PM, Pawel Jakub Dawidek  wrote:
>
> Ok, now that I know you read everything carefully, here is the patch:
>
>        http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2
>

buildworld on i386 (yes I know ZFS isn't ideal there):

===> cddl/lib/libdtrace (all)
cc -O2 -fno-strict-aliasing -pipe -march=prescott
-I/usr/obj/usr/src/cddl/lib/libdtrace -I/usr/src/cddl/lib/libdtrace
-I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/dev/dtrace/i386
-I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris
-I/usr/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include
 -I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head
-I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common
 
-I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common
 -I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common
-I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel
-DDIS_MEM -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector
-Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c
In file included from
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/bitmap.h:36,
 from
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h:33,
 from
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c:33:
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:132:
error: static declaration of 'atomic_cas_ptr' follows non-static
declaration
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:42:
error: previous declaration of 'atomic_cas_ptr' was here
cc1: warnings being treated as errors
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:
In function 'atomic_cas_ptr':
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:133:
warning: cast from pointer to integer of different size
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:134:
warning: cast from pointer to integer of different size
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:134:
warning: passing argument 1 of 'atomic_cas_32' from incompatible
pointer type
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:134:
warning: cast to pointer from integer of different size
*** Error code 1

I tried applying the patch to r212087 to rule out recent changes to
dtrace, but it made no difference. I used patch -E -p0 < patch.

-- 
Rob Farmer
___
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: ZFS v28 is ready for wider testing.

[Pawel Jakub Dawidek]

On Thu, Sep 02, 2010 at 01:55:51AM -0700, Rob Farmer wrote:
> On Tue, Aug 31, 2010 at 2:59 PM, Pawel Jakub Dawidek  wrote:
> >
> > Ok, now that I know you read everything carefully, here is the patch:
> >
> >        http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2
> >
> 
> buildworld on i386 (yes I know ZFS isn't ideal there):
[...]

Yes, I know about this problem, You can use attached patch or wait for
full patch, which I'll be sending later today.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--- sys/cddl/compat/opensolaris/sys/atomic.h
+++ sys/cddl/compat/opensolaris/sys/atomic.h
@@ -39,10 +39,9 @@
 #ifndef __LP64__
 extern void atomic_add_64(volatile uint64_t *target, int64_t delta);
 extern void atomic_dec_64(volatile uint64_t *target);
-extern void *atomic_cas_ptr(volatile void *target, void *cmp,  void *newval);
 #endif
 #ifndef __sparc64__
-extern uint64_t atomic_cas_32(volatile uint32_t *target, uint32_t cmp,
+extern uint32_t atomic_cas_32(volatile uint32_t *target, uint32_t cmp,
 uint32_t newval);
 extern uint64_t atomic_cas_64(volatile uint64_t *target, uint64_t cmp,
 uint64_t newval);
@@ -119,21 +118,19 @@
 }
 
 #ifndef COMPAT_32BIT
-#if defined(__LP64__)
+#ifdef __LP64__
 static __inline void *
 atomic_cas_ptr(volatile void *target, void *cmp,  void *newval)
 {
-	return ((void *)atomic_cas_64((volatile uint64_t *)target, (uint64_t)cmp,
-	(uint64_t)newval));
+	return ((void *)atomic_cas_64(target, (uint64_t)cmp, (uint64_t)newval));
 }
 #else
 static __inline void *
 atomic_cas_ptr(volatile void *target, void *cmp,  void *newval)
 {
-	return ((void *)atomic_cas_32((volatile uint64_t *)target, (uint64_t)cmp,
-	(uint64_t)newval));
+	return ((void *)atomic_cas_32(target, (uint32_t)cmp, (uint32_t)newval));
 }
 #endif
-#endif
+#endif	/* !COMPAT_32BIT */
 
 #endif	/* !_OPENSOLARIS_SYS_ATOMIC_H_ */


pgppo82knRdQW.pgp
Description: PGP signature

Re: Difficulty playing DVDs under AHCI/CAM?

[Andriy Gapon]

on 01/09/2010 21:21 Garrett Wollman said the following:
> < said:
> 
>> Just want to draw attention of those who use ahci, have hald running and burn
>> optical media to couple of known issues:
> 
> What about those of us who use ahci, don't have hald running, and just
> want to read their DVDs?

I am not aware of any known but not resolved issues in this context.
But I think that I gave you a good advice.

> I never heard any response from you when I
> asked for a more specific debugging procedure.

Sorry about that, forgot to tell you about google.
Now, apologies about the joke, no offense meant :-)
These links should give a good overview for the start:
http://wiki.freebsd.org/DTrace
http://wiki.freebsd.org/DTrace/Examples
http://www.freebsd.org/doc/handbook/dtrace.html
http://wikis.sun.com/display/DTrace/Documentation

And, oh, here is a script that I used to investigate a somewhat similar problem
with failing ioctl.  I think you should be able to easily adapt it to your 
needs.

syscall::ioctl:entry
/execname == "k3b" && arg1 == 3299349762/
{
self->trace = 1;
}

fbt:::entry
/self->trace/
{
}

fbt:::return
/self->trace/
{
printf("%d", arg1);
}

syscall::ioctl:return
{
self->trace = 0;
}

> My next step was going
> to be enabling CAMDEBUG and trying to find out which specific
> operation was failing, but I'm not a SCSI expert by any means

Not sure if debugging with CAMDEBUG would be easier or not.
There could be lots of output.

-- 
Andriy Gapon
___
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: Call for Documentation Contributors

[Ed Schouten]

* Mehmet Erol Sanliturk  wrote:
> Please separate Handbook with respect to distributions , i.e. , maintain a
> different Handbook for each distribution .

The problem with that is that it will cause documentation for older, but
still supported releases, to become stale. Most doc changes apply to
functionality provided by both releases, or at least functionality that
is MFC'd.

-- 
 Ed Schouten 
 WWW: http://80386.nl/


pgpGMCzJmSIXQ.pgp
Description: PGP signature