Re: usbd does not use detach

2003-08-17 Thread Jan Stocker


On Thu, 2003-08-14 at 16:30, Olivier Cortes wrote:
 Le Mer 06/08/2003 à 17:55, Jan Stocker a écrit :
  Does nobody has this problem or does noone use this feature?
 
 the problem i see with detach is the utility of the command.

 but when detaching, the umount part should be done BEFORE detaching, not
 after. i can't find any good use for the detach hook. most of things
 should have been done before detaching, and i can't see how to do it
 without user interactivity, thus avoiding use of the detach hook.

Thats another one thats a wrong specification or idea behind it...
but here nothing is been called

 i once included a umount -f in the detach hook. after unplugin' the
 device, it resulted in a panic. i don't remember if the umount was
 causing it or if it was right after, when accessing the mount point or
 repluging the digital recorder. anyway, i learned that umount -f is not
 meant to be used often... perhaps not on top of usb. for now.

But none of this should cause a panic. here this works fine if i
doing it by hand...

Jan
-- 
Jan Stocker [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Gordon Tetlow
I just got through with my commit spree to enable users to build /bin
and /sbin dynamically linked. To do this required a fair amount of
tweaking and moving around libraries and such dangerous equipment as
rtld-elf. If you have any systems that you are dearly in love with,
now is not the time to cvsup. Please wait until any potential issues
are shaken out of the tree. I've done as much testing as I can, but
as experience has shown me, there are likely to be issues.

IA64 users (both of you), do not attempt to build the world using
WITH_DYNAMICROOT! This is guaranteed to fail! I'm currently working
on getting ahold of a toolchain expert to work out the one outstanding
issue with this platform.

Thank you for being patient and please follow up with me if there are
*any* issues. There is a huge potential for foot-shooting here that I
hope to have mitigated but it is possible that I might have missed
something.

Now that all the grim stuff is out of the way, a couple of nice
benefits to building your world WITH_DYNAMICROOT:

1) Space savings. A statically linked /bin and /sbin is 32 MB on
   i386. A dynamically linked /bin and /sbin is only 12 MB (including
   /lib, /libexec, and /rescue)

2) NSS support. You are now able to use a dynamically loaded nss
   module for passwd and group maps and have things like ls(1) and
   tcsh(1) grok uids and gids coming from those sources.

-gordon


pgp0.pgp
Description: PGP signature


SV: when should 5.x be stable enough for web servers

2003-08-17 Thread Matt Douhan
-Ursprungligt meddelande-
Fran: [EMAIL PROTECTED]

On i386 hardware and two processors amd mp. should I wait for 5.2.


We have been using for some time, we use -CURRENT as FireWalls and as
webservers, we have half our production split between STABLE and -CURRENT
machines, so that if/when we hit a -CURRENT bug we simply rely on the STABLE
machines to handle the load until -CURRENT gets fixed.

Rgds

Matt
www.fruitsalad.org

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: LOR with filedesc structure and Giant

2003-08-17 Thread David Malone
On Sat, Aug 16, 2003 at 10:18:43PM +0200, Poul-Henning Kamp wrote:
 At one point we have to say Well, the locks we have above are solid,
 but we need to drop Giant below here but if Witness sees a
 PICKUP_GIANT() as an acquisition of Giant, rather than as a
 resumption of Giant, this clearly does not work.

Wouldn't the risk of deadlock be real, even if it is only a resumption
of Giant? I guess another option is to drop all the locks that are
held and reqcquire all of them in the right order...

David.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


if_sis: performance tweaking

2003-08-17 Thread Poul-Henning Kamp

This patch tweaks various thresholds in the DP8381[56] chip.

On my Soekris 4801, the goes from 5-6 Mbit/sec to 30-40 Mbit/sec
with this patch.

Also included is Sams patch for the short cable problem.

Tests, comments etc most welcome.

Poul-Henning

Index: if_sis.c
===
RCS file: /home/ncvs/src/sys/pci/if_sis.c,v
retrieving revision 1.80
diff -u -r1.80 if_sis.c
--- if_sis.c27 Jul 2003 14:36:02 -  1.80
+++ if_sis.c17 Aug 2003 10:46:59 -
@@ -107,7 +107,7 @@
 static struct sis_type sis_devs[] = {
{ SIS_VENDORID, SIS_DEVICEID_900, SiS 900 10/100BaseTX },
{ SIS_VENDORID, SIS_DEVICEID_7016, SiS 7016 10/100BaseTX },
-   { NS_VENDORID, NS_DEVICEID_DP83815, NatSemi DP83815 10/100BaseTX },
+   { NS_VENDORID, NS_DEVICEID_DP83815, NatSemi DP83815/6 10/100BaseTX },
{ 0, 0, NULL }
 };
 
@@ -2031,6 +2031,10 @@
 */
sis_stop(sc);
 
+   if (sc-sis_type == SIS_TYPE_83815) {
+   CSR_WRITE_4(sc, NS_IHR, 0x120);
+   }
+
mii = device_get_softc(sc-sis_miibus);
 
/* Set MAC address */
@@ -2121,7 +2125,7 @@
if (CSR_READ_4(sc, SIS_CFG)  SIS_CFG_EDB_MASTER_EN) {
CSR_WRITE_4(sc, SIS_RX_CFG, SIS_RXCFG64);
} else {
-   CSR_WRITE_4(sc, SIS_RX_CFG, SIS_RXCFG256);
+   CSR_WRITE_4(sc, SIS_RX_CFG, SIS_RXCFG128);
}
 
 
@@ -2144,6 +2148,29 @@
SIS_CLRBIT(sc, SIS_TX_CFG,
(SIS_TXCFG_IGN_HBEAT|SIS_TXCFG_IGN_CARR));
SIS_CLRBIT(sc, SIS_RX_CFG, SIS_RXCFG_RX_TXPKTS);
+   }
+
+   if (sc-sis_type == SIS_TYPE_83815 
+IFM_SUBTYPE(mii-mii_media_active) == IFM_100_TX) {
+   uint32_t reg;
+
+   /*
+* Some DP83815s experience problems when used with short
+* ( 30m/100ft) Ethernet cables in 100BaseTX mode.  This
+* sequence adjusts the DSP's signal attenuation to fix the
+* problem.
+*/
+   CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
+
+   reg = CSR_READ_4(sc, NS_PHY_DSPCFG);
+   CSR_WRITE_4(sc, NS_PHY_DSPCFG, (reg  0xfff) | 0x1000);
+   DELAY(100);
+   reg = CSR_READ_4(sc, NS_PHY_TDATA);
+   if ((reg  0x0080) == 0 || (reg  0xff) = 0xd8) {
+   CSR_WRITE_4(sc, NS_PHY_TDATA, 0x00e8);
+   SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x20);
+   }
+   CSR_WRITE_4(sc, NS_PHY_PAGE, 0);
}
 
/*
Index: if_sisreg.h
===
RCS file: /home/ncvs/src/sys/pci/if_sisreg.h,v
retrieving revision 1.22
diff -u -r1.22 if_sisreg.h
--- if_sisreg.h 22 Jul 2003 01:35:09 -  1.22
+++ if_sisreg.h 17 Aug 2003 10:50:12 -
@@ -75,6 +75,7 @@
 #define SIS_GPIO   0xB8
 
 /* NS DP83815 registers */
+#define NS_IHR 0x1C
 #define NS_CLKRUN  0x3C
 #define NS_BMCR0x80
 #define NS_BMSR0x84
@@ -237,12 +238,12 @@
 #define SIS_TXDMA_256BYTES 0x0070
 
 #define SIS_TXCFG_100  \
-   (SIS_TXDMA_64BYTES|SIS_TXCFG_AUTOPAD|\
-SIS_TXCFG_FILL(64)|SIS_TXCFG_DRAIN(1536))
+   (SIS_TXDMA_128BYTES|SIS_TXCFG_AUTOPAD|\
+SIS_TXCFG_FILL(1024)|SIS_TXCFG_DRAIN(128))
 
 #define SIS_TXCFG_10   \
(SIS_TXDMA_32BYTES|SIS_TXCFG_AUTOPAD|\
-SIS_TXCFG_FILL(64)|SIS_TXCFG_DRAIN(1536))
+SIS_TXCFG_FILL(64)|SIS_TXCFG_DRAIN(128))
 
 #define SIS_RXCFG_DRAIN_THRESH 0x003E /* 8-byte units */
 #define SIS_RXCFG_DMABURST 0x0070
@@ -262,8 +263,8 @@
 #define SIS_RXDMA_128BYTES 0x0060
 #define SIS_RXDMA_256BYTES 0x0070
 
-#define SIS_RXCFG256 \
-   (SIS_RXCFG_DRAIN(64)|SIS_RXDMA_256BYTES)
+#define SIS_RXCFG128 \
+   (SIS_RXCFG_DRAIN(128)|SIS_RXDMA_128BYTES)
 #define SIS_RXCFG64 \
