Re: Runaway intr, not flash related

[Doug Barton]

On Mon, 16 Aug 2010, Peter Jeremy wrote:


- Have you tried running a uniprocessor kernel?


Ok I tried this, and got the same result early into the 3rd video. After 
I ran the dtrace intr got up to a truly impressive 27% cpu before I shut 
it down.


last pid:  4423;  load averages:  2.07,  1.32,  0.91up 0+02:37:40  23:50:59
98 processes:  2 running, 79 sleeping, 17 waiting
CPU:  3.2% user,  0.0% nice, 16.0% system, 17.3% interrupt, 63.5% idle
Mem: 48M Active, 210M Inact, 117M Wired, 544K Cache, 112M Buf, 1625M Free
Swap: 1024M Total, 1024M Free

  PID USERNAME   PRI NICE   SIZERES STATETIME   WCPU COMMAND
   10 root   171 ki31 0K 8K RUN 69:12 48.19% idle
 4423 dougb  1040  9912K  2036K RUN  0:02 10.70% top
   11 root   -32- 0K   136K WAIT 0:15  6.79% {swi4: clock}
   14 root 0- 0K 8K tzpoll   0:05  0.68% acpi_thermal
   11 root   -68- 0K   136K WAIT 0:55  0.54% {irq5: wpi0}
   17 root96- 0K 8K syncer   0:02  0.44% syncer
  781 root980  9684K  1268K select   0:08  0.34% moused
3 root-8- 0K 8K -0:02  0.24% g_up
 1340 root960  9580K  1192K select   0:07  0.15% powerd
4 root-8- 0K 8K -0:01  0.10% g_down
   19 root   -16- 0K 8K sdflus   0:00  0.10% softdepflush



CPU IDFUNCTION:NAME
  0  2 :END kernel`realitexpire
   value  - Distribution - count
   32768 | 0
   65536 | 1
  131072 | 0

0xc0b0bf30
   value  - Distribution - count
  131072 | 0
  262144 | 1
  524288 | 0

kernel`ieee80211_node_timeout
   value  - Distribution - count
  262144 | 0
  524288 | 1
 1048576 | 0

kernel`loadav
   value  - Distribution - count
 512 | 0
1024 |@@@  1
2048 | 0
4096 | 0
8192 | 0
   16384 | 0
   32768 | 0
   65536 |@@@  1
  131072 | 3
  262144 |@@@  1
  524288 | 0

kernel`uma_timeout
   value  - Distribution - count
 1048576 | 0
 2097152 | 1
 4194304 | 0

kernel`ipport_tick
   value  - Distribution - count
 256 | 0
 512 |@@@  2
1024 | 0
2048 | 0
4096 | 0
8192 | 0
   16384 |@3
   32768 |@@   1
   65536 |@6
  131072 |@@   14
  262144 | 0

kernel`kbdmux_kbd_intr_timo
   value  - Distribution - count
 128 | 0
 256 |@@   1
 512 |@@@  2
1024 | 0
2048 | 0
4096 | 0
8192 | 0
   16384 |@@   1
   32768 |@3
   65536 | 5
  131072 | 13
  262144 | 0
  524288 |@@   1
 1048576 | 

bwn(0) BCM4315/BCM22062000 up for grabs (driver devs only)

[Ian FREISLICH]

Hi

This device is up for grabs for a willing driver developer.  It's
a mini PCI-express half length card.

siba_b...@pci0:1:0:0:   class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)'
class  = network

It does the following:

Aug 12 20:48:24 mini kernel: bwn0: need multicast update callback
Aug 12 20:48:25 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1)
Aug 12 20:48:27 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1)
Aug 12 20:48:28 mini kernel: bwn0: need multicast update callback
Aug 12 20:48:28 mini kernel: bwn0: need multicast update callback
Aug 12 20:48:28 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1)
Aug 12 20:48:30 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1)
Aug 12 20:51:39 mini kernel: bwn0: need multicast update callback

After about 20 minutes I start seeing packet loss at about 5%.
Within a few minutes packet loss increases to 100%.  Contact me off
list if you're interested.

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"

AR9280 "bb hang" and other

[Ian FREISLICH]

Hi

I recently managed to hack my HP/Compaq BIOS to bypass the RF
Whitelist and replace the (crappy) bwn interface with a (decent)
ath card.

There are a few things -

1. The card has AR5B93 printed on the label, but its detected as:

a...@pci0:1:0:0:class=0x028000 card=0x663211ad chip=0x002a168c rev=0x01 
hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'Atheros AR5B91 Wireless Network Adapter (0001)'
class  = network

ath0:  mem 0xfeaf-0xfeaf irq 16 at device 0.0 on pci1
ath0: [MPSAFE]
ath0: [ITHREAD]
ath0: AR9280 mac 128.2 RF5133 phy 13.0

Everything I've read suggests it's actually an Atheros 9281.  It's
possible that the label is wrong.  I'm reluctant to desolder the
RF shield on the spare card I ordered to see what's actually printed
on the chip.




2. I'm getting these messages fairly often.  Transmission stops
briefly around these times:

Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80)
Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80)
Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting
Aug 17 09:05:47 mini kernel: ath0: 0x 0x2000 0x, 0x 
0x 0x
Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting
Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting
Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting
Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting

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: AR9280 "bb hang" and other

[Kurt Jaeger]

Hi!

> I recently managed to hack my HP/Compaq BIOS to bypass the RF
> Whitelist and replace the (crappy) bwn interface with a (decent)
> ath card.

Cool 8-)

> 2. I'm getting these messages fairly often.  Transmission stops
> briefly around these times:

There's an PR which looks pretty similar:

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

I disabled the call to ath_reset() in ath_bmiss_proc and was able
to use my AR9285 that way (not very stable, but usable).

-- 
p...@opsec.eu+49 171 310137210 years to go !
___
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: AR9280 "bb hang" and other

[Rui Paulo]

On 17 Aug 2010, at 09:17, Ian FREISLICH wrote:

> Hi
> 
> I recently managed to hack my HP/Compaq BIOS to bypass the RF
> Whitelist and replace the (crappy) bwn interface with a (decent)
> ath card.
> 
> There are a few things -
> 
> 1. The card has AR5B93 printed on the label, but its detected as:
> 
> a...@pci0:1:0:0:class=0x028000 card=0x663211ad chip=0x002a168c 
> rev=0x01 hdr=0x00
>vendor = 'Atheros Communications Inc.'
>device = 'Atheros AR5B91 Wireless Network Adapter (0001)'
>class  = network
> 
> ath0:  mem 0xfeaf-0xfeaf irq 16 at device 0.0 on pci1
> ath0: [MPSAFE]
> ath0: [ITHREAD]
> ath0: AR9280 mac 128.2 RF5133 phy 13.0
> 
> Everything I've read suggests it's actually an Atheros 9281.

9281 is the 9280 MAC, so this is ok.

>  It's
> possible that the label is wrong.  I'm reluctant to desolder the
> RF shield on the spare card I ordered to see what's actually printed
> on the chip.
> 
> 
> 
> 
> 2. I'm getting these messages fairly often.  Transmission stops
> briefly around these times:
> 
> Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80)
> Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80)
> Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting
> Aug 17 09:05:47 mini kernel: ath0: 0x 0x2000 0x, 
> 0x 0x 0x
> Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting
> Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting
> Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting
> Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting
> 

BB hangs are a problem with the 9280 but I don't know how to fix.
Hardware errors shouldn't happen, but this might mean you have very aggressive 
power reduction settings (ACPI C3, etc.) that are interfering with the atheros 
card. This has happened to me in the past.

--
Rui Paulo


___
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: AR9280 "bb hang" and other

[Ian FREISLICH]

Rui Paulo wrote:
> 
> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote:
> > 2. I'm getting these messages fairly often.  Transmission stops
> > briefly around these times:
> >=20
> > Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80)
> > Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80)
> > Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting
> > Aug 17 09:05:47 mini kernel: ath0: 0x 0x2000 0x, =
> 0x 0x 0x
> > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting
> > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting
> > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting
> > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting
> >=20
> 
> BB hangs are a problem with the 9280 but I don't know how to fix.

