Re: New NVidia drivers on -current

[Kris Kennaway]

On Mon, Nov 18, 2002 at 01:29:12AM -0500, Mikhail Teterin wrote:
> Has anyone tried them yet? After removing the #error triggered by
> __FreeBSD_version being over 50, I got the thing nvidia.ko to build,
> but:
> 
> 00:50:30 aldan shutdown: reboot by root: New world, kernel. Nvidia drivers 
> 00:56:12 aldan kernel: Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc06470b0.
> 00:56:12 aldan kernel: VESA: NVidia
> 00:56:12 aldan kernel: VESA: NVidia Corporation NV15 Reference Board Chip Rev A0
> 00:56:14 aldan kernel: nvidia0:  mem 
>0xf000-0xf7ff,0xe900-0xe9ff irq 11 at device 0.0 on pci1
> 00:56:14 aldan kernel: pcib1: device nvidia0 requested decoded memory range 
>0xe900-0xe9ff
> 00:56:14 aldan kernel: pcib1: device nvidia0 requested unsupported memory range 
>0x0-0xe9ff (decoding 0xe900-0xe9ff, 0xf000-0xf7ff)
> 00:56:14 aldan kernel: nvidia0: Unable to allocate NVIDIA memory resource.
> 00:56:14 aldan kernel: device_probe_and_attach: nvidia0 attach returned 6
> 
> Any clues, or is, indeed, a major porting effort required to get it to
> work on -current? Thanks!

Try putting this in your loader.conf:

hw.pci.allow_unsupported_io_range=1

This allowed the device to probe for me, but the system locks up when
I try and start X.

Kris



msg46846/pgp0.pgp
Description: PGP signature

Re: boot0cfg -B

[Marcel Moolenaar]

On Mon, Nov 18, 2002 at 05:07:08PM +1030, Wilkinson,Alex wrote:
> Howdy crew,
> 
> Any reason why this doesn't work ?
> 
> sheel>sudo boot0cfg -B ad0
> boot0cfg: /dev/ad0: Operation not permitted
> 
> running: FreeBSD 5.0-CURRENT #0: Fri Nov  8 15:07:18 CST 2002

GEOM, I presume?
When file systems are mounted, GEOM does not allow processes to
open the device special files for writing. This needs to be
resolved. It is a known limitation and there's no work-around
as far as I know.

HTH,

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: X problems

[Joe Marcus Clarke]

On Sun, 2002-11-17 at 22:39, wsk wrote:
> if set the locale with zh_CN.EUC ,error occured
> --xconsole:
> pid 492 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> pid 494 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> pid 496 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> pid 498 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> pid 500 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> pid 502 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> pid 504 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)

The problem looks to be a corrupt msgstr in zh_CN.po.  The string in
question is:

# SUN CHANGED MESSAGE
#: server/object-directory-load.c:111
#, c-format
msgid "invalid character '%c' in iid '%s'"

I'm leaving for a business trip tomorrow, so I can't pursue this right
now.  However, I have collected a backtrace with full symbols, and if
anyone wants to pursue this with the bonobo-activation developers. 
Note, backing down to rev 1.14 of zh_CN.po fixes the problem.  A gzip'd
patch is attached.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc



patch-po_zh_CN.po.gz
Description: GNU Zip compressed data


signature.asc
Description: This is a digitally signed message part

Re: New NVidia drivers on -current

[Munish Chopra]

On 2002-11-18 01:29 +, Mikhail Teterin wrote:
> Has anyone tried them yet? After removing the #error triggered by
> __FreeBSD_version being over 50, I got the thing nvidia.ko to build,
> but:
> 
> 00:50:30 aldan shutdown: reboot by root: New world, kernel. Nvidia drivers 
> 00:56:12 aldan kernel: Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc06470b0.
> 00:56:12 aldan kernel: VESA: NVidia
> 00:56:12 aldan kernel: VESA: NVidia Corporation NV15 Reference Board Chip Rev A0
> 00:56:14 aldan kernel: nvidia0:  mem 
>0xf000-0xf7ff,0xe900-0xe9ff irq 11 at device 0.0 on pci1
> 00:56:14 aldan kernel: pcib1: device nvidia0 requested decoded memory range 
>0xe900-0xe9ff
> 00:56:14 aldan kernel: pcib1: device nvidia0 requested unsupported memory range 
>0x0-0xe9ff (decoding 0xe900-0xe9ff, 0xf000-0xf7ff)
> 00:56:14 aldan kernel: nvidia0: Unable to allocate NVIDIA memory resource.
> 00:56:14 aldan kernel: device_probe_and_attach: nvidia0 attach returned 6
> 
> Any clues, or is, indeed, a major porting effort required to get it to
> work on -current? Thanks!
> 
>   -mi
>

http://www.thirteenandtwo.org/nvidia/faq.html

The box is currently down, since somone decided to upgrade it to
-CURRENT and messed up, but Marc Fonvieille was nice enough to put it up
here until tomorrow or so:

http://people.freebsd.org/~blackend/nvidia/faq.html (missing style
sheet, but oh well).

Basically it works fine on -CURRENT, what you are seeing could be
because you have something interfering (anything from ACPI to some old
ISA device), but most likely you are missing SYSVSHM or don't have
sufficiently new X binaries (you need 4.2.1 -Servers, -clients and
-libraries).

If none of the above works, mdodd@ can most likely give you a better
answer.

-- 
Munish Chopra

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

boot0cfg -B

[Wilkinson,Alex]

Howdy crew,

Any reason why this doesn't work ?

sheel>sudo boot0cfg -B ad0
boot0cfg: /dev/ad0: Operation not permitted

running: FreeBSD 5.0-CURRENT #0: Fri Nov  8 15:07:18 CST 2002

Thanks

 - aW


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

New NVidia drivers on -current

[Mikhail Teterin]

Has anyone tried them yet? After removing the #error triggered by
__FreeBSD_version being over 50, I got the thing nvidia.ko to build,
but:

00:50:30 aldan shutdown: reboot by root: New world, kernel. Nvidia drivers 
00:56:12 aldan kernel: Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc06470b0.
00:56:12 aldan kernel: VESA: NVidia
00:56:12 aldan kernel: VESA: NVidia Corporation NV15 Reference Board Chip Rev A0
00:56:14 aldan kernel: nvidia0:  mem 
0xf000-0xf7ff,0xe900-0xe9ff irq 11 at device 0.0 on pci1
00:56:14 aldan kernel: pcib1: device nvidia0 requested decoded memory range 
0xe900-0xe9ff
00:56:14 aldan kernel: pcib1: device nvidia0 requested unsupported memory range 
0x0-0xe9ff (decoding 0xe900-0xe9ff, 0xf000-0xf7ff)
00:56:14 aldan kernel: nvidia0: Unable to allocate NVIDIA memory resource.
00:56:14 aldan kernel: device_probe_and_attach: nvidia0 attach returned 6

Any clues, or is, indeed, a major porting effort required to get it to
work on -current? Thanks!