(SIS_RXCFG_DRAIN(64)|SIS_RXDMA_64BYTES)
 
-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: LOR with filedesc structure and Giant

2003-08-17 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], David Malone writes:
On Sat, Aug 16, 2003 at 10:18:43PM +0200, Poul-Henning Kamp wrote:
 At one point we have to say Well, the locks we have above are solid,
 but we need to drop Giant below here but if Witness sees a
 PICKUP_GIANT() as an acquisition of Giant, rather than as a
 resumption of Giant, this clearly does not work.

Wouldn't the risk of deadlock be real, even if it is only a resumption
of Giant? I guess another option is to drop all the locks that are
held and reqcquire all of them in the right order...

There is no risk at the point where I drop Giant (as far as I have been
able to work out).  Dropping all the locks would not work, because it
is the other locks held which make dropping Giant safe.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Shin-ichi Yoshimoto
make installworld broken.

==libexex/rtld-elf
[snip]
ln: /usr/libexec/ld-elf.so.1: Operation not permitted
*** Error code 1

any idea ?

-- 
Shin-ichi YOSHIMOTO [EMAIL PROTECTED]
http://diary.waishi.jp/~yosimoto/diary/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on sparc64/sparc64

2003-08-17 Thread Tinderbox
TB --- 2003-08-17 11:12:46 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-08-17 11:12:46 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-17 11:14:47 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 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/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
cc -O -pipe  
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure/libexec/sftp-server/../../../crypto/openssh
 -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/bin/ld:
 warning: libz.so.2, needed by 
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so,
 not found (try using -rpath or -rpath-link)
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflate'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflate'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateInit_'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateInit_'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateEnd'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateEnd'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure/libexec/sftp-server.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure/libexec.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2003-08-17 12:03:51 - /usr/bin/make returned exit code  1 
TB --- 2003-08-17 12:03:51 - ERROR: failed to build world
TB --- 2003-08-17 12:03:51 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: if_xl borked in current!!

2003-08-17 Thread Andreas Klemm
On Sat, Aug 16, 2003 at 11:16:53AM -0600, M. Warner Losh wrote:
 nothing.  The 16-bit cards have always had issues on some machines or
 with some cards.  rather than mapping the cis in, 0's are read back.

I never had issues with this card in the same laptop since about
2 years under 4.x-STABLE.

Therefore I assume this is a bug in -current.

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 4.8-STABLE
Need a magic printfilter today ? - http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Slow Boot

2003-08-17 Thread Mike Atamas
When my system boots it seems to stall when it gets here:

xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe100-0xe10001ff irq 11 at device 11.
0 on pci1
ata2: at 0xe100 on atapci0
ata3: at 0xe100 on atapci0

It stalls for about 20-30 seconds and then continues booting. I can not figure out 
what the problem is or how to solve it. Has anyone had similar issues.

Mike Atamas
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Lot's of SIGILL, SIGSEGV

2003-08-17 Thread Stefan Bethke
I've got three machines having trouble doing a installworld, let alone a 
buildworld.

One is a Dell Inspiron 8100 with a GeForce which used to run just fine on a 
5.1-RC, which I updated yesterday.

Two are brand-new Shuttle SS51G with a SIS chipset and 2 GHz Celeron, which 
I installed on Friday, initially with 5.1-R, then cvsupped to -current.

I did make world with CPUTYPE=p4, as I believed this would be innocent. 
However, I can't make world right now without CPUTYPE; I'll get to the 
office to reinstall 5.1-R and make world without CPUTYPE on one of them to 
later today, to see if that helps.

Any other suggestions as to what could be the trouble? At this point I 
doubt it's hardware, as all three seemed to run just fine on 5.1.

Thanks,

Stefan

Here's the dmesg from one of the Shuttle's:

Copyright (c) 1992-2003 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.1-CURRENT #0: Sat Aug 16 12:53:10 CEST 2003
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EISENBOOT
Preloaded elf kernel /boot/kernel/kernel at 0xc0532000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc05321cc.
Timecounter i8254 frequency 1193182 Hz
CPU: Intel(R) Celeron(R) CPU 2.00GHz (2004.56-MHz 686-class CPU)
 Origin = GenuineIntel  Id = 0xf27  Stepping = 7
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MC
A,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
real memory  = 503250944 (479 MB)
avail memory = 483217408 (460 MB)
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: AWARD  AWRDACPI on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 6 entries at 0xc00fde70
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 
0x10c0-0x10ff,0x1000-0x10bf,0x480-0x48f,0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib0: slot 2 INTC is routed to irq 11
pcib0: slot 3 INTA is routed to irq 10
pcib0: slot 3 INTB is routed to irq 11
pcib0: slot 3 INTC is routed to irq 9
pcib0: slot 3 INTD is routed to irq 5
pcib0: slot 15 INTA is routed to irq 11
pcib0: slot 16 INTA is routed to irq 12
agp0: SIS Generic host to PCI bridge mem 0xe800-0xebff at device 
0.0 on pci0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib0: slot 1 INTA is routed to irq 10
pcib1: slot 0 INTA is routed to irq 10
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 2.0 on pci0
isa0: ISA bus on isab0
atapci0: SiS 96X UDMA133 controller port 
0x4000-0x400f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 2.5 
on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: multimedia, audio at device 2.7 (no driver attached)
ohci0: SiS 5571 USB controller mem 0xec10-0xec100fff irq 10 at device 
3.0 on pci0
usb0: OHCI version 1.0, legacy support
usb0: SiS 5571 USB controller on ohci0
usb0: USB revision 1.0
uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1: SiS 5571 USB controller mem 0xec101000-0xec101fff irq 11 at device 
3.1 on pci0
usb1: OHCI version 1.0, legacy support
usb1: SiS 5571 USB controller on ohci1
usb1: USB revision 1.0
uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ohci2: SiS 5571 USB controller mem 0xec102000-0xec102fff irq 9 at device 
3.2 on pci0
usb2: OHCI version 1.0, legacy support
usb2: SiS 5571 USB controller on ohci2
usb2: USB revision 1.0
uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
pci0: serial bus, USB at device 3.3 (no driver attached)
rl0: RealTek 8139 10/100BaseTX, rev. 8139D/8100B/8100C port 0xe800-0xe8ff 
mem 0xec104000-0xec1040ff irq 11 at device 15.0 on pci0
rl0: Ethernet address: 00:30:1b:23:aa:7f
miibus0: MII bus on rl0
rlphy0: RealTek internal media interface on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fwohci0: VIA VT6306 port 0xec00-0xec7f mem 0xec105000-0xec1057ff irq 12 
at device 16.0 on pci0
fwohci0: OHCI version 1.0 (ROM=1)
fwohci0: No. of Isochronous channel is 8.
fwohci0: EUI64 00:00:00:30:1b:27:f7:87
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: IEEE1394(FireWire) bus on fwohci0
if_fwe0: Ethernet over FireWire on firewire0
if_fwe0: Fake Ethernet address: 02:00:00:27:f7:87
sbp0: SBP2/SCSI over firewire on firewire0
fwohci0: Initiate bus reset
fwohci0: BUS reset
fwohci0: node_id=0x8800ffc0, gen=1, non CYCLEMASTER mode
firewire0: 2 nodes, maxhop = 1, cable IRM = 1
fdc0: 

Re: if_xl borked in current!!

2003-08-17 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Andreas Klemm [EMAIL PROTECTED] writes:
: On Sat, Aug 16, 2003 at 11:16:53AM -0600, M. Warner Losh wrote:
:  nothing.  The 16-bit cards have always had issues on some machines or
:  with some cards.  rather than mapping the cis in, 0's are read back.
: 
: I never had issues with this card in the same laptop since about
: 2 years under 4.x-STABLE.
: 
: Therefore I assume this is a bug in -current.

That's what I was trying to say.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Robert Watson

On Sun, 17 Aug 2003, Shin-ichi Yoshimoto wrote:

 make installworld broken.
 
 ==libexex/rtld-elf
 [snip]
 ln: /usr/libexec/ld-elf.so.1: Operation not permitted
 *** Error code 1
 
 any idea ? 

I'm guessing we need to remove the schg flag from the old ld-elf.so.1
before trying to replace it with a symlink:

paprika:/usr/src/kerberos5/usr.bin/kadmin ls -lo /usr/libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  schg 133292 Jul  3 21:07 /usr/libexec/ld-elf.so.1*

You can work around it locally, probably, by doing a chflags noschg
/usr/libexec/ld-elf.so.1, but the official makefiles probably need to do
something about it also.

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


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


bluetooth on 5.1-release or -current ?

2003-08-17 Thread Kim Culhan

Trying to get Max Yevmenkin's bluetooth stack running on 5.1-release.

