Re: Library question/challenge
* John Polstra ([EMAIL PROTECTED]) [990731 09:28]: Jeroen Ruigrok/Asmodai wrote: * John Polstra ([EMAIL PROTECTED]) [990729 18:49]: Right. So the problem must be that you have LD_LIBRARY_PATH set. Yes I have, but this hasn't been a problem for the last 5-6 months. In what way could it interfere with my ldconfig then? (I read man 1aout ld) It won't intefere with ldconfig, but it will affect what the dynamic linker does. If you have "/usr/lib" in your LD_LIBRARY_PATH then the dynamic linker will find libc there, rather than in "/usr/lib/aout" as it should. Ah, ok, I was thinking in the wrong direction. The main reason I stuck LD_LIBRARY_PATH in there is because of Qt. If ldconfig paths are configured ok, will these replace LD_LIBRARY_PATH or would I have to adjust Makefiles/configures in order to point to the libraries present on this system? I don't know why it didn't cause problems for you earlier. Well, I am glad it broke... Because else I would still be using this. This was netscape, right? If so, there's an easy fix. The command that you execute for netscape is really a shell script which does some stuff and then executes a big binary somewhere else. You could add "unset LD_LIBRARY_PATH" to that shell script to work around the problem. Mayhaps, but I would rather tackle the whole of this challenge instead of just a subset. I mean if this LD_LIBRARY_PATH I set is a bad thing to do I want to learn the ways how to best do it instead. -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic plus advice needed
* Greg Lehey ([EMAIL PROTECTED]) [990731 03:50]: On Saturday, 31 July 1999 at 0:19:27 +0200, Jeroen Ruigrok/Asmodai wrote: * Greg Lehey ([EMAIL PROTECTED]) [990730 11:23]: On Friday, 30 July 1999 at 8:45:32 +0200, Jeroen Ruigrok/Asmodai wrote: The first thing you should do with any dump is a backtrace (bt). The appearance depends on how you got there. Since you appear to have gone via ddb, your dump should look something like this: (kgdb) bt #0 0xc0155f14 in boot () #1 0xc0156249 in panic () #2 0xc01e737b in ffs_mapsearch () #3 0xc01e5cea in ffs_alloccg () #4 0xc01e5756 in ffs_hashalloc () #5 0xc01e4adc in ffs_alloc () #6 0xc01e7af0 in ffs_balloc () #7 0xc01f0a5c in ffs_write () #8 0xc01827ce in vn_write () #9 0xc01623ac in dofilewrite () #10 0xc01622bb in write () #11 0xc0225066 in syscall () #12 0xc02192b6 in Xint0x80_syscall () #13 0x807d24a in ?? () #14 0x807666d in ?? () Hmm, that doesn't look like a dump from ddb. Did you have DDB_UNATTENDED set? No, just options DDB. This bt was obtained after doing gdb -k kernel.0 vmcore.0 I still have the DDB trace on paper which I can type in if needed/wanted. What you do with the results depends a lot on what you find. On the whole, I wouldn't think it worth the pain of debugging without symbols. No it isn't... I just made world and am building two kernels now (one with and one without debug info) so that the next time something happens like that I am prepared. Thanks anyways for the help Greg, this will surely help some parts of the PDP, hope I get some stuff in there about this sort of thing today. 'gards, -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldload (module parameters ??)
Nicolai Petri wrote: Would it be possible and wise to implement a way to pass parameters to modules when they are loaded ?? Like "kldload if_olp -recv_debug" ? This message might be over two months old, but hey... :-) Modules can receive parameters when loaded through loader(8). It would make sense that this capability were also present on kldload. One good reason not to do it this way: we want modules to be loadable-on-demand. Of course, there are all sorts of modules that wouldn't make sense to be demand-loadable, and, thus, would be perfectly all right with parameters. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
network got stuck during high nfs-load
Hi driver gurus,
Today I had heavy NFS-load on my CURRENT-SMP machine while compiling
world. Suddenly all NFS-Clients stopped working. I was't able to ping
the server from inside my /29 subnet, same with ping the others from
the server itself. I changed cables, plugged them in and out, did some
ifconfig up down, deleted routes and added them again ... nothing. But
the card was still sending from time to time (once a second) with 100%
load many 0 bytes - like some waves:
(tcp-dump from same subnet, MAC Adress 0:a0:cc:66:32:97 is the NFS-Server)
--
13:53:41.673733 0:a0:cc:66:32:97 0:a0:cc:66:32:97 null test/C len=43
00
13:53:41.773706 0:a0:cc:66:32:97 0:a0:cc:66:32:97 null test/C len=43
00
It looks like a endless loop somewhere in the de0-driver ...
I was able to ping the machine from itself via loopback and via the local
ip. No stucked processes at all, the running make buildworld was still
running. Also the load was normal, I couldn't see some special behaviour ...
I paniced the server and made a crashdump. If anybody is interested in
this strange behaviour, just write me back ... After a reboot, all worked
again, but that's not a good solution ;)
Martin
PS: cvsup is from yesterday (30.7.1999) at 22:00 CET and I included
a backtrace and a dmesg from my server ...
backtrace from debug.kernel
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:291
#1 0xc01538c9 in panic (fmt=0xc0277c14 "from debugger")
at ../../kern/kern_shutdown.c:505
#2 0xc012df19 in db_panic (addr=-1071398025, have_addr=0, count=-1,
modif=0xff80dddc "") at ../../ddb/db_command.c:434
#3 0xc012deb7 in db_command (last_cmdp=0xc02a6f30, cmd_table=0xc02a6d90,
aux_cmd_tablep=0xc02c572c) at ../../ddb/db_command.c:334
#4 0xc012df7e in db_command_loop () at ../../ddb/db_command.c:456
#5 0xc012ffbb in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc023c0c2 in kdb_trap (type=3, code=0, regs=0xff80ded0)
at ../../i386/i386/db_interface.c:157
#7 0xc02524a0 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi
= 0,
tf_esi = -1070741376, tf_ebp = -8331496, tf_isp = -8331524,
tf_ebx = -1070741376, tf_edx = -1070689184, tf_ecx = 16777217,
tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071398025, tf_cs
= 8,
tf_eflags = 582, tf_esp = -1071030749, tf_ss = -1071045718})
at ../../i386/i386/trap.c:534
#8 0xc023c377 in Debugger (msg=0xc02923aa "manual escape to debugger")
at machine/cpufunc.h:64
#9 0xc0236d7c in scgetc (sc=0xc02c3ca0, flags=2)
at ../../dev/syscons/syscons.c:3813
#10 0xc0232529 in sckbdevent (thiskbd=0xc02db0a0, event=0, arg=0xc02c3ca0)
at ../../dev/syscons/syscons.c:688
#11 0xc022bd77 in atkbd_intr (kbd=0xc02db0a0, arg=0x0)
at ../../dev/kbd/atkbd.c:535
#12 0xc02692d7 in atkbd_isa_intr (arg=0xc05a2100) at
../../isa/atkbd_isa.c:125
dmesg-output
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #1: Fri Jul 30 21:31:06 CEST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/FUCHUR
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium/P55C (586-class CPU)
Origin = "GenuineIntel" Id = 0x543 Stepping = 3
Features=0x8003bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,MMX
real memory = 67108864 (65536K bytes)
avail memory = 61652992 (60208K bytes)
Programming 24 pins in IOAPIC #0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0
cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc034.
Intel Pentium detected, installing workaround for F00F bug
Probing for PnP devices:
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge on motherboard
pci0: PCI bus on pcib0
isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0
ide_pci0: Intel PIIX3 Bus-master IDE controller at device 7.1 on pci0
de0: Digital 21140A Fast Ethernet irq 17 at device 9.0 on pci0
de0: 21140A [10-100Mb/s] pass 2.0
de0: address 00:a0:cc:66:32:97
vga-pci0: Matrox MGA 1024SG/1064SG/1164SG graphics accelerator irq 18 at
device 10.0 on pci0
ahc0: Adaptec aic7880 Ultra SCSI adapter irq 19 at device 12.0 on pci0
ahc0: Using left over BIOS settings
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
isa0: ISA bus on motherboard
fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO
Re: RE: network got stuck during high nfs-load
The way I usually handle pseudo users via sendmail is to route them via a dummy subdomain. So, for example, my main server is 'apollo.backplane.com'. I route mail destined for 'pop.apollo.backplane.com' to my special pop mail backend. My /etc/aliases and other forwarding tables then simply map the usernames that I want to route to the dummy domain. For example, the pop user 'fubar' would be mapped to '[EMAIL PROTECTED]', where 'fubar' does not exist in the password file or anything like that. In sendmail, it is a simple addition to ruleset 98: R$+ + $* @ pplus . $=w $* $#popplus $: $1 @ pplus . $3 $4 R$+ + $* @ pplus . $=w . $* $#popplus $: $1 @ pplus . $3 $4 R$* @ pplus . $=w $*$#popplus $: $1 @ pplus . $2 $3 R$* @ pplus . $=w . $* $#popplus $: $1 @ pplus . $2 $3 And then add the new mailer: Mpopplus, P=/usr/local/bin/dpopmail, F=SDEFhlMsu, S=10/30, R=20/40, U=dpop, A=dpopmail $u -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sitting inside, looking out...
We have repeatedly heard that -core's communication with the developers leaves something to be desired, so I'll venture this attempt at improving it. This email is NOT a official statement from core, it is MY PERSONAL attempt, as a core member, at improving communication between core and the developers. I will try to represent the consensus -core as faithfully as I can, but make no mistake: this is seen through my glasses. 1. Core decisions - A lot of you have been asking for -core direction and decisions on various issues, and mostly you didn't get any such thing. It seems that is the way the core team as such wants things to be. I think the best way to express it is that the core team sees itself as a supreme court, not as a governing board: We only act when all other avenues of closure have failed. Think of it as "gigamanagement" rather than "micromanagement". In general the core team doesn't make more than a handful of decisions a year (that is not counting appointing committers) and there isn't resonance in -core for changing this level of activity. So how are things decided in this project if not by -core ? Well, working code speaks loud and clear, thats for sure, but otherwise it happens exactly the way you see it: people discuss things in the mailing lists and try to reach agreement. But if you want to get a core decision on something, make sure that you send an email to [EMAIL PROTECTED] with the question. You cannot expect any reaction from -core by posing the question in some random maillist. Make sure to include sufficient background and references to the subject, at least half of the core members have not heard of the discussion before. And please use a distinctive subject on your emails, "proposal for new committer" is a distinctively bad subject line, much better would be "Samuel B. Morse for committer ?" In the past -core has not been very good at even answering emails, but I have been trying to improve that by assuming a self-styled secretary function: as best I can I try to keep track of outstanding items and make sure they don't fall through the cracks. If you don't get a response from -core, nag me with an email, and I will try to make it happen. 2. Who are the committers anyway ? -- All the noise about Matt Dillons commit bit have generated a lot of questions about who gets to be committers, so here is a little insight into the process of appointing a committer: Generally we in core operate with three kinds of committers: Ports committers These are people who maintain one or more ports. If Asami-san wants to glue a bit on somebody, we will generally let him. Limited scope committers These are people who maintain some specific bit of the tree, typically a subsystem they are (co-)authors of. A good example is the HARP ATM stack, which Mike Spengler is taking care of (and many thanks for that Mike!) Since these people are taken on board with a explicitly stated limited scope, we are more relaxed about them than we are about the last category. People have been known to successfully sneak out from this category and into: Committers at large These are the people who persist in sending well documented PRs containing correct patches. The only way we have devised so far for ridding ourselves of this kind of annoying behaviour is to say "Here! you're a committer, now close your own PRs!" :-) For all these three categories some general rules apply, or rather if they apply the answer is a resounding "no": Flaming people and generally presenting the attitude that people who don't agree with you should leave the planet on the first available rocket (or otherwise), is the most reliable way to not pass the muster. It doesn't matter how good you are technically, if you can't work in a group, your not in this particular group. Being unresponsive to input is another good way to fall through. Some of the people are right 99.994% of the time, but nobody is right 100% of the time. If people point out to you that something you did or said isn't right, listen to them, think about it more than once, they could be right. [even Bruce has been caught on the wrong foot once, that's where I got the 99.994% figure from :-) ] Wasting peoples time. We're all here on borrowed time, most of us have jobs, families, cats, houses, you name it, things that also have legitimate claims to our time. Needlessly wasting peoples time is not welcome, in particular when it is their spare time. If you match any of these descriptions, and if you have proved that you can code or document, and have some time to spare, you'll pass the muster, no worries. And don't despair: we generally appoint a "mentor" for all new committers.
Recent -CURRENT doesn't show process times on some hardware
For about a week now, I've been tracking -CURRENT on two machines,
panic and mojave, building world almost daily. On mojave, a number of
process timing functions have not been working at all during this
time, though panic has no problems. For example:
$ cat loop.c
main ()
{
while (1);
}
$ make loop
cc loop.c -o loop
$ loop
[1] 54987
$ ps up54987
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
grog 54987 0.0 0.2 756 224 p2 R 1:20PM 0:28.98 loop
$ ps up54987
In other words, though the process is looping in user state, ps shows
no CPU usage, though the process time is being counted relatively
correctly.
Also,
$ time loop
Terminated [killed from another xterm]
real0m15.136s
user0m0.000s
sys 0m15.040s
Here the time has been attributed to the system, though it's all in
user space.
top shows:
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle
Mem: 47M Active, 8284K Inact, 30M Wired, 6812K Cache, 9530K Buf, 576K Free
Swap: 256M Total, 192K Used, 256M Free
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
54999 grog 28 0 756K 224K RUN 0:15 0.00% 0.00% loop
The CPU timing information is always 0.0% for everything.
vmstat shows:
r b w avm fre flt re pi po fr sr wd0 wc0 in sy cs us sy id
1 1 09228 7284 112 0 0 0 133 11 0 0 131 230 23 0 0 0
1 1 09228 72804 0 0 0 0 0 0 0 106 43 24 0 0 0
What makes this all the more puzzling is that it happens only on one
machine. Hint: it's a laptop (Dell Latitude CPi). panic is a normal
Pentium machine of no particular lineage. Does this ring a bell with
anybody?
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Assembler capable of supporting 3dnow!
I'm messing around with the latest mesa and have discovered (suprise)that our assembler doesn't support 3dnow instructions. Are there any plans to update to a version of binutils that does? Linux's stuff appears to support it. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
