Re: mergemaster b0rked?
for i in answer isdntel.sh record tell tell-record unknown_incoming ; do install -o -g -m 700 $i /var/tmp/temproot/etc/isdn ; done ; for i in holidays.Disdnd.rates.Aisdnd.rates.D isdnd.rates.F isdnd.rates.L isdnd.rates.UK.BT isdnd.rc.sample isdntel.alias.sample ; do install -o -g -m 600 $i /var/tmp/temproot/etc/isdn ; done install: -g: Invalid argument *** Error code 67 Stop in /usr/src/etc/isdn. *** Error code 1 Stop in /usr/src/etc. *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the temproot environment # I'm seeing this too. I've cvsup'ed and rebuilt world (making sure that mergemaster was rebuilt) and it still occurs. Make sure to get a more clever src/etc/isdn/Makefile. I think 1.11 should do. PS. It broke my nightly release build too. I'm now trying again with the latest Makefile. John -- John Hay -- [EMAIL PROTECTED] / [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 amd64/amd64
TB --- 2003-08-19 05:18:54 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-08-19 05:18:54 - 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-19 05:21:24 - 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-19 06:13:55 - /usr/bin/make returned exit code 1 TB --- 2003-08-19 06:13:55 - ERROR: failed to build world TB --- 2003-08-19 06:13:55 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Broken kernel compile on 5.1-RELEASE / 5-CURRENT (SMP, PAE scsi)
Hi All, When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an extremly puzzling error, I get a bunch of errors when compiling a kernel that has the following options in it... options WITNESS options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options PAE options SMP options APIC_IO Without PAE SMP or APIC_IO the kernel will compile fine. With these options I get the following error when compiling the sym scsi driver. cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/sym/sym_hipd.c cc1: warnings being treated as errors ../../../dev/sym/sym_hipd.c: In function `sym_setup_data_and_start': ../../../dev/sym/sym_hipd.c:8146: warning: cast from pointer to integer of different size *** Error code 1 This is rather unfortunate as the only disks I have run off this controller. I've found that it does compile with the ahc driver but even then some usb stuff needs removing. Does anyone have any insight into this and what I can do to get it fixed. Cheers, -- Mark Sergeant [EMAIL PROTECTED] SNSOnline Technical Services ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Printer?
On 18/08-03 20.31, Bernd Walter wrote: On Mon, Aug 18, 2003 at 04:53:29PM +0200, Daniel Nielsen wrote: On 18/08-03 14.59, Bernd Walter wrote: On Mon, Aug 18, 2003 at 01:02:51PM +0200, Daniel Nielsen wrote: Hi. I installed 5.1-RELEASE on a compuiter with a nforce2 mobo, worked nice... Then I bought a Brother-5050 Laser printer (Postscript). Installed and configured cups. cups worked fine. Then I realized, the printer only works if it is turned on before my freebsd boots. When I power it up, it is detected by the freebsd usb-system: zits root # dmesg | grep ulpt ulpt0: Brother HL-5050, rev 2.00/1.00, addr 3, iclass 7/1 ulpt0: using bi-directional mode zits root # And when I turn it off: zits root # dmesg | grep ulpt snip ulpt0: at uhub0 port 2 (addr 3) disconnected ulpt0: detached zits root # but when I send a job to the printer, the CUPS usb backend just hangs, locking /dev/ulpt0 I tried cat /root/some-file /dev/ulpt0 , and it also just hangs. /dev/ulpt0 shouldn't exist after ulpt0 was detached. It doesn't... I wasn't being clear, I only try the cat thing after the printer is attached and turned on. What does ps -axl say. I'll have to check when I get home. What kind of USB controller do you have? Its the onboard nvidia nforce2 controller, USB 2 is enabled in BIOS. Switching it off doesn't help Are other full-speed USB devices working on this usb controller (mices are often low speed)? No. I only have 2 usb devices, mouse and printer. /Daniel -- There are no great men, only great challenges that ordinary men are forced by circumstances to meet. -- Admiral William Halsey ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: an driver / Cisco Aironet 340 stopped working
Doug Ambrisko writes: I assume you are using a pccard version. It only a problem newer firmware. It works ... just noisy! You can try this patch to -current that should make it quiet. There is a bug with -current and setting the TX speed that I need to work on. Looks like things changed in the wlan module. I may commit this but there is an issue with the mpi-350 support. They changed the programing paradigm and after 14 packets the TX engine stalls. I'm still working on tweaks to that. I had hoped to get that working and commit all of this. Let me know how this works. It should just work. I was ready to say that it's not working but then ipv6 came up automatically. I didn't look this before but now it looks that dhclient don't get address but if manually set v4 address it works. I've to check how it works with older kernel because until now I only checked that I didn't get address from dhcp. Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broken kernel compile on 5.1-RELEASE / 5-CURRENT (SMP, PAE scsi)
On 19 Aug, Mark Sergeant wrote: Hi All, When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an extremly puzzling error, I get a bunch of errors when compiling a kernel that has the following options in it... options WITNESS options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options PAE options SMP options APIC_IO Without PAE SMP or APIC_IO the kernel will compile fine. With these options I get the following error when compiling the sym scsi driver. Take a look at /usr/src/sys/i386/conf/PAE. It says: # What follows is a list of drivers that are normally in GENERIC, but either # don't work or are untested with PAE. Be very careful before enabling any # of these drivers. Drivers which use DMA and don't handle 64 bit physical # address properly may cause data corruption when used in a machine with more # than 4 gigabytes of memory. and under this comment it lists the sym and usb drivers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broken kernel compile on 5.1-RELEASE / 5-CURRENT (SMP, PAE scsi)
Ohh bugger. I suppose I'll have to live without PAE then. Thanks anyway. Cheers, Mark On Tue, 2003-08-19 at 17:19, Don Lewis wrote: On 19 Aug, Mark Sergeant wrote: Hi All, When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an extremly puzzling error, I get a bunch of errors when compiling a kernel that has the following options in it... options WITNESS options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options PAE options SMP options APIC_IO Without PAE SMP or APIC_IO the kernel will compile fine. With these options I get the following error when compiling the sym scsi driver. Take a look at /usr/src/sys/i386/conf/PAE. It says: # What follows is a list of drivers that are normally in GENERIC, but either # don't work or are untested with PAE. Be very careful before enabling any # of these drivers. Drivers which use DMA and don't handle 64 bit physical # address properly may cause data corruption when used in a machine with more # than 4 gigabytes of memory. and under this comment it lists the sym and usb drivers. -- Mark Sergeant [EMAIL PROTECTED] SNSOnline Technical Services ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster b0rked?
On Tue, 19 Aug 2003, John Hay wrote: Stop in /usr/src/etc. *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the temproot environment # I'm seeing this too. I've cvsup'ed and rebuilt world (making sure that mergemaster was rebuilt) and it still occurs. Make sure to get a more clever src/etc/isdn/Makefile. I think 1.11 should do. PS. It broke my nightly release build too. I'm now trying again with the latest Makefile. O'Brien's version 1.11 of src/etc/isdn/Makefile fixes the problem. Thanks! 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: Broken kernel compile on 5.1-RELEASE / 5-CURRENT (SMP, PAE scsi)
Mark Sergeant wrote: Hi All, When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an extremly puzzling error, I get a bunch of errors when compiling a kernel that has the following options in it... options WITNESS options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options PAE options SMP options APIC_IO Without PAE SMP or APIC_IO the kernel will compile fine. With these options I get the following error when compiling the sym scsi driver. cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/sym/sym_hipd.c cc1: warnings being treated as errors ../../../dev/sym/sym_hipd.c: In function `sym_setup_data_and_start': ../../../dev/sym/sym_hipd.c:8146: warning: cast from pointer to integer of different size *** Error code 1 This is rather unfortunate as the only disks I have run off this controller. I've found that it does compile with the ahc driver but even then some usb stuff needs removing. Does anyone have any insight into this and what I can do to get it fixed. Cheers, The key kere is likely PAE, not APIC_IO, as PAE changes the size of some data types. The USB problem is known. The sym problem looks to be harmless assuming that the warning you got is the only one that is emitted. However, it appears that it was never certified as being ready for PAE. If you're adventurous, you can try compiling and loading it as a module (warnings when compiling modules are not fatal like they are in when compiling the kernel). If there are more errors/warning that what you list, I'd be interested in seeing them. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broken kernel compile on 5.1-RELEASE / 5-CURRENT (SMP, PAE scsi)
On Tue, 2003-08-19 at 17:47, Scott Long wrote: Mark Sergeant wrote: Hi All, When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an extremly puzzling error, I get a bunch of errors when compiling a kernel that has the following options in it... options WITNESS options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options PAE options SMP options APIC_IO Without PAE SMP or APIC_IO the kernel will compile fine. With these options I get the following error when compiling the sym scsi driver. cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/sym/sym_hipd.c cc1: warnings being treated as errors ../../../dev/sym/sym_hipd.c: In function `sym_setup_data_and_start': ../../../dev/sym/sym_hipd.c:8146: warning: cast from pointer to integer of different size *** Error code 1 This is rather unfortunate as the only disks I have run off this controller. I've found that it does compile with the ahc driver but even then some usb stuff needs removing. Does anyone have any insight into this and what I can do to get it fixed. Cheers, The key kere is likely PAE, not APIC_IO, as PAE changes the size of some data types. The USB problem is known. The sym problem looks to be harmless assuming that the warning you got is the only one that is emitted. However, it appears that it was never certified as being ready for PAE. If you're adventurous, you can try compiling and loading it as a module (warnings when compiling modules are not fatal like they are in when compiling the kernel). If there are more errors/warning that what you list, I'd be interested in seeing them. Scott There are no other errors apart from those listed so I may try compiling as a module that gets loaded on boot. Just one problem, I succesfully build an SMP kernel without PAE and then rebooted and the server is no longer responding, it seems it crashed just after coming up as I was able to ping it 5 or 6 times and then it went away again. If I've got a crash dump I'll post it. Cheers, -- Mark Sergeant [EMAIL PROTECTED] SNSOnline Technical Services ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE considered harmful? (was: Lot's of SIGILL, SIGSEGV)
On Montag, 18. August 2003 23:15 Uhr +0200 Pawel Jakub Dawidek [EMAIL PROTECTED] wrote: On Sun, Aug 17, 2003 at 08:00:54PM -0700, David O'Brien wrote: + 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. I think he is right, because when upgrading host where was gcc3.2 to current -CURRENT (with gcc3.3) 'make world' builds make(1) in first place and it is builded by gcc3.2 with CPUTYPE=p4, so it will be broken. So gcc have to be upgraded in first place (with CPUTYPE=p3). Hhm, sounds reasonable. However, I had the exact same problem updating from a 5.1-RC to a recent current on a P III 900, and there, I had CPUTYPE=p3 in make.conf. Removing CPUTYPE eventually gave me back working systems (I did restore 5.1-R bits prior to make world). Unfortunatly, I don't have the resources to investigate this further, but for the time being, I will not use CPUTYPE until others can confirm it's safe :-) Thanks all, Stefan -- Stefan Bethke, Phone +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
USB2 and umass devices
I have one of these PCI cards - ehci0: NEC uPD 720100 USB 2.0 controller mem 0xe9029000-0xe90290ff irq 5 at device 8.2 on pci0 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 0.95 usb4: companion controllers, 3 ports each: usb2 usb3 usb4: NEC uPD 720100 USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 5 ports with 5 removable, self powered The card is pretty generic and the NEC chip mentioned is the only major thing on the card. I am trying to use this device - umass0: Acer Labs USB 2.0 Storage Device, rev 2.00/1.03, addr 3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: USB 2.0 Storage Device 0100 Fixed Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) This is when it is connected to the internal VIA controller - uhci0: VIA 83C572 USB controller port 0xc400-0xc41f irq 9 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Unfortunately when I try and plug it into the USB 2.0 controller, I get this - uhub4: device problem, disabling port 1 uhub4: device problem, disabling port 2 uhub4: device problem, disabling port 3 uhub4: device problem, disabling port 4 (I tried all 4 ports) It is running -current from the 11th. The drive works when it's detected but it is _very_ slow (like 800kb/sec or so). If I use the firewire port it goes faster (eg 20mb/sec). A USB mouse works fine, so does a compact flash card reader (I can't tell if it is doing high speed though as CF is pretty slow) Anyone got any hints/tips/patches? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mksnap_ffs, snapshot issues, again
The behaviour of filesystem activity stalling during snapshot creation is intentional, but 30 minutes to snapshot an empty FS is not. Is there disk activity during this time? It's not clear from your mail whether bg fsck is in operation during this time. If so, that's probably the cause, since bg fsck itself uses a snapshot to check the FS consistency. Background fsck was NOT running. I formatted fs and then tried to make snapshot. Machine just hangs. Brane ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow Boot
Bill Moran wrote: 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. In init_main.c, verify that the current value for the thing being initialized is greater than SI_SUB_CONSOLE. If it is, then print out the name of the thing being initialized before you make the call. Whatever prints before a long delay is your culprit. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE considered harmful? (was: Lot's of SIGILL, SIGSEGV)
On Tue, Aug 19, 2003 at 10:07:04AM +0200, Stefan Bethke wrote: Removing CPUTYPE eventually gave me back working systems (I did restore 5.1-R bits prior to make world). Unfortunatly, I don't have the resources to investigate this further, but for the time being, I will not use CPUTYPE until others can confirm it's safe :-) Thanks all, Stefan CPUTYPE in gcc32 is like a landmine. But ever since gcc33 import, CPUTYPE=p4 has yet to fail me. I use it for both world and ports. Regards, Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DEVFS related message
In message [EMAIL PROTECTED], Munehiro Matsuda writ es: Hi All, I just got following DEVFS related message with this mornings current. DEVFS Overflow table with 32768 entries allocated when 925 in use Anybody seen this? This is mostly harmless. When DEVFS initially was integrated the locking situation was rather tricky and malloc failures therefor not easy to handle. Therefore DEVFS uses a compile time array of pointers to its inodes. If this table seems to be running out, (less than 100 free entries) an overflow table will be attempted allocated which can contain more entries. You can adjust both the regular and the overflow table sizes with compile time constants NDEVFSINO and NDEVFSOVERFLOW. When more of the kernel has been de-Giantized, this code can be revisited and these constants can probably be eliminated. -- 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: ACPI on Tyan Motherboard
Stephen Montgomery-Smith schrieb: Actually the power-off button doesn't work at all under FreeBSD-current. (It is a soft power-off button that dmesg shows is detected by the OS.) Have you tried to hold the power-button a little bit longer? My power-button turn the system off when I pres it for ~4secs (but I haven't a Tyan board). Bye, Alexander. ___ [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 Mon, Aug 18, 2003 at 09:05:13AM +0900, Shin-ichi Yoshimoto wrote:
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 ?
Yes, I have the same problem.
Solution:
# mkdir /libexec cp obj/usr/src/libexec/rtld-elf/ld-elf.so.1 /libexec
then make installworld
--
Rgdz,/\ ASCII RIBBON CAMPAIGN
Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL
http://ozz.pp.ru/ X AND NEWS
/ \
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broken kernel compile on 5.1-RELEASE / 5-CURRENT (SMP, PAE scsi)
On Tue, 19 Aug 2003, Mark Sergeant wrote: There are no other errors apart from those listed so I may try compiling as a module that gets loaded on boot. Just one problem, I succesfully build an SMP kernel without PAE and then rebooted and the server is no longer responding, it seems it crashed just after coming up as I was able to ping it 5 or 6 times and then it went away again. If I've got a crash dump I'll post it. Can't speak to the specifics of this, but you want to be very careful not to use kernel modules with PAE: modules are currently without the context of the kernel configuration file, and PAE introduces possible binary incompatibility with modules that dig into VM (which many drivers do). The only supported configuration is to not use modules, but link the driver directly into the kernel when running PAE. This is why the PAE kernel has no_modules defined in the sample PAE configuration file. Various conversations have happened regarding how to address this problem, and I'm not sure we've come up with the right answer yet. There seem to be two conflicting directions: build modules in the context of a kernel module (and get conditionally compiled type/structure/code/... pieces), and try to make the module build entirely independent of a kernel configuration. As someone who uses conditionally compiled components in modules, I tend to fall into the first camp, and no doubt we'll figure out the right answer in due course. The above crash sounds unfortunate too, but quite possibly a separate failure mode :-). 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: an driver / Cisco Aironet 340 stopped working
Tomi Vainio - Sun Finland writes: | Doug Ambrisko writes: | | I assume you are using a pccard version. | | It only a problem newer firmware. It works ... just noisy! | | You can try this patch to -current that should make it quiet. | There is a bug with -current and setting the TX speed that I need | to work on. Looks like things changed in the wlan module. | I may commit this but there is an issue with the mpi-350 support. | They changed the programing paradigm and after 14 packets the | TX engine stalls. I'm still working on tweaks to that. | I had hoped to get that working and commit all of this. | | Let me know how this works. It should just work. | | I was ready to say that it's not working but then ipv6 came up | automatically. I didn't look this before but now it looks that | dhclient don't get address but if manually set v4 address it works. | I've to check how it works with older kernel because until now I only | checked that I didn't get address from dhcp. There have been some changes to dhclient (link detection) that might have some interaction side effects. Not blaming dhclient but that is something to be aware of. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mksnap_ffs, snapshot issues, again
On Tue, 19 Aug 2003, Branko F. Gracnar wrote: The behaviour of filesystem activity stalling during snapshot creation is intentional, but 30 minutes to snapshot an empty FS is not. Is there disk activity during this time? It's not clear from your mail whether bg fsck is in operation during this time. If so, that's probably the cause, since bg fsck itself uses a snapshot to check the FS consistency. Background fsck was NOT running. I formatted fs and then tried to make snapshot. When reporting bgfsck/snapshot/... problems, you may want to CC Kirk McKusick [EMAIL PROTECTED] -- I don't believe he closely tracks current@, and he's the best person to track down and fix problems in this area. I forwarded your earlier message to him, but haven't heard back as yet. Just FYI. 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: Broken kernel on 5.1-RELEASE was :[compile on 5.1-RELEASE/5-CURRENT (SMP, PAE scsi)]
Ah shoot, I should know better than to respond after having a few beers. As Robert pointed out, modules are absolutely not supported in PAE kernels. That not only includes sym and usb, but also acpi (which is automatically loaded at boot). If you still want to experiment with the sym driver, just delete the line that the compiler complains about (it's in a code path that will likely never be used). Scott Mark Sergeant wrote: Ok I've now got problems with the compiled kernel, I get panics on my multiple cpu machine on boot just after boot before the prompt is reached. It's a lock on cpu #2 ( I believe cpu 3 ). Unfortunately I don't have the exact message nor do I have a kernel dump as this machine is meant to be a production one and as such a boot of kernel.old was done. Does anyone have a 4 or greater cpu machine running 5.1-RELEASE succesfully ? I've got a 5.1-RELEASE machine running with the same kernel config 2 cpu's without any problem so I can only think that it's something to do with more than 2 cpu's. Cheers, Mark On Tue, 2003-08-19 at 17:55, Mark Sergeant wrote: On Tue, 2003-08-19 at 17:47, Scott Long wrote: Mark Sergeant wrote: Hi All, When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an extremly puzzling error, I get a bunch of errors when compiling a kernel that has the following options in it... options WITNESS options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options PAE options SMP options APIC_IO Without PAE SMP or APIC_IO the kernel will compile fine. With these options I get the following error when compiling the sym scsi driver. cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/sym/sym_hipd.c cc1: warnings being treated as errors ../../../dev/sym/sym_hipd.c: In function `sym_setup_data_and_start': ../../../dev/sym/sym_hipd.c:8146: warning: cast from pointer to integer of different size *** Error code 1 This is rather unfortunate as the only disks I have run off this controller. I've found that it does compile with the ahc driver but even then some usb stuff needs removing. Does anyone have any insight into this and what I can do to get it fixed. Cheers, The key kere is likely PAE, not APIC_IO, as PAE changes the size of some data types. The USB problem is known. The sym problem looks to be harmless assuming that the warning you got is the only one that is emitted. However, it appears that it was never certified as being ready for PAE. If you're adventurous, you can try compiling and loading it as a module (warnings when compiling modules are not fatal like they are in when compiling the kernel). If there are more errors/warning that what you list, I'd be interested in seeing them. Scott There are no other errors apart from those listed so I may try compiling as a module that gets loaded on boot. Just one problem, I succesfully build an SMP kernel without PAE and then rebooted and the server is no longer responding, it seems it crashed just after coming up as I was able to ping it 5 or 6 times and then it went away again. If I've got a crash dump I'll post it. Cheers, ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.prog.mk duplicate script for target loader
It has been so for ever, and it has been producing the warning (which it wasn't before because of a make(1) bug) for a while now. Known issue, make experts are idly scratching their heads while they ponder a solution. :-) Andre Guibert de Bruet wrote: 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] -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I may be getting older, but I refuse to grow up! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.prog.mk duplicate script for target loader
On 19-Aug-2003 Daniel C. Sobral wrote:
It has been so for ever, and it has been producing the warning (which it
wasn't before because of a make(1) bug) for a while now. Known issue,
make experts are idly scratching their heads while they ponder a
solution. :-)
Gross hack:
Index: bsd.prog.mk
===
RCS file: /usr/cvs/src/share/mk/bsd.prog.mk,v
retrieving revision 1.131
diff -u -r1.131 bsd.prog.mk
--- bsd.prog.mk 29 Jun 2003 18:16:26 - 1.131
+++ bsd.prog.mk 19 Aug 2003 14:40:28 -
@@ -31,11 +31,13 @@
OBJS+= ${SRCS:N*.h:R:S/$/.o/g}
+.if !target(${PROG})
${PROG}: ${OBJS}
.if defined(PROG_CXX)
${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
.else
${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
+.endif
.endif
.else !defined(SRCS)
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
fwcontrol -r missing a close() call
# truss fwcontrol -r mmap(0x0,3440,0x3,0x1000,-1,0x0) = 671535104 (0x2806d000) munmap(0x2806d000,0xd70) = 0 (0x0) __sysctl(0xbfbffa28,0x2,0x2806adac,0xbfbffa24,0x0,0x0) = 0 (0x0) mmap(0x0,32768,0x3,0x1002,-1,0x0)= 671535104 (0x2806d000) issetugid() = 0 (0x0) open(/var/run/ld-elf.so.hints,0x0,00) = 3 (0x3) read(0x3,0xbfbffac0,0x80)= 128 (0x80) lseek(3,0x80,0) = 128 (0x80) read(0x3,0x28071000,0x7a)= 122 (0x7a) close(3) = 0 (0x0) access(/usr/lib/libc.so.5,0) = 0 (0x0) open(/usr/lib/libc.so.5,0x0,027757775430) = 3 (0x3) fstat(3,0xbfbffb00) = 0 (0x0) read(0x3,0x28069d00,0x1000) = 4096 (0x1000) mmap(0x0,880640,0x5,0x20002,3,0x0) = 671567872 (0x28075000) mprotect(0x28134000,0x1000,0x7) = 0 (0x0) mprotect(0x28134000,0x1000,0x5) = 0 (0x0) mmap(0x28135000,20480,0x3,0x12,3,0xbf000)= 672354304 (0x28135000) mmap(0x2813a000,73728,0x3,0x1012,-1,0x0) = 672374784 (0x2813a000) close(3) = 0 (0x0) mmap(0x0,360,0x3,0x1000,-1,0x0) = 672448512 (0x2814c000) munmap(0x2814c000,0x168) = 0 (0x0) mprotect(0x28075000,0xc,0x7) = 0 (0x0) mmap(0x0,21240,0x3,0x1000,-1,0x0)= 672448512 (0x2814c000) munmap(0x2814c000,0x52f8)= 0 (0x0) mprotect(0x28075000,0xc,0x5) = 0 (0x0) sigaction(SIGILL,0xbfbffb40,0xbfbffb20) = 0 (0x0) sigprocmask(0x1,0x0,0x28069c5c) = 0 (0x0) sigaction(SIGILL,0xbfbffb20,0x0) = 0 (0x0) sigprocmask(0x1,0x28069c00,0xbfbffb50) = 0 (0x0) sigprocmask(0x3,0x28069c10,0x0) = 0 (0x0) open(/dev/fw0.0,0x2,01001132500) = 3 (0x3) ioctl(3,FW_IBUSRST,0xbfbff400) = 0 (0x0) exit(0x0) process exit, rval = 0 We're not closing fd #3 before exiting the process. This is also the case with 4.8-STABLE. Digging into the code it appears that it would be trivial to add two lines to catch all instances of this (copy and pasted): --- fwcontrol.c.origMon Aug 4 23:26:14 2003 +++ fwcontrol.c Tue Aug 19 11:15:13 2003 @@ -527,5 +527,9 @@ default: usage(); } + + if(fd != -1) + close(fd); + return 0; } Semantics? Nit-picking? Both? :) 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: CPUTYPE considered harmful? (was: Lot's of SIGILL, SIGSEGV)
On Tue, 19 Aug 2003, Stefan Bethke wrote: On Montag, 18. August 2003 23:15 Uhr +0200 Pawel Jakub Dawidek [EMAIL PROTECTED] wrote: On Sun, Aug 17, 2003 at 08:00:54PM -0700, David O'Brien wrote: + 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. I think he is right, because when upgrading host where was gcc3.2 to current -CURRENT (with gcc3.3) 'make world' builds make(1) in first place and it is builded by gcc3.2 with CPUTYPE=p4, so it will be broken. So gcc have to be upgraded in first place (with CPUTYPE=p3). Hhm, sounds reasonable. However, I had the exact same problem updating from a 5.1-RC to a recent current on a P III 900, and there, I had CPUTYPE=p3 in make.conf. Removing CPUTYPE eventually gave me back working systems (I did restore 5.1-R bits prior to make world). Unfortunatly, I don't have the resources to investigate this further, but for the time being, I will not use CPUTYPE until others can confirm it's safe :-) I've been running my laptop with a world that was built with CPUTYPE=p3 (GCC 3.3.1) for close to a month. I haven't noticed anything odd yet. 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: an driver / Cisco Aironet 340 stopped working
Hi, | I was ready to say that it's not working but then ipv6 came up | automatically. I didn't look this before but now it looks that | dhclient don't get address but if manually set v4 address it works. | I've to check how it works with older kernel because until now I only | checked that I didn't get address from dhcp. There have been some changes to dhclient (link detection) that might have some interaction side effects. Not blaming dhclient but that is something to be aware of. How old is your CURRENT installation ? Can you run dhclient in verbose mode and in foreground (-d -v) and maybe compile if with -DDEBUG ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd.prog.mk duplicate script for target loader
John Baldwin wrote: On 19-Aug-2003 Daniel C. Sobral wrote: It has been so for ever, and it has been producing the warning (which it wasn't before because of a make(1) bug) for a while now. Known issue, make experts are idly scratching their heads while they ponder a solution. :-) Gross hack: [...] Known gross hack too. It's just a warning. No need to do gross hacks. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] If you can lead it to water and force it to drink, it isn't a horse. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Tue, Aug 19, 2003 at 01:26:17PM +0200, Alexander Leidinger wrote: Have you tried to hold the power-button a little bit longer? My power-button turn the system off when I pres it for ~4secs (but I haven't a Tyan board). Sorry but telling experiences with non-Tyan boards don't help one bit. (too bad I don't have Bill Paul's finesse in getting this point across) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
Alexander Leidinger wrote: Stephen Montgomery-Smith schrieb: Actually the power-off button doesn't work at all under FreeBSD-current. (It is a soft power-off button that dmesg shows is detected by the OS.) Have you tried to hold the power-button a little bit longer? My power-button turn the system off when I pres it for ~4secs (but I haven't a Tyan board). I tried pressing the power button for a longer time. It does actually do something. After about 4 seconds, it has the same effect as shutdown -p now or halt -p, that is, the video card stops working, the fans keep going, and the disk access light comes fully on. I am guessing that this 4 second delay is part of how FreeBSD wants it. If that is the case, it shows that the power button is working as it should - it is the power-down process that is not working right. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fwcontrol -r missing a close() call
In the last episode (Aug 19), Andre Guibert de Bruet said: open(/dev/fw0.0,0x2,01001132500) = 3 (0x3) ioctl(3,FW_IBUSRST,0xbfbff400) = 0 (0x0) exit(0x0) process exit, rval = 0 We're not closing fd #3 before exiting the process. This is also the case with 4.8-STABLE. Semantics? Nit-picking? Both? :) Why bother closing a fd when exit() will do it for you? You don't close stdout when you're done with it :) -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On 19-Aug-2003 Stephen Montgomery-Smith wrote: Alexander Leidinger wrote: Stephen Montgomery-Smith schrieb: Actually the power-off button doesn't work at all under FreeBSD-current. (It is a soft power-off button that dmesg shows is detected by the OS.) Have you tried to hold the power-button a little bit longer? My power-button turn the system off when I pres it for ~4secs (but I haven't a Tyan board). I tried pressing the power button for a longer time. It does actually do something. After about 4 seconds, it has the same effect as shutdown -p now or halt -p, that is, the video card stops working, the fans keep going, and the disk access light comes fully on. I am guessing that this 4 second delay is part of how FreeBSD wants it. If that is the case, it shows that the power button is working as it should - it is the power-down process that is not working right. No, the 4 second countdown thing is in the BIOS/hardware and is not OS dependent at all. If the box doesn't properly shut off when you hold the power button for 4 seconds, that is a hardware or BIOS bug and something FreeBSD has no control over. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Tue, 19 Aug 2003 09:54:21 -0700 David O'Brien [EMAIL PROTECTED] wrote: Have you tried to hold the power-button a little bit longer? My power-button turn the system off when I pres it for ~4secs (but I haven't a Tyan board). Sorry but telling experiences with non-Tyan boards don't help one bit. (too bad I don't have Bill Paul's finesse in getting this point across) So far every mainboard with ACPI support I've seen so far behaves as stated above. AFAIK you can't override the press for ~4secs to turn the system off in software on those systems. Feel free to point out, that Tyan boards don't turn the system off, even when you hold the power-button longer than 10 seconds. I'm not reluctant to learn something new. Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [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 Mon, Aug 18, 2003 at 04:36:40PM -0700, Gordon Tetlow wrote: I think this is a bad idea because all of the .a archives will end up in /lib. Seeing how those aren't necessary for running binaries in /bin and /sbin, I'd rather they stay in /usr/lib (which means LIBDIR shouldn't change if I'm reading the Makefile glue correctly). Yeah, I realized that later -- I'm working on a new version of the patch for bsd.lib.mk only. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE considered harmful? (was: Lot's of SIGILL, SIGSEGV)
On Tue, Aug 19, 2003 at 10:07:04AM +0200, Stefan Bethke wrote: I think he is right, because when upgrading host where was gcc3.2 to current -CURRENT (with gcc3.3) 'make world' builds make(1) in first place and it is builded by gcc3.2 with CPUTYPE=p4, so it will be broken. So gcc have to be upgraded in first place (with CPUTYPE=p3). Hhm, sounds reasonable. However, I had the exact same problem updating from a 5.1-RC to a recent current on a P III 900, and there, I had CPUTYPE=p3 in make.conf. You must have a early 5.1-RC. Later ones and the release treated CPUTYPE=p4 as an alias for CPUTYPE=p3. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On 19 Aug 2003, Stephen Montgomery-Smith wrote: Alexander Leidinger wrote: Stephen Montgomery-Smith schrieb: Actually the power-off button doesn't work at all under FreeBSD-current. (It is a soft power-off button that dmesg shows is detected by the OS.) Have you tried to hold the power-button a little bit longer? My power-button turn the system off when I pres it for ~4secs (but I haven't a Tyan board). I tried pressing the power button for a longer time. It does actually do something. After about 4 seconds, it has the same effect as shutdown -p now or halt -p, that is, the video card stops working, the fans keep going, and the disk access light comes fully on. I am guessing that this 4 second delay is part of how FreeBSD wants it. If that is the case, it shows that the power button is working as it should - it is the power-down process that is not working right. For what it's worth, I have a Tyan S2469GN with dual Athlon MP's in it in a 3U rack mounted case. The power button acts as any other ATX soft power button I've ever seen, which is to say, it does nothing unless I hold it down for four seconds, at which point, all power is cut to the machine and it is officially off at this point. This is regardless of the state of the OS. --- From dmesg: --- acpi0: power button is handled as a fixed feature programming model. and sysctl: --- hw.acpi.power_button_state: S5 hw.acpi.disable_on_poweroff: 1 I'm running 5-CURRENT from a few days ago... -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas AM Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a-- C++$ UBL+++$ P---+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- Well, I too worry for all young lovers. The darkness is not the light, my child, and there are lights. You are one of the lights, dear Mina, the light of all light. -- Professor Abraham van Helsing, Bram Stoker's Dracula, 1992 end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
date/time, standards n' stuff question
Folks,
First of all I'm not sure if this is the right list. If it isn't
please accept my apologies and divert the thread to the right one so
I'll know for future reference.
I'm using the following little program to generate nano-second
timestamps for performance testing:
int
main(int argc, char **argv)
{
struct timespec ts;
if (clock_gettime(CLOCK_REALTIME, ts) != 0) {
perror(clock_gettime);
return (1);
}
printf(%d.%09lu\n, ts.tv_sec, ts.tv_nsec);
return (0);
}
My question is would it be right/acceptable/agreeable to augment
/usr/bin/date to include an option to generate nanosecond precision
dates? I'm thinking this might make things icky with regards to
standards, etc. but if it were an option and didn't affect the
existing functionality would it really matter? Would anyone care?
Does anyone like or object to the idea?
My motivation for asking is simply to avoid having to distribute/use
this program with the performance testing stuff as previously
(before I cared about nano-second precision) I just used
/usr/bin/date to generate the datestamps.
--
Adam - Migus Dot Org (http://www.migus.org)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
Dr. Richard E. Hawkins said: On Thu, Aug 14, 2003 at 10:49:42PM -0400, Adam Migus wrote: Andrew Gallatin wrote: WRT the mime thing. My apologies. It never occured to me as everyone I know personally uses a real mail reader. I'd attached them simply to keep the scrolling down and allow order independant viewing. Thanks for the tip. I'll just read them in as plain text in the future. If it gives mail or mh problems, it doesn't work on *real* mail readers. :) hawk, ignobly usin mutt -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \ Well, I guess we're back to that whole, what is real thing. So if for the sake of argument, if works with mime were the qualification for a real mail reader and everyone stopped using mime, would all mail readers become not real? Gee, that could be problematic. There must be something else that makes a mail reader real. Otherwise we'd better hope people keep using mime. If continued, I think this belongs on -chat. :-) -- Adam - Migus Dot Org (http://www.migus.org) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
John Baldwin wrote: On 19-Aug-2003 Stephen Montgomery-Smith wrote: I am guessing that this 4 second delay is part of how FreeBSD wants it. If that is the case, it shows that the power button is working as it should - it is the power-down process that is not working right. No, the 4 second countdown thing is in the BIOS/hardware and is not OS dependent at all. If the box doesn't properly shut off when you hold the power button for 4 seconds, that is a hardware or BIOS bug and something FreeBSD has no control over. FreeBSD must have some control over this process, because in FreeBSD-4.8 and RedHat 9.0 (which make no attempt to access ACPI), the power button immediately powers down the computer. The same is also true if I start FreeBSD-current with ACPI support switched off. (Windows 2000 also works fast, but the Windows 2000 OS first cleanly shuts down the file system.) But now that people are mentioning this 4 second issue, I have now also noticed that if I do halt -p under FreeBSD-current, the OS does all its shutdown stuff, prints the message Uptime x, and then waits about 4 seconds before doing its powerdown attempt. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: an driver / Cisco Aironet 340 stopped working
Martin Blapp writes: How old is your CURRENT installation ? Can you run dhclient in verbose mode and in foreground (-d -v) and maybe compile if with -DDEBUG ? I've supped current on last Saturday. Here are debug logs and how Cisco sees the situation. Windows XP debug from Cisco is quite different. Tomppa *** em0 *** Script started on Tue Aug 19 21:10:58 2003 phb:~(1)# ifconfig -a fwe0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::39ff:fe34:7ff2%fwe0 prefixlen 64 scopeid 0x1 ether 02:00:39:34:7f:f2 ch 1 dma 0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=3RXCSUM,TXCSUM inet6 fe80::208:dff:feda:ec61%em0 prefixlen 64 scopeid 0x2 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 ether 00:08:0d:da:ec:61 media: Ethernet autoselect status: no carrier lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 phb:~(2)# dhclient -d -v em0 Internet Software Consortium DHCP Client V3.0.1rc11 Copyright 1995-2002 Internet Software Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Listening on BPF/em0/00:08:0d:da:ec:61 Sending on BPF/em0/00:08:0d:da:ec:61 Sending on Socket/fallback em0: Polling interface state em0: client state of 2 em0: link = 1 em0: Found Link on interface em0: Polling interface state em0: client state of 2 em0: link = 1 DHCPREQUEST on em0 to 255.255.255.255 port 67 em0: Polling interface state em0: client state of 1 em0: link = 1 DHCPREQUEST on em0 to 255.255.255.255 port 67 em0: Polling interface state em0: client state of 1 em0: link = 1 em0: Polling interface state em0: client state of 1 em0: link = 1 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 10 DHCPOFFER from 212.226.167.254 DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 212.226.167.254 bound to 212.226.167.247 -- renewal in 228123 seconds. em0: Polling interface state em0: client state of 5 em0: link = 1 em0: Polling interface state em0: client state of 5 em0: link = 1 ^C phb:~(3)# ifconfig -a fwe0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::39ff:fe34:7ff2%fwe0 prefixlen 64 scopeid 0x1 ether 02:00:39:34:7f:f2 ch 1 dma 0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=3RXCSUM,TXCSUM inet6 fe80::208:dff:feda:ec61%em0 prefixlen 64 scopeid 0x2 inet 212.226.167.247 netmask 0xfff0 broadcast 212.226.167.255 ether 00:08:0d:da:ec:61 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 phb:~(4)# Script done on Tue Aug 19 21:12:19 2003 *** an0 *** Script started on Tue Aug 19 21:13:40 2003 phb:~(1)# ifconfig -a fwe0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::39ff:fe34:7ff2%fwe0 prefixlen 64 scopeid 0x1 ether 02:00:39:34:7f:f2 ch 1 dma 0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=3RXCSUM,TXCSUM inet6 fe80::208:dff:feda:ec61%em0 prefixlen 64 scopeid 0x2 inet 212.226.167.247 netmask 0xfff0 broadcast 212.226.167.255 inet6 2001:670:82:babe:208:dff:feda:ec61 prefixlen 64 tentative autoconf ether 00:08:0d:da:ec:61 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 an0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::240:96ff:fe38:56e7%an0 prefixlen 64 scopeid 0x4 inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 ether 00:40:96:38:56:e7 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid AsOlA 1:AsOlA stationname phb channel 6 authmode OPEN powersavemode CAM powersavesleep 200 wepmode ON weptxkey 1 wepkey 1:128-bit phb:~(2)# dhclient -d -v an0 Device an0 has 802.11 Internet Software Consortium DHCP Client V3.0.1rc11 Copyright 1995-2002 Internet Software Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP Device an0 has 802.11 Listening on BPF/an0/00:40:96:38:56:e7 Sending on BPF/an0/00:40:96:38:56:e7 Sending on Socket/fallback an0: Polling interface state an0: client state of 2 an0: link = 1 an0: Found Link on interface DHCPDISCOVER on an0 to
Re: ACPI on Tyan Motherboard
On 19-Aug-2003 Stephen Montgomery-Smith wrote: John Baldwin wrote: On 19-Aug-2003 Stephen Montgomery-Smith wrote: I am guessing that this 4 second delay is part of how FreeBSD wants it. If that is the case, it shows that the power button is working as it should - it is the power-down process that is not working right. No, the 4 second countdown thing is in the BIOS/hardware and is not OS dependent at all. If the box doesn't properly shut off when you hold the power button for 4 seconds, that is a hardware or BIOS bug and something FreeBSD has no control over. FreeBSD must have some control over this process, because in FreeBSD-4.8 and RedHat 9.0 (which make no attempt to access ACPI), the power button immediately powers down the computer. The same is also true if I start FreeBSD-current with ACPI support switched off. (Windows 2000 also works fast, but the Windows 2000 OS first cleanly shuts down the file system.) But now that people are mentioning this 4 second issue, I have now also noticed that if I do halt -p under FreeBSD-current, the OS does all its shutdown stuff, prints the message Uptime x, and then waits about 4 seconds before doing its powerdown attempt. Here's how it works: The BIOS/hardware monitor the power button. When an OS tells the BIOS that it is ACPI, then the BIOS doesn't do an instant turn off when the power button is pressed, but waits to do so until the power button has been held down for 4 seconds. If the power button after 4 seconds doesn't work, it's still a hardware problem. FreeBSD can not fix your hardware problem. When you press the power button with an ACPI OS running, the hardware sends an interrupt to the OS. The OS then shuts down and asks the BIOS (via ACPI) to power off the machine. If the machine doesn't physically turn off, it's because your BIOS is screwed up and didn't handle the power down command properly. The fact that the 4 second trick (which as above bypasses FreeBSD completely and has the BIOS call that power down method itself) produces the same broken results means that this bug is in your hardware. FreeBSD sleeps for a bit when it does a halt -p as a workaround for broken IDE disks which claim that writes have hit the media when they are still in the disks cache, so that is a separate issue. If you want more info on ACPI and how it works, feel free to head on over to www.acpi.info and read the spec for yourself. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: an driver / Cisco Aironet 340 stopped working
Hi, DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 212.226.167.254 bound to 212.226.167.247 -- renewal in 228123 seconds. So the first time it works ? You get an IP here ... an0: Found Link on interface DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 11 DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 15 No DHCPOFFERS received. No working leases in persistent database - sleeping. Why don't you get an IP here ? Does the server see your requests ? If not, the an0 driver is broken for your card. IMHO it's not dhclient fault here. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: an driver / Cisco Aironet 340 stopped working
Martin Blapp writes: Why don't you get an IP here ? Does the server see your requests ? If not, the an0 driver is broken for your card. IMHO it's not dhclient fault here. Martin Did you look Cisco's dump where Windows DHCPDISCOVER appears as 0100.4096.3856.e7 but FreeBSD is 0040.9638.56e7? Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: an driver / Cisco Aironet 340 stopped working
Hi, Did you look Cisco's dump where Windows DHCPDISCOVER appears as 0100.4096.3856.e7 but FreeBSD is 0040.9638.56e7? That's strange indeed. But 0040.9638.56e7 looks correct to me. Can you tell me why the server does not send anything back ? Why does it happen to be 01 before the mac if you use windows ? Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Tue, Aug 19, 2003 at 09:54:21AM -0700, David O'Brien wrote: Sorry but telling experiences with non-Tyan boards don't help one bit. (too bad I don't have Bill Paul's finesse in getting this point across) Actually, yes it does... well it's relevant in this case. ATX systems respond to holding the power button down for at least 4 seconds by doing a hard power down. I believe this is part of the applicable specifications. - alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
John Baldwin wrote: Here's how it works: The BIOS/hardware monitor the power button. When an OS tells the BIOS that it is ACPI, then the BIOS doesn't do an instant turn off when the power button is pressed, but waits to do so until the power button has been held down for 4 seconds. If the power button after 4 seconds doesn't work, it's still a hardware problem. FreeBSD can not fix your hardware problem. When you press the power button with an ACPI OS running, the hardware sends an interrupt to the OS. The OS then shuts down and asks the BIOS (via ACPI) to power off the machine. If the machine doesn't physically turn off, it's because your BIOS is screwed up and didn't handle the power down command properly. The fact that the 4 second trick (which as above bypasses FreeBSD completely and has the BIOS call that power down method itself) produces the same broken results means that this bug is in your hardware. FreeBSD sleeps for a bit when it does a halt -p as a workaround for broken IDE disks which claim that writes have hit the media when they are still in the disks cache, so that is a separate issue. If you want more info on ACPI and how it works, feel free to head on over to www.acpi.info and read the spec for yourself. I took a quick look at the acpi web site, but it is a lot more reading than I have time for right now. Following up your suggestion that it is a hardware problem, I decided to try updating the BIOS from version 2.10 to 2.14. Now start up produces lots of ACPI error messages. I am not asking for you guys to fix it, but if you can help me interpret it (or can comfirm that this is indeed a hardware problem), I would appreciate it. Dmesg is included as an attachment. (In particular, it says that the BIOS version is 2.10 when I just updated it to 2.14, unless that 2.10 coincidently refers to something else.) -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen 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 #4: Tue Aug 19 15:25:45 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HUB Preloaded elf kernel /boot/kernel/kernel at 0xc04c2000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04c2244. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) MP 2000+ (1659.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 3221159936 (3071 MB) avail memory = 3132239872 (2987 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard pcibios: BIOS version 2.10 ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6a80 StartNode 0xc93d6a80 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM1._STA] (Node 0xc93d6a80), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6900 StartNode 0xc93d6900 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM2._STA] (Node 0xc93d6900), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6700 StartNode 0xc93d6700 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.LPT_._STA] (Node 0xc93d6700), AE_NOT_FOUND acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6a80 StartNode 0xc93d6a80 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM1._STA] (Node 0xc93d6a80), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6900 StartNode 0xc93d6900 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.COM2._STA] (Node 0xc93d6900), AE_NOT_FOUND ACPI-0438: *** Error: Looking up [Z00Q] in namespace, AE_NOT_FOUND SearchNode 0xc93d6700 StartNode 0xc93d6700 ReturnNode 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.SIO_.LPT_._STA] (Node 0xc93d6700), AE_NOT_FOUND acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_cpu1: CPU port 0x530-0x537
gcc 3.3.1 ICE building R-letter
I see an ICE building the math/R-letter port on -current (x86) from late last week. % gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.1 [FreeBSD] 20030711 (prerelease) cc -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -mieee-fp -O -c plotmath.c -o plotmath.o plotmath.c: In function `Rf_GMMathText': plotmath.c:3184: internal compiler error: in final_scan_insn, at final.c:2799 Please submit a full bug report, Changing the optimization level (ie, -O0 or -O2) makes it go away. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc 3.3.1 ICE building R-letter
On Tue, Aug 19, 2003 at 05:08:44PM -0400, Andrew Gallatin wrote: I see an ICE building the math/R-letter port on -current (x86) from late last week. % gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.1 [FreeBSD] 20030711 (prerelease) cc -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -mieee-fp -O -c plotmath.c -o plotmath.o plotmath.c: In function `Rf_GMMathText': plotmath.c:3184: internal compiler error: in final_scan_insn, at final.c:2799 Please submit a full bug report, I also see this problem on bento and have reported it to kan. Kris pgp0.pgp Description: PGP signature
Re: HEADS UP: dynamic root support now in the tree
From: Shin-ichi Yoshimoto [EMAIL PROTECTED]
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 ?
I stumbled accross this problem too. My solution was to copy
/usr/libexec/ld-elf.so.1 to /libexec and then try the make installworld
again. We're going to need a solution for those that are going from a
system (4.x, 5.0, 5.1) previous to the WITH_DYNAMIC_ROOT changes.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Regarding recent spam on the list
Just curious if anyone knows the origin of all these auto-responses, etc. I'm seeing a lot of these on every list I'm subscribed to (not all of them FreeBSD related) so I was wondering if some Windows trojan is running rampant and using these list addresses as return addys? Anyone know? -- 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: Regarding recent spam on the list
On Tue, 2003-08-19 at 18:03, Bill Moran wrote: Just curious if anyone knows the origin of all these auto-responses, etc. I'm seeing a lot of these on every list I'm subscribed to (not all of them FreeBSD related) so I was wondering if some Windows trojan is running rampant and using these list addresses as return addys? It's W32/[EMAIL PROTECTED] It's spreading *fast* -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH URGENT! E-xpedient nuked APK subdomains; kf8nh.apk.net is DEAD. Sorry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regarding recent spam on the list
Brandon S. Allbery KF8NH wrote: On Tue, 2003-08-19 at 18:03, Bill Moran wrote: Just curious if anyone knows the origin of all these auto-responses, etc. I'm seeing a lot of these on every list I'm subscribed to (not all of them FreeBSD related) so I was wondering if some Windows trojan is running rampant and using these list addresses as return addys? It's W32/[EMAIL PROTECTED] It's spreading *fast* Homer Simpson voice Stupid Windows. /Homer Simpson voice Thanks for the info ... I probably should have just known ... -- 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: Regarding recent spam on the list
Boy am I glad I use a *real* OS for my mail... --Devon Brandon S. Allbery KF8NH wrote: On Tue, 2003-08-19 at 18:03, Bill Moran wrote: Just curious if anyone knows the origin of all these auto-responses, etc. I'm seeing a lot of these on every list I'm subscribed to (not all of them FreeBSD related) so I was wondering if some Windows trojan is running rampant and using these list addresses as return addys? It's W32/[EMAIL PROTECTED] It's spreading *fast* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On 19-Aug-2003 Stephen Montgomery-Smith wrote: John Baldwin wrote: Here's how it works: The BIOS/hardware monitor the power button. When an OS tells the BIOS that it is ACPI, then the BIOS doesn't do an instant turn off when the power button is pressed, but waits to do so until the power button has been held down for 4 seconds. If the power button after 4 seconds doesn't work, it's still a hardware problem. FreeBSD can not fix your hardware problem. When you press the power button with an ACPI OS running, the hardware sends an interrupt to the OS. The OS then shuts down and asks the BIOS (via ACPI) to power off the machine. If the machine doesn't physically turn off, it's because your BIOS is screwed up and didn't handle the power down command properly. The fact that the 4 second trick (which as above bypasses FreeBSD completely and has the BIOS call that power down method itself) produces the same broken results means that this bug is in your hardware. FreeBSD sleeps for a bit when it does a halt -p as a workaround for broken IDE disks which claim that writes have hit the media when they are still in the disks cache, so that is a separate issue. If you want more info on ACPI and how it works, feel free to head on over to www.acpi.info and read the spec for yourself. I took a quick look at the acpi web site, but it is a lot more reading than I have time for right now. Following up your suggestion that it is a hardware problem, I decided to try updating the BIOS from version 2.10 to 2.14. Now start up produces lots of ACPI error messages. I am not asking for you guys to fix it, but if you can help me interpret it (or can comfirm that this is indeed a hardware problem), I would appreciate it. Dmesg is included as an attachment. The 2.10 is the version of the PCI BIOS specification that your motherboard BIOS supports. It is unrelated to the version of your motherboard BIOS. Unfortunately, your new BIOS seems to be buggy as well, but you can probably compile a custom asl to work around it. The best thing to do is to e-mail [EMAIL PROTECTED] providing a link to your acpidump and dmesg and they can give you some pointers on fixing your asl and recompiling it so you can override your BIOS. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
no subject
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Tue, Aug 19, 2003 at 07:16:32PM +0200, Alexander Leidinger wrote: Feel free to point out, that Tyan boards don't turn the system off, even when you hold the power-button longer than 10 seconds. I'm not reluctant to learn something new. My K7 Thunder S2462 doesn't turn off no matter how longer I hold down the power button. It seems to be semi-BIOS version specific and the BIOS setting on what to do when power is lost and then restored. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Tue, Aug 19, 2003 at 01:58:22PM -0700, Alex Zepeda wrote: On Tue, Aug 19, 2003 at 09:54:21AM -0700, David O'Brien wrote: Sorry but telling experiences with non-Tyan boards don't help one bit. (too bad I don't have Bill Paul's finesse in getting this point across) Actually, yes it does... well it's relevant in this case. ATX systems respond to holding the power button down for at least 4 seconds by doing a hard power down. I believe this is part of the applicable specifications. The thread is specifically about the Tyan S2462: I have a Tyan S2462 Thunder K7 motherboard. I was hoping to get power-down to work. So I installed FreeBSD current with ACPI enabled. When I typed shutdown -p now the computer halted, and then the video card switched off, and the fans kept running. The computer was frozen - even the power-off power-on button wouldn't work. Actually the power-off button doesn't work at all under FreeBSD-current. (It is a soft power-off button that dmesg shows is detected by the OS.) I should add that power-down works great with Windows 2000. Also, the power-off button works properly with FreeBSD-stable. perhaps people aren't reading before replying. I also own a Tyan S2462 Thunder K7 system and it behaves just as the poster stated. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Wednesday 20 August 2003 02:49, John Baldwin wrote: Here's how it works: The BIOS/hardware monitor the power button. When an OS tells the BIOS that it is ACPI, then the BIOS doesn't do an instant turn off when the power button is pressed, but waits to do so until the power button has been held down for 4 seconds. If the power button after 4 seconds doesn't work, it's still a hardware problem. FreeBSD can not fix your hardware problem. When you press the power button with an ACPI OS running, the hardware sends an interrupt to the OS. The OS then shuts down and asks the BIOS (via ACPI) to power off the machine. If the machine doesn't physically turn off, it's because your BIOS is screwed up and didn't handle the power down command properly. The fact that the 4 second trick (which as above bypasses FreeBSD completely and has the BIOS call that power down method itself) produces the same broken results means that this bug is in your hardware. FreeBSD sleeps for a bit when it does a halt -p as a workaround for broken IDE disks which claim that writes have hit the media when they are still in the disks cache, so that is a separate issue. If you want more info on ACPI and how it works, feel free to head on over to www.acpi.info and read the spec for yourself. Windows 2000 can shutdown my Tiger 230T in very short time, while FreeBSD is always timeouted with halt -p. I dont't think it is hardware or BIOS problem, FreeBSD must be wrong in something, just like FreeBSD ATA bug for my Tiger 230T, all OS I have in hand work fine, only FreeBSD does not. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc 3.3.1 ICE building R-letter
On Tue, Aug 19, 2003 at 02:15:03PM -0700, Kris Kennaway wrote: I see an ICE building the math/R-letter port on -current (x86) from late last week. % gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.1 [FreeBSD] 20030711 (prerelease) ... I also see this problem on bento and have reported it to kan. Better would be to install the GCC 3.3 port (which is post 3.3.1 release) and see if it still happens. If it does then please submit a GCC bug report to the GCC guys. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Tue, Aug 19, 2003 at 06:13:19PM -0400, John Baldwin wrote: Following up your suggestion that it is a hardware problem, I decided to try updating the BIOS from version 2.10 to 2.14. Now start up produces lots of ACPI error messages. ... The 2.10 is the version of the PCI BIOS specification that your motherboard BIOS supports. It is unrelated to the version of your motherboard BIOS. NO. His 2.10 above *IS* the version of his BIOS. I know exactly what version he had and has now. He is correct about the extra ACPI error verbage. -- -- David ([EMAIL PROTECTED]) P.S. \me wishes people not owning a K7 Thunder S2462 wounldn't repsond with specifics contricting the truth. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc 3.3.1 ICE building R-letter
On Tue, Aug 19, 2003 at 06:39:13PM -0700, David O'Brien wrote: On Tue, Aug 19, 2003 at 02:15:03PM -0700, Kris Kennaway wrote: I see an ICE building the math/R-letter port on -current (x86) from late last week. % gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.1 [FreeBSD] 20030711 (prerelease) ... I also see this problem on bento and have reported it to kan. Better would be to install the GCC 3.3 port (which is post 3.3.1 release) and see if it still happens. If it does then please submit a GCC bug report to the GCC guys. I've been forwarding all the failures from the bento machines to kan at his request...he may have already taken care of this. Kris pgp0.pgp Description: PGP signature
Re: ACPI on Tyan Motherboard
David O'Brien wrote: On Tue, Aug 19, 2003 at 06:13:19PM -0400, John Baldwin wrote: Following up your suggestion that it is a hardware problem, I decided to try updating the BIOS from version 2.10 to 2.14. Now start up produces lots of ACPI error messages. ... The 2.10 is the version of the PCI BIOS specification that your motherboard BIOS supports. It is unrelated to the version of your motherboard BIOS. NO. His 2.10 above *IS* the version of his BIOS. I know exactly what version he had and has now. He is correct about the extra ACPI error verbage. But why would FreeBSD tell me that the BIOS version is 2.10 when I just installed version 2.14? Is this something wrong with the bios update features of this motherboard? The bios update seemed to go successfully. I might add that even with this updated BIOS, that seems to be more buggy from FreeBSD-current's point of view, that power down still works fine with Windows 2000. (It would be nice to have working ACPI with FreeBSD, but I'm not going to be greatly upset if it doesn't work. From every other point of view, this motherboard seems to work very nicely, with every operating system I have tried on it. My main reason for wanting properly working powerdown is so that if a fan stops working, then the healthd program would kick in and power-down the computer. Of course it is possible that if a fan breaks, then the CPU overheats so quickly that the healthd/acpiconf -s S5 combination just isn't quick enough. In that case, ACPI is nothing more than a nicety for me.) -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI on Tyan Motherboard
On Tue, Aug 19, 2003 at 08:55:10PM -0500, Stephen Montgomery-Smith wrote: Following up your suggestion that it is a hardware problem, I decided to try updating the BIOS from version 2.10 to 2.14. Now start up produces lots of ACPI error messages. ... The 2.10 is the version of the PCI BIOS specification that your motherboard BIOS supports. It is unrelated to the version of your motherboard BIOS. NO. His 2.10 above *IS* the version of his BIOS. I know exactly what version he had and has now. He is correct about the extra ACPI error verbage. But why would FreeBSD tell me that the BIOS version is 2.10 when I just installed version 2.14? Is this something wrong with the bios update features of this motherboard? The bios update seemed to go successfully. Sorry! Now I know what 2.10 was being refered to. Sorry to JHB for that. JHB was correct 2.10 is a specification and does not refer to the Tyan version given to a specific BIOS. I might add that even with this updated BIOS, that seems to be more buggy from FreeBSD-current's point of view, that power down still works fine with Windows 2000. And yes, that is my experiences also with K7 Thunder BIOS version 2.14 (and 2.13 and 2.10). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
usb printer problems
I have an Epson Stylus Color 880 which is connected to my machine through USB. Whenver I try to print to it, it tells me 'ulpt0: output error'. Ive tried ulpt0 and unlpt0 and neither of them work. I also scoured the net, I found people with similar problems, but no solution. I am using CUPS, and the config is correct, because this worked on an older system I had and the config is the same. 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: Broken kernel on 5.1-RELEASE was :[compile on 5.1-RELEASE /5-CURRENT (SMP, PAE scsi)]
Ok I've now got problems with the compiled kernel, I get panics on my multiple cpu machine on boot just after boot before the prompt is reached. It's a lock on cpu #2 ( I believe cpu 3 ). Unfortunately I don't have the exact message nor do I have a kernel dump as this machine is meant to be a production one and as such a boot of kernel.old was done. Does anyone have a 4 or greater cpu machine running 5.1-RELEASE succesfully ? I've got a 5.1-RELEASE machine running with the same kernel config 2 cpu's without any problem so I can only think that it's something to do with more than 2 cpu's. Cheers, Mark On Tue, 2003-08-19 at 17:55, Mark Sergeant wrote: On Tue, 2003-08-19 at 17:47, Scott Long wrote: Mark Sergeant wrote: Hi All, When trying to compile a kernel for my 8 cpu DELL 8450's I recieve an extremly puzzling error, I get a bunch of errors when compiling a kernel that has the following options in it... options WITNESS options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options PAE options SMP options APIC_IO Without PAE SMP or APIC_IO the kernel will compile fine. With these options I get the following error when compiling the sym scsi driver. cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/sym/sym_hipd.c cc1: warnings being treated as errors ../../../dev/sym/sym_hipd.c: In function `sym_setup_data_and_start': ../../../dev/sym/sym_hipd.c:8146: warning: cast from pointer to integer of different size *** Error code 1 This is rather unfortunate as the only disks I have run off this controller. I've found that it does compile with the ahc driver but even then some usb stuff needs removing. Does anyone have any insight into this and what I can do to get it fixed. Cheers, The key kere is likely PAE, not APIC_IO, as PAE changes the size of some data types. The USB problem is known. The sym problem looks to be harmless assuming that the warning you got is the only one that is emitted. However, it appears that it was never certified as being ready for PAE. If you're adventurous, you can try compiling and loading it as a module (warnings when compiling modules are not fatal like they are in when compiling the kernel). If there are more errors/warning that what you list, I'd be interested in seeing them. Scott There are no other errors apart from those listed so I may try compiling as a module that gets loaded on boot. Just one problem, I succesfully build an SMP kernel without PAE and then rebooted and the server is no longer responding, it seems it crashed just after coming up as I was able to ping it 5 or 6 times and then it went away again. If I've got a crash dump I'll post it. Cheers, -- Mark Sergeant [EMAIL PROTECTED] SNSOnline Technical Services ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is rl broken?
This thread originally taken from the -stable mailing list, but I'm seeing weird things in -current now, so I thought I'd ask I cvsup'd and rebuilt a FreeBSD 4.8 system last Friday after receiving the realpath security advisory. The machine is remote and the NIC uses the rl driver. After booting the machine I had no network connectivity. The person at the remote site says the boot was normal and he could see that the NIC was properly configured but he could not ping it and I could not login. We booted off kernel.old and everything came up fine. I have a machine with an Intel nic using the fxp driver that is exhibiting the same sort of weirdness. I just installed 5.1-RELEASE on it after it was built and things were rock solid. I got my NIC configured to use DHCP in my LAN here at home, everything's fine. then I cvsup and buildworld/kernel (the same kernel config that an *identical* system on my LAN is using) and test out the new kernel before installkernel and dhclient seems to finish properly and the interface seems configured correctly with the correct IP. netstat -r shows the right stuff, but I can't even ping the NIC itself. It says sendto: permission denied when I try to ping the NIC itself and *also* 127.0.0.1. If I revert back to the 5.1-RELEASE kernel with the same hardware and zero config changes, everything is hunky dory again. Sorry, I'm light on details--I need to do some more experiments and will cut-n-paste what I see, but I wanted to see if anybody else is experiencing anything oddball like this. -Jr -- John ReynoldsSr. Physical Design Engineer - WCCG/CCE PDE Intel Corporation MS: CH6-210 Phone: 480-554-9092RIM PIN: 10326855 [EMAIL PROTECTED] (e-mail with PAGE in subj to forward to RIM) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is rl broken?
On Tue, 19 Aug 2003, John Reynolds~ wrote: sendto: permission denied Turn off ipfw, then try again. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