This with ngbt-fbsd-20030501.tar.gz from

http://www.geocities.com/m_evmenkin/

Trying to start the stack, it returns:

./rc.bluetooth start ubt0

Could not execute command reset. Operation timed out

From the syslog:

ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command
OGF=0x3, OCF=0x3. Timeout

ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)

kldstat shows:

Id Refs AddressSize Name
 1   15 0xc010 3de128   kernel
 21 0xc04df000 bf44 ng_ubt.ko
 31 0xc04eb000 4a30cacpi.ko
 44 0xc2953000 2000 ng_bluetooth.ko
 51 0xc2957000 13000ng_hci.ko
 61 0xc296a000 16000ng_l2cap.ko
 71 0xc2981000 1c000ng_btsocket.ko
 81 0xc26d8000 4000 ng_socket.ko


Any help here is greatly appreciated..

-kim

--
[EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on alpha/alpha

2003-08-17 Thread Tinderbox
TB --- 2003-08-17 16:00:12 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-08-17 16:00:12 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-17 16:01:53 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 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/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec/sftp-server/../../../crypto/openssh
 -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin/ld:
 warning: libz.so.2, needed by 
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so,
 not found (try using -rpath or -rpath-link)
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `deflate'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `inflate'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateInit_'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateInit_'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateEnd'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateEnd'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec/sftp-server.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
TB --- 2003-08-17 16:58:12 - /usr/bin/make returned exit code  1 
TB --- 2003-08-17 16:58:12 - ERROR: failed to build world
TB --- 2003-08-17 16:58:12 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on amd64/amd64

2003-08-17 Thread Tinderbox
TB --- 2003-08-17 16:58:13 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2003-08-17 16:58:13 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-17 16:59:51 - building world
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 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/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
cc -O -pipe  
-I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure/libexec/sftp-server/../../../crypto/openssh
 -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin/ld:
 warning: libz.so.2, needed by 
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so,
 not found (try using -rpath or -rpath-link)
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflate'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflate'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateInit_'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateInit_'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateEnd'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateEnd'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure/libexec/sftp-server.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure/libexec.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
TB --- 2003-08-17 17:52:17 - /usr/bin/make returned exit code  1 
TB --- 2003-08-17 17:52:17 - ERROR: failed to build world
TB --- 2003-08-17 17:52:17 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


error: ln: /usr/libexec/ld-elf.so.1: Operation not permitted

2003-08-17 Thread dave
 I'm getting a consistent error with cvsup from this morning during
make installworld
libexec/rtld-elf
install -s -o root -g wheel -m 555  -fschg -C -b ld-elf.so.1 /libexec
install -o root -g wheel -m 444 rtld.1.gz  /usr/share/man/man1
/usr/share/man/man1/ld-elf.so.1.1.gz - /usr/share/man/man1/rtld.1.gz
/usr/share/man/man1/ld.so.1.gz - /usr/share/man/man1/rtld.1.gz
/usr/libexec/ld-elf.so.1 - /libexec/ld-elf.so.1
ln: /usr/libexec/ld-elf.so.1: Operation not permitted
*** Error code 1
Stop in /usr/src/libexec/rtld-elf.
*** Error code 1
Stop in /usr/src/libexec.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
# exit
Script done on Sun Aug 17 07:48:42 2003
I've done make cleandir and re-cvsup etc. Same error.
amd 2400 asus mb. running cvsup/makeworld  almost daily for
4 months with minimal problems.
Probably something simple I just don't see.

cheers,

dave

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: bluetooth on 5.1-release or -current ?

2003-08-17 Thread Maksim Yevmenkin
Hello Kim,

 Trying to get Max Yevmenkin's bluetooth stack running on 5.1-release.
 
 This with ngbt-fbsd-20030501.tar.gz from
 
 http://www.geocities.com/m_evmenkin/

first of all - all kernel modules and user space tools were committed to
-current. so you do not have to use snapshots. all kernel modules are
connected to buildkernel process, so you should have all bluetooth modules
in /boot/kernel/modules. note: user space tools are not connected to the 
buildworld process, so you have to build them by hand, i.e.

# cd /usr/src/usr.bin/bluetooth
# make depend  make intall  make clean

# cd /usr/src/usr.sbin/bluetooth
# make depend  make intall  make clean

example of rc.bluetooth script can be found in 

/usr/src/share/examples/netgraph/bluetooth
 
 Trying to start the stack, it returns:
 
 ./rc.bluetooth start ubt0
 
 Could not execute command reset. Operation timed out
 
 From the syslog:
 
 ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command
 OGF=0x3, OCF=0x3. Timeout
 
 ubt_request_complete2: ubt0 - Control request failed. TIMEOUT (15)

well, the USB device did not respond to the control request.

1) what USB device do you have? (please give me exact name/model number).

2) what did ng_ubt(4) driver said when you attached the device
   (look for ubt0: ... lines in /var/log/messages). 
 
 kldstat shows:
 
 Id Refs AddressSize Name
  1   15 0xc010 3de128   kernel
  21 0xc04df000 bf44 ng_ubt.ko
  31 0xc04eb000 4a30cacpi.ko
  44 0xc2953000 2000 ng_bluetooth.ko
  51 0xc2957000 13000ng_hci.ko
  61 0xc296a000 16000ng_l2cap.ko
  71 0xc2981000 1c000ng_btsocket.ko
  81 0xc26d8000 4000 ng_socket.ko

this looks fine. what does ngctl li says? 
 
 Any help here is greatly appreciated..

i need to know more about the USB device you have. some USB devices may
require
firmware download (for example Broadcom chip based devices). you can verify
that you have (or dont have) Broadcom device by looking at USB vendor ID,
product ID pair (vendor ID - Broadcom/Product ID - 0x2033). if you do have a
Broadcom device you need to

1) make sure the USB device is detached
2) load ubtbcmfw(4) module
3) load ng_ubt(4) module
4) attach the device
5) load Broadcom firmware with bcmfw(8) tools (in /usr/src/usr.sbin/bluetooth)
   (note: you need to get firmware of the internet - see man page)
6) verify that ubtbcmfw0: device was detached and ubt0: device was attached
7) run rc.bluetooth script on ubt0 device

hope this helps.

thanks,
max

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Gordon Tetlow
On Sun, Aug 17, 2003 at 08:47:42PM +0900, Shin-ichi Yoshimoto wrote:
 make installworld broken.
 
 ==libexex/rtld-elf
 [snip]
 ln: /usr/libexec/ld-elf.so.1: Operation not permitted
 *** Error code 1
 
 any idea ?

Thanks for reporting this. I've fixed it in rev 1.22 of
src/libexec/rtld-elf/Makefile.

-gordon


pgp0.pgp
Description: PGP signature


Re: Slow Boot

2003-08-17 Thread Bill Moran
Mike Atamas wrote:
When my system boots it seems to stall when it gets here:

xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe100-0xe10001ff irq 11 at device 11.
0 on pci1
ata2: at 0xe100 on atapci0
ata3: at 0xe100 on atapci0
It stalls for about 20-30 seconds and then continues booting. I can not figure out
 what the problem is or how to solve it. Has anyone had similar issues.

I've seen this on various hardware.  I actually have a 200mhz machine sitting here
that has always done this.  I've never seen it cause any problems, and I've never
had any suggestions on how to stop it either.
My best guess is that the chipset responds slowly to probes, thus it takes a while
to get the list of devices from it.  However, I've never looked into it any more
than that.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: error: ln: /usr/libexec/ld-elf.so.1: Operation not permitted

2003-08-17 Thread Jeremy Messenger
On Sun, 17 Aug 2003 13:41:17 -0500, dave [EMAIL PROTECTED] wrote:

I'm getting a consistent error with cvsup from this morning during
make installworld
snip
ln: /usr/libexec/ld-elf.so.1: Operation not permitted
snip
I've done make cleandir and re-cvsup etc. Same error.
amd 2400 asus mb. running cvsup/makeworld  almost daily for
4 months with minimal problems.
Probably something simple I just don't see.
gordon just fixed in the rev 1.22 of src/libexec/rtld-elf/Makefile, so 
CVSup and try it again.

Cheers,
Mezz
cheers,

dave


--
bsdforums.org 's moderator, mezz.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: if_xl borked in current!!

2003-08-17 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
M. Warner Losh [EMAIL PROTECTED] writes:
: In message: [EMAIL PROTECTED]
: Andreas Klemm [EMAIL PROTECTED] writes:
: : On Sat, Aug 16, 2003 at 11:16:53AM -0600, M. Warner Losh wrote:
: :  nothing.  The 16-bit cards have always had issues on some machines or
: :  with some cards.  rather than mapping the cis in, 0's are read back.
: : 
: : I never had issues with this card in the same laptop since about
: : 2 years under 4.x-STABLE.
: : 
: : Therefore I assume this is a bug in -current.
: 
: That's what I was trying to say.

