more on supermicro 6010H hang
I have isolated the point at which current no longer runs as Jan 31 - Feb 1 of this year. Prior version work fine, in Feb Mar I get either Kernel trap 9 with interrupts disabled or I think the same thing with trap 26 (really not sure on that one). Next I took a brand new current from this evening and tried it - it still hangs, but a keypress on the keyboard pretty much always breaks it out of the hang and into a normal boot. Now, I finally got the equipment and time together to remote gdb the bad kernel and here's what I get: I set a breakpoint at cam_xpt.c::xpt_config() - this is where the Waiting 15 seconds.. message is from and stepped down through it. I get through the first xpt_for_all_busses (xptconfigbuscountfunc,...) and then I hit the second one (~line 6749 of cam_xpt.c) I pass through several things, including the xptconfigfunc() and end up in subr_autoconf.c::run_interrupt_driven_config_hooks(). At the bottom of this function there is a tsleep that gets called - this is apparently where it hangs. If I hit a key on the keyboard it will continue on past this point and all seems to work fine from then on. This is my first time this deep into the kernel - can you suggest a further plan of attack? thanks! dave c here's the dmesg output for this system if this helps any: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Mon Jul 16 22:32:23 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/SMP Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (999.53-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1048512K bytes) avail memory = 1040248832 (1015868K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel kernel at 0xc0527000. Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 7 entries at 0xc00f5370 npx0: math processor on motherboard npx0: INT 16 interface pcib0: ServerWorks host to PCI bridge at pcibus 0 on motherboard IOAPIC #1 intpin 12 - irq 2 IOAPIC #1 intpin 10 - irq 5 IOAPIC #1 intpin 11 - irq 7 IOAPIC #1 intpin 15 - irq 9 pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 0.1 on pci0 IOAPIC #1 intpin 14 - irq 11 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xc800-0xc83f mem 0xfe80-0xfe8f,0xfeafb000-0xfeafbfff irq 2 at device 4.0 on pci0 fxp0: Ethernet address 00:30:48:11:69:84 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xfeafc000-0xfeafcfff irq 5 at device 5.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 7 at device 5.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs fxp1: Intel Pro 10/100B/100+ Ethernet port 0xd400-0xd43f mem 0xfe90-0xfe9f,0xfeafd000-0xfeafdfff irq 9 at device 6.0 on pci0 fxp1: Ethernet address 00:30:48:11:6e:27 inphy1: i82555 10/100 media interface on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge port 0x580-0x58f at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks ROSB4 ATA33 controller port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: OHCI (generic) USB controller mem 0xfeafe000-0xfeafefff irq 10 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib2: ServerWorks host to PCI bridge at pcibus 2 on motherboard pci2: PCI bus on pcib2 orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xcefff,0xcf000-0xc on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4
No Subject
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
A7A266 motherboard
Hello, There is a problem with with running Xfree86 with FreeBSD on the Asus A7A266 motherboards. I have tried with 4.3 RELEASE 4.3 STABLE and now 5.0 CURRENT with 2 different video cards. ( ATI Radeon and a Matrox G450).This motherboard has the ALiMAGiK1 M1647 chipset. There are several other people with this hardware having the same problem.Is there a fix?. Thanks Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A7A266 motherboard
* Jake Bishop [EMAIL PROTECTED] [010717 02:28] wrote: Hello, There is a problem with with running Xfree86 with FreeBSD on the Asus A7A266 motherboards. I have tried with 4.3 RELEASE 4.3 STABLE and now 5.0 CURRENT with 2 different video cards. ( ATI Radeon and a Matrox G450).This motherboard has the ALiMAGiK1 M1647 chipset. There are several other people with this hardware having the same problem.Is there a fix?. I doubt that FreeBSD is your problem. which version of xfree are you using? i would try installing the 4.1.0 version of xfree from ports or packages. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA disks problem in -CURRENT
Søren == Søren Schmidt [EMAIL PROTECTED] writes: Søren Hmm, I havn't changed anything in the ATA driver lately, so I Søren dont know what should have caused this malfunction. When was Søren the last date -current worked for you ? I don't know exactly, but I started noticing problems about one month ago. Just to make sure, SSE isn't enabled by default, is it? (looks like it is not according to NOTES) However, the mean time between crashes has been increased since I removed PostgreSQL, Zope and Squid, which were sometimes disk intensive (especially Squid). Is there any way the dump I generated could help? (e.g., for checking invariants or locking structures of the disk?) Sam -- Samuel Tardieu -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Load average synchronisation and phantom loads
On 15-Jul-01 Ian Dowse wrote: There are a few PRs and a number of messages in the mailing list archives that describe a problem where the load average occasionally remains at 1.0 or greater even though top(1) reports that the CPU is nearly 100% idle. The PRs I could find in a quick search are kern/21155, kern/23448 and kern/27334. The most probable cause for this effect is a synchonisation between the load measurement and processes that periodically run for short amounts of time. The load average is based on samples of the number of running processes taken at exact 5-second intervals. If some other process regularly runs with a period that divides into 5 seconds, that process may always be seen as running even though it may only run for a tiny fraction of the available CPU time. A very likely candidate process is bufdaemon; it sleeps for 1 second at a time, so if it happens to get scheduled in the same tick as the load measurement and before the load measurement, it will always be seen as running. The patch below causes the samples of running processes to be somewhat randomised; instead of being taken every 5 seconds, the gap now varies in the range 4 to 6 seconds, so that synchronisation should no longer occur. Would there be any objections to my committing this? Two comments on the patch: - This patch removes the SSLEEP case in loadav(), because in the existing code, p-p_slptime has always just been incremented in schedcpu() so this case never made a difference. To keep the same load average behaviour when loadav() is called at different times, this case needs to be removed. - The load average calculation now has really nothing to do with the VM system, so it could be moved elsewhere. I've just left it in vm_meter.c because that's where it's always been. sys/kern/kern_synch.c perhaps? Might be best to do that as a separate commit however. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Make world hosed ?
Am I the only one who sees this ? === usr.sbin/inetd cc -nostdinc -O -pipe -DINET6 -DIPSEC -DLOGIN_CAP -I/usr/obj/flat/src/i386/usr/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpoin ter-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /flat/src/usr.sbin/inetd/inetd.c gzip -cn /flat/src/usr.sbin/inetd/inetd.8 inetd.8.gz cc -nostdinc -O -pipe -DINET6 -DIPSEC -DLOGIN_CAP -I/usr/obj/flat/src/i386/usr/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpoin ter-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /flat/src/usr.sbin/inetd/builtins.c cc1: warnings being treated as errors In file included from /usr/obj/flat/src/i386/usr/include/rpc/rpc.h:50, from /flat/src/usr.sbin/inetd/inetd.c:125: /usr/obj/flat/src/i386/usr/include/rpc/xdr.h:141: warning: function declaration isn't a prototype In file included from /flat/src/usr.sbin/inetd/inetd.c:139: /usr/obj/flat/src/i386/usr/include/tcpd.h:34: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:35: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:36: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:37: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:75: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:76: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:77: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:78: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:79: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:80: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:81: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:82: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:83: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:126: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:127: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:128: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:129: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:130: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:131: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:137: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:138: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:139: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:187: warning: function declaration isn't a prototype -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Make world hosed ?
On Tue, Jul 17, 2001 at 08:38:13PM +0200, Poul-Henning Kamp wrote: Am I the only one who sees this ? I suspect that this is my fault for not doing a buildworld after turning on WARNS stuff in inetd. I think the problem must be that -nostdinc must cause errors to be issued for files which wouldn't usually be. I'll back out the WARNS stuff and find out what's going on. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Load average synchronisation and phantom loads
In message [EMAIL PROTECTED], Bruce Ev ans writes: I think that is far too much variation. 5 seconds is hard-coded into the computation of the load average (constants in cexp[]), so even a variation of +-1 ticks breaks the computation slightly. I have not changed the mean inter-sample time from 5 seconds (*), so is this really a problem? There will be a slight time-warping effect in the load calculation, but even for the shorter 5-minute timescale, this will average out to typically no more than a few percent (i.e the 5 minutes will instead normally be approx 4.8 to 5.2 minutes). Apart from a marginally more wobbley xload display, this should not make any real difference. If the variation was much smaller than it is in the proposed patch, you could get a noticable drifting in and out of phase with processes that have a regular run-pause pattern. Obviously this is a much bigger problem when the sample period is fixed like it is now, but I wanted to minimise the possibility of this effect while keeping the inter-update time relatively constant. The alternative that I considered was to sample the processes once during every 5-second interval, but to place the sampling point randomly over the interval. That probably results in a better synchronisation-avoidance behaviour. However, to incorporate the sample into the load average requires either waiting until the end of the interval, or updating the load average at the time of sampling. The former introduces a new delay into the load average computation, and the latter results in a lot of very noticable jitter on the inter-sample interval. (*) Actually, I have changed the mean by 0.5 ticks, but that is a bug that I will fix. The 4 + random() % (hz * 2) should be 4 + random() % (hz * 2 + 1) instead. Not another SYSINIT (all SYSINITs are evil IMO). SI_SUB_PSEUDO is bogus here -- there are no pseudo ttys here. sched_setup() is a good place to do this initialization. John Baldwin suggested moving the load average calculation into kern_synch.c, so it would certainly make sense to initialise it from sched_setup() then. This seems like a good idea to me; does that sound OK? Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Tue, Jul 17, 2001 at 10:27:14 -0700, Kris Kennaway wrote:
On Tue, Jul 17, 2001 at 01:23:44PM -0400, Garance A Drosihn wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
I vote this too. We don't need stripped down libreadline under
'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
--
Andrey A. Chernov
http://ache.pp.ru/
PGP signature
Re: Make world hosed ?
On Tue, Jul 17, 2001 at 07:55:18PM +0100, David Malone wrote: I suspect that this is my fault for not doing a buildworld after turning on WARNS stuff in inetd. YES! Why are you committing these very easy to break the build, as we've seen changes w/o full `make buildworld' testing?!? I'll back out the WARNS stuff and find out what's going on. Yes, please. If you guys doing the WARNS stuff cannot slow down a little and do proper build testing, I personally (and I know at least one will disagree with me here) wish you guys would stop the effort. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A7A266 motherboard
I have compiled and installed Xfree86-4.1.0_4 from ports several times with RELEASE, STABLE and CURRENT. I am using 4.1.0 with Slackware Linux with a ATI Radeon card on the same machine.It works fine. As I mentioned also there are some others with this setup who are having the same problems. When I try to run xf86cfg or XFree86 -configure the machine locks up then does a spontaneous hard reboot. Hello, I doubt that FreeBSD is your problem. which version of xfree are you using? i would try installing the 4.1.0 version of xfree from ports or packages. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Signal handler context restore difference - pthreads/non-pthreads
Hi, I have run into an issue with the difference between what happens when a signal handler returns from a program converted to use pthreads (vs non-pthreads). Basically, in the non-pthread case, a change made to the sc_eip element of the scp struct is honored when the kernel restores the processes context. In the pthreads case, the change to the sc_eip element is ignored. A test case which shows both a working and non-working version of this resides at: http://www.freebsd.org/~jwd/sigtst/ The makefile produces two executables: fptrap : a 'correct' executable - non-pthreads fptrapt: a 'bad' executable - pthreads %./fptrap ** Result correct: 1234.57 %./fptrapt ** Result incorrect: 1 I'd like to hear if you've dealt with the issue of precise error recovery and how it was dealt with. I'm currently exploring whether a fix to the pthread library is feasible or whether an application change is required (or conclude that the type of error recovery I need can't be done with pthreads). Thanks! John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Signal handler context restore difference - pthreads/non-pthreads
On Tue, 17 Jul 2001, John W. De Boskey wrote: Hi, I have run into an issue with the difference between what happens when a signal handler returns from a program converted to use pthreads (vs non-pthreads). Basically, in the non-pthread case, a change made to the sc_eip element of the scp struct is honored when the kernel restores the processes context. This has come up once before. The threads library doesn't copy the modified context back to the originating threads context. In a threaded program, there is no guarantee that the signal handler is being called in the context of the thread that was interrupted by the signal. The interrupted thread may actually be running on another processor, or the signal handler could block allowing another thread to run, either of which could prevent modification of the context from having any effect. In addition, if the context [passed in as arg3] were to actually be stored on the interrupted threads stack, you could corrupt the stack if the thread ran before you modified the context. Sometimes signal handlers are delayed a bit too (if the currently running thread is in a critical region) so the context would be somewhat meaningless in that case. But the case you provide an example for is a synchronous signal that should be handled in the context of the currently running thread. And I would hope the threads library wouldn't be causing these types of signals, especially within critical regions. One thing that we could do, is copy the context back to the threads context iff the signal handler is being called in the context of the currently running thread, and the signal is a synchronous signal. But the easier thing to do is for the application to call sigreturn() with the modified context (as long as it knows the signal handler is being called in the context of the interrupted thread). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATA CD read problems
I think I've got a line on my recent CD copying problems. I can make an iso image from a CD with a small amount of data (about 68M) no problem. However, when I try to make an iso image of a cd with a large amount of data (around 600M) it dies after writing about 500M. I'm using a command line of 'dd if=/dev/acd0c of=test.iso bs=2k'. On the console I get error messages like this: acd0: READ_BIG command timeout - resetting ata0: resetting devices .. done acd0: READ_BIG command timeout - resetting ata0: resetting devices .. done acd0: READ_BIG command timeout - resetting ata0: resetting devices .. done The dd processes get stuck in physst state according to top, and can't be kill'ed, even with -9. According to ps their state is DWL or DWL+. The CD is a generic OEM 24x EIDE drive, and I have hw.ata.atapi_dma=1 in /boot/loader.conf. The CD is identified as: acd0: CDROM BCD 24XM CD-ROM at ata0-master UDMA33 at boot time. I'm using 5-current built on 3 June. I'm happy to do what I can to test patches, upgrade, etc. I haven't had a lot of time for FreeBSD lately, so I haven't been tracking -current closely. This build has been very stable for me other than this problem. I generally don't have problems with this CD drive (that I've ever noticed anyway) but this is the first time I've tried making iso images. It's entirely possible that this CD reader is just a POS, which is fine, but I thought I'd ask just in case. Doug -- If you're never wrong, you're not trying hard enough. Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
At 3:19 AM -0700 7/16/01, Kris Kennaway wrote: Hmm. We could easily provide a libreadline port for ports to use, as long as libedit does everything that's needed for the in-tree users (are there any others apart from bc and gdb?) The only danger is if future versions of those grow the need to use other parts of the API which we don't implement. The upside is that both the FreeBSD and NetBSD communities would be facing the same problem, meaning greater developer power to implement new features. Personally, I think it's worth it to get rid of a GNU dependency in the base system, as well as reducing the overall amount of functional code duplication. I may be misunderstanding what you mean here, but I don't think we should replace libreadline with libedit. However, I do find this very interesting, as some of my friends and I have a program that we're going to switch from gnu to bsd licensing, and it would be nice if we could use this libedit instead of libreadline. Is there some way freebsd could switch base-system components to use libedit, and then turn libreadline into a port for any other ports which need libreadline? And maybe have the README for the libreadline port just suggest to people that they might want to try libedit instead of installing the libreadline port? Note that part of what I want is for people who are looking for libreadline to find out that libedit exists. I'm not sure of the best way to do that. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Tue, Jul 17, 2001 at 12:23:28PM -0400, Garance A Drosihn wrote: I may be misunderstanding what you mean here, but I don't think we should replace libreadline with libedit. However, I do find this very interesting, as some of my friends and I have a program that we're going to switch from gnu to bsd licensing, and it would be nice if we could use this libedit instead of libreadline. Is there some way freebsd could switch base-system components to use libedit, and then turn libreadline into a port for any other ports which need libreadline? I think hacking gdb to use libedit would cause a lot of pain for future maintenance, although bc allegedly supports libedit already (I say allegedly because last time I tried to build with it, it didn't compile). Vinum is the third thing in the base system which uses libreadline: it could feasibly be rewritten. However, gdb, vinum and bc all compile fine using the libreadline API shim for libedit (modulo bugs and missing features which people need to investigate and tell me about), leaving no dependencies on GNU libreadline in the base system at the present time. Kris PGP signature
Re: Load average synchronisation and phantom loads
On Sun, 15 Jul 2001, Ian Dowse wrote: The patch below causes the samples of running processes to be somewhat randomised; instead of being taken every 5 seconds, the gap now varies in the range 4 to 6 seconds, so that synchronisation should no longer occur. Would there be any objections to my committing this? I think that is far too much variation. 5 seconds is hard-coded into the computation of the load average (constants in cexp[]), so even a variation of +-1 ticks breaks the computation slightly. Index: vm/vm_meter.c === RCS file: /dump/FreeBSD-CVS/src/sys/vm/vm_meter.c,v retrieving revision 1.57 diff -u -r1.57 vm_meter.c --- vm/vm_meter.c 2001/07/04 19:00:12 1.57 +++ vm/vm_meter.c 2001/07/15 20:54:38 ... +SYSINIT(loadav, SI_SUB_PSEUDO, SI_ORDER_ANY, loadav_init, NULL) Not another SYSINIT (all SYSINITs are evil IMO). SI_SUB_PSEUDO is bogus here -- there are no pseudo ttys here. sched_setup() is a good place to do this initialization. + Extra blank line. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Wed, 18 Jul 2001 00:23:43 +0400, Andrey A. Chernov wrote:
On Tue, Jul 17, 2001 at 10:27:14 -0700, Kris Kennaway wrote:
On Tue, Jul 17, 2001 at 01:23:44PM -0400, Garance A Drosihn wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
I vote this too. We don't need stripped down libreadline under
'libreadline' name pretend to be full version (f.e. for autoconf, etc.)
This idea was certainly crossing my mind too. This way we would insure
ourserves from a number of weird problems associated with having two
version of libreadline.{a,so} and appropriate similarly named headers
in /usr and /usr/local. Ports that can work with libeditNG then could
be properly tailored to link with it instead of GNU libreadline. The
only drawback here is that authors of tools, which need to be linkable
with both libeditNG and GNU libreadline (think about vinum) will have to
do some black #ifdef magick, but that's life...
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
At 9:40 AM -0700 7/17/01, Kris Kennaway wrote:
On Tue, Jul 17, 2001, Garance A Drosihn wrote:
Is there some way freebsd could switch base-system components to
use libedit, and then turn libreadline into a port for any other
ports which need libreadline?
I think hacking gdb to use libedit would cause a lot of pain for
future maintenance, although bc allegedly supports libedit already (I
say allegedly because last time I tried to build with it, it didn't
compile). Vinum is the third thing in the base system which uses
libreadline: it could feasibly be rewritten.
However, gdb, vinum and bc all compile fine using the libreadline API
shim for libedit (modulo bugs and missing features which people need
to investigate and tell me about), leaving no dependencies on GNU
libreadline in the base system at the present time.
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
I'm just wanted to suggest a few alternatives. I am a little uneasy
about just-replacing-libreadline, unless we have something which does
replace all of libreadline. My understanding of this libedit-shim is
that it isn't quite a complete replacement. I think we'd want to be
able to switch a component between the real libreadline and this
libedit-shim version. The base system would not include libreadline,
but if someone added it from ports then they wouldn't have to worry
about the real-version changing how the system-components worked.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
On Tue, Jul 17, 2001 at 01:23:44PM -0400, Garance A Drosihn wrote:
Okay. So it sounds like there's a shim to libedit which would be
the API replacement for libreadline. Could we call that something
cute like 'libreadlinele' ('le' for 'libedit') or 'libeditrl', but
leave libreadline as a separate port?
How about 'libedit'? :) I could live with that; it's just some
makefile changes.
Kris
PGP signature
Re: ncurses: 4.x - 5.x buildworld failure + patch
On Mon, 16 Jul 2001, John Polstra wrote:
While upgrading an old (October 2000) -current system which did not
have a libc.so.5 yet, I ran into this failure in src/lib/ncurses:
cc -o make_keys -nostdinc -O -pipe -mcpu=ev56 -mcpu=ev56 -I. -I/c/src/lib/libncurses
-I/c/src/lib/libncurses/../../contrib/ncur
ses/ncurses -I/c/src/lib/libncurses/../../contrib/ncurses/include -Wall
-DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/
usr/obj/c/src/alpha/usr/include
/c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/make_keys.c
./make_keys /c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/keys.list
init_keytry.h
/usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
*** Error code 1
I am reasonably sure the same problem would occur in trying to upgrade
from -stable to -current.
I patched it as shown below and the buildworld was able to finish.
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libncurses/Makefile,v
retrieving revision 1.51
diff -u -r1.51 Makefile
--- Makefile2001/06/12 01:14:02 1.51
+++ Makefile2001/07/16 15:24:59
@@ -330,10 +330,10 @@
build-tools: make_hash make_keys
make_keys: make_keys.c names.c curses.h ncurses_def.h
- ${CC} -o $@ ${CFLAGS} ${NCURSES}/ncurses/tinfo/make_keys.c
+ ${CC} -o $@ -static ${CFLAGS} ${NCURSES}/ncurses/tinfo/make_keys.c
make_hash: comp_hash.c hashsize.h curses.h ncurses_def.h
- ${CC} -o $@ ${CFLAGS} -DMAIN_PROGRAM \
+ ${CC} -o $@ -static ${CFLAGS} -DMAIN_PROGRAM \
${NCURSES}/ncurses/tinfo/comp_hash.c
# ./configure generated
I have used essentially the same patch (with ${LDFLAGS} instead of
-static) for a year or two, but I don't quite understand why you needed
it. make_keys and make_hash are build-tools, so they should get built
in the host environment and be linked to the host shared libraries (if
any). The command line seems to show them being built in the target
environment (-I/usr/obj/c/src/alpha/usr/include). The -mcpu stuff
also seems to be a problem (but not here). I think we use the new
bsd.cpu.mk even for building tools. It might not work on old hosts.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel with SSE is unstable
Good.
I want all use of the cpu number removed. It seems to be just to avoid
alignment problems that shouldn't happen in practice (the save area
should always be suitably aligned if it isn't already, and I think it
is already).
The pcb_save area has the proper alignment but the dummy variable used
in npxinit might not have the proper alignment when on the stack.
The enclosed patch should be a step in the right direction.
- Tor Egge
Index: sys/i386/isa/npx.c
===
RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v
retrieving revision 1.105
diff -u -r1.105 npx.c
--- sys/i386/isa/npx.c 2001/07/16 06:00:23 1.105
+++ sys/i386/isa/npx.c 2001/07/16 16:54:13
@@ -564,7 +564,7 @@
npxinit(control)
u_short control;
{
- union savefpu dummy;
+ static union savefpu dummy;
critical_t savecrit;
if (!npx_exists)
@@ -926,30 +926,21 @@
fpusave(addr)
union savefpu *addr;
{
- static struct savexmm svxmm[MAXCPU];
- u_char oncpu = PCPU_GET(cpuid);
if (!cpu_fxsr)
fnsave(addr);
- else {
- fxsave(svxmm[oncpu]);
- bcopy(svxmm[oncpu], addr, sizeof(struct savexmm));
- }
+ else
+ fxsave(addr);
}
static void
fpurstor(addr)
union savefpu *addr;
{
- static struct savexmm svxmm[MAXCPU];
- u_char oncpu = PCPU_GET(cpuid);
-
if (!cpu_fxsr)
frstor(addr);
- else {
- bcopy(addr, svxmm[oncpu], sizeof (struct savexmm));
- fxrstor(svxmm[oncpu]);
- }
+ else
+ fxrstor(addr);
}
#ifdef I586_CPU_XXX
Re: pxeboot doesn't work anymore
I use FreeBSD 5.0. Falco Krepel wrote: I use the 3COM 3C905c TX-M with bootrom (PXE v2.20, MBA v4.30). Some time after 2001-05-14 the pxeboot is not working anymore. I have the following behavior: 1. The client gets his IP address and bootfile with DHCP. 2. TFTP starts with downloading the pxeboot and after approximatly 1 kbyte it stops and on the entire display, colored and flashing characters appear. I have no idea where the problem could be, because the pxeboot changes are only minor changes. Maybe somebody could help me. Thanx, Falco -- Falco KrepelPhone: +49-(0)30 - 34 63 - 7 276 GMD-FOKUS Fax:+49-(0)30 - 34 63 - 8 276 Kaiserin-Augusta-Allee 31 e-mail: [EMAIL PROTECTED] 10589 BerlinWWW:http://www.fokus.gmd.de/usr/krepel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel with SSE is unstable
On Tue, 17 Jul 2001 [EMAIL PROTECTED] wrote:
I want all use of the cpu number removed. It seems to be just to avoid
alignment problems that shouldn't happen in practice (the save area
should always be suitably aligned if it isn't already, and I think it
is already).
The pcb_save area has the proper alignment but the dummy variable used
in npxinit might not have the proper alignment when on the stack.
I see. __attribute__((__^H^Haligned(16))) doesn't actually work even for
gcc because we use -mpreferred-stack-boundary=2 for the kernel.
The dummy variable should go away for other reasons: the dummy npxsave()
has no effect except possibly for the first call (from npxattach()) and
the second call (for the first call from setregs()). For subsequent
calls from setregs(), the state must have already been saved in the pcb
of the previous owner of the CPU, or else we would be stealing the state
from the current owner.
The enclosed patch should be a step in the right direction.
Yes, please commit it.
@@ -926,30 +926,21 @@
fpusave(addr)
union savefpu *addr;
{
- static struct savexmm svxmm[MAXCPU];
- u_char oncpu = PCPU_GET(cpuid);
if (!cpu_fxsr)
fnsave(addr);
- else {
- fxsave(svxmm[oncpu]);
- bcopy(svxmm[oncpu], addr, sizeof(struct savexmm));
- }
+ else
+ fxsave(addr);
}
I like to use the conditional operator for simple conditionals like this:
(cpu_fxsr ? fxsave : fnsave)(addr);
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ncurses: 4.x - 5.x buildworld failure + patch
In article [EMAIL PROTECTED],
Bruce Evans [EMAIL PROTECTED] wrote:
On Mon, 16 Jul 2001, John Polstra wrote:
While upgrading an old (October 2000) -current system which did not
have a libc.so.5 yet, I ran into this failure in src/lib/ncurses:
cc -o make_keys -nostdinc -O -pipe -mcpu=ev56 -mcpu=ev56 -I.
-I/c/src/lib/libncurses
-I/c/src/lib/libncurses/../../contrib/ncur
ses/ncurses -I/c/src/lib/libncurses/../../contrib/ncurses/include -Wall
-DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/
usr/obj/c/src/alpha/usr/include
/c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/make_keys.c
./make_keys /c/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/keys.list
init_keytry.h
/usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
[...]
I have used essentially the same patch (with ${LDFLAGS} instead of
-static) for a year or two, but I don't quite understand why you needed
it. make_keys and make_hash are build-tools, so they should get built
in the host environment and be linked to the host shared libraries (if
any). The command line seems to show them being built in the target
environment (-I/usr/obj/c/src/alpha/usr/include).
In my case, make_keys was built once in the build tools phase. Then
in the building libraries phase, it was rebuilt 4 times and executed
successfully after each rebuild. Finally, in the make dependencies
phase, it was built yet again. It was in that phase that executing it
failed.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
