Re: ld-elf.so.1 (or VM?) weirdness
John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Maxim Sobolev <[EMAIL PROTECTED]> wrote: > > > For a quite long time I searched for the way to reproduce this bug, > > and it seems that I've finally found how to do it. In most cases > > attempt to make any port on a freshly booted system stops with: > > > > /usr/libexec/ld-elf.so.1: /usr/bin/awk: Shared object has no run-time symbol > > table > > > > but when I'm trying to run make again with the same port it works > > flawlessly. > > I haven't heard any other reports of this. I'm almost certain it is > caused by something outside the dynamic linker -- probably a kernel > bug. The debugging output you included shows evidence that the > dynamic linker is seeing garbage when it mmaps your executable. The > fact that it works OK after the first attempt also points to the VM > system as the culprit. The dynamic linker hasn't changed much > recently, but the kernel has changed a lot. Ok, but why it affects only linker and what in your opinion best course of actions would be to reveal reason of this misbehaviour? -Maxim -- "We believe in the Power and the Might!" (Manowar, 1996) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-stable to -current
trying to take a system from stable to current. o cvsup current o try makeworld but get cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_ashrsi3 -o _ashrsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Error code 140 *** Error code 140 *** Error code 140 *** Error code 140 *** Error code 140 *** Error code 140 cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_ashlsi3 -o _ashlsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c Bad system call - core dumped *** Error code 140 Bad system call - core dumped *** Error code 140 o so build -current binary for config o update kernel config file to -current o config a -current kernel o make a -current kernel o install -current kernel o reboot o crash in init after configuring network, but was too fast to capture o but i think that the last line of the boot tells the story, see below so what's the upgrade path? randy 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 #0: Thu Oct 28 22:40:51 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/RIP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff real memory = 134205440 (131060K bytes) avail memory = 127012864 (124036K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc02e6000. Pentium Pro MTRR support enabled ccd0-5: Concatenated disk drivers npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 16 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: unexpected tag 14 isa0: on isab0 chip1: at device 4.1 on pci0 chip2: irq 19 at device 4.2 on pci0 Timecounter "PIIX" frequency 3579545 Hz chip3: at device 4.3 on pci0 ahc0: irq 19 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: irq 19 at device 9.0 on pci0 fxp0: Ethernet address 00:a0:c9:df:c8:4e pci0: unknown card (vendor=0x109e, dev=0x036e) at 10.0 irq 18 pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18 fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A wl0 at port 0x300-0x30f irq 7 on isa0 wl0: address 08:00:6a:2b:dd:cb, NWID 0x pcm0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 unknown0: at port 0x200-0x207 on isa0 unknown1: at port 0x620-0x623 on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 wl0 XXX: driver didn't set ifq_maxlen Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! Creating DISK da0 Creating DISK da1 sa0 at ahc0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) Creating DISK cd0 Creating DISK cd1 changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (924 512 byte sectors: 255H 63S/T 553C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4340MB (924 512 byte sectors: 255H 63S/T 553C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: cd present [140956 x 2048 byte records] link_elf: symbol curproc undefined To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bogus libncp header installation
`make beforeinstall' in libncp corrupts the source tree (or fails with EROFS) in the SHARED=symlinks case. It installs headers in /usr/include/netncp -> ../../sys/netncp. Headers that belong in should just be in the source tree for netncp. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ARP Failure
I'm sorry I don't have logs to include with this, but after booting with the current kernel and system (as of Oct 28 14:52), I kept getting arp lookup failures on every address, didn't experience anything else out of the ordinary. Any ideas as to what's wrong? (If you need the actual error messages let me know and I'll recreate them) -- Phil 0. Nature --BEGIN GEEK CODE BLOCK- Version: 3.1 GIT d++ s+:+ a C+++ UB+++ 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-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CMAP2 busy ?
On Thu, 28 Oct 1999, Luoqi Chen wrote: > > ... > > panic: pmap_zero_page: CMAP2 busy > > > It looked like an interrupt hit when the cpu was in an idle loop replenishing > zero filled pages, and the interrupt handler somehow also tried to zero some > pages itself. In vm_page_zero_idle(), pmap_zero_page should be called > at splvm() to prevent this from happening, or allocate another pte exclusively > for the idle loop. The latter seems to be preferable. It is an error to use CMAP2 in an interrupt handler. CMAP2 is reserved for use in process and trap context. E.g., it is used in pmap_copy_page() which is often called from vm_fault() without any spl protection. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VESA module breaks USB?
I just upgraded my play machine from a month-old or so -current, and I've found that my OHCI-based USB controller fails to probe correctly iff the VESA module is loaded. I present the two sets of boot messages, in unidiff format. --- /tmp/dmesg.good Thu Oct 28 18:08:44 1999 +++ /tmp/dmesg.bad Thu Oct 28 18:06:30 1999 @@ -1,348 +1,361 @@ 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 #0: Thu Oct 28 21:10:03 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/LION-AROUND -Calibrating clock(s) ... TSC clock: 166193070 Hz, i8254 clock: 1193182 Hz +Calibrating clock(s) ... TSC clock: 166192685 Hz, i8254 clock: 1193179 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium/P54C (166.19-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 100663296 (98304K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) -0x0031e000 - 0x05ffbfff, 97378304 bytes (23774 pages) +0x00324000 - 0x05ffbfff, 97353728 bytes (23768 pages) sio0: gdb debugging port -avail memory = 94334976 (92124K bytes) +avail memory = 94310400 (92100K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f7d60 bios32: Entry = 0xf77b0 (c00f77b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x77e0 pnpbios: Found PnP BIOS data at 0xc00fbd20 pnpbios: Entry = f:bd50 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: ACPI: -Preloaded elf kernel "kernel" at 0xc0305000. +Preloaded elf kernel "kernel" at 0xc030b000. +Preloaded elf module "vesa.ko" at 0xc030b0a8. Intel Pentium detected, installing workaround for F00F bug +VESA: information block +56 45 53 41 02 01 9e 4b 00 c0 00 00 00 00 c8 4b +00 c0 40 00 00 00 00 00 00 00 00 00 00 00 00 00 +00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +VESA: 32 mode(s) found +VESA: v1.2, 4096k memory, flags:0x0, mode table:0xc00c4bc8 (c0004bc8) +VESA: Number Nine Visual Technology Corporation Math emulator present pci_open(1): mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12508086) -npx0: on motherboard -npx0: INT 16 interface -i586_bzero() bandwidth = 173550850 bytes/sec -bzero() bandwidth = 736377025 bytes/sec apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 +npx0: on motherboard +npx0: INT 16 interface +i586_bzero() bandwidth = 173520735 bytes/sec +bzero() bandwidth = 736919675 bytes/sec pci_open(1): mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12508086) pcib0: on motherboard found->vendor=0x8086, dev=0x1250, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found->vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found->vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[4]: type 1, range 32, base e800, size 4 found->vendor=0x1045, dev=0xc861, revid=0x10 class=0c-03-10, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[0]: type 1, range 32, base fb00, size 12 found->vendor=0x5333, dev=0x883d, revid=0x02 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[0]: type 1, range 32, base f400, size 26 pci0: on pcib0 isab0: at device 7.0 on pci0 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: IRQ11, B: IRQ9, C: disabled, D: disabled MB0: IRQ15, MB1: Trying Read_Port at 203 Trying Read_Port at 243 CTL0042: start dependant CTL0042: adding irq mask 0x20 CTL0042: adding dma mask 0x2 CTL0042: adding dma mask 0x20 CTL0042: adding io range 0x220-0x22f, size=0x10, align=0x1 CTL0042: adding io range 0x330-0x331, size=0x2, align=0x1 CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1 CTL0042: start dependant CTL0042: adding irq mask 0x6a0 CTL0042: adding dma mask 0xb CTL0042: adding dma mask 0xe0 CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20 CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30 CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1 CTL0042: start dependant CTL0042: addi
Re: odd NFS behaviour with DU 4.F client
On 1999-Oct-29 11:03:20 +1000, Matthew Dillon wrote: > Unfortunately, we just don't see these sorts >of panics on Intel boxes all that much because IA32 allows misaligned >accesses. This means there are almost certainly alignment bugs in the >code. You can enable user-mode alignment traps on the IA32. Check out EFLAGS bit 18 and the AM bit in CR0 - unfortunately, it doesn't seem to work for ring 0, 1, 2 so you can't find alignment problems in the kernel. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
Matthew Dillon writes: > :Speaking of NFS changes, there was talk at one time about turning the > :nfsm macros into functions. Is this going to happen? > > No. The nfsm macros have goto's all over the place that jump outside > the macro, and also use local variables declared outside the macro. > Short of rewriting a fairly large hunk of the NFS code entirely it > aint gonna happen. Nobody is contemplating rewriting the code. Exactly why I wasn't going to try to do it myself ;-) But I could have sworn I read somewhere that somebody was planning it. Oh well. > You can use gdb to disassemble the code to locate the exact point where > the panic occured. It is definitely more difficult, but there isn't > much we can do about it. The rpc design tends to keep things aligned > and NFS packet elements tend to be sized such that alignment remains > intact, so if these panics can be tracked down the fixes should be > relatively easy to make. Unfortunately, we just don't see these sorts > of panics on Intel boxes all that much because IA32 allows misaligned > accesses. This means there are almost certainly alignment bugs in the > code. > > -Matt I'm all in favor of having all the developers have alphas so these things get caught early ;-) Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
On 28-Oct-99 Matthew Jacob wrote: > UDP. Local network. Very puzzling. Have you tried a week old kernel? Might be worth the test to see if someone broke something subtle. --- 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
:Speaking of NFS changes, there was talk at one time about turning the :nfsm macros into functions. Is this going to happen? No. The nfsm macros have goto's all over the place that jump outside the macro, and also use local variables declared outside the macro. Short of rewriting a fairly large hunk of the NFS code entirely it aint gonna happen. Nobody is contemplating rewriting the code. :I ask because I've seen occasional unaligned access panics on :FreeBSD/alpha in the client side code. I've only seen them on a :really lossy link (basically a misconfigured duplex on a 100Mb link). :They tend to be in nfs_request (nfs/nfs_socket.c:110) or nfs_readrpc :(nfs/nfs_vnops.c:1093). These are both calls to nfs macros that would :be a lot easier to debug if they weren't macros ;-) : :Thanks, : :Drew :-- :Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin You can use gdb to disassemble the code to locate the exact point where the panic occured. It is definitely more difficult, but there isn't much we can do about it. The rpc design tends to keep things aligned and NFS packet elements tend to be sized such that alignment remains intact, so if these panics can be tracked down the fixes should be relatively easy to make. Unfortunately, we just don't see these sorts of panics on Intel boxes all that much because IA32 allows misaligned accesses. This means there are almost certainly alignment bugs in the code. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
Matthew Dillon writes: > :We have an NFS server setup running an older FreeBSD-current (Wed Jun 30). > :This server exports a filesystem to a number of heterogenous clients. > :On most clients, this filesystem is automounted. > : > :Occasionally, some random Digital UNIX box running 4.0F will partially > :wedge because it's automounter is blocked accessing the FreeBSD > > Lots of bugs have been fixed since then. I recommend upgrading the > server (despite the hassle) and seeing if the problem still occurs. <..> OK, will do. I'm mainly waiting for the next rev of the ata driver The volume this box serves up is a ccd stripe of 4 18GB ide disks attached to multiple Promise controllers. > There should be a response to the rpc either way so my guess is that > it is a server-side bug. OK, thanks. Good to know. Speaking of NFS changes, there was talk at one time about turning the nfsm macros into functions. Is this going to happen? I ask because I've seen occasional unaligned access panics on FreeBSD/alpha in the client side code. I've only seen them on a really lossy link (basically a misconfigured duplex on a 100Mb link). They tend to be in nfs_request (nfs/nfs_socket.c:110) or nfs_readrpc (nfs/nfs_vnops.c:1093). These are both calls to nfs macros that would be a lot easier to debug if they weren't macros ;-) Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/etc pccard.conf.sample
In message <[EMAIL PROTECTED]> Bill Fumerola writes: : There are two versions of the XIRCOM realport multifunc cards, : one that is Cardbus and one that isn't. I have the latter. : if_xe is broken now, BTW. I have at least one Xircom card which I plan to make work, if at all possible, with the new pccard code. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/etc pccard.conf.sample
On Thu, 28 Oct 1999 [EMAIL PROTECTED] wrote: > I have friends who happen to have Xircom multifunc cards (which > _are_ CardBus) - would you guys like me to try and test them? I > can get them long enough to test them out with the newconfig > functionality. There are two versions of the XIRCOM realport multifunc cards, one that is Cardbus and one that isn't. I have the latter. if_xe is broken now, BTW. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/etc pccard.conf.sample
At 01:46 AM 10/27/99 -0700, you wrote: >Are you *SURE* this is CardBus? AFAIK, we don't yet (at least >pre-Warner's new pcic code) support CardBus. Hrmm.. I could have sworn it was a CardBus card: http://www.3com.com/client/mcd/products/3ccfe574btsp.html Perhaps I was just seeing things, sorry. I have friends who happen to have Xircom multifunc cards (which _are_ CardBus) - would you guys like me to try and test them? I can get them long enough to test them out with the newconfig functionality. In retrospect.. I probably confused their cards with mine. :-) >> # 3Com Megahertz 3C574B (3CCFE574BT) > >Isn't this just a rebadged (and slightly tweaked) 3Com 3c574tx? Most likely. Their pccard.conf configurations are very similar. Jun, `pccardc dumpcis` output for you at: http://stimpy.multiweb.net/~dragon/3CCFE574BT.txt I have sup'd my sources and will be remaking world & kernel tonight, I will let you know what happens... -- Will Andrews <[EMAIL PROTECTED]> GCS/E/S @d- s+:+>+:- a--->+++ C++ UB 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? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
:We have an NFS server setup running an older FreeBSD-current (Wed Jun 30). :This server exports a filesystem to a number of heterogenous clients. :On most clients, this filesystem is automounted. : :Occasionally, some random Digital UNIX box running 4.0F will partially :wedge because it's automounter is blocked accessing the FreeBSD Lots of bugs have been fixed since then. I recommend upgrading the server (despite the hassle) and seeing if the problem still occurs. :server's filesystem. Any access to automounted directories will then :cause a process to hang. : :I've noticed that if I do a tcpdump on the FreeBSD NFS server, I see: : :17:48:16.397101 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh :234,2/163298400 "chase" (ttl 30, id 4256) :17:48:36.397144 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh :234,2/163298400 "chase" (ttl 30, id 4310) :17:48:56.397212 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh :234,2/163298400 "chase" (ttl 30, id 4384) :17:49:16.397123 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh :234,2/163298400 "chase" (ttl 30, id 4453) : :These requests go on seemingly forever with no reply from the FreeBSD :NFS server. "chase" is a users' directory in the top level of this :filesystem, and nfsfilesystem/chase/bin is a component of the user :chase's path. :... :The truely interesting thing is that if I type 'mount' on DU4CLIENT, I :DO NOT see the filesystem in question in the mount table! : :If I kill all of chase's process on DU4CLIENT, the automounter :unsticks and all is well. If I then try to access the chase directory Well, there was a bug in nfsrv_create() which caused the server to not reply to an NFS packet. This led to a general revamping of the server side code which may have fixed other rpc's at the same time. Whether fixing that bug solves the problem you are having or not is unknown. :I would guess that the DU4CLIENT has the filehandle cached somewhere, :even though it has unmounted the filesystem. : :My question: Whose fault is this? Should the FreeBSD server be :ignoring requests to a valid filehandle if the client has not mounted :the FS? Should it be returning some sort of error? : :Thanks, : :Drew There should be a response to the rpc either way so my guess is that it is a server-side bug. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
odd NFS behaviour with DU 4.F client
We have an NFS server setup running an older FreeBSD-current (Wed Jun 30). This server exports a filesystem to a number of heterogenous clients. On most clients, this filesystem is automounted. Occasionally, some random Digital UNIX box running 4.0F will partially wedge because it's automounter is blocked accessing the FreeBSD server's filesystem. Any access to automounted directories will then cause a process to hang. I've noticed that if I do a tcpdump on the FreeBSD NFS server, I see: 17:48:16.397101 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh 234,2/163298400 "chase" (ttl 30, id 4256) 17:48:36.397144 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh 234,2/163298400 "chase" (ttl 30, id 4310) 17:48:56.397212 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh 234,2/163298400 "chase" (ttl 30, id 4384) 17:49:16.397123 DU4CLIENT.1946927300 > FREEBSDSERVER.nfs: 188 lookup fh 234,2/163298400 "chase" (ttl 30, id 4453) These requests go on seemingly forever with no reply from the FreeBSD NFS server. "chase" is a users' directory in the top level of this filesystem, and nfsfilesystem/chase/bin is a component of the user chase's path. The truely interesting thing is that if I type 'mount' on DU4CLIENT, I DO NOT see the filesystem in question in the mount table! If I kill all of chase's process on DU4CLIENT, the automounter unsticks and all is well. If I then try to access the chase directory in this filesystem, the DU4CLIENT mounts it & I see this transaction: 18:00:27.725678 DU4CLIENT.1435222468 > FREEBSDSERVER.nfs: 168 lookup fh 234,2/163298400 "chase" (ttl 30, id 9546) 18:00:27.725763 FREEBSDSERVER.nfs > DU4CLIENT.1435222468: reply ok 236 lookup fh 234,2/163298400 DIR 755 ids 1449/107 sz 1024 nlink 21 rdev 134/57475167 fsid 86036d005f nodeid 36d005f a/m/ctime 941102013.00 940944335.00 940944335.00 post dattr: DIR 775 ids 0/107 sz 512 nlink 25 rdev 4/40 fsid 40028 nodeid 28 a/m/ctime 941134393.00 940612206.00 940612206.00 (ttl 64, id 16062) I would guess that the DU4CLIENT has the filehandle cached somewhere, even though it has unmounted the filesystem. My question: Whose fault is this? Should the FreeBSD server be ignoring requests to a valid filehandle if the client has not mounted the FS? Should it be returning some sort of error? Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CMAP2 busy ?
> Hi. > > I've been experiencing problems with my machine crashing when in X, > when idle overnight. > > Normally it panics with XF86_S3. Today however the machine returned > something a little different, which I haven't seen before. > I hope this helps someone. > > The machine worlds with no problems, and is perfectly stable > when in console mode. X has been rebuilt several times. > > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-unknown-freebsd"... > IdlePTD 3559424 > initial pcb at 29d280 > panicstr: pmap_zero_page: CMAP2 busy > panic messages: > --- > panic: pmap_zero_page: CMAP2 busy > It looked like an interrupt hit when the cpu was in an idle loop replenishing zero filled pages, and the interrupt handler somehow also tried to zero some pages itself. In vm_page_zero_idle(), pmap_zero_page should be called at splvm() to prevent this from happening, or allocate another pte exclusively for the idle loop. The latter seems to be preferable. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CMAP2 busy ?
On Thu, 28 Oct 1999, Khetan Gajjar wrote: > #0 boot (howto=256) at ../../kern/kern_shutdown.c:280 > 280 dumppcb.pcb_cr3 = rcr3(); > (kgdb) quit That's useless, every panic will look like that. Please see the handbook's instructions for good debugging tips. -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
Matthew Jacob writes: > > UDP. Local network. Very puzzling. Oh well. So much for a shot in the dark.. -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
UDP. Local network. Very puzzling. On Thu, 28 Oct 1999, Andrew Gallatin wrote: > > Matthew Jacob writes: > > > > Hmm. Could be. That's a good thing to try. The connection is a Full Duplex > > 100BaseT to a 3com switch (both alpha/freebsd && Solaris) so what you > > suggest Just Didn't Occur To Me (tm). Thanks > > > > Is this a UDP or TCP mount? > > I've seen very strange things with TCP mounts of Solaris 2.7 servers > with i386 clients running recent -currents. Things start out just > fine (3-4MB/sec), then after some period of time (a day or 2 > generally), the performance degrades down to a few KB/sec. > > I didn't really have time to look into it properly, so I just switched > all my mounts over to udp & the problem just went away. > > Drew > > -- > Andrew Gallatin, Sr Systems Programmerhttp://www.cs.duke.edu/~gallatin > Duke University Email: [EMAIL PROTECTED] > Department of Computer SciencePhone: (919) 660-6590 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
Matthew Jacob writes: > > Hmm. Could be. That's a good thing to try. The connection is a Full Duplex > 100BaseT to a 3com switch (both alpha/freebsd && Solaris) so what you > suggest Just Didn't Occur To Me (tm). Thanks > Is this a UDP or TCP mount? I've seen very strange things with TCP mounts of Solaris 2.7 servers with i386 clients running recent -currents. Things start out just fine (3-4MB/sec), then after some period of time (a day or 2 generally), the performance degrades down to a few KB/sec. I didn't really have time to look into it properly, so I just switched all my mounts over to udp & the problem just went away. Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cpdup port committed
: :On Tue, Oct 26, 1999 at 08:03:35PM -0700, Matthew Dillon wrote: :> Yes, I'll do a cpdup port too. : :Thanks, Matt! I know plenty of people that will find this useful. : :-- :Jos Backus _/ _/_/_/ "Reliability means never /usr/ports/misc/cpdup now exists! Trek73 will be next... it's a bit more difficult to create a port for. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CMAP2 busy ?
Hi. I've been experiencing problems with my machine crashing when in X, when idle overnight. Normally it panics with XF86_S3. Today however the machine returned something a little different, which I haven't seen before. I hope this helps someone. The machine worlds with no problems, and is perfectly stable when in console mode. X has been rebuilt several times. GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD 3559424 initial pcb at 29d280 panicstr: pmap_zero_page: CMAP2 busy panic messages: --- panic: pmap_zero_page: CMAP2 busy syncing disks... 7 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 done dumping to dev #wd/0x20001, offset 77824 dump 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 boot (howto=256) at ../../kern/kern_shutdown.c:280 280 dumppcb.pcb_cr3 = rcr3(); (kgdb) quit --- Khetan Gajjar (!kg1779) * [EMAIL PROTECTED] http://khetan.os.org.za/ * Talk/Finger [EMAIL PROTECTED] FreeBSD enthusiast* http://www2.za.freebsd.org/ /dev/random output : Nihil est--in vita priore ego imperator Romanus fui. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
Hmm. Could be. That's a good thing to try. The connection is a Full Duplex 100BaseT to a 3com switch (both alpha/freebsd && Solaris) so what you suggest Just Didn't Occur To Me (tm). Thanks On Thu, 28 Oct 1999, Matthew Dillon wrote: > :Okay- I went home and left a cvs update going on /usr/src - reading from > :a local CVSUP repository NFS mounted on /home/ncvs. The server is a > :Sun SS1000 Solaris 2.6 box. 6 hours later, the cvs update is still chugging > :slowly along- top shows cvs as: > : > : PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND > : 275 mjacob 2 0 8704K 7616K sbwait 1:28 1.90% 1.90% cvs > : > :most of the time. Just to check that something wasn't broken for da5, > :I did a test dd writing to a file just now and it happily munched along > :at 4MB/s. > : > :The filesystem *is* a fat block fs: > : > : a: 430489604.2BSD 8192 3276816 # (Cyl.0 - 267*) > : > :I suppose the blockage could be at the ufs end... Anyone have a pointer > :as to what try to narrow this down- mainly to save me the trouble of > :actually thinking about it (got a lot else on mind)? Unacceptably bad > :something or others here. > > This kinda sounds like packet loss to me, causing the NFS link to > back off. This would be true for both a udp or tcp nfs mount, but > tcp tends to be more sensitive to packet loss. > > You should be able to tell by ktrace'ing the running cvs and then > kdump -R'ing the resulting ktrace.out file to see if weird delays are > occuring on nfs-related syscalls. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
:Okay- I went home and left a cvs update going on /usr/src - reading from :a local CVSUP repository NFS mounted on /home/ncvs. The server is a :Sun SS1000 Solaris 2.6 box. 6 hours later, the cvs update is still chugging :slowly along- top shows cvs as: : : PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND : 275 mjacob 2 0 8704K 7616K sbwait 1:28 1.90% 1.90% cvs : :most of the time. Just to check that something wasn't broken for da5, :I did a test dd writing to a file just now and it happily munched along :at 4MB/s. : :The filesystem *is* a fat block fs: : : a: 430489604.2BSD 8192 3276816 # (Cyl.0 - 267*) : :I suppose the blockage could be at the ufs end... Anyone have a pointer :as to what try to narrow this down- mainly to save me the trouble of :actually thinking about it (got a lot else on mind)? Unacceptably bad :something or others here. This kinda sounds like packet loss to me, causing the NFS link to back off. This would be true for both a udp or tcp nfs mount, but tcp tends to be more sensitive to packet loss. You should be able to tell by ktrace'ing the running cvs and then kdump -R'ing the resulting ktrace.out file to see if weird delays are occuring on nfs-related syscalls. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
In article <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> wrote: > > I emailed Peter so as not to create any confusion because he seemed > active at the time, but if either if you could move the file I would > appreciate it! Good, I've just done it. Your best bet for CVS requests is to mail to <[EMAIL PROTECTED]>. That way Peter, Mark, and I will all get it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
: :In article <[EMAIL PROTECTED]>, Matthew :Dillon <[EMAIL PROTECTED]> wrote: : :> The sys.mk adjustment has already been committed. An email has :> been sent to the CVS meisters to get /usr/src/etc/make.conf :> moved. : :Are you sure? I didn't receive anything from you. : :John : John Polstra [EMAIL PROTECTED] I emailed Peter so as not to create any confusion because he seemed active at the time, but if either if you could move the file I would appreciate it! -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lsof + namecache
> > fstat(1) does not have the functionality (that is now missing) that > > people have come to expect from LSOF. > ...which is? Say for instance I want to know which program someone is running (and what libs it is using). fstat does not show the path to the program: obrien communicator-4.7 84460 root / 2 drwxr-xr-x1536 r obrien communicator-4.7 84460 wd /files 500011 drwx--x--x9728 r obrien communicator-4.7 84460 text / 72712 -r-xr-xr-x 13234176 r vs. LSOF: communica 82769 obrien txt VREG 13,131072 13234176 72712 /usr/local/lib/netscape/communicator-4.7.us.bin communica 82769 obrien txt VREG 13,131072 77824 87630 /usr/libexec/ld.so communica 82769 obrien txt VREG 13,131072 292041 143092 /usr/X11R6/lib/aout/libXt.so.6.0 communica 82769 obrien txt VREG 13,131072 79896 143093 /usr/X11R6/lib/aout/libXmu.so.6.0 ... Both tools are useful. As Vic Abell has said: I think lsof and fstat have gradually converged. Each delivers some information the other doesn't but both deliver the same essential information. Probably the most important thing in lsof's favor is that it provides consistent support across multiple UNIX dialects -- Linux, NetBSD, OpenBSD, AIX, HP-UX, SCO OSR, SCO Unixware, and Sun Solaris to name a few. Lsof might have a richer set of command option filters than fstat, and it has an output mode designed for use by post processing scripts and filters. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld problem...
As Peter Jeremy wrote ... > On 1999-Oct-28 07:36:53 +1000, David O'Brien wrote: > >IF you are going to run -CURRENT, you need to read this list. > > And read /usr/src/UPDATING which also warns about this > > >(/me wonders how many MORE times we are going to have to say this because > >of the signal changes...) > > A very large number I suspect. > > IMHO, the correct solution is to for the entire make world process to > be re-worked. I believe the process should always be to boot a new > kernel first (as bde(?) commented - it's much easier to recover from a > broken kernel than a broken world), and then install a new world. > Getting there from here is non-trivial - the major problem being that > our build process does not adequately differentiate between compiling > code that must run now and code that must run with the new kernel. Marcel (the one that hacked on signals ;-) is giving this very subject intensive thought. But it is definitely a lot of work. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lsof + namecache
In the last episode (Oct 28), Garrett Wollman said: > < said: > > > fstat(1) does not have the functionality (that is now missing) that > > people have come to expect from LSOF. > > ...which is? The ability to map a filedescriptor with a filesystem name by digging inside the kernel's namecache: (emssrv5:root) /root># fstat -p 1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root init 1 wd / 2 drwxr-xr-x1024 r root init 1 text /153791 -r-x-- 233472 r (emssrv5:root) /root># lsof -p 1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME init 1 root cwd VDIR 4,131072 1024 2 / init 1 root txt VREG 4,131072 233472 153791 /sbin/init (emssrv5:root) /root># -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ld-elf.so.1 weirdness
In article <[EMAIL PROTECTED]>, Maxim Sobolev <[EMAIL PROTECTED]> wrote: > For a quite long time I searched for the way to reproduce this bug, > and it seems that I've finally found how to do it. In most cases > attempt to make any port on a freshly booted system stops with: > > /usr/libexec/ld-elf.so.1: /usr/bin/awk: Shared object has no run-time symbol > table > > but when I'm trying to run make again with the same port it works > flawlessly. I haven't heard any other reports of this. I'm almost certain it is caused by something outside the dynamic linker -- probably a kernel bug. The debugging output you included shows evidence that the dynamic linker is seeing garbage when it mmaps your executable. The fact that it works OK after the first attempt also points to the VM system as the culprit. The dynamic linker hasn't changed much recently, but the kernel has changed a lot. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
In article <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> wrote: > The sys.mk adjustment has already been committed. An email has > been sent to the CVS meisters to get /usr/src/etc/make.conf > moved. Are you sure? I didn't receive anything from you. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lsof + namecache
< said: > fstat(1) does not have the functionality (that is now missing) that > people have come to expect from LSOF. ...which is? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lsof + namecache
On Thu, Oct 28, 1999 at 10:52:30AM -0400, Garrett Wollman wrote: > > The lsof functionality should in my opinion be added to the system, > > and the necessary hooks should be added to the kernel using sysctl. > > fstat(1). fstat(1) does not have the functionality (that is now missing) that people have come to expect from LSOF. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lsof + namecache
< said: > The lsof functionality should in my opinion be added to the system, > and the necessary hooks should be added to the kernel using sysctl. fstat(1). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Solidão
Solidão "Você não pode estar só se gostar da pessoa com quem fica quando esta sozinho." - Wayne Dyer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ld-elf.so.1 weirdness
Hi there, For a quite awhile I'm observing strange problems with dynamic loader (ld-elf). On my -current system (last 'suped and compiled several hours ago) I often observed the following error message: /usr/libexec/ld-elf.so.1: /usr/bin/foobar: Shared object has no run-time symbol table where foobar can be virtually any dynamically linked binary. For a quite long time I searched for the way to reproduce this bug, and it seems that I've finally found how to do it. In most cases attempt to make any port on a freshly booted system stops with: /usr/libexec/ld-elf.so.1: /usr/bin/awk: Shared object has no run-time symbol table but when I'm trying to run make again with the same port it works flawlessly. I've compiled rtld-elf with -DDEBUG and produced two debugging logs of two subsequently attempts to run make for one of the ports and attaching it with this message. If any additional info/debugging will be necessary please do not hesitate to contact me. Sincerely, Maxim ldlog.tar.bz2
Re: lsof + namecache
In message <[EMAIL PROTECTED]>, Chuck Rob ey writes: >Lsof is broken. > >I already wrote Poul about it, but he hasn't seen my email yet, I guess. I've been busy, your email is sitting in my inbox somewhere, to be dealt with when I have time. >Does anyone know the direction this was going in, and what visibility the >namecache is intended to have? The namecache is intended to have no visibility from userland. The fact that lsof (with the aid of libkvm) abuses it doesn't change this fact. The lsof functionality should in my opinion be added to the system, and the necessary hooks should be added to the kernel using sysctl. As a short term fix, you can remove the "static", but take this as a first warning: the namecache implementation is NOT an API. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NOT! KDE 1.1.2 package for current seems broken
Hi ... It seems that the qt-1.42 package of current is different than that of the 3.3. packages ... I just installed the current version of qt-1.42 and now kde 1.1.2 is working fine ... Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KDE 1.1.2 package for current seems broken
Hi ... Anyone tried to install the KDE 1.1.2 current package ?? I tried to install this and it would not startup, it complained about undefined symbols. I searched for these symbols and found them in libqt2.so.2 ... I installed this and tried to start KDE again, it then complained about symbols only found in libqt.so.2 (qt 1.42) The executables are only linked to libqt.so.2 (qt 1.42)... It seems that it is looking for both libraries which is wrong ?? Anyone got this working ?? Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
really draggy NFS access in -current?
I have the following setup for an alpha PC164 running a current -current (as in a kernel from the last day): farrago.feral.com > mount /dev/da0a on / (ufs, local, writes: sync 608 async 3306) procfs on /proc (procfs, local) mfs:30 on /tmp (mfs, asynchronous, local, writes: sync 2 async 7) bird:/export/home on /home (nfs) bird:/home/ncvs on /home/ncvs (nfs) bird:/space5/freebsd/FreeBSD-current/sys on /space/sys (nfs) bird:/space5/freebsd/FreeBSD-CVS on /cvs-src/FreeBSD-CVS (nfs) bird:/space5/freebsd/distfiles on /usr/ports/distfiles (nfs) /dev/da6a on /usr/obj (ufs, local, soft-updates, writes: sync 2 async 1) /dev/da5a on /usr/src (ufs, local, soft-updates, writes: sync 2 async 19415) Okay- I went home and left a cvs update going on /usr/src - reading from a local CVSUP repository NFS mounted on /home/ncvs. The server is a Sun SS1000 Solaris 2.6 box. 6 hours later, the cvs update is still chugging slowly along- top shows cvs as: PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 275 mjacob 2 0 8704K 7616K sbwait 1:28 1.90% 1.90% cvs most of the time. Just to check that something wasn't broken for da5, I did a test dd writing to a file just now and it happily munched along at 4MB/s. The filesystem *is* a fat block fs: a: 430489604.2BSD 8192 3276816 # (Cyl.0 - 267*) I suppose the blockage could be at the ufs end... Anyone have a pointer as to what try to narrow this down- mainly to save me the trouble of actually thinking about it (got a lot else on mind)? Unacceptably bad something or others here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld problem...
Peter Jeremy wrote: > > >(/me wonders how many MORE times we are going to have to say this because > >of the signal changes...) > > A very large number I suspect. > > IMHO, the correct solution is to for the entire make world process to > be re-worked. That's what I'm currently doing. If I have a stripped down make process ready for public viewing, I'll let you all know. A thread on the subject can be found in the -arch archives. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