Here 'always had issues' means 'always with NEWCARD'.  That wasn't
very clear.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Gordon Tetlow
On Sun, Aug 17, 2003 at 11:51:36AM -0700, Gordon Tetlow wrote:
 On Sun, Aug 17, 2003 at 08:47:42PM +0900, Shin-ichi Yoshimoto wrote:
  make installworld broken.
  
  ==libexex/rtld-elf
  [snip]
  ln: /usr/libexec/ld-elf.so.1: Operation not permitted
  *** Error code 1
  
  any idea ?
 
 Thanks for reporting this. I've fixed it in rev 1.22 of
 src/libexec/rtld-elf/Makefile.

Silly me forgot to honor DESTDIR. rev 1.23 is much better =)

-gordon


pgp0.pgp
Description: PGP signature


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Shin-ichi Yoshimoto
Subject: Re: HEADS UP: dynamic root support now in the tree,
On Sun, 17 Aug 2003 12:05:34 -0700, Gordon Tetlow wrote:
  Thanks for reporting this. I've fixed it in rev 1.22 of
  src/libexec/rtld-elf/Makefile.
 
 Silly me forgot to honor DESTDIR. rev 1.23 is much better =)

Thanks Gordon. I can save a space :-)

-- 
Shin-ichi YOSHIMOTO [EMAIL PROTECTED]
http://diary.waishi.jp/~yosimoto/diary/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Gordon Tetlow
On Sun, Aug 17, 2003 at 01:54:38AM -0700, Gordon Tetlow wrote:
 I just got through with my commit spree to enable users to build /bin
 and /sbin dynamically linked. To do this required a fair amount of
 tweaking and moving around libraries and such dangerous equipment as
 rtld-elf. If you have any systems that you are dearly in love with,
 now is not the time to cvsup. Please wait until any potential issues
 are shaken out of the tree. I've done as much testing as I can, but
 as experience has shown me, there are likely to be issues.

Just to clear everything up. A dynamically-linked /sbin and /bin is
still not the default. In order to build a dynamically-linked /sbin
and /bin requires you to define WITH_DYNAMICROOT. Sorry for the
confusion.

-gordon


pgp0.pgp
Description: PGP signature


RE: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Devon H. O'Dell
Hey,

Just signed up for this list; so I just read the archive -- my question is:
Will this be default when it's stable?

Kind regards,

Devon

 -Oorspronkelijk bericht-
 Van: [EMAIL PROTECTED] [mailto:owner-freebsd-
 [EMAIL PROTECTED] Namens Gordon Tetlow
 Verzonden: Sunday, August 17, 2003 10:26 PM
 Aan: [EMAIL PROTECTED]
 Onderwerp: Re: HEADS UP: dynamic root support now in the tree
 
 On Sun, Aug 17, 2003 at 01:54:38AM -0700, Gordon Tetlow wrote:
  I just got through with my commit spree to enable users to build /bin
  and /sbin dynamically linked. To do this required a fair amount of
  tweaking and moving around libraries and such dangerous equipment as
  rtld-elf. If you have any systems that you are dearly in love with,
  now is not the time to cvsup. Please wait until any potential issues
  are shaken out of the tree. I've done as much testing as I can, but
  as experience has shown me, there are likely to be issues.
 
 Just to clear everything up. A dynamically-linked /sbin and /bin is
 still not the default. In order to build a dynamically-linked /sbin
 and /bin requires you to define WITH_DYNAMICROOT. Sorry for the
 confusion.
 
 -gordon

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [current tinderbox] failure on alpha/alpha

2003-08-17 Thread Gordon Tetlow
On Sun, Aug 17, 2003 at 12:58:12PM -0400, Tinderbox wrote:
  stage 4: building everything..
 [...]
 cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee 
 -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec/sftp-server/../../../crypto/openssh
  -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
 /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin/ld:
  warning: libz.so.2, needed by 
 /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so,
  not found (try using -rpath or -rpath-link)

I have a patch to fix this that I'm currently waiting on DES to approve.

-gordon


pgp0.pgp
Description: PGP signature


Re: error: ln: /usr/libexec/ld-elf.so.1: Operation not permitted

2003-08-17 Thread dave
At 01:57 PM 8/17/2003

gordon just fixed in the rev 1.22 of src/libexec/rtld-elf/Makefile, so 
CVSup and try it again.

Cheers,
Mezz


it's fine now.

thanks
dave
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


cdcontrol no longer needs 'c' partition?

2003-08-17 Thread Craig Rodrigues
Hi,

With GEOM in place, is the 'c' partition for a CD device no
longer necessary for cdcontrol?  At least on my system,
the CD shows up as /dev/acd0, not as /dev/acd0c.


--- src/usr.sbin/cdcontrol/cdcontrol.c.orig Sun Aug 17 17:25:46 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.c  Sun Aug 17 17:27:49 2003
@@ -52,10 +52,6 @@
 #  define DEFAULT_CD_DRIVE  /dev/cd0
 #endif
 
-#ifndef DEFAULT_CD_PARTITION
-#  define DEFAULT_CD_PARTITION  c
-#endif
-
 #define CMD_DEBUG  1
 #define CMD_EJECT  2
 #define CMD_HELP   3
@@ -1248,11 +1244,6 @@
}
 
fd = open (devbuf, O_RDONLY);
-
-   if (fd  0  errno == ENOENT) {
-   strcat (devbuf, DEFAULT_CD_PARTITION);
-   fd = open (devbuf, O_RDONLY);
-   }
 
if (fd  0) {
if (errno == ENXIO) {
--- src/usr.sbin/cdcontrol/cdcontrol.1.orig Sun Aug 17 17:25:39 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.1  Sun Aug 17 17:26:27 2003
@@ -185,10 +185,10 @@
 .Ev CDROM .
 .El
 .Sh FILES
-.Bl -tag -width .Pa /dev/mcd0c -compact
-.It Pa /dev/cd0c
-.It Pa /dev/mcd0c
-.It Pa /dev/acd0c
+.Bl -tag -width .Pa /dev/mcd0 -compact
+.It Pa /dev/cd0
+.It Pa /dev/mcd0
+.It Pa /dev/acd0
 .El
 .Sh AUTHORS
 .An Jean-Marc Zucconi




-- 
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: cdcontrol no longer needs 'c' partition?

2003-08-17 Thread Poul-Henning Kamp

Yes, the 'a' and 'c' partitions on CD drives are bogus, but this
has nothing directly to do with GEOM, it is only a sideeffect
of the semantic cleanups that went ahead of GEOM.

The patch looks good to me, but I'd like somebody to test it
before it gets committed.  Any takers ?

Poul-Henning

In message [EMAIL PROTECTED], Craig Rodrigues writes:
Hi,

With GEOM in place, is the 'c' partition for a CD device no
longer necessary for cdcontrol?  At least on my system,
the CD shows up as /dev/acd0, not as /dev/acd0c.


--- src/usr.sbin/cdcontrol/cdcontrol.c.origSun Aug 17 17:25:46 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.c Sun Aug 17 17:27:49 2003
@@ -52,10 +52,6 @@
 #  define DEFAULT_CD_DRIVE  /dev/cd0
 #endif
 
-#ifndef DEFAULT_CD_PARTITION
-#  define DEFAULT_CD_PARTITION  c
-#endif
-
 #define CMD_DEBUG 1
 #define CMD_EJECT 2
 #define CMD_HELP  3
@@ -1248,11 +1244,6 @@
   }
 
   fd = open (devbuf, O_RDONLY);
-
-  if (fd  0  errno == ENOENT) {
-  strcat (devbuf, DEFAULT_CD_PARTITION);
-  fd = open (devbuf, O_RDONLY);
-  }
 
   if (fd  0) {
   if (errno == ENXIO) {
--- src/usr.sbin/cdcontrol/cdcontrol.1.origSun Aug 17 17:25:39 2003
+++ src/usr.sbin/cdcontrol/cdcontrol.1 Sun Aug 17 17:26:27 2003
@@ -185,10 +185,10 @@
 .Ev CDROM .
 .El
 .Sh FILES
-.Bl -tag -width .Pa /dev/mcd0c -compact
-.It Pa /dev/cd0c
-.It Pa /dev/mcd0c
-.It Pa /dev/acd0c
+.Bl -tag -width .Pa /dev/mcd0 -compact
+.It Pa /dev/cd0
+.It Pa /dev/mcd0
+.It Pa /dev/acd0
 .El
 .Sh AUTHORS
 .An Jean-Marc Zucconi




-- 
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


bluetooth working on 5.1-release

2003-08-17 Thread Kim Culhan

Greetings current-

Have bluetooth almost working on 5.1-release, thank you Max.

On Sun, 17 Aug 2003, Maksim Yevmenkin wrote:

 first of all - all kernel modules and user space tools were committed to
 -current. so you do not have to use snapshots. all kernel modules are
 connected to buildkernel process, so you should have all bluetooth
modules
 in /boot/kernel/modules. note: user space tools are not connected to the
 buildworld process, so you have to build them by hand, i.e.

 # cd /usr/src/usr.bin/bluetooth
 # make depend  make intall  make clean

 # cd /usr/src/usr.sbin/bluetooth
 # make depend  make intall  make clean

 example of rc.bluetooth script can be found in

 /usr/src/share/examples/netgraph/bluetooth

The device is a Belkin F8T001, at plugin it logs:

Aug 17 16:43:01 radio kernel: ubt0: Broadcom Corp. BCM2033, rev 1.01/0.a0,
addr 2
Aug 17 16:43:01 radio kernel: ubt0: Interface 0 endpoints: interrupt=0x81,
bulk-in=0x82, bulk-out=0x2
Aug 17 16:43:01 radio kernel: ubt0: Interface 1 (alt.config 4) endpoints:
isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320

Procedure which works as follows:

 1) make sure the USB device is detached
 2) load ubtbcmfw(4) module
 3) load ng_ubt(4) module
 4) attach the device