Do you have a card to play with?  (Since I'm offering hardware at the moment)

> Hardware errors shouldn't happen, but this might mean you have very =
> aggressive power reduction settings (ACPI C3, etc.) that are interfering =
> with the atheros card. This has happened to me in the past.

I don't think it's that:

hw.acpi.cpu.cx_lowest: C1

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"

Building world with clang

[Dimitry Andric]

Hi,

Since clang has gone into the tree, there has been an effort to get head
in a state where world can optionally be built with it.  A number of
changes required for this have already been committed, mainly thanks to
Ed Schouten, Roman Divacky and Rui Paulo.  Most of these changes were
adapted from the clangbsd project branch.

There are several other changes in the queue, pending review and/or
further enhancement, but I would like to solicit your comments about one
particular set: the changes required to let buildworld use clang as the
compiler.

Probably the most logical way to specify that you want world built with
clang, is to put CC=clang and CXX=clang++ in /etc/src.conf.  Any
necessary modifications to Makefile.inc1 or bsd.*.mk can then be put
between conditionals like:

.if ${CC:T:Mclang} == "clang"
[...stuff specific to clang...]
.endif

so nothing will change for non-clang builds.

Now, for building clang as the bootstrap compiler, there are basically
two methods to make it use the correct headers, C startup objects, and
libraries from the object tree (${WORLDTMP}):

1) The "isysroot" method: build a regular version of clang, and make
   sure WMAKEENV contains something like:

   CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
   -L${WORLDTMP}/usr/lib/"

2) The "tools-prefix" method: build a special version of clang, that
   has its default search paths for headers, startup objects and
   libraries modified, to look for everything under ${WORLDTMP}.

Method 1) is used in the clangbsd project branch.

Method 2) is similar to what is used for building the in-tree gcc as
the bootstrap compiler.  During the cross-tools stage, TOOLS_PREFIX is
defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in
search paths get prefixed with it.

An advantage of method 1) is that it does not require any modifications
to the compiler, and basically just a few extra command line arguments.
The same method could probably even be made to work for gcc.

However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot, -B
and -L flags, so there is still a chance that headers, objects or
libraries outside of ${WORLDTMP} will be picked up during the world
stage.

An advantage of method 2) is that you can be 100% sure all built-in
search paths of the bootstrap compiler point to directories under
${WORLDTMP}.  Of course, a disadvantage is that you have to make some
modifications to the compiler source itself.

I would like to hear your opinions about which method is preferred, or
if there may be another good way to solve the bootstrap compiler issue.

I have also attached two patches to this mail, which can be applied to
head, to show the exact set of changes required for each method.

The "isysroot" method for building world with clang.

First of all, Makefile.inc1 is modified to build the clang libraries and
binaries during the cross-tools stage, iff CC=clang.

We basically adjust WMAKEENV, which applies to the world stage, and
LIB32FLAGS, which optionally applies to 32-bit world stage, to add
-isysroot, -B and -L options, so the compiler looks under ${WORLDTMP}
for its headers, startup objects and libraries.

We also need to create symlinks from ${WORLDTMP}/usr/bin/as and ld to
${WORLDTMP}/usr/lib, since the -B option in clang is not additive, and
is used both for finding CRT startup objects and for finding the
assembler and linker.


diff --git a/Makefile.inc1 b/Makefile.inc1
index d2581c5..c31eba9 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -257,6 +257,10 @@ WMAKEENV=  ${CROSSENV} \
VERSION="${VERSION}" \
INSTALL="sh ${.CURDIR}/tools/install.sh" \
PATH=${TMPPATH}
+.if ${CC:T:Mclang} == "clang"
+WMAKEENV+= CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ 
-L${WORLDTMP}/usr/lib/" \
+   CXX="${CXX} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ 
-L${WORLDTMP}/usr/lib/"
+.endif
 .if ${MK_CDDL} == "no"
 WMAKEENV+= NO_CTF=1
 .endif
@@ -289,8 +293,11 @@ LIB32WMAKEENV= MACHINE=powerpc MACHINE_ARCH=powerpc \
 .endif
 
 
-LIB32FLAGS=-m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \
-   -isystem ${LIB32TMP}/usr/include/ \
+LIB32FLAGS=-m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT
+.if ${CC:T:Mclang} == "clang"
+LIB32FLAGS+=   -isysroot ${LIB32TMP}/
+.endif
+LIB32FLAGS+=   -isystem ${LIB32TMP}/usr/include/ \
-L${LIB32TMP}/usr/lib32 \
-B${LIB32TMP}/usr/lib32
 
@@ -440,6 +447,11 @@ everything:
@echo "--"
@echo ">>> stage 4.4: building everything"
@echo "--"
+.if ${CC:T:Mclang} == "clang"
+   # mergemaster goes through this but those files do not exist
+   [ ! -e ${WORLDTMP}/usr/bin/as ] || ln -sf ${WORLDTMP}/usr/bin/as 
${WORLDTMP}/usr/lib/as
+   [ ! -

Re: Building world with clang

[Ed Schouten]

Hello Dimitry!

* Dimitry Andric  wrote:
> @@ -408,9 +411,10 @@ static bool getWindowsSDKDir(std::string &path) {
>  
>  void InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple &triple,
>  const HeaderSearchOptions 
> &HSOpts) {
> -#if 0 /* Remove unneeded include paths. */
>// FIXME: temporary hack: hard-coded paths.
> -  AddPath("/usr/local/include", System, true, false, false);
> +#ifndef __FreeBSD__
> +  AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, false);
> +#endif
>  
>// Builtin includes use #include_next directives and should be positioned
>// just prior C include dirs.

Hmmm... Do we really want this? /usr/local/include is omitted from our
compiler include paths on purpose, to prevent accidental linkage against
pieces of software built from ports.

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


pgp8aoYpsSw3U.pgp
Description: PGP signature

Re: Building world with clang

[Dimitry Andric]

On 2010-08-17 13:40, Ed Schouten wrote:
>> +#ifndef __FreeBSD__
>> +  AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, false);
>> +#endif
>>  
>>// Builtin includes use #include_next directives and should be positioned
>>// just prior C include dirs.
> 
> Hmmm... Do we really want this? /usr/local/include is omitted from our
> compiler include paths on purpose, to prevent accidental linkage against
> pieces of software built from ports.

That is why it says "#ifndef __FreeBSD__" :)  I just changed the "#if
0" from the clangbsd tree to this, so it is more palatable for upstream.
___
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: Building world with clang

[Ed Schouten]

* Dimitry Andric  wrote:
> On 2010-08-17 13:40, Ed Schouten wrote:
> >> +#ifndef __FreeBSD__
> >> +  AddPath(CLANG_PREFIX "/usr/local/include", System, true, false, false);
> >> +#endif
> >>  
> >>// Builtin includes use #include_next directives and should be 
> >> positioned
> >>// just prior C include dirs.
> > 
> > Hmmm... Do we really want this? /usr/local/include is omitted from our
> > compiler include paths on purpose, to prevent accidental linkage against
> > pieces of software built from ports.
> 
> That is why it says "#ifndef __FreeBSD__" :)  I just changed the "#if
> 0" from the clangbsd tree to this, so it is more palatable for upstream.

