[current tinderbox] failure on amd64/amd64
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]"
[current tinderbox] failure on alpha/alpha
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]"
bsd.prog.mk duplicate script for target "loader"
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]"
Re: Slow Boot
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 __
Re: Slow Boot
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: Lot's of SIGILL, SIGSEGV
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: Lot's of SIGILL, SIGSEGV
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=0xbfebfbff 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: on motherboard > npx0: INT 16 interface > acpi0: 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: on acpi0 > acpi_cpu1: on acpi0 > acpi_tz0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port > 0x10c0-0x10ff,0x1000-0x10bf,0x480-0x48f,0xcf8-0xcff on acpi0 > pci0: 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: mem 0xe800-0xebff at device > 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pcib0: slot 1 INTA is routed to irq 10 > pcib1: slot 0 INTA is routed to irq 10 > pci1: at device 0.0 (no driver attached) > isab0: at device 2.0 on pci0 > isa0: on isab0 > atapci0: 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: at device 2.7 (no driver attached) > ohci0: mem 0xec10-0xec100fff irq 10 at device > 3.0 on pci0 > usb0: OHCI version 1.0, legacy support > usb0: 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: mem 0xec101000-0xec101fff irq 11 at device > 3.1 on pci0 > usb1: OHCI version 1.0, legacy support > usb1: 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: mem 0xec102000-0xec102fff irq 9 at device > 3.2 on pci0 > usb2: OHCI version 1.0, legacy support > usb2: 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: at device 3.3 (no driver attached) > rl0: port 0xe800-0xe8ff > mem 0xec104000-0xec1040ff irq 11 at device 15.0 on pci0 > rl0: Ethernet address: 00:30:1b:23:aa:7f > miibus0: on rl0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fwohci0: 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:
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
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
--- lib/libgeo
Re: RFC: Allow non-root users to use make distribution and makeinstallworld?
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: Slow Boot
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: bluetooth working on 5.1-release
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> > > > > > 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: HEADS UP: dynamic root support now in the tree
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]"
[current tinderbox] failure on sparc64/sparc64
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: RFC: Allow non-root users to use make distribution and makeinstallworld?
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 ia64/ia64
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]"
bluetooth working on 5.1-release
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> 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]"
Re: cdcontrol no longer needs 'c' partition?
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]"
cdcontrol no longer needs 'c' partition?
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: error: ln: /usr/libexec/ld-elf.so.1: Operation not permitted
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]"
Re: [current tinderbox] failure on alpha/alpha
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: HEADS UP: dynamic root support now in the tree
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: 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 pgp0.pgp Description: PGP signature
Re: HEADS UP: dynamic root support now in the tree
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
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: if_xl borked in current!!
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: error: ln: /usr/libexec/ld-elf.so.1: Operation not permitted
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 ln: /usr/libexec/ld-elf.so.1: Operation not permitted 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: Slow Boot
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: HEADS UP: dynamic root support now in the tree
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: bluetooth on 5.1-release or -current ?
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]"
error: ln: /usr/libexec/ld-elf.so.1: Operation not permitted
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]"
[current tinderbox] failure on amd64/amd64
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]"
[current tinderbox] failure on alpha/alpha
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]"
bluetooth on 5.1-release or -current ?
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]"
Re: HEADS UP: dynamic root support now in the tree
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]"
Re: if_xl borked in current!!
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]"
Lot's of SIGILL, SIGSEGV
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=0xbfebfbff 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: on motherboard npx0: INT 16 interface acpi0: 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: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x10c0-0x10ff,0x1000-0x10bf,0x480-0x48f,0xcf8-0xcff on acpi0 pci0: 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: mem 0xe800-0xebff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib0: slot 1 INTA is routed to irq 10 pcib1: slot 0 INTA is routed to irq 10 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: 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: at device 2.7 (no driver attached) ohci0: mem 0xec10-0xec100fff irq 10 at device 3.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: 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: mem 0xec101000-0xec101fff irq 11 at device 3.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: 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: mem 0xec102000-0xec102fff irq 9 at device 3.2 on pci0 usb2: OHCI version 1.0, legacy support usb2: 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: at device 3.3 (no driver attached) rl0: port 0xe800-0xe8ff mem 0xec104000-0xec1040ff irq 11 at device 15.0 on pci0 rl0: Ethernet address: 00:30:1b:23:aa:7f miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fwohci0: 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: on fwohci0 if_fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:27:f7:87 sbp0: 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: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xcc000-0xce7ff,0xc-0xcbfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 2004556956 Hz Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default IPsec: Initializ
Slow Boot
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]"
Re: if_xl borked in current!!
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]"
[current tinderbox] failure on sparc64/sparc64
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: HEADS UP: dynamic root support now in the tree
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]"
Re: LOR with filedesc structure and Giant
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]"
if_sis: performance tweaking
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
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]"
SV: when should 5.x be stable enough for web servers
>-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]"
HEADS UP: dynamic root support now in the tree
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
Re: usbd does not use detach
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]"