It logs:

Aug 17 16:10:31 radio kernel: ubtbcmfw0: Broadcom product 0x2033, rev
1.01/0.a0, addr 2 ^

 5) load Broadcom firmware with bcmfw(8) tools (in
 /usr/src/usr.sbin/bluetooth)
 (note: you need to get firmware off the internet - see man page)

Off the net:

http://bluez.sourceforge.net/download/bluez-bluefw-0.9.tar.gz

Then load the minidriver and firmware:

bcmfw -n ubtbcmfw0 -m /usr/local/bin/BCM2033-MD.hex -f [all one line..]
/usr/local/bin/BCM2033-FW.bin

 6) verify that ubtbcmfw0: device was detached and ubt0: device was
 attached

It logs:

Aug 17 17:25:24 radio kernel: ubtbcmfw0: at uhub0 port 1 (addr 2)
disconnected
Aug 17 17:25:24 radio kernel: ubtbcmfw0: detached
Aug 17 17:25:25 radio kernel: ubt0: Broadcom Corp. BCM2033, rev 1.01/0.a0,
addr 2
Aug 17 17:25:25 radio kernel: ubt0: Interface 0 endpoints: interrupt=0x81,
bulk-in=0x82, bulk-out=0x2
Aug 17 17:25:25 radio kernel: ubt0: Interface 1 (alt.config 4) endpoints:
isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320

 7) run rc.bluetooth script on ubt0 device

Aug 17 16:45:40 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0xe, length=4
Aug 17 16:45:40 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0xe, length=10
Aug 17 16:45:40 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0xe, length=12
Aug 17 16:45:40 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0xe, length=11
Aug 17 16:45:40 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0xe, length=4
Aug 17 16:45:40 radio last message repeated 2 times
Aug 17 16:45:40 radio kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - HCI node
is up, bdaddr: 0:3:c9:2d:c9:b5, pkt_size=377 bytes, num_pkts=10

Yeah !! Great !!

Now it returns:

radio# /etc/rc.bluetooth start ubt0
BD_ADDR: 00:03:c9:2d:c9:b5
Features: 0xff 0xfd 0x5 00 00 00 00 00
3-Slot 5-Slot Encryption Slot offset
Timing accuracy Switch Hold mode Sniff mode
Park mode Channel quality SCO link HV2 packets
HV3 packets u-law log A-law log CVSD
Power control
Max. ACL packet size: 377 bytes
Number of ACL packets: 10
Max. SCO packet size: 16 bytes
Number of SCO packets: 0

Now this problem:

radio# hccontrol -n ubt0hci inquiry
Inquiry complete. Status: No error [00]

It logs:

Aug 17 17:28:41 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0xf, length=4
Aug 17 17:28:47 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0x1, length=1
Aug 17 17:29:59 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0xf, length=4
Aug 17 17:30:05 radio kernel: ng_hci_process_event: ubt0hci - got HCI
event=0x7, length=255

What do you think Max ?

-kim

--
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on ia64/ia64

2003-08-17 Thread Tinderbox
TB --- 2003-08-17 20:55:11 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-08-17 20:55:11 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-17 20:57:48 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 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/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
cc -O -pipe  
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/secure/libexec/sftp-server/../../../crypto/openssh
 -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/bin/ld:
 warning: libz.so.2, needed by 
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libssh.so,
 not found (try using -rpath or -rpath-link)
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflate'
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflate'
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateInit_'
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateInit_'
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateEnd'
/home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateEnd'
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/secure/libexec/sftp-server.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/secure/libexec.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/secure.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src.
TB --- 2003-08-17 21:53:57 - /usr/bin/make returned exit code  1 
TB --- 2003-08-17 21:53:57 - ERROR: failed to build world
TB --- 2003-08-17 21:53:57 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RFC: Allow non-root users to use make distribution and makeinstallworld?

2003-08-17 Thread Bruce Evans
On Sun, 17 Aug 2003, Ulrich Spoerlein wrote:

 I'm trying to build a new LiveCD based upon the Freesbie scripts, and
 well, I don't want to require superuser privileges to build the LiveCD
 image. While this is not a problem with 'make buildworld' 'make
 distribution' in /usr/src/etc is broken for the non-root case.

 Attached are some patches to make this work by make the user/group
 info passed to install overrideable.

 The problem now lies with 'make installworld' which currently dies here:
 === lib/libcom_err/doc
 install-info --quiet  --defsection=Programming  development tools.  --defentry=* 
 libcom_err: (com_err).A Common Error Description Library for UNIX.  
 com_err.info /usr/test/root/usr/share/info/dir
 /usr/test/root/usr/share/info/dir: Permission denied
 *** Error code 1

 because /usr/share/info/dir has permissions 444 and therefore the 'user'
 can't write to that file (whereas mode 444 wouldn't stop the superuser)

 The question now is, should I provide patches to make this work. Do we
 actually want this to work? Or is anybody trying to run installworld as
 non-user doing something completely stupid?

I tried this the other day but gave up on the info dir.  I was doing
something stupid -- I knew that installworld wouldn't work and only
wanted to test buildworld, but forgot to change the test script :-).

Setting INFOMODE to 644 should work after you fix all the hard-coded
ownerships and modes.  Other defaults for the mode may need to be changed
similarly.

The default read-only modes are bogus for root anyway.  BINMODE=555 only
made sense when BINOWN was bin.  But read-only modes are a safe default.

 --- etc/isdn/Makefile.origSun Aug 17 20:14:23 2003
 +++ etc/isdn/Makefile Sun Aug 17 20:14:48 2003
 @@ -18,8 +18,8 @@

  install:
   for i in ${I4BETCPROG} ; do \
 -   ${INSTALL} -o root -g wheel -m 700 $$i ${DESTDIR}/etc/isdn ; \
 +   ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 700 $$i ${DESTDIR}/etc/isdn 
 ; \
   done ; \
   for i in ${I4BETCFILE} ; do \
 -   ${INSTALL} -o root -g wheel -m 600 $$i ${DESTDIR}/etc/isdn ; \
 +   ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 600 $$i ${DESTDIR}/etc/isdn 
 ; \
   done

The patches make some lines too long.

 --- etc/rc.d/motd.origSun Aug 17 20:24:01 2003
 +++ etc/rc.d/motd Sun Jun 15 18:55:59 2003
 @@ -33,7 +33,7 @@
   #
   echo Updating motd.
   if [ ! -f /etc/motd ]; then
 - install -c -o ${BINOWN} -g ${BINGRP} -m ${PERMS} /dev/null /etc/motd
 + install -c -o root -g wheel -m ${PERMS} /dev/null /etc/motd
   fi

   case ${OSTYPE} in

This partcular patch seems to be reversed.

I don't see how rc.d can know the build defaults.  Perhaps it shouldn't.
It could adjust ownerships and modes to runtime defaults if the build
ones are insecure.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on sparc64/sparc64

2003-08-17 Thread Tinderbox
TB --- 2003-08-17 21:53:57 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-08-17 21:53:57 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-17 21:56:36 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 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/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
cc -O -pipe  
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure/libexec/sftp-server/../../../crypto/openssh
 -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/bin/ld:
 warning: libz.so.2, needed by 
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so,
 not found (try using -rpath or -rpath-link)
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflate'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflate'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateInit_'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateInit_'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateEnd'
/home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateEnd'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure/libexec/sftp-server.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure/libexec.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/secure.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2003-08-17 22:45:40 - /usr/bin/make returned exit code  1 
TB --- 2003-08-17 22:45:40 - ERROR: failed to build world
TB --- 2003-08-17 22:45:40 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread Shin-ichi Yoshimoto
Subject: Re: HEADS UP: dynamic root support now in the tree,
On Mon, 18 Aug 2003 04:28:53 +0900, Shin-ichi Yoshimoto wrote:
 Thanks Gordon. I can save a space :-)