Sorry about that. I only read the `#if 0' part.

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


pgp17lcaec3D1.pgp
Description: PGP signature

Re: Building world with clang

[Bob Bishop]

Hi,

On 17 Aug 2010, at 12:32, Dimitry Andric wrote:

> Hi,
> 
> Since clang has gone into the tree, there has been an effort to get head
> in a state where world can optionally be built with it.
> [...]
> Now, for building clang as the bootstrap compiler, there are basically
> two methods to make it use the correct headers, C startup objects, and
> libraries from the object tree (${WORLDTMP}):
> 
> 1) The "isysroot" method: build a regular version of clang, and make
>   sure WMAKEENV contains something like:
> 
>   CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
>   -L${WORLDTMP}/usr/lib/"
> 
> 2) The "tools-prefix" method: build a special version of clang, that
>   has its default search paths for headers, startup objects and
>   libraries modified, to look for everything under ${WORLDTMP}.
> 
> Method 1) is used in the clangbsd project branch.
> 
> Method 2) is similar to what is used for building the in-tree gcc as
> the bootstrap compiler.  During the cross-tools stage, TOOLS_PREFIX is
> defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in
> search paths get prefixed with it.
> 
> An advantage of method 1) is that it does not require any modifications
> to the compiler, and basically just a few extra command line arguments.
> The same method could probably even be made to work for gcc.
> 
> However, a disadvantage is that the built-in search paths of the
> bootstrap compiler are not entirely disabled by using the -isysroot, -B
> and -L flags,

This could be viewed as a bug ...

> so there is still a chance that headers, objects or
> libraries outside of ${WORLDTMP} will be picked up during the world
> stage.

... and the last thing you want in buildworld is this kind of POLA violation ...

> An advantage of method 2) is that you can be 100% sure all built-in
> search paths of the bootstrap compiler point to directories under
> ${WORLDTMP}.  Of course, a disadvantage is that you have to make some
> modifications to the compiler source itself.

... so, which fix to the compiler do you want to make?

> [etc]

--
Bob Bishop
r...@gid.co.uk




___
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: AR9280 "bb hang" and other

[Rui Paulo]

On 17 Aug 2010, at 12:17, Ian FREISLICH wrote:

> Rui Paulo wrote:
>> 
>> On 17 Aug 2010, at 09:17, Ian FREISLICH wrote:
>>> 2. I'm getting these messages fairly often.  Transmission stops
>>> briefly around these times:
>>> =20
>>> Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80)
>>> Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80)
>>> Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting
>>> Aug 17 09:05:47 mini kernel: ath0: 0x 0x2000 0x, =
>> 0x 0x 0x
>>> Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting
>>> Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting
>>> Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting
>>> Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting
>>> =20
>> 
>> BB hangs are a problem with the 9280 but I don't know how to fix.
> 
> Do you have a card to play with?  (Since I'm offering hardware at the moment)
> 

Yes. What I don't have is time and access to the proper documentation.

Regards,
--
Rui Paulo


___
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: AR9280 "bb hang" and other

[Ian FREISLICH]

Ian FREISLICH wrote:
> Rui Paulo wrote:
> > 
> > BB hangs are a problem with the 9280 but I don't know how to fix.
> 
> Do you have a card to play with?  (Since I'm offering hardware at the moment)
> 
> > Hardware errors shouldn't happen, but this might mean you have very =

Replying to myself - Just got this error:

ath0: ath_chan_set: unable to reset channel 3 (2422 MHz, flags 0x480), hal 
status 14

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: Building world with clang

[Dimitry Andric]

On 2010-08-17 13:49, Bob Bishop wrote:
>> However, a disadvantage is that the built-in search paths of the
>> bootstrap compiler are not entirely disabled by using the -isysroot, -B
>> and -L flags,
> 
> This could be viewed as a bug ...

It is probably a bit more complicated than that.  Let me expand a bit
on those compiler flags (and note that clang tries to mimic gcc's
interpretation of them, but is not always perfect).

The -isysroot option

The -isysroot option is supposed to 'reset' the root for include files
to the specified path, according to the gcc documentation.  If I compile
an empty .c file with "gcc -v -S", the default include paths are
printed:

  /usr/include/gcc/4.2
  /usr/include

If you now add "-isysroot ${WORLDTMP}" (the default value of WORLDTMP is
/usr/obj/usr/src/tmp), the resulting include paths become:

  /usr/include/gcc/4.2
  ${WORLDTMP}/usr/include

So unfortunately, gcc seems to only prepend the isysroot path to one of
the directories.

Clang's default include paths are:

  /usr/include/clang/2.8
  /usr/include

With the same -isysroot option added, they become:

  ${WORLDTMP}/usr/include/clang/2.8
  ${WORLDTMP}/usr/include

E.g. clang does the right thing here.

The -B option
=
The -B option is supposed to "...[specify] where to find the
executables, libraries, include files, and data files of the compiler
itself".  This option is a bit strange, since it is used for finding
both executables (cc1, as, ld), objects (crt*.o) and libraries. 

If you run "gcc -print-search-dirs", it gives its defaults:

  programs: =/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
  libraries: =/usr/lib/:/usr/lib/

When you add -B${WORLDTMP}/usr/libexec/ (where the cross-tools
built cc1 and cc1plus are), it gives:

  programs: 
=${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
  libraries: 
=${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:/usr/lib/:/usr/lib/

Thus, the -B path is prepended (why it does it twice, I do not know;
probably a bug), but the defaults are *not* removed, so there is still a
risk of picking up an incorrect executable.

Note the path is also prepended to the libraries path, which is rather
useless; there are never any .o or .a files in a libexec directory.  To
fix that path up, you would need to add yet *another* -B option, and you
probably also need yet another -B option to make it find the correct as
and ld.  The final command line would then become:

  gcc -B${WORLDTMP}/usr/bin/ -B${WORLDTMP}/usr/libexec/ -B${WORLDTMP}/usr/lib/

giving the following search dirs:

  programs: 
=${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/lib/:${WORLDTMP}/usr/lib/:/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
  libraries: 
=${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/bin/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/libexec/:${WORLDTMP}/usr/lib/:${WORLDTMP}/usr/lib/:/usr/lib/:/usr/lib/

Clang also implements the -B option, but it is not additive yet, so
there is no way to specify both the ${WORLDTMP}/usr/bin directory (for
finding its second stage, as and ld), and ${WORLDTMP}/usr/lib (for
finding startup objects and libraries).

This is also the reason clang-bootstrap-isysroot.diff needs to create
symlinks from ${WORLDTMP}/usr/bin/as and ld to ${WORLDTMP}/usr/lib, as
only the latter directory is specified with -B, and it otherwise would
not be able to find the correct as and ld.

The -L option
=
The -L option just adds the specified directory to the library search
path.  It puts them before the built-in paths, but it does not disable
those either.  Moreover, the -L paths are *not* used to find the CRT
startup objects:

  $ gcc -L${WORLDTMP}/usr/lib -v test.c
  [...]
   /usr/bin/as -o /tmp/ccZcUXwc.o /tmp/ccYTRRrk.s
   /usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o test 
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L${WORLDTMP}/usr/lib 
-L/usr/lib -L/usr/lib /tmp/ccZcUXwc.o -lgcc --as-needed -lgcc_s --no-as-needed 
-lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o

The behaviour of clang is the same for this option, so it does not
improve the situation: it is still possible for libraries outside of
${WORLDTMP} to be found.


>> An advantage of method 2) is that you can be 100% sure all built-in
>> search paths of the bootstrap compiler point to directories under
>> ${WORLDTMP}.  Of course, a disadvantage is that you have to make some
>> modifications to the compiler source itself.
> 
> ... so, which fix to the compiler do you want to make?

My personal preference is method 2), e.g. modify the compiler's
built-in paths, but it is more reasonable to present both methods, and
ask for opinions.  Someone may even know another good method. :)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd

Re: Building world with clang

[Daniel Nebdal]

On Tue, Aug 17, 2010 at 1:49 PM, Bob Bishop  wrote:
> On 17 Aug 2010, at 12:32, Dimitry Andric wrote:
>
>> However, a disadvantage is that the built-in search paths of the
>> bootstrap compiler are not entirely disabled by using the -isysroot, -B
>> and -L flags,
>
> This could be viewed as a bug ...

For clarification, did you (Dimitry, that is) mean
a) The paths are still there so they could resurface if some Makefile
doesn't specify those flags , or
b) they sometimes come into play even when using the appropriate flags?


-- 
Daniel Nebdal
___
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: Building world with clang

[Alexander Kabaev]

On Tue, 17 Aug 2010 13:32:39 +0200
Dimitry Andric  wrote:

> Hi,
> 
> Since clang has gone into the tree, there has been an effort to get
> head in a state where world can optionally be built with it.  A
> number of changes required for this have already been committed,
> mainly thanks to Ed Schouten, Roman Divacky and Rui Paulo.  Most of
> these changes were adapted from the clangbsd project branch.
> 
> There are several other changes in the queue, pending review and/or
> further enhancement, but I would like to solicit your comments about
> one particular set: the changes required to let buildworld use clang
> as the compiler.
> 
> Probably the most logical way to specify that you want world built
> with clang, is to put CC=clang and CXX=clang++ in /etc/src.conf.  Any
> necessary modifications to Makefile.inc1 or bsd.*.mk can then be put
> between conditionals like:
> 
> .if ${CC:T:Mclang} == "clang"
> [...stuff specific to clang...]
> .endif
> 
> so nothing will change for non-clang builds.
> 
> Now, for building clang as the bootstrap compiler, there are basically
> two methods to make it use the correct headers, C startup objects, and
> libraries from the object tree (${WORLDTMP}):
> 
> 1) The "isysroot" method: build a regular version of clang, and make
>sure WMAKEENV contains something like:
> 
>CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
>-L${WORLDTMP}/usr/lib/"
> 
> 2) The "tools-prefix" method: build a special version of clang, that
>has its default search paths for headers, startup objects and
>libraries modified, to look for everything under ${WORLDTMP}.
> 
> Method 1) is used in the clangbsd project branch.
> 
> Method 2) is similar to what is used for building the in-tree gcc as
> the bootstrap compiler.  During the cross-tools stage, TOOLS_PREFIX is
> defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in
> search paths get prefixed with it.
> 
> An advantage of method 1) is that it does not require any
> modifications to the compiler, and basically just a few extra command
> line arguments. The same method could probably even be made to work
> for gcc.
> 
> However, a disadvantage is that the built-in search paths of the
> bootstrap compiler are not entirely disabled by using the -isysroot,
> -B and -L flags, so there is still a chance that headers, objects or
> libraries outside of ${WORLDTMP} will be picked up during the world
> stage.
> 
> An advantage of method 2) is that you can be 100% sure all built-in
> search paths of the bootstrap compiler point to directories under
> ${WORLDTMP}.  Of course, a disadvantage is that you have to make some
> modifications to the compiler source itself.
> 
> I would like to hear your opinions about which method is preferred, or
> if there may be another good way to solve the bootstrap compiler
> issue.
> 
> I have also attached two patches to this mail, which can be applied to
> head, to show the exact set of changes required for each method.
> 

Does method 1) work fine with 'make buildenv'? I doubt that. I would
strongly suggest we should not lose this feature. I do not like the
idea of having to depend on -isystem in CFLAGS in such an environment. 

-- 
Alexander Kabaev


signature.asc
Description: PGP signature

Re: Building world with clang

[Dimitry Andric]

On 2010-08-17 15:03, Daniel Nebdal wrote:
>>> However, a disadvantage is that the built-in search paths of the
>>> bootstrap compiler are not entirely disabled by using the -isysroot, -B
>>> and -L flags,
...
> For clarification, did you (Dimitry, that is) mean
> a) The paths are still there so they could resurface if some Makefile
> doesn't specify those flags , or
> b) they sometimes come into play even when using the appropriate flags?

Any sub-makefiles would not have to specify those flags explicitly,
since they were added to ${CC} and ${CXX}.

But what I meant is that even if you specify those flags, the compiler
still searches for headers and libraries in the base system.  So if some
header is removed from /usr/src, for example, but is still available in
/usr/include, it can be erroneously picked up during buildworld.
___
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: nvidia-driver not work

[John Baldwin]

On Saturday, August 14, 2010 9:35:02 pm Álvaro Castillo wrote:
> $ dmesg (cut)
> 
> panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
> cpuid = 0
> Uptime: 3m35s

Use the latest nvidia driver from the website (256.44) and not from the port.

-- 
John Baldwin
___
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[John Baldwin]

On Monday, August 16, 2010 2:54:56 pm Kostik Belousov wrote:
> On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
> > On 16 August 2010 21:05, pluknet  wrote:
> > > Hi.
> > >
> > > Seeing on mostly idle, recently updated current, while closing a file.
> > > Presumably never reported on ML.
> > >
> > > lock order reversal:
> > >  1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301
> > >  2nd 0xff000234a048 filedesc structure (filedesc structure) @
> > > /usr/src/sys/kern/kern_descrip.c:1580
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > > _witness_debugger() at _witness_debugger+0x2e
> > > witness_checkorder() at witness_checkorder+0x807
> > > _sx_xlock() at _sx_xlock+0x55
> > > fdinit() at fdinit+0x5b
> > > fdcopy() at fdcopy+0x2a
> > > fork1() at fork1+0x836
> > > kproc_create() at kproc_create+0x63
> > > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7
> > > nfs_asyncio() at nfs_asyncio+0xa6
> > > nfs_strategy() at nfs_strategy+0x83
> > > bufstrategy() at bufstrategy+0x43
> > > nfs_writebp() at nfs_writebp+0xcf
> > > nfs_flush() at nfs_flush+0x1dc
> > > nfs_close() at nfs_close+0x213
> > > vn_close() at vn_close+0x10e
> > > vn_closefile() at vn_closefile+0x5a
> > > _fdrop() at _fdrop+0x23
> > > closef() at closef+0x5b
> > > kern_close() at kern_close+0x110
> > > syscallenter() at syscallenter+0x1aa
> > > syscall() at syscall+0x4c
> > > Xfast_syscall() at Xfast_syscall+0xe2
> > > --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp =
> > > 0x7fffea88, rbp = 0 ---
> > >
> > >
> > 
> > Mostly the same (different 2nd lock path).
> > 
> > lock order reversal:
> >  1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301
> >  2nd 0x80ca47e0 proctree (proctree) @ 
/usr/src/sys/kern/kern_fork.c:335
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > _witness_debugger() at _witness_debugger+0x2e
> > witness_checkorder() at witness_checkorder+0x807
> > _sx_slock() at _sx_slock+0x55
> > fork1() at fork1+0x190
> > kproc_create() at kproc_create+0x63
> > nfs_nfsiodnew() at nfs_nfsiodnew+0xd7
> > nfs_asyncio() at nfs_asyncio+0xa6
> > nfs_strategy() at nfs_strategy+0x83
> > bufstrategy() at bufstrategy+0x43
> > nfs_writebp() at nfs_writebp+0xcf
> > nfs_flush() at nfs_flush+0x1dc
> > nfs_close() at nfs_close+0x213
> > vn_close() at vn_close+0x10e
> > vn_closefile() at vn_closefile+0x5a
> > _fdrop() at _fdrop+0x23
> > closef() at closef+0x5b
> > kern_close() at kern_close+0x110
> > syscallenter() at syscallenter+0x1aa
> > syscall() at syscall+0x4c
> > Xfast_syscall() at Xfast_syscall+0xe2
> > --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp =
> > 0x7fffea88, rbp = 0 ---
> > 
> Both LORs are valid. The fork performed deep inside the VFS call stack
> is obviously problematic. As a workaround, you may fix the number of
> nfsiods.
> 
> Proper fix might consist of creating a shepherd thread which only task
> is to act on the requests on creating new nfsiods.
> 
> Would you try to implement this ? I will provide the assistance, if needed.

Or queue a task to create new nfsiod threads instead of invoking 
kproc_create() directly.  That can be cheaper than creating a dedicated 
shepherd thread.

-- 
John Baldwin
___
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: nvidia-driver not work

[Ivan Klymenko]

В Tue, 17 Aug 2010 09:52:50 -0400
John Baldwin  пишет:

> On Saturday, August 14, 2010 9:35:02 pm Álvaro Castillo wrote:
> > $ dmesg (cut)
> > 
> > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
> > cpuid = 0
> > Uptime: 3m35s
> 
> Use the latest nvidia driver from the website (256.44) and not from
> the port.
> 
Here the test port...
___
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: Building world with clang

[Dimitry Andric]

On 2010-08-17 15:15, Alexander Kabaev wrote:
> Dimitry Andric  wrote:
... 
>> 1) The "isysroot" method: build a regular version of clang, and make
>>sure WMAKEENV contains something like:
>>
>>CC="${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
>>-L${WORLDTMP}/usr/lib/"
>>
>> 2) The "tools-prefix" method: build a special version of clang, that
>>has its default search paths for headers, startup objects and
>>libraries modified, to look for everything under ${WORLDTMP}.
...
> Does method 1) work fine with 'make buildenv'? I doubt that. I would
> strongly suggest we should not lose this feature. I do not like the
> idea of having to depend on -isystem in CFLAGS in such an environment. 

I have not tested make buildenv with this method, but since ${CC} is
modified, not ${CFLAGS}, there is a reasonable chance that it might
work. :)

Note a similar method is already being using for the build32 stage on
amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B)
appended.
___
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: Building world with clang

[Daniel Nebdal]

On Tue, Aug 17, 2010 at 3:47 PM, Dimitry Andric  wrote:
> On 2010-08-17 15:03, Daniel Nebdal wrote:
 However, a disadvantage is that the built-in search paths of the
 bootstrap compiler are not entirely disabled by using the -isysroot, -B
 and -L flags,
> ...
>> For clarification, did you (Dimitry, that is) mean
>> a) The paths are still there so they could resurface if some Makefile
>> doesn't specify those flags , or
>> b) they sometimes come into play even when using the appropriate flags?
>
> Any sub-makefiles would not have to specify those flags explicitly,
> since they were added to ${CC} and ${CXX}.
>
> But what I meant is that even if you specify those flags, the compiler
> still searches for headers and libraries in the base system.  So if some
> header is removed from /usr/src, for example, but is still available in
> /usr/include, it can be erroneously picked up during buildworld.
>

Mmh, I just read through the in-detail description you gave in another
mail. It's a bit surprising that there isn't a simple and reliable way
to disable/replace all hardcoded paths, but I guess it doesn't come up
that often.

As a third possibility, hacking a real -drop-all-builtin-paths flag
into the local copies of both compilers could work (essentially being
a cleanup of your alternative 1), though there's still the issues with
-B. All in all, I agree that your alternative 2 sounds better.


-- 
Daniel Nebdal
___
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: Building world with clang

[Dimitry Andric]

On 2010-08-17 16:28, Daniel Nebdal wrote:
> Mmh, I just read through the in-detail description you gave in another
> mail. It's a bit surprising that there isn't a simple and reliable way
> to disable/replace all hardcoded paths, but I guess it doesn't come up
> that often.

Well, except when you want to bootstrap something. :)  I guess this
whole issue is just not as applicable to Linux, where gcc's main
development takes place.


> As a third possibility, hacking a real -drop-all-builtin-paths flag
> into the local copies of both compilers could work

The idea of method 1) is that you do not modify the compiler at all,
making it potentially easier to hook in any new compilers, provided they
are option-compatible with gcc.
___
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: Building world with clang

[Eitan Adler]

On Tue, Aug 17, 2010 at 10:28 AM, Daniel Nebdal  wrote:
> On Tue, Aug 17, 2010 at 3:47 PM, Dimitry Andric  wrote:
>> On 2010-08-17 15:03, Daniel Nebdal wrote:
> However, a disadvantage is that the built-in search paths of the
> bootstrap compiler are not entirely disabled by using the -isysroot, -B
> and -L flags,
>> ...
>>> For clarification, did you (Dimitry, that is) mean
>>> a) The paths are still there so they could resurface if some Makefile
>>> doesn't specify those flags , or
>>> b) they sometimes come into play even when using the appropriate flags?
>>
>> Any sub-makefiles would not have to specify those flags explicitly,
>> since they were added to ${CC} and ${CXX}.
>>
>> But what I meant is that even if you specify those flags, the compiler
>> still searches for headers and libraries in the base system.  So if some
>> header is removed from /usr/src, for example, but is still available in
>> /usr/include, it can be erroneously picked up during buildworld.
>>
>
> Mmh, I just read through the in-detail description you gave in another
> mail. It's a bit surprising that there isn't a simple and reliable way
> to disable/replace all hardcoded paths, but I guess it doesn't come up
> that often.

what about -nostdinc ?
   Do not search the standard system directories for header files.

Or will this also disable the command line equivalents ?






-- 
Eitan Adler
___
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: Official request: Please make GNU grep the default

[Dimitry Andric]

On 2010-08-16 10:55, Dag-Erling Smørgrav wrote:
> Dimitry Andric  writes:
>> - Uses plain file descriptors instead of struct FILE, since the
>>   buffering is done manually anyway, and it makes it easier to support
>>   gzip and bzip2.
> It might be worth a shot adding mmap(2) support as well, i.e. when
> processing an uncompressed regular file, try to mmap(2) it first, and if
> that fails, fall back to the plain buffered read(2) method.

I added a simple mmap to grep, and time-trialed it, but the mmap version
was somewhat slower than the regular version.  I understood from Kostik
Belousov that readahead does not work properly with mmap, and it should
not be used for "one-time" reads.

I also experimented with different buffer sizes on the same big test
file, and this gives the following results (times in s):

buffer size test1   test2   test3   average
=== === === === ===
512 467 484 465 472
  1,024 391 415 392 399
  2,048 361 356 365 361
  4,096 353 353 356 354
  8,192 348 345 357 350
 16,384 341 373 350 354
 32,768 339 348 346 344
 65,536 336 359 371 355
262,144 334 352 350 345
  1,048,576 334 350 351 345
  2,097,152 339 342 369 350
373,293,056 544 547 559 550

E.g. the 32k buffer size that I borrowed from GNU grep seems to be
reasonable enough.  There is no profit in wasting huge amounts of memory
to speed things up.

___
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[pluknet]

2010/8/16 Kostik Belousov :
> On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
>> On 16 August 2010 21:05, pluknet  wrote:
>> > Hi.
>> >
>> > Seeing on mostly idle, recently updated current, while closing a file.
>> > Presumably never reported on ML.
[...]
>>
> Both LORs are valid. The fork performed deep inside the VFS call stack
> is obviously problematic. As a workaround, you may fix the number of
> nfsiods.
>
> Proper fix might consist of creating a shepherd thread which only task
> is to act on the requests on creating new nfsiods.
>
> Would you try to implement this ? I will provide the assistance, if needed.

Hmm.. I tried to move kproc_create() under shepherd thread and now stuck
with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b.
Did I screw up something?
See weird draft patch attached (weird, as I have no idea how to nicely
exchange data between nfs_nfsiodnew() and shep_thread() thread).

load: 1.34  cmd: cp 1348 [bo_wwait] 4.74r 0.00u 0.00s 0% 1204k

tst-web# procstat -k 1348
  PIDTID COMM TDNAME   KSTACK
 1348 100095 cp   -mi_switch sleepq_switch
sleepq_wait _sleep bufobj_wwait nfs_flush nfs_close vn_close
vn_closefile _fdrop closef kern_close syscallenter syscall
Xfast_syscall

Process 1347 (cp) thread 0xff0002ed7000 (100094)
exclusive lockmgr nfs (nfs) r = 0 (0xff006a05a638) locked @
/usr/src/sys/kern/vfs_vnops.c:301

(kgdb) bt
#0  sched_switch (td=0xff0002ed7000, newtd=0x80ca17e0,
flags=Variable "flags" is not available.
)
at /usr/src/sys/kern/sched_ule.c:1848
#1  0x805bf49b in mi_switch (flags=260, newtd=0x0)
at /usr/src/sys/kern/kern_synch.c:449
#2  0x805f50e3 in sleepq_switch (wchan=0xff006a05a720, pri=77)
at /usr/src/sys/kern/subr_sleepqueue.c:530
#3  0x805f5ccd in sleepq_wait (wchan=0xff006a05a720, pri=77)
at /usr/src/sys/kern/subr_sleepqueue.c:609
#4  0x805bfac9 in _sleep (ident=0xff006a05a720,
lock=0xff006a05a6c0, priority=Variable "priority" is not available.
) at /usr/src/sys/kern/kern_synch.c:234
#5  0x80633083 in bufobj_wwait (bo=0xff006a05a6c0,
slpflag=Variable "slpflag" is not available.
)
at /usr/src/sys/kern/vfs_bio.c:4016
#6  0x8077f5af in nfs_flush (vp=0xff006a05a5a0, waitfor=1,
commit=Variable "commit" is not available.
)
at /usr/src/sys/nfsclient/nfs_vnops.c:3216
#7  0x807802e3 in nfs_close (ap=0xff8029bd8900)
at /usr/src/sys/nfsclient/nfs_vnops.c:644
#8  0x8065b3fe in vn_close (vp=0xff006a05a5a0, flags=2,
file_cred=0xff006a01b600, td=0xff0002ed7000) at vnode_if.h:225
#9  0x8065b4fa in vn_closefile (fp=0xff00027c7500,
td=0xff0002ed7000) at /usr/src/sys/kern/vfs_vnops.c:942
#10 0x8057e3e3 in _fdrop (fp=0xff00027c7500, td=Variable
"td" is not available.
) at file.h:277
#11 0x8057ff4b in closef (fp=0xff00027c7500, td=0xff0002ed7000)
at /usr/src/sys/kern/kern_descrip.c:2117
---Type  to continue, or q  to quit---
#12 0x80580530 in kern_close (td=0xff0002ed7000, fd=4)
at /usr/src/sys/kern/kern_descrip.c:1162

-- 
wbr,
pluknet


nfs_shep.diff
Description: Binary data
___
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: Official request: Please make GNU grep the default

[Kostik Belousov]

[Cc: list sanitized]

On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote:
> On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote:
> > Dimitry Andric  writes:
> >> - Uses plain file descriptors instead of struct FILE, since the
> >>   buffering is done manually anyway, and it makes it easier to support
> >>   gzip and bzip2.
> > It might be worth a shot adding mmap(2) support as well, i.e. when
> > processing an uncompressed regular file, try to mmap(2) it first, and if
> > that fails, fall back to the plain buffered read(2) method.
> 
> I added a simple mmap to grep, and time-trialed it, but the mmap version
> was somewhat slower than the regular version.  I understood from Kostik
> Belousov that readahead does not work properly with mmap, and it should
> not be used for "one-time" reads.
This is not exactly what I said. I argue that read-ahead implemented
by vm_faul() is much less efficient that buffer clustering. Also,
the cost of setting user mapping for the one time read is also non-trivial.
The conclusion is right, it is better to use read(2) for one-time read.


pgpNutWnngklZ.pgp
Description: PGP signature

Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[Kostik Belousov]

On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote:
> 2010/8/16 Kostik Belousov :
> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
> >> On 16 August 2010 21:05, pluknet  wrote:
> >> > Hi.
> >> >
> >> > Seeing on mostly idle, recently updated current, while closing a file.
> >> > Presumably never reported on ML.
> [...]
> >>
> > Both LORs are valid. The fork performed deep inside the VFS call stack
> > is obviously problematic. As a workaround, you may fix the number of
> > nfsiods.
> >
> > Proper fix might consist of creating a shepherd thread which only task
> > is to act on the requests on creating new nfsiods.
> >
> > Would you try to implement this ? I will provide the assistance, if needed.
> 
> Hmm.. I tried to move kproc_create() under shepherd thread and now stuck
> with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b.
> Did I screw up something?
> See weird draft patch attached (weird, as I have no idea how to nicely
> exchange data between nfs_nfsiodnew() and shep_thread() thread).
Most likely, you loose the requests to create nfsiods since the
existing request in the global variable shep_chan can be overwritten
by new request. You should either sleep till existing request is serviced,
or form a queue.

Also please take a note of the John' suggestion to use the taskqueue.



pgp3bwnkHmoXg.pgp
Description: PGP signature

Re: ZFS will gone,FreeBSD will import btrfs?

[Olivier Smedts]

2010/8/17 Mark Linimon :
> On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote:
>> opensolaris is gone
>
> It appears there will be a fork, but that's not particularly crucial
> to FreeBSD.
>
>> ZFS also gone.

OpenSolaris is gone, Oracle won't make any OpenSolaris release but
they're still working on Solaris (and maybe ZFS).

But did they close the sources too ? I mean, they have a VCS, can we
still access it and download the ZFS source files ? Did they also
relicense them ?
As for btrfs, don't forget it's GPL, and still not production-ready.
ZFS has a proven reliability, if Oracle drops it because they have
btrfs, I'll be very angry...

> We're not going to drop ZFS because Oracle's plans are unclear.  It
> remains to be seen how much other community support there is behind ZFS.
>
>> Will FreeBSD import btrfs or other similar file system?
>
> >From my observation, it takes about 2 years from the initial work on a
> new filesystem until it's relatively stable, so I don't know why we would
> suddenly decide to go that direction.
>
> mcl
> ___
> 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"
>



-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."
___
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580

[Matthew Fleming]

On Tue, Aug 17, 2010 at 4:04 PM, Kostik Belousov  wrote:
> On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote:
>> 2010/8/16 Kostik Belousov :
>> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
>> >> On 16 August 2010 21:05, pluknet  wrote:
>> >> > Hi.
>> >> >
>> >> > Seeing on mostly idle, recently updated current, while closing a file.
>> >> > Presumably never reported on ML.
>> [...]
>> >>
>> > Both LORs are valid. The fork performed deep inside the VFS call stack
>> > is obviously problematic. As a workaround, you may fix the number of
>> > nfsiods.
>> >
>> > Proper fix might consist of creating a shepherd thread which only task
>> > is to act on the requests on creating new nfsiods.
>> >
>> > Would you try to implement this ? I will provide the assistance, if needed.
>>
>> Hmm.. I tried to move kproc_create() under shepherd thread and now stuck
>> with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b.
>> Did I screw up something?
>> See weird draft patch attached (weird, as I have no idea how to nicely
>> exchange data between nfs_nfsiodnew() and shep_thread() thread).
> Most likely, you loose the requests to create nfsiods since the
> existing request in the global variable shep_chan can be overwritten
> by new request. You should either sleep till existing request is serviced,
> or form a queue.

If you sleep for the request to be serviced, this presumably has the
same LOR/deadlock possibility (unless locks are released before
sleep), except now WITNESS can't see the LOR.

Thanks,
matthew
___
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 will gone,FreeBSD will import btrfs?

[Olivier Smedts]

2010/8/17 Artem Belevich :
>> But did they close the sources too ?
>> I mean, they have a VCS, can we still access it and download the ZFS source 
>> files ?
>
> If I understand Oracle's announcement correctly, sources would still
> be available. The change is that they will stop publishing them
> near-real-time and would release them after corresponding features
> appear in official Solaris release.
>
>> Did they also relicense them ?
> Quote:
> 
> We will not remove the CDDL from any files in Solaris to which it
> already applies, and new source code files that are created will
> follow the current policy regarding applying the CDDL (simply, that
> usr/src files will have the CDDL, and the very small minority of files
> in usr/closed might not have it)
> 
>
> The way I read it ZFS will still be available under CDDL.

Great. That would mean : no change for ZFS in FreeBSD. If Oracle
implements the long-awaited block pointer rewrite feature, we'll be
able to import it :)
I hope they will continue working on it, even if they have btrfs...

>
> --Artem
>

-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."
___
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 will gone,FreeBSD will import btrfs?

[Astrodog]

On Tue, Aug 17, 2010 at 10:44 AM, Olivier Smedts  wrote:
> 2010/8/17 Mark Linimon :
>> On Tue, Aug 17, 2010 at 12:21:07PM +0800, lhmwzy wrote:
>>> opensolaris is gone
>>
>> It appears there will be a fork, but that's not particularly crucial
>> to FreeBSD.
>>
>>> ZFS also gone.
>
> OpenSolaris is gone, Oracle won't make any OpenSolaris release but
> they're still working on Solaris (and maybe ZFS).
>
> But did they close the sources too ? I mean, they have a VCS, can we
> still access it and download the ZFS source files ? Did they also
> relicense them ?
> As for btrfs, don't forget it's GPL, and still not production-ready.
> ZFS has a proven reliability, if Oracle drops it because they have
> btrfs, I'll be very angry...
>
>> We're not going to drop ZFS because Oracle's plans are unclear.  It
>> remains to be seen how much other community support there is behind ZFS.
>>
>>> Will FreeBSD import btrfs or other similar file system?
>>
>> >From my observation, it takes about 2 years from the initial work on a
>> new filesystem until it's relatively stable, so I don't know why we would
>> suddenly decide to go that direction.
>>
>> mcl

Assuming, for the moment, that there is no other support behind ZFS, I
don't see why one would want to remove it from FreeBSD. It fills a
useful gap, as far as filesystems on FreeBSD go, and if it came down
to it, atleast for the foreseeable future, it would be worth
supporting alone. It's not like anyone thinks FreeBSD should toss out
UFS2, just because not many other OSes use it. The same holds true for
DTrace. It's useful to have, Solaris or no Solaris.

OpenSolaris dying shouldn't have a big impact on where FreeBSD goes
with these tools, as long as they continue to be useful for the
community and the developers, and aren't hampering development
elsewhere.
___
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: nvidia-driver not work

[Ivan Klymenko]

> >>> $ dmesg (cut)
> >>>
> >>> panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
> >>> cpuid = 0
> >>> Uptime: 3m35s
> >>
> >> Use the latest nvidia driver from the website (256.44) and not from
> >> the port.
> >>
> > Here the test port...
> 
> Sorry, I am afraid there is no attachment

another attempt...
___
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 will gone,FreeBSD will import btrfs?

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/08/16 21:21, lhmwzy wrote:
> opensolaris is gone,ZFS also gone.

It's not "gone" since Oracle can not withdraw code that is already
licensed under CDDL.  They _may_ choose not to release anything new but
we already have a newer zfs version that have basic functionality usable
in p4.

> Will FreeBSD import btrfs or other similar file system?

Not until someone(TM) sit down and work on it.

Cheers,
- -- 
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMar0EAAoJEATO+BI/yjfB56sH/0kp+vWpiomiC7GKp6q8RFis
wH+VTdh0HJbxeguXX89otUbHwQ5bm4XdxKl1PCUH7HFAkbUgKxkhRLGQAefMiGQE
yqH+IVY3hT4qWpPaFkXadzx7TKyP/zEbrKOSdf+9zjMu64RCipmfH3PvqoZn7fVu
KLQPUdeWhAY63MsFI7fAoLRqCckWS6YpcQrGcQhKqJ5TGPkXh50Ww3ZUGN9dGUvZ
Ik2+SEXscBjB/lKjxurkBruqwJkrowUTORUcD5RQrb2hYJEQdkFEpYBk0RXVYNuX
61uNGgUGM9/PUnqSA+ddU5sckFLk/9lyj/+TVk5eEqaskSOHi+DKL+xSE1U1cqs=
=Zq75
-END PGP SIGNATURE-
___
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: Official request: Please make GNU grep the default

[Alan Cox]

2010/8/17 Dimitry Andric 

> On 2010-08-16 10:55, Dag-Erling Smørgrav wrote:
> > Dimitry Andric  writes:
> >> - Uses plain file descriptors instead of struct FILE, since the
> >>   buffering is done manually anyway, and it makes it easier to support
> >>   gzip and bzip2.
> > It might be worth a shot adding mmap(2) support as well, i.e. when
> > processing an uncompressed regular file, try to mmap(2) it first, and if
> > that fails, fall back to the plain buffered read(2) method.
>
> I added a simple mmap to grep, and time-trialed it, but the mmap version
> was somewhat slower than the regular version.  I understood from Kostik
> Belousov that readahead does not work properly with mmap, and it should
> not be used for "one-time" reads.
>
>

Try it again on a memory resident file with the MAP_PREFAULT_READ option
that is provided by this patch:

http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch

Regards,
Alan
___
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 will gone,FreeBSD will import btrfs?

[Artem Belevich]

> But did they close the sources too ?
> I mean, they have a VCS, can we still access it and download the ZFS source 
> files ?

If I understand Oracle's announcement correctly, sources would still
be available. The change is that they will stop publishing them
near-real-time and would release them after corresponding features
appear in official Solaris release.

> Did they also relicense them ?
Quote:

We will not remove the CDDL from any files in Solaris to which it
already applies, and new source code files that are created will
follow the current policy regarding applying the CDDL (simply, that
usr/src files will have the CDDL, and the very small minority of files
in usr/closed might not have it)


The way I read it ZFS will still be available under CDDL.

--Artem
___
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: nvidia-driver not work

[Rainer Hurling]

On 17.08.2010 16:11 (UTC+1), Ivan Klymenko wrote:

В Tue, 17 Aug 2010 09:52:50 -0400
John Baldwin  пишет:


On Saturday, August 14, 2010 9:35:02 pm Álvaro Castillo wrote:

$ dmesg (cut)

panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
cpuid = 0
Uptime: 3m35s


Use the latest nvidia driver from the website (256.44) and not from
the port.


Here the test port...


Sorry, I am afraid there is no attachment
___
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: Official request: Please make GNU grep the default

[Alan Cox]

On Tue, Aug 17, 2010 at 10:45 AM, Kostik Belousov wrote:

> [Cc: list sanitized]
>
> On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote:
> > On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote:
> > > Dimitry Andric  writes:
> > >> - Uses plain file descriptors instead of struct FILE, since the
> > >>   buffering is done manually anyway, and it makes it easier to support
> > >>   gzip and bzip2.
> > > It might be worth a shot adding mmap(2) support as well, i.e. when
> > > processing an uncompressed regular file, try to mmap(2) it first, and
> if
> > > that fails, fall back to the plain buffered read(2) method.
> >
> > I added a simple mmap to grep, and time-trialed it, but the mmap version
> > was somewhat slower than the regular version.  I understood from Kostik
> > Belousov that readahead does not work properly with mmap, and it should
> > not be used for "one-time" reads.
> This is not exactly what I said. I argue that read-ahead implemented
> by vm_faul() is much less efficient that buffer clustering. Also,
> the cost of setting user mapping for the one time read is also non-trivial.
> The conclusion is right, it is better to use read(2) for one-time read.
>

The mapping (and unmapping) costs should be relatively small if the contents
of the file can be prefaulted using 2/4MB pages.  In such cases, we still
touch every struct vm_page in the 2/4MB region, but we only create and
destroy one PTE and PV entry, and perform a single INVLPG.

Alan
___
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: Building world with clang

[Dimitry Andric]

On 2010-08-17 17:04, Eitan Adler wrote:
> what about -nostdinc ?
>Do not search the standard system directories for header files.
> 
> Or will this also disable the command line equivalents ?

It seems that -isysroot doesn't work with that:

  $ gcc -nostdinc -isysroot ${WORLDTMP} -S -v test.c
  [...]
  #include "..." search starts here:
  #include <...> search starts here:
  End of search list.

So you have to cumbersomely specify all needed include directories by
hand instead:

  $ gcc -nostdinc -isystem ${WORLDTMP}/usr/include/gcc/4.2 -isystem 
${WORLDTMP}/usr/include -S -v testc
  [...]
  #include "..." search starts here:
  #include <...> search starts here:
   ${WORLDTMP}/usr/include/gcc/4.2
   ${WORLDTMP}/usr/include
  End of search list.

An alternative that almost works properly, is when you use multiple -B
options:
- The first pointing to ${WORLDTMP}/usr/bin, where as and ld live
- The second pointing to ${WORLDTMP}/usr/libexec, where cc1, cc1obj and
  cc1plus live
- The third pointing to ${WORLDTMP}/usr/lib, where the startup objects
  and the libraries live
This results in:

  $ gcc -B${WORLDTMP}/usr/bin -B${WORLDTMP}/usr/libexec -B${WORLDTMP}/usr/lib 
-v test.c -o test
  Using built-in specs.
  Target: i386-undermydesk-freebsd
  Configured with: FreeBSD/i386 system compiler
  Thread model: posix
  gcc version 4.2.1 20070719  [FreeBSD]
   ${WORLDTMP}/usr/libexec/cc1 -quiet -v -D_LONGLONG test.c -quiet -dumpbase 
test.c -auxbase test -version -o /tmp/cceCBnL1.s
  #include "..." search starts here:
  #include <...> search starts here:
   ${WORLDTMP}/usr/include/gcc/4.2
   ${WORLDTMP}/usr/include
  End of search list.
  GNU C version 4.2.1 20070719  [FreeBSD] (i386-undermydesk-freebsd)
  compiled by GNU C version 4.2.1 20070719  [FreeBSD].
  GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128948
  Compiler executable checksum: c9b7cdb24796993b910f114335b27daf
   ${WORLDTMP}/usr/bin/as -o /tmp/ccTZPpZn.o /tmp/cceCBnL1.s
   ${WORLDTMP}/usr/bin/ld --eh-frame-hdr -V -dynamic-linker 
/libexec/ld-elf.so.1 -o test ${WORLDTMP}/usr/lib/crt1.o 
${WORLDTMP}/usr/lib/crti.o ${WORLDTMP}/usr/lib/crtbegin.o -L${WORLDTMP}/usr/bin 
-L${WORLDTMP}/usr/bin -L${WORLDTMP}/usr/libexec -L${WORLDTMP}/usr/libexec 
-L${WORLDTMP}/usr/lib -L${WORLDTMP}/usr/lib -L/usr/lib -L/usr/lib 
/tmp/ccTZPpZn.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed 
-lgcc_s --no-as-needed ${WORLDTMP}/usr/lib/crtend.o ${WORLDTMP}/usr/lib/crtn.o
  GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
 elf_i386_fbsd

The include directories have been completely reset, but unfortunately
you can still see the default library directory /usr/lib in there.

Yet another alternative is to use the COMPILER_PATH and LIBRARY_PATH
environment variables, which can contain colon-separated directories:

  $ COMPILER_PATH=${WORLDTMP}/usr/bin:${WORLDTMP}/usr/libexec 
LIBRARY_PATH=${WORLDTMP}/usr/lib gcc -v hello.c -o hello
  Using built-in specs.
  Target: i386-undermydesk-freebsd
  Configured with: FreeBSD/i386 system compiler
  Thread model: posix
  gcc version 4.2.1 20070719  [FreeBSD]
   ${WORLDTMP}/usr/libexec/cc1 -quiet -v -D_LONGLONG test.c -quiet -dumpbase 
test.c -auxbase test -version -o /tmp/cciXQvhb.s
  #include "..." search starts here:
  #include <...> search starts here:
   ${WORLDTMP}/usr/include/gcc/4.2
   ${WORLDTMP}/usr/include
  End of search list.
  GNU C version 4.2.1 20070719  [FreeBSD] (i386-undermydesk-freebsd)
  compiled by GNU C version 4.2.1 20070719  [FreeBSD].
  GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128948
  Compiler executable checksum: c9b7cdb24796993b910f114335b27daf
   ${WORLDTMP}/usr/bin/as -o /tmp/ccKJZI5V.o /tmp/cciXQvhb.s
   ${WORLDTMP}/usr/bin/ld --eh-frame-hdr -V -dynamic-linker 
/libexec/ld-elf.so.1 -o test ${WORLDTMP}/usr/lib/crt1.o 
${WORLDTMP}/usr/lib/crti.o ${WORLDTMP}/usr/lib/crtbegin.o -L${WORLDTMP}/usr/lib 
-L${WORLDTMP}/usr/lib -L/usr/lib -L/usr/lib /tmp/ccKJZI5V.o -lgcc --as-needed 
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed 
${WORLDTMP}/usr/lib/crtend.o ${WORLDTMP}/usr/lib/crtn.o
  GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
 elf_i386_fbsd

Conclusion: it looks like there is no working option to disable the
built-in library directory /usr/lib.
___
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 powerpc/powerpc64

[FreeBSD Tinderbox]

TB --- 2010-08-17 17:55:45 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-17 17:55:45 - starting HEAD tinderbox run for powerpc/powerpc64
TB --- 2010-08-17 17:55:45 - mkdir /tinderbox/HEAD/powerpc/powerpc64
TB --- 2010-08-17 17:55:45 - cleaning the object tree
TB --- 2010-08-17 17:55:45 - cvsupping the source tree
TB --- 2010-08-17 17:55:45 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc/powerpc64/supfile
TB --- 2010-08-17 18:01:06 - building world
TB --- 2010-08-17 18:01:06 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-08-17 18:01:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-08-17 18:01:06 - TARGET=powerpc64
TB --- 2010-08-17 18:01:06 - TARGET_ARCH=powerpc
TB --- 2010-08-17 18:01:06 - TZ=UTC
TB --- 2010-08-17 18:01:06 - __MAKE_CONF=/dev/null
TB --- 2010-08-17 18:01:06 - cd /src
TB --- 2010-08-17 18:01:06 - /usr/bin/make -B buildworld
"/src/Makefile.inc1", line 139: Unknown target powerpc:powerpc64.
*** Error code 1

Stop in /src.
TB --- 2010-08-17 18:01:06 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-08-17 18:01:06 - ERROR: failed to build world
TB --- 2010-08-17 18:01:06 - 12.50 user 39.09 system 321.75 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc64.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: nvidia-driver not work

[Álvaro Castillo]

[Solved] The problem, is a driver of the port "nvidia-driver", i used the
test port (said me Ivan)
В Tue, 17 Aug 2010 09:52:50 -0400
John Baldwin  пишет:
- Show quoted text -
Here the test port... nvidia-driver.256.44.port.tar.bz2
5K Download

I upload the file in this URL
http://rapidshare.com/files/413522883/nvidia-driver.256.44.port.tar.bz2
MD5: F4167FAFAFD76C8FE9AA067877F8DE1A

Have got nvidia geforce 8200
Thanks all


On 15 August 2010 02:35, Álvaro Castillo  wrote:

> Hello all
>
> I installed the FreeBSD/amd64 8.0 and updated to 9-CURRENT with csup
>
> Following...
> # cp /usr/share/examples/cvsup/standard-supfile /root && cd /root && sed
> -ie 's/CHANGE_THIS/cvsup.de/g' standard-supfile && sed -ie
> 's/CHANGE_THIS/./g' standard-supfile && csup -g -L 2 /root/standard-supfile
>
> Downloaded files...
>
> # cd /usr/src && make buildworld
>
> All good, now, i compiled the kernel with my conf
>
> # cd /usr/src/sys/amd64/conf && mdkir /root/kernels && cp GENERIC
> /root/kernels/SPACE && ee /root/kernels/SPACE && ln -s /root/kernels/SPACE
> && cd /usr/src && make buildkernel KERNCONF=SPACE && make installkernel
> KERNCONF=SPACE
>
> This is my kernel
>
> http://pastebin.com/1NpvzNp6
>
> $ dmesg (cut)
>
> panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
> cpuid = 0
> Uptime: 3m35s
>
> Dump failed. Partition too small.
> Automatic reboot in 15 seconds - press a key on the console to abort
> panic: bufwrite: buffer is not busy???
> cpuid = 0
> Uptime: 3m35s
> Copyright (c) 1992-2010 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 9.0-CURRENT #0: Sat Aug 14 19:58:17 WEST 2010
> t...@x0term.lan:/usr/obj/usr/src/sys/SPACE amd64
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3015.07-MHz K8-class
> CPU)
> Origin = "AuthenticAMD" Id = 0x40f33 Family = f Model = 43 Stepping = 3
>
> Features=0x178bfbff
> Features2=0x2001
> AMD Features=0xea500800
> AMD Features2=0x1f
> real memory = 4294967296 (4096 MB)
>
>
> vgapci0:  port 0xec00-0xec7f mem
> 0xfd00-0xfdff,0xf000-0xf7ff,0xfa00-0xfbff irq 21 at
> device 0.0 on pci2
> nvidia0:  on vgapci0
> vgapci0: child nvidia0 requested pci_enable_busmaster
> vgapci0: child nvidia0 requested pci_enable_io
> vgapci0: child nvidia0 requested pci_enable_io
> nvidia0: [ITHREAD]
>
>
> I compiled to nvidia-driver next to install kernel, and i charge to this,
> here good, work, but i try $ startx with Driver "nvidia" on xorg.conf and
> the pc is not responding, screen is black.
> With nv and vesa work.
> I dont understand this -> Dump failed. Partition too small. -> My root
> partition has got a 435GB only ocupated 17GB and swap 512MB
>
> Can help me? This is a primary failed to nvidia-driver
>
___
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: nvidia-driver not work

[Rainer Hurling]

On 17.08.2010 18:47 (UTC+1), Ivan Klymenko wrote:

$ dmesg (cut)

panic: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:1759
cpuid = 0
Uptime: 3m35s


Use the latest nvidia driver from the website (256.44) and not from
the port.


Here the test port...


Sorry, I am afraid there is no attachment


another attempt...


Thanks for the test port. It works like a charm for me :-)

This is on recent FreeBSD 9.0-CURRENT (amd64) with 4GB RAM and NVidia 
GeForce 9800GT.

___
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: Official request: Please make GNU grep the default

[Dimitry Andric]

On 2010-08-17 18:29, Alan Cox wrote:
> Try it again on a memory resident file with the MAP_PREFAULT_READ option
> that is provided by this patch:
> 
> http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch

A time trial gives:

  grep with normal mmap()   1396s
  grep with prefault mmap() 1354s
  grep with regular read()  1354s

So normal mmap is ~3% slower, and prefault mmap does not seem to make
any measurable difference.  I guess the added complexity is not really
worth it, for now.
___
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: Official request: Please make GNU grep the default

[Alan Cox]

On Tue, Aug 17, 2010 at 3:29 PM, Dimitry Andric  wrote:

> On 2010-08-17 18:29, Alan Cox wrote:
> > Try it again on a memory resident file with the MAP_PREFAULT_READ option
> > that is provided by this patch:
> >
> > http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch
>
> A time trial gives:
>
>  grep with normal mmap()   1396s
>  grep with prefault mmap() 1354s
>  grep with regular read()  1354s
>
> So normal mmap is ~3% slower, and prefault mmap does not seem to make
> any measurable difference.  I guess the added complexity is not really
> worth it, for now.
>

Do you know what fraction of this time is being spent in the kernel?  Does
the value of "sysctl vm.pmap.pde.mappings" increase as a result of your
test?  If not, there is still room for improvement in the results with
mmap().

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