-mi

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Run two copies of named from rc.conf?

[Terry Lambert]

John De Boskey wrote:
> It would be nice if rc.conf could start a 2nd copy
> of named (split dns). Comments on the following simplistic
> patch?

Interior and exterior DNS is a useful case; however, there
are multiple ways to set it up; in general, it's not possible
to have interior authoritative DNS at the same time you have
exterior authoritative DNS (this was a mistake we made on the
InterJet, for a long time), without modifying the DNS server
to forward requests for which it has incomplete information
(e.g. the "PNS" draft RFC I wrote).

See the files in:

ftp://ftp.whistle.com/pub/terry/drafts/

for details.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP stability ? [was Re: more info from panic from running dneton SMP kernel]

[Bruce Evans]

On Sun, 17 Nov 2002, Robert Watson wrote:

> I've seen several reports that using a serial break to get into ddb is now
> quite a bit more reliable than a keyboard break.  If you're not already

This is a fact.  In RELENG_4, the keyboard interrupt handler is a
normal tty interrupt handler so it can't interrupt things blocked by
spltty(), while the sio interrupt handler is a fast interrupt handler
so it can interrupt almost anything (anything not blocked by disable_intr(),
which should be everything except fast interrupt handlers and the entry
code for normal interrupt handlers).  Things are much more broken in
-current: the keyboard interrupt handler is non-MPSAFE so it can't
interrupt things blocked by Giant (which is most syscalls), and the
sio interrupt handler is a "fast" interrupt handler so it can't interrupt
things blocked by critical_enter() (which is too many things for too
long, so fast interrupt handlers aren't actually fast).

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Run two copies of named from rc.conf?

[Juli Mallett]

* De: Doug Barton <[EMAIL PROTECTED]> [ Data: 2002-11-17 ]
[ Subjecte: Re: Run two copies of named from rc.conf? ]
> John De Boskey wrote:
> > 
> > It would be nice if rc.conf could start a 2nd copy
> > of named (split dns).
> 
> IMO, running two named's on the same box is an edge case, and not likely
> to be attractive to the majority of our userbase. I think you might be
> better off with something in /usr/local/etc/rc.d.

Or at least abstracting it in such a way that it doesn't get in anyone's
way, and so it won't trigger the "what if I need N" where N>2 case, and
in some meaningful way...  Like maybe using a named_configs lists, and
start one named for each config, or something.
-- 
Juli Mallett <[EMAIL PROTECTED]>
OpenDarwin, Mono, FreeBSD Developer.
ircd-hybrid Developer, EFnet addict.
FreeBSD on MIPS-Anything on FreeBSD.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Run two copies of named from rc.conf?

[Doug Barton]

John De Boskey wrote:
> 
> It would be nice if rc.conf could start a 2nd copy
> of named (split dns).

IMO, running two named's on the same box is an edge case, and not likely
to be attractive to the majority of our userbase. I think you might be
better off with something in /usr/local/etc/rc.d.

Doug

-- 
   "We have known freedom's price. We have shown freedom's power.
  And in this great conflict, ...  we will see freedom's victory."
- George W. Bush, President of the United States
  State of the Union, January 28, 2002

 Do YOU Yahoo!?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Run two copies of named from rc.conf?

[John De Boskey]

It would be nice if rc.conf could start a 2nd copy
of named (split dns). Comments on the following simplistic
patch?

-John

cvs diff: Diffing src/etc
Index: src/etc/rc.network
===
RCS file: /home/ncvs/src/etc/rc.network,v
retrieving revision 1.138
diff -u -r1.138 rc.network
--- src/etc/rc.network  2 Nov 2002 08:21:26 -   1.138
+++ src/etc/rc.network  18 Nov 2002 04:22:00 -
@@ -24,7 +24,7 @@
 # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 # SUCH DAMAGE.
 #
-# $FreeBSD$
+# $FreeBSD: src/etc/rc.network,v 1.138 2002/11/02 08:21:26 ume Exp $
 #  From: @(#)netstart  5.9 (Berkeley) 3/30/91
 #
 
@@ -561,6 +561,11 @@
case ${named_enable} in
[Yy][Ee][Ss])
echo -n ' named';   ${named_program:-named} ${named_flags}
+   ;;
+   esac
+   case ${named_enable2} in
+   [Yy][Ee][Ss])
+   echo -n ' named';   ${named_program2:-named}
${named_flags2}
;;
esac
 
cvs diff: Diffing src/etc/defaults
Index: src/etc/defaults/rc.conf
===
RCS file: /home/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.163
diff -u -r1.163 rc.conf
--- src/etc/defaults/rc.conf15 Nov 2002 08:26:36 -  1.163
+++ src/etc/defaults/rc.conf18 Nov 2002 04:25:01 -
@@ -13,7 +13,7 @@
 #
 # All arguments must be in double or single quotes.
 #
-# $FreeBSD$
+# $FreeBSD: src/etc/defaults/rc.conf,v 1.163 2002/11/15 08:26:36 ru Exp $
 
 ##
 ###  Important initial Boot-time options  
@@ -140,6 +140,10 @@
# components of named. See /etc/rc.d/named.
 named_symlink_enable="YES" # Symlink /var/run/named.pid and /var/run/ndc
# to their chrooted counterparts.
+
+named_enable2="NO" # Run a 2nd copy of named?
+named_program2="/usr/sbin/named"
+named_flags2="-u bind -g bind"
 
 #
 # kerberos. Do not run the admin daemons on slave servers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

X problems

[suken woo]

hi,all:
sorry the send before
if set the locale with zh_CN.EUC ,error occured
--xconsole:
> > pid 492 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> > pid 494 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> > pid 496 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> > pid 498 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> > pid 500 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> > pid 502 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> > pid 504 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
> > --.xsessesion-errors
> > _IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
> > SESSION_MANAGER=local/wsk.gddsn.org.cn:/tmp/.ICE-unix/485
> > Loaded background '0x809d840
> > Gnome-Message: gnome_execute_async_with_env_fds: returning -1
> > ICE default IO error handler doing an exit(), pid = 514, errno = 0
> > ICE default IO error handler doing an exit(), pid = 516, errno = 0
> > 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

X problems

[wsk]

if set the locale with zh_CN.EUC ,error occured
--xconsole:
pid 492 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 494 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 496 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 498 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 500 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 502 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
pid 504 (bonobo-activation-s), uid 1001: exited on signal 11 (core dumped)
--.xsessesion-errors
_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
SESSION_MANAGER=local/wsk.gddsn.org.cn:/tmp/.ICE-unix/485
Loaded background '0x809d840
Gnome-Message: gnome_execute_async_with_env_fds: returning -1
ICE default IO error handler doing an exit(), pid = 514, errno = 0
ICE default IO error handler doing an exit(), pid = 516, errno = 0