I found another problem in src/Makefile.inc

[snip]
.if ${TARGET_ARCH} == ${MACHINE_ARCH}  !defined(DISTDIR)  \
(!defined(DESTDIR) || empty(DESTDIR) || ${DESTDIR} == /)
@echo Checking to see if your booted kernel is fresh enough..
${.OBJDIR}/bin/sh/sh -c \
'echo Testing installed kernel for new sigaction(2) 
syscall'
@echo Seems ok..
.endif
[snip]

${.OBJDIR}/bin/sh/sh is dynamically-linked if WITH_DYNAMICROOT is 
defined. But sh cannot find /libexec/ld-elf.so.1 before instaling 
/libexec/ld-elf.so.1.

Is this right ?

-- 
Shin-ichi YOSHIMOTO [EMAIL PROTECTED]
http://diary.waishi.jp/~yosimoto/diary/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: bluetooth working on 5.1-release

2003-08-17 Thread Maksim Yevmenkin
Hello Kim,

 Have bluetooth almost working on 5.1-release, thank you Max.

[...]
 
 The device is a Belkin F8T001, at plugin it logs:
 
 Aug 17 16:43:01 radio kernel: ubt0: Broadcom Corp. BCM2033, rev 1.01/0.a0,
 addr 2
 Aug 17 16:43:01 radio kernel: ubt0: Interface 0 endpoints: interrupt=0x81,
 bulk-in=0x82, bulk-out=0x2
 Aug 17 16:43:01 radio kernel: ubt0: Interface 1 (alt.config 4) endpoints:
 isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320

yes, it is a Broadcom chip based device. you need to download firmware 
before you can use it.

 Procedure which works as follows:
 
  1) make sure the USB device is detached
  2) load ubtbcmfw(4) module
  3) load ng_ubt(4) module
  4) attach the device
 
 It logs:
 
 Aug 17 16:10:31 radio kernel: ubtbcmfw0: Broadcom product 0x2033, rev
 1.01/0.a0, addr 2 ^

yes, that is correct
 
  5) load Broadcom firmware with bcmfw(8) tools (in
  /usr/src/usr.sbin/bluetooth)
  (note: you need to get firmware off the internet - see man page)
 
 Off the net:
 
 http://bluez.sourceforge.net/download/bluez-bluefw-0.9.tar.gz
 
 Then load the minidriver and firmware:
 
 bcmfw -n ubtbcmfw0 -m /usr/local/bin/BCM2033-MD.hex -f [all one line..]
 /usr/local/bin/BCM2033-FW.bin

yes. that is also correct

  6) verify that ubtbcmfw0: device was detached and ubt0: device was
  attached
 
 It logs:
 
 Aug 17 17:25:24 radio kernel: ubtbcmfw0: at uhub0 port 1 (addr 2)
 disconnected
 Aug 17 17:25:24 radio kernel: ubtbcmfw0: detached
 Aug 17 17:25:25 radio kernel: ubt0: Broadcom Corp. BCM2033, rev 1.01/0.a0,
 addr 2
 Aug 17 17:25:25 radio kernel: ubt0: Interface 0 endpoints: interrupt=0x81,
 bulk-in=0x82, bulk-out=0x2
 Aug 17 17:25:25 radio kernel: ubt0: Interface 1 (alt.config 4) endpoints:
 isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320

yes, that is what is should look like.
 
  7) run rc.bluetooth script on ubt0 device

[...]
 
 Yeah !! Great !!
 
 Now it returns:
 
 radio# /etc/rc.bluetooth start ubt0
 BD_ADDR: 00:03:c9:2d:c9:b5
 Features: 0xff 0xfd 0x5 00 00 00 00 00
 3-Slot 5-Slot Encryption Slot offset
 Timing accuracy Switch Hold mode Sniff mode
 Park mode Channel quality SCO link HV2 packets
 HV3 packets u-law log A-law log CVSD
 Power control
 Max. ACL packet size: 377 bytes
 Number of ACL packets: 10
 Max. SCO packet size: 16 bytes
 Number of SCO packets: 0

well, your Belkin adapter was initialized successfully. everything so far
looks
normal to me. BTW you do not have to have debug level so high :) 

 Now this problem:
 
 radio# hccontrol -n ubt0hci inquiry
 Inquiry complete. Status: No error [00]
 
 It logs:
 
 Aug 17 17:28:41 radio kernel: ng_hci_process_event: ubt0hci - got HCI
 event=0xf, length=4
 Aug 17 17:28:47 radio kernel: ng_hci_process_event: ubt0hci - got HCI
 event=0x1, length=1
 Aug 17 17:29:59 radio kernel: ng_hci_process_event: ubt0hci - got HCI
 event=0xf, length=4
 Aug 17 17:30:05 radio kernel: ng_hci_process_event: ubt0hci - got HCI
 event=0x7, length=255
 
 What do you think Max ?

i do not see any problem. you have asked local device to perform an inquiry,
i.e. discover other Bluetooth devices in range. what local device tells you
is that there is no devices in range. Note: the device can be put into the
hidden mode where it will ignore inquiry requests. this hidden mode is
default on almost all devices. make sure you make your other device (i.e.
cell phone, PDA, etc.) is in discoverable (or sometimes called visible)
mode. once you put other device in discoverable mode, run inquiry again
and you should see responses.

thanks,
max


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Slow Boot

2003-08-17 Thread Kevin Oberman
I have been seeing this for some time ( 2 years) on my ASUS P5A based
K6 system. I have no idea why it's doing it, but I re-boot so
infrequently that I just have not worried about it. It does seem that
it is less likely to happen after a true cold boot. (Cut main power.)

I was seeing this with V4 and I'm seeing it with V5. I don't think I
ever saw it back on V3, but that was a LONG time ago. It may have
started when some change was made to the ATA driver, but I really
can't say since it's been doing it for so long.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RFC: Allow non-root users to use make distribution and makeinstallworld?

2003-08-17 Thread David O'Brien
On Sun, Aug 17, 2003 at 10:58:51PM +0200, Ulrich Spoerlein wrote:
 The question now is, should I provide patches to make this work. Do we
 actually want this to work? Or is anybody trying to run installworld as
 non-user doing something completely stupid?

I've committed the obivously correct parts of this.  Can you post a new
proposed diff?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: dynamic root support now in the tree

2003-08-17 Thread David O'Brien
On Sun, Aug 17, 2003 at 01:54:38AM -0700, Gordon Tetlow wrote:
 I just got through with my commit spree to enable users to build /bin
 and /sbin dynamically linked. To do this required a fair amount of
 tweaking and moving around libraries and such dangerous equipment as

I think this is a more correct way to change the install locations of the
/ needed libs.  Your current way makes the real location a 2nd class
citizen vs. /usr/lib for any needed compatibility links.

I'd like to commit this:

Index: lib/libalias/Makefile
===
RCS file: /home/ncvs/src/lib/libalias/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- lib/libalias/Makefile   17 Aug 2003 08:28:43 -  1.21
+++ lib/libalias/Makefile   18 Aug 2003 01:42:15 -
@@ -1,7 +1,7 @@
 # $FreeBSD: src/lib/libalias/Makefile,v 1.21 2003/08/17 08:28:43 gordon Exp $
 
 LIB=   alias
-SHLIBDIR?= /lib
+LIBDIR?= /lib
 SHLIB_MAJOR=   4
 MAN=   libalias.3
 SRCS=  alias.c alias_cuseeme.c alias_db.c alias_ftp.c alias_irc.c \
Index: lib/libatm/Makefile
===
RCS file: /home/ncvs/src/lib/libatm/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- lib/libatm/Makefile 17 Aug 2003 08:28:43 -  1.8
+++ lib/libatm/Makefile 18 Aug 2003 01:42:11 -
@@ -28,7 +28,7 @@
 #
 
 LIB=   atm
-SHLIBDIR?= /lib
+LIBDIR?= /lib
 SRCS=  atm_addr.c cache_key.c ioctl_subr.c ip_addr.c ip_checksum.c timer.c
 INCS=  libatm.h
 
Index: lib/libc/Makefile
===
RCS file: /home/ncvs/src/lib/libc/Makefile,v
retrieving revision 1.42
diff -u -r1.42 Makefile
--- lib/libc/Makefile   17 Aug 2003 08:28:44 -  1.42
+++ lib/libc/Makefile   18 Aug 2003 01:42:08 -
@@ -10,7 +10,7 @@
 # system call stubs.
 LIB=c
 SHLIB_MAJOR= 5
-SHLIBDIR?=/lib
+LIBDIR?= /lib
 CFLAGS+=-I${.CURDIR}/include -I${.CURDIR}/../../include
 CFLAGS+=-I${.CURDIR}/${MACHINE_ARCH}
 CLEANFILES+=tags
Index: lib/libcam/Makefile
===
RCS file: /home/ncvs/src/lib/libcam/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- lib/libcam/Makefile 17 Aug 2003 08:28:44 -  1.11
+++ lib/libcam/Makefile 18 Aug 2003 01:42:21 -
@@ -1,7 +1,7 @@
 # $FreeBSD: src/lib/libcam/Makefile,v 1.11 2003/08/17 08:28:44 gordon Exp $
 
 LIB=   cam
-SHLIBDIR?= /lib
+LIBDIR?=   /lib
 SRCS=  camlib.c scsi_cmdparse.c scsi_all.c scsi_da.c scsi_sa.c cam.c
 INCS=  camlib.h
 
Index: lib/libcrypt/Makefile
===
RCS file: /home/ncvs/src/lib/libcrypt/Makefile,v
retrieving revision 1.33
diff -u -r1.33 Makefile
--- lib/libcrypt/Makefile   17 Aug 2003 08:28:44 -  1.33
+++ lib/libcrypt/Makefile   18 Aug 2003 01:42:23 -
@@ -4,7 +4,7 @@
 
 SHLIB_MAJOR=   2
 LIB=   crypt
-SHLIBDIR?= /lib
+LIBDIR?=   /lib
 
 .PATH: ${.CURDIR}/../libmd
 SRCS=  crypt.c misc.c \
Index: lib/libdevstat/Makefile
===
RCS file: /home/ncvs/src/lib/libdevstat/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- lib/libdevstat/Makefile 17 Aug 2003 08:28:44 -  1.12
+++ lib/libdevstat/Makefile 18 Aug 2003 01:42:28 -
@@ -1,7 +1,7 @@
 # $FreeBSD: src/lib/libdevstat/Makefile,v 1.12 2003/08/17 08:28:44 gordon Exp $
 
 LIB=   devstat
-SHLIBDIR?= /lib
+LIBDIR?= /lib
 # Bump DEVSTAT_USER_API_VER in devstat.h every time this is incremented.
 SHLIB_MAJOR= 4
 SRCS=  devstat.c
Index: lib/libedit/Makefile
===
RCS file: /home/ncvs/src/lib/libedit/Makefile,v
retrieving revision 1.27
diff -u -r1.27 Makefile
--- lib/libedit/Makefile17 Aug 2003 08:28:44 -  1.27
+++ lib/libedit/Makefile18 Aug 2003 01:42:37 -
@@ -4,7 +4,7 @@
 
 LIB=   edit
 SHLIB_MAJOR=   4
-SHLIBDIR?= /lib
+LIBDIR?= /lib
 
 OSRCS= chared.c common.c el.c emacs.c fcns.c help.c hist.c key.c map.c \
parse.c prompt.c read.c refresh.c search.c sig.c term.c tty.c vi.c
Index: lib/libexpat/Makefile
===
RCS file: /home/ncvs/src/lib/libexpat/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- lib/libexpat/Makefile   17 Aug 2003 08:28:44 -  1.4
+++ lib/libexpat/Makefile   18 Aug 2003 01:42:43 -
@@ -3,7 +3,7 @@
 EXPAT= ${.CURDIR}/../../contrib/expat
 
 LIB=   bsdxml
-SHLIBDIR?= /lib
+LIBDIR?=   /lib
 SHLIB_MAJOR=   1
 SRCS=  xmlparse.c xmlrole.c xmltok.c
 INCS=  bsdxml.h
Index: lib/libgeom/Makefile
===
RCS file: /home/ncvs/src/lib/libgeom/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- 

Re: Lot's of SIGILL, SIGSEGV

2003-08-17 Thread Andre Guibert de Bruet
Stefan,

This is a FAQ. In the future, please search the archives before posting.

At this moment in time, 'p4' isn't a safe CPUTYPE (It produces broken
code). 'p3' or 'i686' are what's recommended for Pentium 4s.

You'll also want to make sure that your CFLAGS don't use optimization
higher than -O, as -O2 and -O3 have been the cause of odd behavior in the
past with GCC3 (This might not apply to GCC 3.3.1 as I haven't had the
time to do extensive regression testing, yet).

Regards,

 Andre Guibert de Bruet | Enterprise Software Consultant 
 Silicon Landmark, LLC. | http://siliconlandmark.com/

On Sun, 17 Aug 2003, Stefan Bethke wrote:

 I've got three machines having trouble doing a installworld, let alone a
 buildworld.

 One is a Dell Inspiron 8100 with a GeForce which used to run just fine on a
 5.1-RC, which I updated yesterday.

 Two are brand-new Shuttle SS51G with a SIS chipset and 2 GHz Celeron, which
 I installed on Friday, initially with 5.1-R, then cvsupped to -current.

 I did make world with CPUTYPE=p4, as I believed this would be innocent.
 However, I can't make world right now without CPUTYPE; I'll get to the
 office to reinstall 5.1-R and make world without CPUTYPE on one of them to
 later today, to see if that helps.

 Any other suggestions as to what could be the trouble? At this point I
 doubt it's hardware, as all three seemed to run just fine on 5.1.


 Thanks,

 Stefan


 Here's the dmesg from one of the Shuttle's:

 Copyright (c) 1992-2003 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.1-CURRENT #0: Sat Aug 16 12:53:10 CEST 2003
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EISENBOOT
 Preloaded elf kernel /boot/kernel/kernel at 0xc0532000.
 Preloaded elf module /boot/kernel/acpi.ko at 0xc05321cc.
 Timecounter i8254 frequency 1193182 Hz
 CPU: Intel(R) Celeron(R) CPU 2.00GHz (2004.56-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0xf27  Stepping = 7
  Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MC
 A,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
 real memory  = 503250944 (479 MB)
 avail memory = 483217408 (460 MB)
 Pentium Pro MTRR support enabled
 npx0: math processor on motherboard
 npx0: INT 16 interface
 acpi0: AWARD  AWRDACPI on motherboard
 pcibios: BIOS version 2.10
 Using $PIR table, 6 entries at 0xc00fde70
 acpi0: power button is handled as a fixed feature programming model.
 Timecounter ACPI-fast frequency 3579545 Hz
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 acpi_cpu0: CPU on acpi0
 acpi_cpu1: CPU on acpi0
 acpi_tz0: thermal zone on acpi0
 acpi_button0: Power Button on acpi0
 acpi_button1: Sleep Button on acpi0
 pcib0: ACPI Host-PCI bridge port
 0x10c0-0x10ff,0x1000-0x10bf,0x480-0x48f,0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 pcib0: slot 2 INTC is routed to irq 11
 pcib0: slot 3 INTA is routed to irq 10
 pcib0: slot 3 INTB is routed to irq 11
 pcib0: slot 3 INTC is routed to irq 9
 pcib0: slot 3 INTD is routed to irq 5
 pcib0: slot 15 INTA is routed to irq 11
 pcib0: slot 16 INTA is routed to irq 12
 agp0: SIS Generic host to PCI bridge mem 0xe800-0xebff at device
 0.0 on pci0
 pcib1: PCI-PCI bridge at device 1.0 on pci0
 pci1: PCI bus on pcib1
 pcib0: slot 1 INTA is routed to irq 10
 pcib1: slot 0 INTA is routed to irq 10
 pci1: display, VGA at device 0.0 (no driver attached)
 isab0: PCI-ISA bridge at device 2.0 on pci0
 isa0: ISA bus on isab0
 atapci0: SiS 96X UDMA133 controller port
 0x4000-0x400f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 2.5
 on pci0
 ata0: at 0x1f0 irq 14 on atapci0
 ata1: at 0x170 irq 15 on atapci0
 pci0: multimedia, audio at device 2.7 (no driver attached)
 ohci0: SiS 5571 USB controller mem 0xec10-0xec100fff irq 10 at device
 3.0 on pci0
 usb0: OHCI version 1.0, legacy support
 usb0: SiS 5571 USB controller on ohci0
 usb0: USB revision 1.0
 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
 uhub0: 2 ports with 2 removable, self powered
 ohci1: SiS 5571 USB controller mem 0xec101000-0xec101fff irq 11 at device
 3.1 on pci0
 usb1: OHCI version 1.0, legacy support
 usb1: SiS 5571 USB controller on ohci1
 usb1: USB revision 1.0
 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
 uhub1: 2 ports with 2 removable, self powered
 ohci2: SiS 5571 USB controller mem 0xec102000-0xec102fff irq 9 at device
 3.2 on pci0
 usb2: OHCI version 1.0, legacy support
 usb2: SiS 5571 USB controller on ohci2
 usb2: USB revision 1.0
 uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
 uhub2: 2 ports with 2 removable, self powered
 pci0: serial bus, USB at device 3.3 (no driver attached)
 rl0: RealTek 8139 10/100BaseTX, rev. 8139D/8100B/8100C port 0xe800-0xe8ff
 mem 0xec104000-0xec1040ff irq 11 at device 15.0 on pci0
 rl0: Ethernet address: 00:30:1b:23:aa:7f
 miibus0: MII bus on rl0
 rlphy0: RealTek 

Re: Lot's of SIGILL, SIGSEGV

2003-08-17 Thread David O'Brien
On Sun, Aug 17, 2003 at 10:54:43PM -0400, Andre Guibert de Bruet wrote:
 Stefan,
 
 This is a FAQ. In the future, please search the archives before posting.
 
 At this moment in time, 'p4' isn't a safe CPUTYPE (It produces broken
 code). 'p3' or 'i686' are what's recommended for Pentium 4s.