N…'²æìr¸›zǧvf¢–Ú&j:+v‰¨·ž è®"¶§²æìr¸›yúÞy»rêëz{bžØ^n‡r¡ûazg¬±¨

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Sun Nov 17 15:07:23 PST 2002
--
===> vinum
/h/des/src/sys/kern/kern_thread.c: In function `kse_create':
/h/des/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in this 
function)
/h/des/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is reported only 
once
/h/des/src/sys/kern/kern_thread.c:498: for each function it appears in.)
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/GENERIC.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sparc64 tinderbox failure

[Julian Elischer]

On Sun, 17 Nov 2002, Jake Burkholder wrote:

> Apparently, On Sun, Nov 17, 2002 at 12:23:20PM -0800,
>   Julian Elischer said words to the effect of;
> 
> > 
> > 
> > On Sun, 17 Nov 2002, Mike Barcroft wrote:
> > > --
> > > >>> Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002
> > > --
> > > ===> ipfilter
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create':
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first 
>use in this function)
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier 
>is reported only once
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears 
>in.)
> > 
> > 
> > ok mea culpa..
> > 
> > what is there in SPARC that should be used instead..?
> 
> mp_ncpus is defined in sys/smp.h which is not included kern_thread.c
> I don't see why this builds on any platform.
> 
#if 0  /* while debugging */ 
#ifdef SMP
if (kg->kg_kses > mp_ncpus)
#endif
return (EPROCLIM);
#endif
(last night)
seems to have changed in the last 12 hours to:
#ifdef SMP
if (kg->kg_kses > mp_ncpus)
#endif
return (EPROCLIM);


i.e. the #if 0 seems to have disappeared...

I guess that David Xu forgot to include smp.h
in his patch.

> Jake
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sparc64 tinderbox failure

[Clive Lin]

On Sun, Nov 17, 2002 at 03:46:55PM -0500, Jake Burkholder wrote:
> Apparently, On Sun, Nov 17, 2002 at 12:23:20PM -0800,
>   Julian Elischer said words to the effect of;
> > On Sun, 17 Nov 2002, Mike Barcroft wrote:
> > > --
> > > >>> Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002
> > > --
> > > ===> ipfilter
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create':
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first 
>use in this function)
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier 
>is reported only once
> > > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears 
>in.)
> > 
> > 
> > ok mea culpa..
> > 
> > what is there in SPARC that should be used instead..?
> 
> mp_ncpus is defined in sys/smp.h which is not included kern_thread.c
> I don't see why this builds on any platform.
> 
> Jake

This does not compile on i386 with options SMP, either.

It looks like a '#if 0' was removed in kern_thread.c rev 1.61, which
exposes bug in SMP case.

Something like this should fix kernel building.
(I have no idea where to place the #include, though)

Index: kern_thread.c
===
RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v
retrieving revision 1.61
diff -u -r1.61 kern_thread.c
--- kern_thread.c   17 Nov 2002 11:47:03 -  1.61
+++ kern_thread.c   17 Nov 2002 22:22:35 -
@@ -47,6 +47,10 @@
 #include 
 #include 
 
+#ifdef SMP
+#include 
+#endif
+
 #include 
 #include 
 #include 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ccd & disklabel (what should work?)

[John De Boskey]

In trying to setup a ccd on a -current system I
seem to have run into a few issues:

/etc/ccd.conf:
# ccd   ileave  flags   component devices
ccd0 64  none/dev/ad1s1a /dev/ad2s1a

# ccdconfig -g
ccd064  0   /dev/ad1s1a /dev/ad2s1a

# ls -al /dev/ccd*
crw-r-  1 root  operator   74,   2 Nov 17 22:09 /dev/ccd0c

So far, so good...


# disklabel -rw ccd0c auto
disklabel: auto: unknown disk type
# disklabel -rw ccd0 auto 
disklabel: cannot open /dev/ccd0: No such file or directory
disklabel: auto: unknown disk type

#disklabel -e ccd0c
disklabel: ioctl DIOCWDINFO: no disk label on disk;
add "-r" to install initial label
re-edit the label? [y]: 



Ok, let's just newfs the 'c' partition

# newfs -U /dev/ccd0c
/dev/ccd0c: 76345.1MB (156354688 sectors) block size 16384, fragment size 2048
using 416 cylinder groups of 183.69MB, 11756 blks, 23552 inodes.
with soft updates
super-block backups (for fsck -b #) at:
...
 154614944, 154991136, 155367328, 155743520, 156119712
newfs: ioctl (WDINFO): /dev/ccd0c: can't rewrite disk label: No such process


Should we be able to disklabel 'auto' a ccd?
Should we be able to create multiple partitions? ('a','c','d', etc)

If not, the ccdconfig man page and handbook probably need
a bit of updating. They seem to indicate that the above should work.

Comments?

Thanks,
John


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: rpc.lockd problems

[Kris Kennaway]

On Sun, Nov 17, 2002 at 09:31:40PM +0100, Martijn Pronk wrote:

> I hope this is enough info for you, if you need a real dump to look
> at yourself, just let me know, I'll put it online then.

Thanks, but the binary dump would be more useful so I can read it into
ethereal.  ethereal does a really good job of decoding RPC requests,
so I can see exactly what is going on and what is different from my
linux case.

Kris



msg46829/pgp0.pgp
Description: PGP signature

Re: Processes hanging in thrd_sleep

[Alan L. Cox]

This late-night commit might help:

jeff2002/11/17 01:33:00 PST

  Modified files:
sys/kern kern_exec.c 
  Log:
   - Release the imgp vnode prior to freeing exec_map resources to avoid
 deadlock.
  
  Revision  ChangesPath
  1.200 +4 -4  src/sys/kern/kern_exec.c

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sparc64 tinderbox failure

[Jake Burkholder]

Apparently, On Sun, Nov 17, 2002 at 12:23:20PM -0800,
Julian Elischer said words to the effect of;

> 
> 
> On Sun, 17 Nov 2002, Mike Barcroft wrote:
> > --
> > >>> Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002
> > --
> > ===> ipfilter
> > /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create':
> > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first 
>use in this function)
> > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is 
>reported only once
> > /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears 
>in.)
> 
> 
> ok mea culpa..
> 
> what is there in SPARC that should be used instead..?

mp_ncpus is defined in sys/smp.h which is not included kern_thread.c
I don't see why this builds on any platform.

Jake

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: rpc.lockd problems

[Martijn Pronk]

Andrew P. Lentvorski wrote:


Can you produce a packet trace for Kris?  This would give him a known good
trace so that he can point out the differences from his particular
configuration, or, alternatively, he could file a bug report with the
Linux folks.
 

Ok, here is a but of output from tcpudmp, first is the locking of the 
file, later  the unlocking
of the file.
(Beware, long lines ahead...)
[This is when the locking begins-- I'm not sure if the RPC packets should
be included...]

21:05:36.681339 dhcp157.in-10.sillywalks.org.49445 > 
pluto.in-10.sillywalks.org.lockd: udp 196 (ttl 64, id 14737, len 224)
0x   4500 00e0 3991  4011 aa4c c0a8 0a9dE...9...@..L
0x0010   c0a8 0a42 c125 0fcd 00cc e277 3ddd 99f0...B.%.w=...
0x0020      0002 0001 86b5  0004
0x0030    0007  0001  0028 3dd7 f690...(=...
0x0040    0006 626f 656b 6a65   03e8boekje..
0x0050      ..
21:05:36.684128 pluto.in-10.sillywalks.org.826 > 
dhcp157.in-10.sillywalks.org.sunrpc: udp 84 (DF) (ttl 255, id 23949, len 
112)
0x   4500 0070 5d8d 4000 ff11 87bf c0a8 0a42E..p].@B
0x0010   c0a8 0a9d 033a 006f 005c c339 b296 4aab.:.o.\.9..J.
0x0020      0002 0001 86a0  0002
0x0030    0003  0001  001c 3dd8 0492=...
0x0040    0005 706c 7574 6f00   pluto...
0x0050   
21:05:36.685941 dhcp157.in-10.sillywalks.org.sunrpc > 
pluto.in-10.sillywalks.org.826: [udp sum ok] udp 28 (ttl 64, id 14738, 
len 56)
0x   4500 0038 3992  4011 aaf3 c0a8 0a9dE..89...@...
0x0010   c0a8 0a42 006f 033a 0024 64b9 b296 4aab...B.o.:.$d...J.
0x0020    0001      
0x0030      03d1
21:05:36.688612 pluto.in-10.sillywalks.org.825 > 
dhcp157.in-10.sillywalks.org.977: udp 92 (DF) (ttl 255, id 23950, len 120)
0x   4500 0078 5d8e 4000 ff11 87b6 c0a8 0a42E..x].@B
0x0010   c0a8 0a9d 0339 03d1 0064 012b b296 4aac.9...d.+..J.
0x0020      0002 0001 86b5  0004
0x0030    000c  0001  001c 3dd8 0492=...
0x0040    0005 706c 7574 6f00   pluto...
0x0050   
--
[The next part is when I close the file]
--
21:05:39.077292 dhcp157.in-10.sillywalks.org.49445 > 
pluto.in-10.sillywalks.org.lockd: udp 180 (ttl 64, id 14742, len 208)
0x   4500 00d0 3996  4011 aa57 c0a8 0a9dE...9...@..W
0x0010   c0a8 0a42 c125 0fcd 00bc e1bd 3ddd 99f1...B.%..=...
0x0020      0002 0001 86b5  0004
0x0030    0009  0001  0028 3dd7 f693...(=...
0x0040    0006 626f 656b 6a65   03e8boekje..
0x0050      ..
21:05:39.078515 pluto.in-10.sillywalks.org.825 > 
dhcp157.in-10.sillywalks.org.977: udp 92 (DF) (ttl 255, id 12356, len 120)
0x   4500 0078 3044 4000 ff11 b500 c0a8 0a42E..x0D@B
0x0010   c0a8 0a9d 0339 03d1 0064 0026 b296 4aad.9...d.&..J.
0x0020      0002 0001 86b5  0004
0x0030    000e  0001  001c 3dd8 0494=...
0x0040    0005 706c 7574 6f00   pluto...
0x0050   
-
I hope this is enough info for you, if you need a real dump to look
at yourself, just let me know, I'll put it online then.

HTH,

Martijn


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sparc64 tinderbox failure

[Julian Elischer]

On Sun, 17 Nov 2002, Mike Barcroft wrote:
> --
> >>> Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002
> --
> ===> ipfilter
> /tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create':
> /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use 
>in this function)
> /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is 
>reported only once
> /tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.)


ok mea culpa..

what is there in SPARC that should be used instead..?




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

sparc64 tinderbox failure

[Mike Barcroft]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating 
>/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002
--
===> ipfilter
/tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create':
/tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in 
this function)
/tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is 
reported only once
/tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.)
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP stability ? [was Re: more info from panic from runningdnet on SMP kernel]

[Joel M. Baldwin]

ack, I keep forgetting there are TWO conf dirs now.  I didn't
even see those options.   I'll try this also.

--On Sunday, November 17, 2002 8:55 PM +0100 Thierry Herbelot 
<[EMAIL PROTECTED]> wrote:

Le Sunday 17 November 2002 20:46, Robert Watson a écrit :


I've seen several reports that using a serial break to get into ddb
is now quite a bit more reliable than a keyboard break.  If you're
not already using a serial console, you might want to give it a try
(make sure to turn on BREAK_TO_DEBUGGER and/or
ALT_BREAK_TO_DEBUGGER).


OK, I'll do so

	TfH

PS : I think one other BP6 user is Grog

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: more info from panic from running dnet on SMP kernel ( lockorder reversal, recursed on non-recursive lock )

[Joel M. Baldwin]

--On Sunday, November 17, 2002 2:54 PM -0500 Robert Watson 
<[EMAIL PROTECTED]> wrote:

Hmm.  It looks like there is indeed a lock leak in the RFTHREAD code.
Maybe a change like the following might help:

PROC_LOCK(p2);
psignal(p2, SIGKILL);
PROC_UNLOCK(p2);
}

Change the } to:
		} else
			PROC_UNLOCK(p1->p_leader);

And see if that gets rid of the problem.  Any chance this is highly
reproduceable, btw? :-)  And what app are you running that's using
RFTHREAD -- linux thread stuff?


What source file would this be in?

Yes, it is 100% reproduceable

dnet is the distrubuted.net client  for their various distributed
computing projects.  



Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

On Sun, 17 Nov 2002, Joel M. Baldwin wrote:



running dnet on a SMP kernel causes the kernel to panic.


lock order reversal
 1st 0xc2c803e8 process lock (process lock) @


. . . snip . . .



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Asking for tester (small patch to chown(8)/chgrp(1))

[Oliver Fromme]

Alexander Leidinger <[EMAIL PROTECTED]> wrote:
 > Oliver Fromme <[EMAIL PROTECTED]> wrote:
 > > The patch adds an option -r to chown(8) and chgrp(1), which
 > > does pretty much the same as the -r option of touch(1) and
 > > truncate(1).  Basically, it let's you "copy" ownerships and
 > > group memberships from one file to another, which is useful
 > > in scripts.
 > 
 > I'm concerned about the used character: "-r" is similiar to "-R"

Why exactly is that cause for concern?

What character would you suggest instead?  touch(1) and
truncate(1) also use "-r".

Regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"All that we see or seem is just a dream within a dream" (E. A. Poe)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]

[Thierry Herbelot]

Le Sunday 17 November 2002 20:46, Robert Watson a écrit :
>
> I've seen several reports that using a serial break to get into ddb is now
> quite a bit more reliable than a keyboard break.  If you're not already
> using a serial console, you might want to give it a try (make sure to turn
> on BREAK_TO_DEBUGGER and/or ALT_BREAK_TO_DEBUGGER).

OK, I'll do so

TfH

PS : I think one other BP6 user is Grog

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: more info from panic from running dnet on SMP kernel ( lock order reversal, recursed on non-recursive lock )

[Robert Watson]

Hmm.  It looks like there is indeed a lock leak in the RFTHREAD code.
Maybe a change like the following might help:

PROC_LOCK(p2);
psignal(p2, SIGKILL);
PROC_UNLOCK(p2);
}

Change the } to:
} else
PROC_UNLOCK(p1->p_leader);

And see if that gets rid of the problem.  Any chance this is highly
reproduceable, btw? :-)  And what app are you running that's using
RFTHREAD -- linux thread stuff?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

On Sun, 17 Nov 2002, Joel M. Baldwin wrote:

> 
> running dnet on a SMP kernel causes the kernel to panic.
> 
> 
> lock order reversal
>  1st 0xc2c803e8 process lock (process lock) @ 
> ../../../kern/kern_fork.c:571
>  2nd 0xc03cfce0 proctree (proctree) @ ../../../kern/kern_fork.c:596
> recursed on non-recursive lock (sleep mutex) process lock @ 
> ../../../kern/kern_fork.c:599
> first acquired @ ../../../kern/kern_fork.c:571
> panic: recurse
> cpuid = 1; lapic.id = 0100
> Debugger("panic")
> Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
> db> t
> Debugger(c03926fa,100,c0395ada,d26f5c08,1) at Debugger+0x55
> panic(c0395ada,c038feab,23b,c038feab,257) at panic+0x11f
> witness_lock(c2c803e8,8,c038feab,257,0) at witness_lock+0x3e6
> _mtx_lock_flags(c2c803e8,0,c038feab,257,d26f5cb8) at 
> _mtx_lock_flags+0xb2
> fork1(c2773d00,6050,0,d26f5cd4,c2c803e8) at fork1+0xbfc
> rfork(c2773d00,d26f5d10,c03b07a2,407,1) at rfork+0x65
> syscall(2f,2f,2f,0,80ddf10) at syscall+0x28e
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (251, FreeBSD ELF32, rfork), eip = 0x8087d14, esp = 
> 0xbfbff4a8, ebp = 0xbfbff524 ---
> db> ps
>   pid   proc addruid  ppid  pgrp  flag   stat  wmesgwchan 
> cmd
>  6217 c2b98e00 d28a70000  6215  6216 000 newpanic: unknown 
> thread state
> cpuid = 1; lapic.id = 0100
> boot() called on cpu#1
> Uptime: 1h43m39s
> pfs_vncache_unload(): 1 entries remaining
> Dumping 255 MB
>  16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
> Dump complete
> Automatic reboot in 15 seconds - press a key on the console to abort
> Rebooting...
> cpu_reset called on cpu#1
> cpu_reset: Restarting BSP
> cpu_reset_proxy: Stopped CPU 1
> 
> 
> 
> And then when the system came back up and I took a closer
> look at the core dump.
> 
> 
> (kgdb) where
> #0  doadump () at ../../../kern/kern_shutdown.c:232
> #1  0xc02114ad in boot (howto=260) at ../../../kern/kern_shutdown.c:364
> #2  0xc0211767 in panic () at ../../../kern/kern_shutdown.c:517
> #3  0xc014f2bc in db_ps (dummy1=-1070342907, dummy2=0, dummy3=-1, 
> dummy4=0xd26f5a24 "")
> at ../../../ddb/db_ps.c:169
> #4  0xc014d142 in db_command (last_cmdp=0xc03be920, cmd_table=0x0, 
> aux_cmd_tablep=0xc03b5540,
> aux_cmd_tablep_end=0xc03b5558) at ../../../ddb/db_command.c:346
> #5  0xc014d256 in db_command_loop () at ../../../ddb/db_command.c:472
> #6  0xc014feea in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
> #7  0xc033da10 in kdb_trap (type=3, code=0, regs=0xd26f5b80)
> at ../../../i386/i386/db_interface.c:166
> #8  0xc0356a3f in trap (frame=
>   {tf_fs = -1069481960, tf_es = 16, tf_ds = 16, tf_edi = 
> -1032372992, tf_esi = 256, tf_ebp = -764453940, tf_isp = -764453972, 
> tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err 
> = 0, tf_eip = -1070342907, tf_cs = 8, tf_eflags = 662, tf_esp = 
> -1069883258, tf_ss = -1069996294}) at ../../../i386/i386/trap.c:603
> #9  0xc033f238 in calltrap () at {standard input}:99
> #10 0xc021174f in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:503
> #11 0xc02333d6 in witness_lock (lock=0xc2c803e8, flags=8,
> file=0xc038feab "../../../kern/kern_fork.c", line=599) at 
> ../../../kern/subr_witness.c:609
> #12 0xc02079c2 in _mtx_lock_flags (m=0xc03cf4c0, opts=0, 
> file=0xc042cfd4 "è\003È«þ8À;\002",
> line=-1027079192) at ../../../kern/kern_mutex.c:328
> #13 0xc01fd3ec in fork1 (td=0xc2773d00, flags=24656, pages=0, 
> procp=0xd26f5cd4)
> at ../../../kern/kern_fork.c:599
> #14 0xc01fc6c5 in rfork (td=0xc2773d00, uap=0xd26f5d10) at 
> ../../../kern/kern_fork.c:168
> #15 0xc035739e in syscall (frame=
>   {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 
> 135126800, tf_ebp = -1077938908, tf_isp = -764453516, tf_ebx = 2, 
> tf_edx = 135381248, tf_ecx = 135381248, tf_eax = 251, tf_trapno = 0, 
> tf_err = 2, tf_eip = 134774036, tf_cs = 31, tf_eflags = 659, tf_esp = 
> -1077939032, tf_ss = 47})
> at ../../../i386/i386/trap.c:1033
> #16 0xc033f28d in Xint0x80_syscall () at {standard input}:141
> ---Can't read userspace from dump, or kernel process---
> 
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the 

Re: Processes hanging in thrd_sleep

[Robert Watson]

I ran into that during heavy builds on one of my boxes a few months ago --
I never really got around to properly debugging it because the UFS file
systems promptly ate themselves.  Oddly, I had two boxes in particular
that this happened on, and none of my others, and it wasn't clear to me if
there was a useful pattern.  I will try reproducing it sometime this
weekend.  Basically, the system seemed fairly live, but any attempt to
execve() would hang the process in that sleep state.  It looked a bit like
a VM lock leak followed by piling up on locks into a deadlock staet.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

On Sun, 17 Nov 2002, Kris Kennaway wrote:

> Since upgrading my kernel to today's current (from a couple of weeks
> ago) I have had a number of hangs where processes block in the kernel,
> usually in the thrd_sleep state (but once one hung in the ufs state).
> 
> e.g:
> 
> > load: 0.01  cmd: cc 708 [ufs] 0.00u 0.00s 0% 56k
> 
> > load: 0.01  cmd: tcsh 709 [thrd_sleep] 0.00u 0.00s 0% 1220k
> 
> I've seen this on my sparc64 box as well as an i386 box.
> 
> Any bright ideas?  Anyone feeling guilty? :)
> 
> Kris
> 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]

[Robert Watson]

On Sun, 17 Nov 2002, Thierry Herbelot wrote:

> Even make -j1 buildworld with the SMP kernel ends with a complete freeze
> of the machine (the kernel does not go to a panic where I could try a
> backtrace) 

I've seen several reports that using a serial break to get into ddb is now
quite a bit more reliable than a keyboard break.  If you're not already
using a serial console, you might want to give it a try (make sure to turn
on BREAK_TO_DEBUGGER and/or ALT_BREAK_TO_DEBUGGER). 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Josef Karthauser]

On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote:
> 
> > ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe)
> > ohci_device_bulk_start+0x0d
> > ohci_device_bulk_transfer+0x27
> > usbd_transfer+0xc0
> > umass_setup_transfer+0x4f
> > umass_bbb_state
> > usb_transfer_complete
> > ohci_softintr
> > 
> > Can anyone confirm if this is normal or I have an exceptional system?  I 
> > have two completely unrelated OHCI-based controllers in my system and 
> > neither works.
> 
> Anyone?  I kinda want to use my CF reader.
> 

There are rumours that OHCI is borked in NetBSD too and this is a bug
that we've inherited.  Me, I've not got an OHCI system to test just
UHCI.

Did it used to work, and got broken, or has it never worked?

Joe
-- 
Josef Karthauser ([EMAIL PROTECTED])  http://www.josef-k.net/
FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/
Physics Particle Theory (student)   http://www.pact.cpes.sussex.ac.uk/
 An eclectic mix of fact and theory. =



msg46816/pgp0.pgp
Description: PGP signature

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian F. Feldman]

Brian Fundakowski Feldman <[EMAIL PROTECTED]> wrote:
> I can't get more info because crash dumps don't work when this happens, but 
> for what it's worth, here's a traceback which shows what happens when I 
> attempt to use my da0:  Removable Direct Access
> SCSI-2 device on an OHCI-based controller.  This was working just a few days 
> ago with a UHCI controller, so ...
> 
> The crash is from an invalid read at 0xbff3e000, which is PTmap plus some
> offset. The trace as far as I can get it, from a kernel with USB but no
> "options" 
> enabled, would be:
> 
> ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe)
> ohci_device_bulk_start+0x0d
> ohci_device_bulk_transfer+0x27
> usbd_transfer+0xc0
> umass_setup_transfer+0x4f
> umass_bbb_state
> usb_transfer_complete
> ohci_softintr
> 
> Can anyone confirm if this is normal or I have an exceptional system?  I 
> have two completely unrelated OHCI-based controllers in my system and 
> neither works.

Anyone?  I kinda want to use my CF reader.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Weird error during "make installworld" [executable becomes "data"]

[David Wolfskill]

>Date: Sun, 17 Nov 2002 19:06:40 +0100
>From: Stefan Farfeleder <[EMAIL PROTECTED]>

>> g1-9(5.0-C)[2] file /tmp/install.*|* | grep data
>^

>> #SC.SAVE~: Command not found.

>Are these just typoes in the mail or did you really type this? :-)


I cut & pasted it.

Color me embarrassed  :-(

Sorry, gang,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I have no confidence in results obtained through the use of Microsoft products.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Weird error during "make installworld" [executable becomes "data"]

[David Wolfskill]

>Date: Tue, 12 Nov 2002 10:18:03 -0800 (PST)
>From: David Wolfskill <[EMAIL PROTECTED]>

[Yes, replying to my own message, if not myself  dhw]

>Here's an excerpt of the typescript from the "make installworld":

>---%<- snip! --
 Installing everything..
>...
>/tmp/install.O6fzOZh4/mtree: 62: Syntax error: "(" unexpected
>*** Error code 2
>---%<- snip! --

>Now, watch this:

>g1-9(5.0-C)[4] file /tmp/install.O6fzOZh4/* |grep data
>/tmp/install.O6fzOZh4/mtree:data
>g1-9(5.0-C)[5] 

>Huh??!?

I think I can top that:

g1-9(5.0-C)[2] file /tmp/install.*|* | grep data
COPYRIGHT: Command not found.


while from a different xterm on the same machine:

g1-9(5.0-C)[2] file /tmp/install.*|* | grep data
#SC.SAVE~: Command not found.


As before, this is running with /tmp mounted on a "md" device that is
swap-backed.

Clues?

Thanks,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I have no confidence in results obtained through the use of Microsoft products.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SMP stability ? [was Re: more info from panic from runningdnet on SMP kernel]

[Joel M. Baldwin]

--On Sunday, November 17, 2002 11:36 AM +0100 Thierry Herbelot 
<[EMAIL PROTECTED]> wrote:

Le Sunday 17 November 2002 10:50, Joel M. Baldwin a écrit :

running dnet on a SMP kernel causes the kernel to panic.




[Hijacking another thread ?]


No problem, lets compare notes.


I haven't been able to complete a full buildworld with an SMP on a
Abit BP6  (bi-celeron) board for two weeks (the kernel config is just
a full GENERIC  with SMP and APICIO options enabled).


I also am running a BP6.  IS ANYONE successfully running an ABIT
BP6 motherboard on a SMP kernel with -current?

What BIOS version are running?  I'm one version behind I think,
so I'm going to upgrade and see if that makes any difference.


The same machine runs happily strings of make -j48 buildworld's when
running  with the straight GENERIC UP kernel, so I think the hardware
seems to be  working OK.


I haven't tried anything that drastic, but I have had NO crashes
or lockups that I couldn't explain in a NON SMP kernel.  The SMP
kernel on the other hand will Hard Lock anywhere in anywhere from
seconds to days.  It seems to be more likely the harder I push it.
I don't think its the hardware.  I've pulled my hair out and tried
everything I can think of to eliminate the possability of it
being hardware.  I'm hoping that dnet causing a panic is somehow
related.


Even make -j1 buildworld with the SMP kernel ends with a complete
freeze of  the machine (the kernel does not go to a panic where I
could try a backtrace)


Exactly!  Hard Lock, no panic, no keyboard, no choices other than reset.


The hardware config of the machine is pretty dull (see dmesg later).

One point that could be better is that the sources are NFS mounted
from a  4.7-Stable server, over an rl(4) board, which may be unstable
(/usr/obj is  local, on the Maxtor drive)


All my harddrives are local, 3 SCSI and 3 IDE.


. . . snip . . .




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SMP stability ? [was Re: more info from panic from running dnet on SMP kernel]

[Thierry Herbelot]

Le Sunday 17 November 2002 10:50, Joel M. Baldwin a écrit :
> running dnet on a SMP kernel causes the kernel to panic.
>
>

[Hijacking another thread ?]

I haven't been able to complete a full buildworld with an SMP on a Abit BP6 
(bi-celeron) board for two weeks (the kernel config is just a full GENERIC 
with SMP and APICIO options enabled).

The same machine runs happily strings of make -j48 buildworld's when running 
with the straight GENERIC UP kernel, so I think the hardware seems to be 
working OK.

Even make -j1 buildworld with the SMP kernel ends with a complete freeze of 
the machine (the kernel does not go to a panic where I could try a backtrace)

The hardware config of the machine is pretty dull (see dmesg later).

One point that could be better is that the sources are NFS mounted from a 
4.7-Stable server, over an rl(4) board, which may be unstable (/usr/obj is 
local, on the Maxtor drive)

TfH

PS : the machine was re-installed anew from the 5.0-20021027-CURRENT snapshot, 
then upgraded via make buildworld/buildkernel and mergemaster

PS2 : full dmesg (when running the stable, UP, GENERIC)

Copyright (c) 1992-2002 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 5.0-CURRENT #17: Sat Nov 16 19:16:25 CET 2002

XXX@YYY:/usr/obj/files2/src-free/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0662000.
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 334092192 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x665  Stepping = 5
  
Features=0x183fbff
real memory  = 536870912 (512 MB)
avail memory = 514818048 (490 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
npx0:  on motherboard
npx0: INT 16 interface
Using $PIR table, 8 entries at 0xc00fdef0
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
agp0:  mem 0xe000-0xe3ff at 
device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xf000-0xf00f at device 7.1 on 
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0:  port 0xd000-0xd01f irq 10 at 
device 7.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
pci0:  at device 7.3 (no driver attached)
rl0:  port 0xd400-0xd4ff mem 0xe500-0xe5ff 
irq 10 at device 17.0 on pci0
rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode
rl0: Ethernet address: 00:40:95:30:38:36
miibus0:  on rl0
rlphy0:  on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
atapci1:  port 
0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 11 at device 19.0 on pci0
ata2: at 0xd800 on atapci1
atapci2:  port 
0xec00-0xecff,0xe800-0xe803,0xe400-0xe407 irq 11 at device 19.1 on pci0
ata3: at 0xe400 on atapci2
orm0:  at iomem 0xc6800-0xc7fff,0xc-0xc5fff on isa0
pmtimer0 on isa0
atkbdc0:  at port 0x64,0x60 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
fdc0:  at port 
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0:  on ppbus0
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
unknown:  can't assign resources (port)
Timecounters tick every 10.000 msec
ad0: 6149MB  [13328/15/63] at ata0-master UDMA33
acd0: CDROM  at ata1-master PIO4
Mounting root from ufs:/dev/ad0s2a


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Asking for tester (small patch to chown(8)/chgrp(1))

[Alexander Leidinger]

On Sat, 16 Nov 2002 12:29:20 +0100 (CET)
Oliver Fromme <[EMAIL PROTECTED]> wrote:

> The patch adds an option -r to chown(8) and chgrp(1), which
> does pretty much the same as the -r option of touch(1) and
> truncate(1).  Basically, it let's you "copy" ownerships and
> group memberships from one file to another, which is useful
> in scripts.

I'm concerned about the used character: "-r" is similiar to "-R"

Bye,
Alexander.

-- 
   "One world, one web, one program"  -- Microsoft promotional ad
 "Ein Volk, ein Reich, ein Fuehrer"  -- Adolf Hitler

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

alpha tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
>>> Kernel build for GENERIC started on Sun Nov 17 03:03:07 PST 2002
--
>>> Kernel build for GENERIC completed on Sun Nov 17 03:33:23 PST 2002
--
>>> Kernel build for LINT started on Sun Nov 17 03:33:24 PST 2002
--
===> vinum
"Makefile", line 4446: warning: duplicate script for target "geom_bsd.o" ignored
cc1: warnings being treated as errors
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in':
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different 
type arg (arg 2)
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out':
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different 
type arg (arg 2)
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different 
type arg (arg 4)
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different 
type arg (arg 5)
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Processes hanging in thrd_sleep

[Kris Kennaway]

On Sun, Nov 17, 2002 at 02:59:19AM -0800, Kris Kennaway wrote:
> Since upgrading my kernel to today's current (from a couple of weeks
> ago) I have had a number of hangs where processes block in the kernel,
> usually in the thrd_sleep state (but once one hung in the ufs state).
> 
> e.g:
> 
> > load: 0.01  cmd: cc 708 [ufs] 0.00u 0.00s 0% 56k
> 
> > load: 0.01  cmd: tcsh 709 [thrd_sleep] 0.00u 0.00s 0% 1220k
> 
> I've seen this on my sparc64 box as well as an i386 box.
> 
> Any bright ideas?  Anyone feeling guilty? :)

It looks like this broke some time between Nov 1 and Nov 5 (I was able
to lock up the kernel from the Nov 5 current.freebsd.org snapshot
instantly by running a make -j4).  The Nov 1 kernel is happily building.

Kris



msg46808/pgp0.pgp
Description: PGP signature

RE: Is RAIDframe currently usable?

[Long, Scott]

> 
> Hi,
> 
> Yesterday I installed a jpsnap (FreeBSD christine.energyhq.tk
> 5.0-CURRENT-20021115-JPSNAP i386), and tried to setup a RAID0 config
> with two disks. raidctl -C goes fine, so does -I and -iv. 
> Then fdisk'ed
> and disklabelled. But when I tried to newfs the newly created 
> partition
> I started getting a bunch of errors like this:

RAIDframe should be considered highly experimental.  While it was
tested extensively under SMP in FreeBSD 4.x, it received very
little testing under SMP in -current.  If you have more details
on this failure, I'd appreciate it.

Scott

> 
> ---
> Nov 16 00:04:59 christine kernel: raid0: node (R  ) returned fail,
> rolling backward
> Nov 16 00:04:59 christine kernel: raid0: DAG failure: r addr 0x40 (64)
> nblk 0x20 (32) buf 0xcdd50ea0
> Nov 16 00:04:59 christine kernel: raid0: node (R  ) returned fail,
> rolling backw byte 76893
> ---
> and so on.
> 
> Anyway, the newfs process finishes, then a simple piped tar 
> to move the
> old /usr to the RAID partition creates a myriad of those 
> messages, to a
> point where the system spends all the time logging those 
> errors and tar
> no longer continues.
> 
> The system is a dual P3 box, running a slightly modified 
> GENERIC (added
> SMP, raidframe and pcm), with INVARIANTS and WITNESS enabled (tried
> without them too, no success).
> 
> So, any known issues with RAIDframe? I can supply more 
> detailed info if
> needed.
> 
> Cheers,
> -- 
> Miguel Mendez - [EMAIL PROTECTED]
> GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
> EnergyHQ :: http://www.energyhq.tk
> Of course it runs NetBSD!
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

sparc64 tinderbox failure

[Mike Barcroft]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating 
>/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
>>> stage 4: building libraries
--
===> lib/libc
/tinderbox/sparc64/src/lib/libc/gen/getcap.c: In function `getent':
/tinderbox/sparc64/src/lib/libc/gen/getcap.c:251: warning: passing arg 3 of `cdbget' 
discards qualifiers from pointer target type
/tinderbox/sparc64/src/lib/libc/gen/getcap.c: In function `cgetmatch':
/tinderbox/sparc64/src/lib/libc/gen/getcap.c:576: warning: assignment discards 
qualifiers from pointer target type
/tinderbox/sparc64/src/lib/libc/gen/getcap.c:581: warning: assignment discards 
qualifiers from pointer target type
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c: In function `sysconf':
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c:259: syntax error before "break"
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c:263: syntax error before "break"
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c:267: syntax error before "break"
*** Error code 1

Stop in /tinderbox/sparc64/src/lib/libc.
*** Error code 1

Stop in /tinderbox/sparc64/src/lib.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Processes hanging in thrd_sleep

[Kris Kennaway]

Since upgrading my kernel to today's current (from a couple of weeks
ago) I have had a number of hangs where processes block in the kernel,
usually in the thrd_sleep state (but once one hung in the ufs state).

e.g:

> load: 0.01  cmd: cc 708 [ufs] 0.00u 0.00s 0% 56k

> load: 0.01  cmd: tcsh 709 [thrd_sleep] 0.00u 0.00s 0% 1220k

I've seen this on my sparc64 box as well as an i386 box.

Any bright ideas?  Anyone feeling guilty? :)

Kris




msg46805/pgp0.pgp
Description: PGP signature

more info from panic from running dnet on SMP kernel ( lockorder reversal, recursed on non-recursive lock )

[Joel M. Baldwin]

running dnet on a SMP kernel causes the kernel to panic.


lock order reversal
1st 0xc2c803e8 process lock (process lock) @ 
../../../kern/kern_fork.c:571
2nd 0xc03cfce0 proctree (proctree) @ ../../../kern/kern_fork.c:596
recursed on non-recursive lock (sleep mutex) process lock @ 
../../../kern/kern_fork.c:599
first acquired @ ../../../kern/kern_fork.c:571
panic: recurse
cpuid = 1; lapic.id = 0100
Debugger("panic")
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db> t
Debugger(c03926fa,100,c0395ada,d26f5c08,1) at Debugger+0x55
panic(c0395ada,c038feab,23b,c038feab,257) at panic+0x11f
witness_lock(c2c803e8,8,c038feab,257,0) at witness_lock+0x3e6
_mtx_lock_flags(c2c803e8,0,c038feab,257,d26f5cb8) at 
_mtx_lock_flags+0xb2
fork1(c2773d00,6050,0,d26f5cd4,c2c803e8) at fork1+0xbfc
rfork(c2773d00,d26f5d10,c03b07a2,407,1) at rfork+0x65
syscall(2f,2f,2f,0,80ddf10) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (251, FreeBSD ELF32, rfork), eip = 0x8087d14, esp = 
0xbfbff4a8, ebp = 0xbfbff524 ---
db> ps
 pid   proc addruid  ppid  pgrp  flag   stat  wmesgwchan 
cmd
6217 c2b98e00 d28a70000  6215  6216 000 newpanic: unknown 
thread state
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 1h43m39s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset called on cpu#1
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 1



And then when the system came back up and I took a closer
look at the core dump.


(kgdb) where
#0  doadump () at ../../../kern/kern_shutdown.c:232
#1  0xc02114ad in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2  0xc0211767 in panic () at ../../../kern/kern_shutdown.c:517
#3  0xc014f2bc in db_ps (dummy1=-1070342907, dummy2=0, dummy3=-1, 
dummy4=0xd26f5a24 "")
   at ../../../ddb/db_ps.c:169
#4  0xc014d142 in db_command (last_cmdp=0xc03be920, cmd_table=0x0, 
aux_cmd_tablep=0xc03b5540,
   aux_cmd_tablep_end=0xc03b5558) at ../../../ddb/db_command.c:346
#5  0xc014d256 in db_command_loop () at ../../../ddb/db_command.c:472
#6  0xc014feea in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7  0xc033da10 in kdb_trap (type=3, code=0, regs=0xd26f5b80)
   at ../../../i386/i386/db_interface.c:166
#8  0xc0356a3f in trap (frame=
 {tf_fs = -1069481960, tf_es = 16, tf_ds = 16, tf_edi = 
-1032372992, tf_esi = 256, tf_ebp = -764453940, tf_isp = -764453972, 
tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err 
= 0, tf_eip = -1070342907, tf_cs = 8, tf_eflags = 662, tf_esp = 
-1069883258, tf_ss = -1069996294}) at ../../../i386/i386/trap.c:603
#9  0xc033f238 in calltrap () at {standard input}:99
#10 0xc021174f in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:503
#11 0xc02333d6 in witness_lock (lock=0xc2c803e8, flags=8,
   file=0xc038feab "../../../kern/kern_fork.c", line=599) at 
../../../kern/subr_witness.c:609
#12 0xc02079c2 in _mtx_lock_flags (m=0xc03cf4c0, opts=0, 
file=0xc042cfd4 "è\003È«þ8À;\002",
   line=-1027079192) at ../../../kern/kern_mutex.c:328
#13 0xc01fd3ec in fork1 (td=0xc2773d00, flags=24656, pages=0, 
procp=0xd26f5cd4)
   at ../../../kern/kern_fork.c:599
#14 0xc01fc6c5 in rfork (td=0xc2773d00, uap=0xd26f5d10) at 
../../../kern/kern_fork.c:168
#15 0xc035739e in syscall (frame=
 {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 
135126800, tf_ebp = -1077938908, tf_isp = -764453516, tf_ebx = 2, 
tf_edx = 135381248, tf_ecx = 135381248, tf_eax = 251, tf_trapno = 0, 
tf_err = 2, tf_eip = 134774036, tf_cs = 31, tf_eflags = 659, tf_esp = 
-1077939032, tf_ss = 47})
   at ../../../i386/i386/trap.c:1033
#16 0xc033f28d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sbin/sysctl sysctl.8 src/sys/kern init_main.c

[Mark Murray]

Sorry, this is a subscription-only feature.

M

> Was the following just swallowed up into the bowels of the CVS beast or
> something?  :-)
> 
> I've tried updating my sources several times, and still not retrieving it.
> 
> On 12-Nov-2002 Dag-Erling Smorgrav wrote:
> > des 2002/11/12 02:69:42 PST
> > 
> >   Modified files:
> > sbin/sysctl  sysctl.8
> > sys/kern init_main.c
> >   Log:
> >   Add the kern.turbo sysctl, which makes the system run twice as fast.
> >   Default to 0 (off) for backward compatibility.
> > 
> >   Revision  ChangesPath
> >   1.48  +1 -0  src/sbin/sysctl/sysctl.8
> >   1.215 +3 -0  src/sys/kern/init_main.c
> 
> -- 
> Conrad Sabatier <[EMAIL PROTECTED]>
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
Mark Murray
Beware! I'm umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

startx -listen_tcp = core dump

[Arun Sharma]

Works fine when I don't specify -listen_tcp. Has anyone seen this ?

-Arun

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message