Andre, I think you are out of date -- CPUTYPE=p4 is now safe with GCC
3.3.1.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Slow Boot

2003-08-17 Thread Matthew D. Fuller
On Sun, Aug 17, 2003 at 02:55:46PM -0400 I heard the voice of
Bill Moran, and lo! it spake thus:
 
 My best guess is that the chipset responds slowly to probes, thus it
 takes a while to get the list of devices from it.  However, I've never
 looked into it any more than that.

I've always presumed it to be a question of timing out probes to the
drives; it only ever happens on IDE controllers with no devices attached
to 'em.  I habitually just disable the controller channels that are empty
(or, in the case of my SCSI systems, just yank ATA support altogether).


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Slow Boot

2003-08-17 Thread Mike Atamas
On Sun, 17 Aug 2003 22:35:14 -0400 (EDT)
Andre Guibert de Bruet [EMAIL PROTECTED] wrote:

 pciconf -vl

Here is the output that it gave. I included everything because nothing particular 
struck me as relavent. 


[EMAIL PROTECTED]:0:0:  class=0x06 card=0x80ac1043 chip=0x01e010de rev=0xc1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce2 AGP Controller'
class= bridge
subclass = HOST-PCI
[EMAIL PROTECTED]:0:1:  class=0x05 card=0x0c1710de chip=0x01eb10de rev=0xc1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce2 Memory Controller 1'
class= memory
subclass = RAM
[EMAIL PROTECTED]:0:2:  class=0x05 card=0x0c1710de chip=0x01ee10de rev=0xc1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce2 Memory Controller 4'
class= memory
subclass = RAM
[EMAIL PROTECTED]:0:3:  class=0x05 card=0x0c1710de chip=0x01ed10de rev=0xc1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce2 Memory Controller 3'
class= memory
subclass = RAM
[EMAIL PROTECTED]:0:4:  class=0x05 card=0x0c1710de chip=0x01ec10de rev=0xc1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce2 Memory Controller 2'
class= memory
subclass = RAM
[EMAIL PROTECTED]:0:5:  class=0x05 card=0x0c1710de chip=0x01ef10de rev=0xc1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce2 Memory Controller 5'
class= memory
subclass = RAM
[EMAIL PROTECTED]:1:0:  class=0x060100 card=0x80ad1043 chip=0x006010de rev=0xa4 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 ISA Bridge'
class= bridge
subclass = PCI-ISA
[EMAIL PROTECTED]:1:1:  class=0x0c0500 card=0x0c111043 chip=0x006410de rev=0xa2 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP-T? SMBus Controller'
class= serial bus
subclass = SMBus
[EMAIL PROTECTED]:2:0:  class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 OpenHCI USB Controller'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:2:1:  class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 OpenHCI USB Controller'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:2:2:  class=0x0c0320 card=0x0c111043 chip=0x006810de rev=0xa4 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 EHCI USB 2.0 Controller'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:4:0:  class=0x02 card=0x80a71043 chip=0x006610de rev=0xa1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 Networking Adapter'
class= network
subclass = ethernet
[EMAIL PROTECTED]:5:0:  class=0x040100 card=0x0c111043 chip=0x006b10de rev=0xa2 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP-T? Audio Processing Unit (Dolby Digital)'
class= multimedia
subclass = audio
[EMAIL PROTECTED]:6:0:  class=0x040100 card=0x80951043 chip=0x006a10de rev=0xa1 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 Audio Codec Interface'
class= multimedia
subclass = audio
[EMAIL PROTECTED]:8:0:  class=0x060400 card=0x chip=0x006c10de rev=0xa3 
hdr=0x01
vendor   = 'NVIDIA Corporation'
device   = 'nForce PCI to PCI Bridge'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:9:0:  class=0x01018a card=0x0c111043 chip=0x006510de rev=0xa2 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 EIDE Controller'
class= mass storage
subclass = ATA
[EMAIL PROTECTED]:12:0: class=0x060400 card=0x chip=0x006d10de rev=0xa3 
hdr=0x01
vendor   = 'NVIDIA Corporation'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:13:0: class=0x0c0010 card=0x809a1043 chip=0x006e10de rev=0xa3 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'nForce MCP2 OHCI Compliant IEEE 1394 Controller'
class= serial bus
subclass = FireWire
[EMAIL PROTECTED]:30:0: class=0x060400 card=0x chip=0x01e810de rev=0xc1 
hdr=0x01
vendor   = 'NVIDIA Corporation'
device   = 'nForce2 AGP Host to PCI Bridge'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:11:0: class=0x010400 card=0x61121095 chip=0x31121095 rev=0x02 
hdr=0x00
vendor   = 'Silicon Image Inc (Was: CMD Technology Inc)'
device   = 'SiI 3112 SATARaid Controller'
class= mass storage
subclass = RAID
[EMAIL PROTECTED]:1:0:  class=0x02 card=0x80ab1043 chip=0x920110b7 rev=0x40 
hdr=0x00
vendor   = '3COM Corp, Networking Division'
class= network
subclass = ethernet
[EMAIL PROTECTED]:0:0:  class=0x03 card=0x40081043 chip=0x010010de rev=0x10 
hdr=0x00
vendor   = 'NVIDIA Corporation'
device   = 'GeForce 256 [NV10]'
class= display
subclass = VGA

bsd.prog.mk duplicate script for target loader

2003-08-17 Thread Andre Guibert de Bruet

I'm seeing the following on today's current (Just cvsup'ed):

...
=== sys/boot/i386/btx/lib
=== sys/boot/i386/boot2
=== sys/boot/i386/cdboot
=== sys/boot/i386/kgzldr
=== sys/boot/i386/libi386
=== sys/boot/i386/loader
/usr/src/share/mk/bsd.prog.mk, line 38: warning: duplicate script for target 
loader ignored
=== sys/boot/i386/pxeldr
...

This occurs with:
# $FreeBSD: src/share/mk/bsd.prog.mk,v 1.131 2003/06/29 18:16:26 gordon Exp $

Regards,

 Andre Guibert de Bruet | Enterprise Software Consultant 
 Silicon Landmark, LLC. | http://siliconlandmark.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on alpha/alpha

2003-08-17 Thread Tinderbox
TB --- 2003-08-18 04:00:11 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-08-18 04:00:11 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-18 04:02:59 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 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/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec/sftp-server/../../../crypto/openssh
 -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin/ld:
 warning: libz.so.2, needed by 
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so,
 not found (try using -rpath or -rpath-link)
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `deflate'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `inflate'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateInit_'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateInit_'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateEnd'
/home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateEnd'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec/sftp-server.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure/libexec.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/secure.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
TB --- 2003-08-18 04:59:15 - /usr/bin/make returned exit code  1 
TB --- 2003-08-18 04:59:15 - ERROR: failed to build world
TB --- 2003-08-18 04:59:15 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


[current tinderbox] failure on amd64/amd64

2003-08-17 Thread Tinderbox
TB --- 2003-08-18 04:59:16 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2003-08-18 04:59:16 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-18 05:02:06 - building world
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src
TB --- /usr/bin/make -B buildworld
 Rebuilding the temporary build tree
 stage 1: legacy release compatibility shims
 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/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include
 stage 4: building libraries
 stage 4: make dependencies
 stage 4: building everything..
[...]
cc -O -pipe  
-I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure/libexec/sftp-server/../../../crypto/openssh
 -DNO_IDEA  -o sftp-server sftp-common.o sftp-server.o -lssh -lcrypto
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin/ld:
 warning: libz.so.2, needed by 
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so,
 not found (try using -rpath or -rpath-link)
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflate'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflate'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateInit_'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateInit_'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `inflateEnd'
/home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libssh.so:
 undefined reference to `deflateEnd'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure/libexec/sftp-server.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure/libexec.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/secure.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
TB --- 2003-08-18 05:54:38 - /usr/bin/make returned exit code  1 
TB --- 2003-08-18 05:54:38 - ERROR: failed to build world
TB --- 2003-08-18 05:54:38 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]