Re: Memory Mangement Problem in 5.1-RELEASE
Jeremy Messenger wrote: > Well, the 5.0, old -CURRENT and 4.8 have never touch the swap, until 5.1- > CURRENT. My system has 256mb ram and it's always touch swap now. If I > compile some stuff, sometime it will get around 300mb swap. Current, I only > have Gnome 2.3.x and Opera running, so what my top looks like this: The new gcc is a pig. So is the new Gnome. What if you install the old Gnome from 5.0 on your system? You probably can't get away with the old gcc, since the binary format changed For No Good Reason(tm). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Jeremy Messenger wrote: > Well, it still should not touch the swap since I have very few stuff > running with 256mb ram. I just reboot and start with Gnome 2.3.x and Opera, > then doing the update (compile/install) gnome-panel. Now, it's already use > the swap in minutes and later hours I will get more mbs or swap. 1) He's running Gnome 2.2, not 2.3.x 2) The version is probably less important than the compiler that was used to compile it 3) Start looking at free memory with only the kernel being different between the tests, instead of changing all sorts of variabls at once, or you'll never convince anyone that what you think is the problem is actually the problem -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
Adrian Chadd wrote: > Will any releases of MacOS X have the "full 64 bit" code? > > Will Darwin ever be released with the "full 64 bit" code? I don't know; you could always ask Jordan. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic while reading ntfs partition
On Fri, Jul 25, 2003 at 12:33:28PM +1000, Tim Robbins wrote: > On Thu, Jul 24, 2003 at 02:14:20PM +0200, Karel J. Bosschaart wrote: > > > Not sure if this is useful, but I'm getting a perfectly reproducible > > panic when doing 'grep -R foo .' (as normal user) in a read-only > > mounted ntfs partition on a -current as of ~3 weeks ago: > > > [...] > > Panicstring: bundirty: buffer 0xc72d9868 still on queue 2 > [...] > > Thanks for the report - I thought I'd already fixed this problem. Would you I checked that I have indeed the latest version of ntfs_subr.c (1.30). > mind trying the attached patch? It seems to fix the problem for me, but > grep uses an awful lot of memory in the process (perhaps it's trying to > read a "line" from the pagefile containing mostly zeroes.) > Fixed for me as well, thanks! The grep ends now with 'grep: memory exhausted' after a while, but previously the machine would freeze immediately after entering the command and reboot some time later. Karel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Gaim Crashing X
Hi All, I've beenfinding that when running gaim that its causing X to crash back down to the shell prompt. This has happened with both vesa, nv and nvidia drivers. Doing a latest buildworld still hasn't helped. Anyone got any insite in to this? Rgds Rus -- www: http://jvds.com | Virtual Servers from just $15/mo MSNM: [EMAIL PROTECTED] | Totally Customizable Technology e: [EMAIL PROTECTED] | FreeBSD & Linux 10% donation to FreeBSD.org on each purchase ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Gaim Crashing X
On Fri, 2003-07-25 at 06:33, Rus Foster wrote: > I've beenfinding that when running gaim that its causing X to crash back > down to the shell prompt. This has happened with both vesa, nv and nvidia > drivers. Doing a latest buildworld still hasn't helped. Anyone got any > insite in to this? This is more of an anecdote than anything else, since I don't have any systems running -current at the moment, but it might be helpful in tracking it down. I haven't had it crash X, but it tends to die with SIGILL when someone logs out; turning on "show offline buddies" makes it happen less often. If it's dying after sending a partial X protocol request to the server, that would probably do it; XFree86 doesn't seem to deal with that very well, in my experience. -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university ["better check the oblivious first" -ke6sls] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Jeremy Messenger wrote: Well, the 5.0, old -CURRENT and 4.8 have never touch the swap, until 5.1- CURRENT. My system has 256mb ram and it's always touch swap now. If I compile some stuff, sometime it will get around 300mb swap. Current, I only have Gnome 2.3.x and Opera running, so what my top looks like this: Mem: 85M Active, 29M Inact, 51M Wired, 4496K Cache, 35M Buf, 73M Free Swap: 512M Total, 79M Used, 433M Free, 15% Inuse But, I will remove the Gnome System Monitor applet, then reboot and see how it goes for the whole afternoon. People, swap is just a backing store for idle data. If you have 79 Mb that isn't getting used, what would you prefer: to keep it swap-backed so you can throw the pages out on demand, or *wait* until your system is heavily loaded to put the pages on the swap? Anyway, placing data on the swap is not a problem. What is a problem is what some call "swapping": reading and writing to the swap all the time. Start a "vmstat 1" and see if pi and po have non-zero values constantly. If not, then your system is _not_ wasting time writing and reading to the disk. (btw, unless you have disk activity, writing data to the swap does not impact on performance either) -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ever feel like life was a game and you had the wrong instruction book? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
VMWare inflicted kernel panic
vmware3-3.2.1-2237_1, rtc-2002.03.05.2_2, world built on 21-7, backtrace:
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc02217d9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0221bb8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0373f66 in trap_fatal (frame=0xe219c710, eva=0)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc03734a3 in trap (frame=
{tf_fs = -1069481960, tf_es = -1067974640, tf_ds = -979763184, tf_edi =
-979938720, tf_esi = -979943236, tf_ebp = -501626976, tf_isp = -501627076, tf_ebx = 1,
tf_edx = 1966080, tf_ecx = -979938720, tf_eax = -1071470963, tf_trapno = 12, tf_err =
2, tf_eip = -1070127771, tf_cs = 8, tf_eflags = 77826, tf_esp = -1071470963, tf_ss =
-979938720}) at /usr/src/sys/i386/i386/trap.c:256
#5 0xc0363ef8 in calltrap () at {standard input}:102
#6 0xc02214c2 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:312
#7 0xc0221bb8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#8 0xc0373f66 in trap_fatal (frame=0xe219c8d0, eva=0)
at /usr/src/sys/i386/i386/trap.c:836
#9 0xc03734a3 in trap (frame=
{tf_fs = -1069481960, tf_es = -1067974640, tf_ds = -1051525104, tf_edi =
-979938720, tf_esi = -979943236, tf_ebp = -501626528, tf_isp = -501626628, tf_ebx = 0,
tf_edx = 1966080, tf_ecx = -979938720, tf_eax = -1071470963, tf_trapno = 12, tf_err =
2, tf_eip = -1070127771, tf_cs = 8, tf_eflags = 78342, tf_esp = -1071470963, tf_ss =
-979938720}) at /usr/src/sys/i386/i386/trap.c:256
#10 0xc0363ef8 in calltrap () at {standard input}:102
#11 0xc0229d2f in msleep (ident=0xce521990, mtx=0xc041dce0, priority=68,
wmesg=0x0, timo=0) at /usr/src/sys/kern/kern_synch.c:256
#12 0xc0270c40 in bwait (bp=0xce521990, pri=68 'D', wchan=0xc03a340a "spread")
at /usr/src/sys/kern/vfs_bio.c:3735
#13 0xc01dc5f6 in spec_getpages (ap=0xe219cab8)
at /usr/src/sys/fs/specfs/spec_vnops.c:749
#14 0xc01daf08 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#15 0xc03104b2 in ffs_getpages (ap=0xe219cb20) at vnode_if.h:1314
#16 0xc033dfdb in vnode_pager_getpages (object=0xc4604a68, m=0x0, count=0,
reqpage=0) at vnode_if.h:1314
#17 0xc0323bc2 in vm_fault (map=0xc6b45400, vaddr=673882112,
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_pager.h:125
#18 0xc0373ae5 in trap_pfault (frame=0xe219cd48, usermode=1, eva=673882112)
at /usr/src/sys/i386/i386/trap.c:726
#19 0xc037359c in trap (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135054704, tf_esi = -1077939004,
tf_ebp = -1077940796, tf_isp = -501625484, tf_ebx = 674764720, tf_edx = 135010302,
tf_ecx = -1077939004, tf_eax = 135054704, tf_trapno = 12, tf_err = 4, tf_eip =
673882110, tf_cs = 31, tf_eflags = 78470, tf_esp = -1077949236, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:321
#20 0xc0363ef8 in calltrap () at {standard input}:102
/S
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Alpha/EISA broken?
Hi Latest boot on my Alpha breaks thus: Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xfc3303c0... sio1: gdb debugging port Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Fri Jul 25 11:50:23 BST 2003 [EMAIL PROTECTED]:/usr/src/sys/alpha/compile/G_ALPHA Preloaded elf kernel "/boot/kernel/kernel" at 0xfc868000. Preloaded elf module "/boot/kernel/linux.ko" at 0xfc8680d0. Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xfc8681a0. Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xfc868270. Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xfc868340. Preloaded elf module "/boot/kernel/osf1.ko" at 0xfc868410. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xfc8684e0. Preloaded elf module "/boot/kernel/miibus.ko" at 0xfc8685b0. Preloaded elf module "/boot/kernel/random.ko" at 0xfc868680. Preloaded elf module "/boot/kernel/isp.ko" at 0xfc868750. Preloaded elf module "/boot/kernel/cam.ko" at 0xfc868820. Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xfc8688f0. Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xfc8689c8. AlphaServer 1000/1000A AlphaServer 1000A 5/500, 500MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x1000600020117 real memory = 266371072 (254 MB) avail memory = 250863616 (239 MB) cia0: <2117x Core Logic chipset> cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21 pcib0: <2117x PCI host bus adapter> on cia0 pci0: on pcib0 eisab0: at device 7.0 on pci0 halted CPU 0 halt code = 7 machine check while in PAL mode PC = 18100 >>> Any idea what gives? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
In message: <[EMAIL PROTECTED]> Adrian Chadd <[EMAIL PROTECTED]> writes: : On Thu, Jul 24, 2003, M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > Chris BeHanna <[EMAIL PROTECTED]> writes: : > : Can't they just redact that information from the spec.? : > : > Typically no. Even in a redacted spec it would be painfully obvious : > what to do. Also, different regulatory domains have different : > frequencies that are real no-nos in other regulatory domains and : > they'd need to document how to properly generate the RF in both : > cases. : : So, assuming that there's at least one person smart enough to reverse : engineer the binary driver but stupid enough to release it publicly, : what happens to the manufacturer there? : : Can they now take "they took relevant steps" as a defence in a law court? That's a very interesting question. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
On Fri, 2003-07-25 at 02:21, Terry Lambert wrote: > You probably can't get away with the old gcc, since the binary > format changed For No Good Reason(tm). Didn't the GNU people say they had to change it to be more ABI compliant with the 'standard'? -- Shawn <[EMAIL PROTECTED]> http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
On Fri, 2003-07-25 at 01:42, Terry Lambert wrote: > I do know that even if they remove the bridge, they are unlikely > to provide enough documentation to boot and run natively on the > hardware without having IBM code setting up the bus arbitration > and other bits that are currently undocumented. Why would IBM try to hide this? Wouldn't they *want* people to take full advantage of the processor for the best performance to help give their product a good image? -- Shawn <[EMAIL PROTECTED]> http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Gaim Crashing X
Can't say I've ever had a problem of any kind with X and gaim in current (or any flavor for that matter). On Friday 25 July 2003 06:50, Brandon S. Allbery KF8NH wrote: > On Fri, 2003-07-25 at 06:33, Rus Foster wrote: > > I've beenfinding that when running gaim that its causing X to crash back > > down to the shell prompt. This has happened with both vesa, nv and nvidia > > drivers. Doing a latest buildworld still hasn't helped. Anyone got any > > insite in to this? > > This is more of an anecdote than anything else, since I don't have any > systems running -current at the moment, but it might be helpful in > tracking it down. > > I haven't had it crash X, but it tends to die with SIGILL when someone > logs out; turning on "show offline buddies" makes it happen less often. > > If it's dying after sending a partial X protocol request to the server, > that would probably do it; XFree86 doesn't seem to deal with that very > well, in my experience. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make buildworld warning
===> sys/boot/i386/loader "/usr/src/share/mk/bsd.prog.mk", line 38: warning: duplicate script for target " loader" ignored FYI, -- Shawn <[EMAIL PROTECTED]> http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VMWare inflicted kernel panic
On Fri, 2003-07-25 at 07:54, Sławek Żak wrote: > vmware3-3.2.1-2237_1, rtc-2002.03.05.2_2, world built on 21-7, backtrace: > > /S I've been seeing these for a few days as well. I just did a quick search for open PRs and found ports/54417 that says you should have "options VFS_AIO" in your kernel or load aio.ko to get VMWare to work properly. I haven't had time to test this myself, but will be doing so shortly. Fish ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fun with 'fdisk -B -b /boot/boot0 ad0'
On Wednesday 23 July 2003 04:26 pm, Ryan T. Dean wrote: > [...] The FreeBSD boot program came back, > however, when I attempt to load FreeBSD, it merely beeps at me. It will, > however, boot into W2k. I've tried supping, rebuilding the boot blocks (cd > src/sys/boot; make install; fdisk -B -b /boot/boot0 ad0; disklabel -B > ad0s2) with no success. Am I correct in assuming that the W2k slice is at the start of the disk and the FreeBSD slice is several gigs in (probably past the 1024 cylinder boundary)? If this is the case, the following command may fix the problem: boot0cfg -o packet ad0 Hope this helps, Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vchans related page fault
Hi!
Looks like the vchans code still is broken. I get panics approx. twice
a day on, all related to sound usage.
FreeBSD fump.kawo2.rwth-aachen.de 5.1-CURRENT FreeBSD 5.1-CURRENT #9:
Wed Jul 9 19:26:12 CEST 2003
[EMAIL PROTECTED]:/data/obj/usr/src/sys/ZEROGRAVITY i386
It begins with xmms _sometimes_ not being able to open /dev/dsp
(Operation not by device) (after heavy usage before), then when trying to
play again it outputs "DSP_SETSPEED: ..." (can't remember exactly), and
then the system already hangs (in X => after a short while reboot with
crashdump)
I currently don't understand everything of the the feeder code, but it
seems sometimes there is no feeder_feed function available, so this
results in a page fault:
p 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0x0
stack pointer = 0x10:0xd67bcba0
frame pointer = 0x10:0xd67bcbd0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 24 (irq5: fwohci0 pcm0)
trap number = 12
panic: page fault
Stack backtrace:
syncing disks, buffers remaining... 3803 3802 3802 3802 3802 3802 3802
3802 3802 3802 3802 3802 3802 3802 3802 3802 3802 3802 3802 3802 3802
giving up on 779 buffers
Uptime: 20h31m28s
Dumping 511 MB
ata0: resetting devices ..
done
ad0: timeout waiting for DRQata0: resetting devices ..
done
[CTRL-C to abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160
176 192 208 224 240 256 272 288 304 320 336 352[CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] 368 384 400 416 432 448
464 480 496
---
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc023184a in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0231bf4 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc039726b in trap_fatal (frame=0xd67bcb60, eva=0) at
/usr/src/sys/i386/i386/trap.c:836
#4 0xc0396f53 in trap_pfault (frame=0xd67bcb60, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:750
#5 0xc0396ac8 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi =
-990232576, tf_ebp = -696529968, tf_isp = -696530036, tf_ebx = 2044,
tf_edx = 0, tf_ecx = 0, tf_eax = -967561216, tf_trapno = 12, tf_err = 0,
tf_eip = 0, tf_cs = 8, tf_eflags = 66182, tf_esp = -1071922962, tf_ss =
-990232576}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc03873c8 in calltrap () at {standard input}:96
#7 0xc01c03d4 in FEEDER_FEED (feeder=0xc4fa4000, c=0x0, buffer=0x0,
count=0, source=0x0) at feeder_if.h:61
#8 0xc01bfcb7 in feed_vchan_s16 (f=0xc4211dc0, c=0x0, b=---Can't read
userspace from dump, or kernel process---
) at /usr/src/sys/dev/sound/pcm/vchan.c:98
#9 0xc01b5dc4 in FEEDER_FEED (feeder=0xc4211dc0, c=0x0, buffer=0x0,
count=0, source=0x0) at feeder_if.h:61
#10 0xc01b5c07 in sndbuf_feed (from=0x0, to=0xc4211dc0, channel=0x0,
feeder=0x0, count=3291058728)
at /usr/src/sys/dev/sound/pcm/buffer.c:538
#11 0xc01b61bb in chn_wrfeed (c=0xc4036a80) at
/usr/src/sys/dev/sound/pcm/channel.c:218
#12 0xc01b620c in chn_wrintr (c=0xc4299228) at
/usr/src/sys/dev/sound/pcm/channel.c:234
#13 0xc01b66f2 in chn_intr (c=0xc4299228) at
/usr/src/sys/dev/sound/pcm/channel.c:443
#14 0xc0198ab1 in cmi_intr (data=0xc4036600) at
/usr/src/sys/dev/sound/pci/cmi.c:537
#15 0xc021cc92 in ithread_loop (arg=0xc4036780) at
/usr/src/sys/kern/kern_intr.c:534
#16 0xc021b9ff in fork_exit (callout=0xc021cad0 , arg=0x0,
frame=0x0)
at /usr/src/sys/kern/kern_fork.c:794
(kgdb) up 7
#7 0xc01c03d4 in FEEDER_FEED (feeder=0xc4fa4000, c=0x0, buffer=0x0,
count=0, source=0x0) at feeder_if.h:61
61 feeder_if.h: No such file or directory.
in feeder_if.h
(kgdb) print *feeder
$1 = {ops = 0x1f40, align = 8000, desc = 0x0, desc_static = {type = 0,
in = 0, out = 0, flags = 2, idx = 0},
data = 0x0, class = 0x0, source = 0x0, parent = 0x0}
(kgdb) print *(feeder->ops)
---Can't read userspace from dump, or kernel process---
(kgdb) print feeder->ops
$2 = (struct kobj_ops *) 0x1f40
56 in feeder_if.h
(kgdb) up
#8 0xc01bfcb7 in feed_vchan_s16 (f=0xc4211dc0, c=0x0, b=---Can't read
userspace from dump, or kernel process---
) at /usr/src/sys/dev/sound/pcm/vchan.c:98
98 cnt = FEEDER_FEED(ch->feeder, ch,
(u_int8_t *)tmp, count, ch->bufsoft);
(kgdb) list
93 SLIST_FOREACH(cce, &c->children, link) {
94 ch = cce->channel;
95 if (ch->flags & CHN_F_TRIGGERED) {
96 if (ch->flags & CHN_F_MAPPED)
97 sndbuf_acquire(ch->bufsoft,
NULL, sndbuf_getfree(ch->bufsoft));
98 cnt = FEEDER_FEED(ch->feeder, ch,
(u_int8_t *)tmp, count, ch->bufsoft);
99 vchan_mix_s16(dst, tmp, cnt / 2)
Re: Memory Mangement Problem in 5.1-RELEASE
hi, I recompiled my kernel yesterday and that game me an entire 4Mb more...WOW!! sarcasim killed the cat, but anyway. A debug option, *NOT THE* degug option, in the config file of the kernel was activated so I commented the line out and I got an extra 4Mb !! WOW. It was this line: Options INVARIANT_SUPPORT #extra sanity checks I don't have the internet setup on my bsd machine because my dad likes AOL, so I can't send a bug to the freeBSD team. Sorry!! _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Buildworld problem in 5.1-CURRENT
I cvsup'ed this morning and buildworld failed: ... ===> lib/libpam/modules/pam_echo cc -O2 -pipe -march=pentiumpro -I/usr/src/lib/libpam/modules/pam_echo/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_echo/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c: In function `_pam_echo': /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_echo. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 3070.221u 348.805s 1:06:24.35 85.8% 3287+2406k 2053+890io 806pf+0w I should probably note that: -This was done with 'make -DNO_RESCUE buildworld' as per UPDATING -I had not updated since shortly after installing 5.1-RELEASE -A previous buildworld had failed (with error code 2) so I ran 'make install' from contrib/gcc to go to 3.3.1 -I did check the archives for the last week (via the web), but the other buildworld problems don't mention this. fordprefect# gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.1 [FreeBSD] 20030711 (prerelease) fordprefect# Chris Johnson [EMAIL PROTECTED] Q: How many supply-siders does it take to change a light bulb? A: None. The darkness will cause the light bulb to change by itself. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld problem in 5.1-CURRENT
On Fri, Jul 25, 2003 at 08:13:58AM -0700, Christopher Johnson wrote: > I cvsup'ed this morning and buildworld failed: > > ... > > ===> lib/libpam/modules/pam_echo > cc -O2 -pipe -march=pentiumpro What is in your /etc/make.conf? I do not think that -O2 is supported in the build right now, due to increased verbosity of warnings in gcc 3.3. > /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing > type-punned pointer will break strict-aliasing rules > *** Error code 1 -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alpha/EISA broken?
On Fri, Jul 25, 2003 at 01:07:46PM +0100, Mark Murray wrote: > Hi > > Latest boot on my Alpha breaks thus: > > real memory = 266371072 (254 MB) > avail memory = 250863616 (239 MB) > cia0: <2117x Core Logic chipset> > cia0: ALCOR/ALCOR2, pass 3 > cia0: extended capabilities: 21 > pcib0: <2117x PCI host bus adapter> on cia0 > pci0: on pcib0 > eisab0: at device 7.0 on pci0 > > halted CPU 0 > > halt code = 7 > machine check while in PAL mode > PC = 18100 > >>> > > Any idea what gives? Not really, but as a datapoint today's -current does work OK on a EISA-less machine. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alpha/EISA broken?
Wilko Bulte writes: > > halt code = 7 > > machine check while in PAL mode > > PC = 18100 > > >>> > > > > Any idea what gives? > > Not really, but as a datapoint today's -current > does work OK on a EISA-less machine. GENERIC kernel also has above error. Remove eisa, and the boot goes straight to panic (no clock). M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
This is not the problem. We know what is the purpose of swap data. It is swaping when there is more than suffiecient memory to do so. There is disk activity on the swap disk (I have a seperate disk for faster access) even when there is enough memory to suit my request and more. It is simply swapping when it shouldn't. Opening Mozilla, Opera, Netscape, DrJava, jEdit, Emacs, PrBoom, XBubbles, and Nautilus at the same time on a 233Mhz machine should fill up the memory (160Mb) but instead it has decided to use the swap disk for a measly 50Mb which I do have in RAM!! _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alpha/EISA broken?
On Fri, Jul 25, 2003 at 05:31:27PM +0100, Mark Murray wrote: > Wilko Bulte writes: > > > halt code = 7 > > > machine check while in PAL mode > > > PC = 18100 > > > >>> > > > > > > Any idea what gives? > > > > Not really, but as a datapoint today's -current > > does work OK on a EISA-less machine. > > GENERIC kernel also has above error. > > Remove eisa, and the boot goes straight to panic (no clock). That is because your clock sits behind eisa I think. ticso recently posted some days ago that eisa is now mandatory on alpha. I did not follow in detail to be honest. Check the archives. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problem with AHC driver.
Hi... I updated my system last night with make world/make kernel/mergemaster, and the new kernel doesn't seem to work. It sits there for a while at "Waiting for SCSI devices to settle" and then gives the following message. ahc0: Timedout SCB already complete. Interrupts may not be functioning. (probe1:ahc:0:1:0): SCB 0x8 - timed out It then dumps the card state, which I can copy down if needed, but it'll have to be by hand, since I don't have a serial console. An older kernel (May 7th 2003) works fine. The controller is: ahc0: port 0xd800-0xd8ff mem 0xde00-0xde000fff irq 15 at device 9.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs The drives on the card are: da0 at ahc0 bus 0 target 8 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 64H 32S/T 4134C) and cd0 at ahc0 bus 0 target 3 lun 0 cd0: < CD-R/RW RW7060S 1.50> Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers The cd-rw drive is external, if that makes any difference. I'm pretty sure my cabling and termination are good, as I've been running in this setup for over a year now without any problems. The motherboard is an ASUS P5A, with an AMD K6-2/500MHz processor. Does anyone have a clue what's wrong, and/or how to fix it? I'm happy to provide any debugging information requested, just tell me what you need and how to get it. Thanks -Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alpha/EISA broken?
Wilko Bulte writes: > > GENERIC kernel also has above error. > > > > Remove eisa, and the boot goes straight to panic (no clock). > > That is because your clock sits behind eisa I think. ticso recently > posted some days ago that eisa is now mandatory on alpha. > I did not follow in detail to be honest. Check the archives. Well, that's left me hosed :-(. I looked through current@ and alpha@ (briefly) and saw nothing obvious. What should I be looking for? M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/acpica acpi_ec.c
If you get the error message below, please enable hw.acpi.verbose=1 in loader.conf and post the dmesg output. I'm trying to find if there are any more broken ECs that need to be worked around. Anything more than 1000 us is starting to get iffy although you should only get an error if you hit 5 us. -Nate -- Forwarded message -- njl 2003/07/25 09:49:46 PDT FreeBSD src repository Modified files: sys/dev/acpica acpi_ec.c Log: Add an informational debugging printf of the maximum time spent in EcEventWait(). If you get AE_HARDWARE_NO_RESPONSE errors, please enable this info by setting hw.acpi.verbose=1 in loader.conf. Revision ChangesPath 1.37 +10 -0 src/sys/dev/acpica/acpi_ec.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alpha/EISA broken?
On Fri, Jul 25, 2003 at 01:07:46PM +0100, Mark Murray wrote: > Hi > > Latest boot on my Alpha breaks thus: > > Booting [/boot/kernel/kernel]... > Entering /boot/kernel/kernel at 0xfc3303c0... > sio1: gdb debugging port > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.1-CURRENT #0: Fri Jul 25 11:50:23 BST 2003 > [EMAIL PROTECTED]:/usr/src/sys/alpha/compile/G_ALPHA > Preloaded elf kernel "/boot/kernel/kernel" at 0xfc868000. > Preloaded elf module "/boot/kernel/linux.ko" at 0xfc8680d0. > Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xfc8681a0. > Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xfc868270. > Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xfc868340. > Preloaded elf module "/boot/kernel/osf1.ko" at 0xfc868410. > Preloaded elf module "/boot/kernel/if_dc.ko" at 0xfc8684e0. > Preloaded elf module "/boot/kernel/miibus.ko" at 0xfc8685b0. > Preloaded elf module "/boot/kernel/random.ko" at 0xfc868680. > Preloaded elf module "/boot/kernel/isp.ko" at 0xfc868750. > Preloaded elf module "/boot/kernel/cam.ko" at 0xfc868820. > Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xfc8688f0. > Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xfc8689c8. > AlphaServer 1000/1000A > AlphaServer 1000A 5/500, 500MHz > 8192 byte page size, 1 processor. > CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 > OSF PAL rev: 0x1000600020117 > real memory = 266371072 (254 MB) > avail memory = 250863616 (239 MB) > cia0: <2117x Core Logic chipset> > cia0: ALCOR/ALCOR2, pass 3 > cia0: extended capabilities: 21 > pcib0: <2117x PCI host bus adapter> on cia0 > pci0: on pcib0 > eisab0: at device 7.0 on pci0 > > halted CPU 0 > > halt code = 7 > machine check while in PAL mode > PC = 18100 > >>> > > Any idea what gives? Sounds like an SRM problem or EISA configuration problem. Normaly the bus and then system board should be probed at this point. We never used EISA on alpha before - EISA bridge support was only conditionalisized on pci. I tested localy on an AS4100 system: eisab0: at device 1.0 on pci1 eisa0: on eisab0 mainboard0: on eisa0 slot 0 isa0: on eisab0 What says show config and show device? In case something is wrong with your eisa setup. Eisa configuration has to be done via alphabios. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: yesterday's ACPI not working -> patch
Please try again with today's -current with hw.acpi.debug=1 in loader.conf. It should not generate errors of AE_HARDWARE_NO_RESPONSE but if it does, let me know the values reported by acpi_ec0 for its max delay. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with AHC driver.
Try disabling ACPI. Scott Adam Kranzel wrote: Hi... I updated my system last night with make world/make kernel/mergemaster, and the new kernel doesn't seem to work. It sits there for a while at "Waiting for SCSI devices to settle" and then gives the following message. ahc0: Timedout SCB already complete. Interrupts may not be functioning. (probe1:ahc:0:1:0): SCB 0x8 - timed out It then dumps the card state, which I can copy down if needed, but it'll have to be by hand, since I don't have a serial console. An older kernel (May 7th 2003) works fine. The controller is: ahc0: port 0xd800-0xd8ff mem 0xde00-0xde000fff irq 15 at device 9.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs The drives on the card are: da0 at ahc0 bus 0 target 8 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 64H 32S/T 4134C) and cd0 at ahc0 bus 0 target 3 lun 0 cd0: < CD-R/RW RW7060S 1.50> Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers The cd-rw drive is external, if that makes any difference. I'm pretty sure my cabling and termination are good, as I've been running in this setup for over a year now without any problems. The motherboard is an ASUS P5A, with an AMD K6-2/500MHz processor. Does anyone have a clue what's wrong, and/or how to fix it? I'm happy to provide any debugging information requested, just tell me what you need and how to get it. Thanks -Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: This is not the problem. We know what is the purpose of swap data. It is swaping when there is more than suffiecient memory to do so. There is disk activity on the swap disk (I have a seperate disk for faster access) even when there is enough memory to suit my request and more. It is simply swapping when it shouldn't. Opening Mozilla, Opera, Netscape, DrJava, jEdit, Emacs, PrBoom, XBubbles, and Nautilus at the same time on a 233Mhz machine should fill up the memory (160Mb) but instead it has decided to use the swap disk for a measly 50Mb which I do have in RAM!! You *ARE* measuring this with FreeBSD's top(1), right? Linux has different semantics for memory, so things it thinks are "free" are actually in use on FreeBSD, and most monitor programs are written with Linux semantics in mind. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Just when you get really good at something, you don't need to do it anymore. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: We have ath, now what about Broadcom?
On Fri, Jul 25, 2003 at 06:36:55AM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Adrian Chadd <[EMAIL PROTECTED]> writes: > : On Thu, Jul 24, 2003, M. Warner Losh wrote: > : > In message: <[EMAIL PROTECTED]> > : > Chris BeHanna <[EMAIL PROTECTED]> writes: > : > : Can't they just redact that information from the spec.? > : > > : > Typically no. Even in a redacted spec it would be painfully obvious > : > what to do. Also, different regulatory domains have different > : > frequencies that are real no-nos in other regulatory domains and > : > they'd need to document how to properly generate the RF in both > : > cases. > : > : So, assuming that there's at least one person smart enough to reverse > : engineer the binary driver but stupid enough to release it publicly, > : what happens to the manufacturer there? > : > : Can they now take "they took relevant steps" as a defence in a law court? > > That's a very interesting question. I would guess that if there were wide-spread problems, they might cancel the license for the devices until they deliberatly broke the firmware interfaces, but it's probably the case that they aren't going to hold the manufacture responsible for blatent, high-effort misuse of the product even if they technical could. On the other hand these modern, programmable radios are probably more of an issue then the current problems with illegal amplification or overly high-gain antennas. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
"authenticated tftp"
Yeah, seems like an oxy-moron, but this is a legitimate question, I promise. My linksys wireless router requires me to disable the admin password on it to tftp a firmware update to it--however, the Windows tftp client that Linksys ships appear to support some form of "Oh yeah, and here's a password". It probably really doesn't make a difference security-wise, but it would be a lot more convenient to update wireless routers if our tftp client spoke whatever extension they use to carry the password. Does anyone know anything about that protocol extension, or if there are existing tweaks to add it to our tftp? (I saw nothing in the man page). If there's a pointer to the on-the-write bits, I can always stick it in myself, but I have yet to find one. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with AHC driver.
On Friday 25 July 2003 10:08, Scott Long wrote: > Try disabling ACPI. > ACPI is already disabled (with 'hint.acpi.0.disabled="1"' in /boot/device.hints) I should have mentioned that, sorry. Any other suggestions? -Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alpha/EISA broken?
On Fri, Jul 25, 2003 at 07:02:09PM +0200, Bernd Walter wrote: > > eisab0: at device 7.0 on pci0 > > > > halted CPU 0 > > > > halt code = 7 > > machine check while in PAL mode > > PC = 18100 > > >>> > > > > Any idea what gives? > > Sounds like an SRM problem or EISA configuration problem. > Normaly the bus and then system board should be probed at this point. > We never used EISA on alpha before - EISA bridge support was only > conditionalisized on pci. Which triggers me: did you run the ECU? A copy is at: ftp://ftp.tcja.nl/pub/wilko/alpha > In case something is wrong with your eisa setup. > Eisa configuration has to be done via alphabios. Do 'runecu' from the SRM console and it should work. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on amd64/amd64
TB --- 2003-07-25 17:38:50 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-25 17:38:50 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-25 17:40:54 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree [...] rm -f chkey chkey.o generic.o update.o chkey.1.gz chkey.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.bin/newkey rm -f newkey newkey.o generic.o update.o newkey.8.gz newkey.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> usr.sbin "/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/usr.sbin/Makefile", line 213: Unassociated shell command "boot0cfg btxld lptcontrol mount_nwfs mount_smbfs sicontrol spkrtest zzz" make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-07-25 17:42:19 - /usr/bin/make returned exit code 1 TB --- 2003-07-25 17:42:19 - ERROR: failed to build world TB --- 2003-07-25 17:42:19 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sleeping on "objtrm" with non-sleepable locks held
Hola senores! I got this on the console output of my Sun E250 running a -current from ~July 12th. The machine continued running after displaying this. e250# e250# Sleeping on "objtrm" with the following non-sleepablelocks held: exclusive sleep mutex system map r = 0 (0xf80067e92098) locked @ /usr/src/sys/vm/vm_map.c:2192 lock order reversal 1st 0xf80067e92098 system map (system map) @ /usr/src/sys/vm/vm_map.c:2192 2nd 0xc0354d70 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:312 Stack backtrace: _mtx_lock_flags() at _mtx_lock_flags+0xa0 msleep() at msleep+0x6a8 vm_object_pip_wait() at vm_object_pip_wait+0x48 vm_object_terminate() at vm_object_terminate+0x30 vm_object_deallocate() at vm_object_deallocate+0x374 vm_map_entry_delete() at vm_map_entry_delete+0x3c vm_map_delete() at vm_map_delete+0x32c vm_map_remove() at vm_map_remove+0x44 kmem_free() at kmem_free+0x20 pipe_free_kmem() at pipe_free_kmem+0x98 pipeclose() at pipeclose+0x124 pipe_close() at pipe_close+0x20 fdrop_locked() at fdrop_locked+0x134 fdrop() at fdrop+0x20 closef() at closef+0x1f8 close() at close+0x168 syscall() at syscall+0x2ac -- syscall (6, FreeBSD ELF64, close) %o7=0x10706c -- userland() at 0x120128 user trace: trap %o7=0x10706c pc 0x120128, sp 0x7fddd41 pc 0x107164, sp 0x7fdde01 pc 0x1090cc, sp 0x7fddec1 pc 0x10c3f4, sp 0x7fddf91 pc 0x10b22c, sp 0x7fde061 pc 0x1001dc, sp 0x7fdedd1 pc 0, sp 0x7fdee91 done e250# I googled and searched the mailing list archive of the -current list. I didn't see anyone reporting this for 5.x-current, and the only thread I found was from July of 1999. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "authenticated tftp"
On Fri, 25 Jul 2003, 13:22-0400, Robert Watson wrote: > > Yeah, seems like an oxy-moron, but this is a legitimate question, I > promise. My linksys wireless router requires me to disable the admin > password on it to tftp a firmware update to it--however, the Windows tftp > client that Linksys ships appear to support some form of "Oh yeah, and > here's a password". It probably really doesn't make a difference > security-wise, but it would be a lot more convenient to update wireless > routers if our tftp client spoke whatever extension they use to carry the > password. Does anyone know anything about that protocol extension, or if > there are existing tweaks to add it to our tftp? (I saw nothing in the > man page). If there's a pointer to the on-the-write bits, I can always > stick it in myself, but I have yet to find one. There are several tftp extension that NetBSD folk integrated to their tftpd/tftp recently. IIRC they were 2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: 2349 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. I know nothing about auth extension yet but the protocol is quite simple (trivial :-)) and if you get a dump of udp session between the router and windows tftp client it would be easy incorporate this one. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 3Com 3C9340 (3C200) support
On Thu, Jul 24, 2003 at 02:23:01AM -0400, Nathan Binkert wrote: > > I own an Abit IS7-G which includes an intergrated 3Com 3C940 card > > currently not supported in any FreeBSD branch to my knowledge. Some > > people said that the nic could world with the Tigon III driver but I > > haven't been able to get it to work with it during install. Are there > > any plans or projects to get this card supported in the near future? A > > Linux driver is provided by 3Com. Thanks in advance for your time. > > In the next few days, I will be committing support for this chip to the > OpenBSD sk driver. Our sk driver was based on the freebsd, so it will be > simple to backport. Can you please be so kind to send a short headsup when you are done? I'm planning on getting your work integrated once you have the OpenBSD driver updated. (I'm lazy, I admit ;) -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VMWare inflicted kernel panic
On Fri, 2003-07-25 at 04:54, Sławek Żak wrote:
> vmware3-3.2.1-2237_1, rtc-2002.03.05.2_2, world built on 21-7, backtrace:
>
> (kgdb) bt
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1 0xc02217d9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
> #2 0xc0221bb8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #3 0xc0373f66 in trap_fatal (frame=0xe219c710, eva=0)
> at /usr/src/sys/i386/i386/trap.c:836
> #4 0xc03734a3 in trap (frame=
> {tf_fs = -1069481960, tf_es = -1067974640, tf_ds = -979763184, tf_edi =
> -979938720, tf_esi = -979943236, tf_ebp = -501626976, tf_isp = -501627076, tf_ebx =
> 1, tf_edx = 1966080, tf_ecx = -979938720, tf_eax = -1071470963, tf_trapno = 12,
> tf_err = 2, tf_eip = -1070127771, tf_cs = 8, tf_eflags = 77826, tf_esp =
> -1071470963, tf_ss = -979938720}) at /usr/src/sys/i386/i386/trap.c:256
> #5 0xc0363ef8 in calltrap () at {standard input}:102
> #6 0xc02214c2 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:312
> #7 0xc0221bb8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #8 0xc0373f66 in trap_fatal (frame=0xe219c8d0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:836
> #9 0xc03734a3 in trap (frame=
> {tf_fs = -1069481960, tf_es = -1067974640, tf_ds = -1051525104, tf_edi =
> -979938720, tf_esi = -979943236, tf_ebp = -501626528, tf_isp = -501626628, tf_ebx =
> 0, tf_edx = 1966080, tf_ecx = -979938720, tf_eax = -1071470963, tf_trapno = 12,
> tf_err = 2, tf_eip = -1070127771, tf_cs = 8, tf_eflags = 78342, tf_esp =
> -1071470963, tf_ss = -979938720}) at /usr/src/sys/i386/i386/trap.c:256
> #10 0xc0363ef8 in calltrap () at {standard input}:102
> #11 0xc0229d2f in msleep (ident=0xce521990, mtx=0xc041dce0, priority=68,
> wmesg=0x0, timo=0) at /usr/src/sys/kern/kern_synch.c:256
> #12 0xc0270c40 in bwait (bp=0xce521990, pri=68 'D', wchan=0xc03a340a "spread")
> at /usr/src/sys/kern/vfs_bio.c:3735
> #13 0xc01dc5f6 in spec_getpages (ap=0xe219cab8)
> at /usr/src/sys/fs/specfs/spec_vnops.c:749
> #14 0xc01daf08 in spec_vnoperate (ap=0x0)
> at /usr/src/sys/fs/specfs/spec_vnops.c:122
> #15 0xc03104b2 in ffs_getpages (ap=0xe219cb20) at vnode_if.h:1314
> #16 0xc033dfdb in vnode_pager_getpages (object=0xc4604a68, m=0x0, count=0,
> reqpage=0) at vnode_if.h:1314
> #17 0xc0323bc2 in vm_fault (map=0xc6b45400, vaddr=673882112,
> fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_pager.h:125
> #18 0xc0373ae5 in trap_pfault (frame=0xe219cd48, usermode=1, eva=673882112)
> at /usr/src/sys/i386/i386/trap.c:726
> #19 0xc037359c in trap (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135054704, tf_esi = -1077939004,
> tf_ebp = -1077940796, tf_isp = -501625484, tf_ebx = 674764720, tf_edx = 135010302,
> tf_ecx = -1077939004, tf_eax = 135054704, tf_trapno = 12, tf_err = 4, tf_eip =
> 673882110, tf_cs = 31, tf_eflags = 78470, tf_esp = -1077949236, tf_ss = 47}) at
> /usr/src/sys/i386/i386/trap.c:321
> #20 0xc0363ef8 in calltrap () at {standard input}:102
>
> /S
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
I've been running VMWare 3 with FreeBSD for quite some time and have come to this
conclusion.
Disable RTC, our rtc module hella sucks. The difference of 92-99% cpu
usage on vmware and 3%.
Secondly enable AIO i've found a great performance and less crash happy
experience by doing so, make sure also you're using linux_compat and not
linux_compat8 that creates further problems unfortunatly.
Beyond that expect panics, I can get it to run 'once' flawlessly and
then I have to reboot my workstation or else the 2nd time I boot into
it, it WILL panic in mid-boot of Windows 2000.
and BTW,
RTC is only needed if you run Windows 98 for the 'fades' and 'effects'
so if you don't use them, kill the kernel module. You won't miss much.
Infact it shouldn't be a dependancy since VMWare does NOT require it to
work. It complains and gives you a hint to disable that
'complaint/hint'. But nothing more.
Good luck
--
"I think we ought to be out there doing what we do best - making large
holes in other people's countries." - George Carlin
signature.asc
Description: This is a digitally signed message part
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: This is not the problem. We know what is the purpose of swap data. It is swaping when there is more than suffiecient memory to do so. There is disk activity on the swap disk (I have a seperate disk for faster access) even when there is enough memory to suit my request and more. It is simply swapping when it shouldn't. Opening Mozilla, Opera, Netscape, DrJava, jEdit, Emacs, PrBoom, XBubbles, and Nautilus at the same time on a 233Mhz machine should fill up the memory (160Mb) but instead it has decided to use the swap disk for a measly 50Mb which I do have in RAM!! This is definitely an FAQ. In short, FreeBSD manages swap space differently than does Linux or other systems. In particular, FreeBSD will copy data to swap preemptively in order to fulfill future memory requests more quickly. (By copying the data to swap now in the background, it can avoid stalling a future memory request because those blocks can simply be reallocated without waiting on the disk at the time the request is made.) If your system is spending a lot of time moving data to and from swap when it is not memory-starved, or if it is stalling memory allocations that it should be able to fulfill from free RAM, that's a concern. Otherwise, it is perfectly normal and expected to see a low level of swap activity even when memory is not completely full. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PATCH: Disable 6 byte commands for USB, firewire, ATAPICAM
In article <[EMAIL PROTECTED]>, Nate Lawson wrote: > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Attached is a patch that disables ever sending 6 byte commands to buses > that do not support them. Got this trap, it's sitting there at the prompt, let me know how I can help. The clie should be acting as a USB mass storage device with no entries in scsi_da.c for quirks. I simply plugged in the device in 'export mode' (which should be like plugging in a cf reader with media inserted), and then observed these errors, then disconnected the device. The device was 'hung' during these reset/bulk messages. [EMAIL PROTECTED] root]$ sysctl hw.usb.umass.debug=5 hw.usb.umass.debug: 0 -> 5 umass0: Sony Sony PEG Mass Storage, rev 1.10/1.00, addr 2 umass0: 8070i (ATAPI) over CBI with CCI (using CBI); quirks = 0x umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) umass0: CBI reset failed, TIMEOUT umass0: CBI bulk-in stall clear failed, TIMEOUT umass0: CBI bulk-out stall clear failed, TIMEOUT daregister: setting no 6 byte umass0: CBI reset failed, TIMEOUT umass0: CBI bulk-in stall clear failed, TIMEOUT umass0: CBI bulk-out stall clear failed, TIMEOUT umass0: CBI reset failed, TIMEOUT umass0: CBI bulk-in stall clear failed, TIMEOUT umass0: CBI bulk-out stall clear failed, TIMEOUT umass0: CBI reset failed, TIMEOUT umass0: CBI bulk-in stall clear failed, TIMEOUT umass0: CBI bulk-out stall clear failed, TIMEOUT umass0: CBI reset failed, TIMEOUT umass0: CBI bulk-in stall clear failed, TIMEOUT umass0: CBI bulk-out stall clear failed, TIMEOUT umass0: CBI reset failed, IOERROR umass0: CBI bulk-in stall clear failed, IOERROR umass0: CBI bulk-out stall clear failed, IOERROR (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device umass0: CBI reset failed, IOERROR umass0: CBI bulk-in stall clear failed, IOERROR umass0: CBI bulk-out stall clear failed, IOERROR umass0: CBI reset failed, IOERROR umass0: CBI bulk-in stall clear failed, IOERROR umass0: CBI bulk-out stall clear failed, IOERROR umass0: CBI reset failed, IOERROR umass0: CBI bulk-in stall clear failed, IOERROR umass0: CBI bulk-out stall clear failed, IOERROR umass0: CBI reset failed, IOERROR umass0: CBI bulk-in stall clear failed, IOERROR umass0: CBI bulk-out stall clear failed, IOERROR umass0: CBI reset failed, IOERROR umass0: at uhub0 port 2 (addr 2) disconnected umass0: detached Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc10a fault code = supervisor read, page not present instruction pointer = 0x8:0xc034a346 stack pointer = 0x10:0xc8625b88 frame pointer = 0x10:0xc8625b88 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 26 (usb0) kernel: type 12 trap, code=0 Stopped at device_get_nameunit+0x6:movl0x2c(%eax),%eax db> trace device_get_nameunit(deadc0de,23,0,0,6) at device_get_nameunit+0x6 umass_cbi_state(c1c12300,c1c12500,6,c18b5000,6) at umass_cbi_state+0x659 usb_transfer_complete(c1c12300,2,c053635d,c18b5000,c19f5800,c05900c4) at usb_tra nsfer_complete+0x1ba uhci_abort_xfer(c1c12300,6,c8625c40,c02d7349,c1c12300) at uhci_abort_xfer+0x118 uhci_device_ctrl_abort(c1c12300,0,c053635d,14a,c19f5800) at uhci_device_ctrl_abo rt+0x33 usbd_ar_pipe(c19f5800,c8625c60,c02d5594,c19f5800,c19f5d80) at usbd_ar_pipe+0x99 usbd_abort_pipe(c19f5800,c19f5d80,c19f5e00,c8625c7c,c02d62bd) at usbd_abort_pipe +0x11 usbd_kill_pipe(c19f5800,c0349f4c,c19f5e00,1,c18d55c0) at usbd_kill_pipe+0x14 usb_free_device(c19f5e00,c19f5d80,c18d15a0,c18d5400,c18d15a0) at usb_free_device +0x1d usb_disconnect_port(c18d55c0,c18d5500,11,0,0) at usb_disconnect_port+0x12d uhub_explore(c18d5400,c18aa120,c8625d0c,c02d2d01,c18aa120) at uhub_explore+0x2a1 usb_discover(c18aa120,0,5c,c052c40e,1770) at usb_discover+0x65 usb_event_thread(c18aa120,c8625d48,c053571a,312,423f0) at usb_event_thread+0x91 fork_exit(c02d2c70,c18aa120,c8625d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc8625d7c, ebp = 0 --- db> --- Mark atkin901 at NOSPAM yahoo dot com (!wired)?(coffee++):(wired); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
dude, I have a third of my memory free!! _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "authenticated tftp"
Maxim Konovalov <[EMAIL PROTECTED]> writes: > On Fri, 25 Jul 2003, 13:22-0400, Robert Watson wrote: > > > > > Yeah, seems like an oxy-moron, but this is a legitimate question, I > > promise. My linksys wireless router requires me to disable the admin > > password on it to tftp a firmware update to it--however, the Windows tftp > > client that Linksys ships appear to support some form of "Oh yeah, and > > here's a password". It probably really doesn't make a difference > > security-wise, but it would be a lot more convenient to update wireless > > routers if our tftp client spoke whatever extension they use to carry the > > password. Does anyone know anything about that protocol extension, or if > > there are existing tweaks to add it to our tftp? (I saw nothing in the > > man page). If there's a pointer to the on-the-write bits, I can always > > stick it in myself, but I have yet to find one. > > There are several tftp extension that NetBSD folk integrated to their > tftpd/tftp recently. IIRC they were > > 2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: > 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: > 2349 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. > > I know nothing about auth extension yet but the protocol is quite > simple (trivial :-)) and if you get a dump of udp session between the > router and windows tftp client it would be easy incorporate this one. Just to explain further what Maxim is pointing out here: the authentication option, whatever it is, is *not* a standard, unlike the ones he listed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PATCH: Disable 6 byte commands for USB, firewire, ATAPICAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 24 July 2003 10:00 pm, Nate Lawson wrote: > Attached is a patch that disables ever sending 6 byte commands to buses > that do not support them. Numerous USB devices hang when receiving a 6 > byte command. For testing, this patch comments out the scsi_da quirks for > devices that I believe are addressed by this patch and no longer need the > quirk. > > Please test devices such as USB keys, USB cameras, Firewire hard disks, > and ATAPICAM cd drives to be sure they still work with this patch. > Especially if you've needed a quirk before, it is important to see if this > patch does not break your device. I hope to get this into the tree early > so there is plenty of testing before 5.2. > > Thanks, > Nate > Works with my one quirks device (USB Floppy). - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/IZJixqA5ziudZT0RAi3sAKC31OPu1rTpgu/6boISEjwHRo7T9QCfcb09 jhTFTaGRLuAG2DHNdF8Zm+A= =Ztfy -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floppyless release build of sparc64
On Thu, Jul 24, 2003 at 11:50:10PM +0300, Ruslan Ermilov wrote: > > > > boot.flp is actually useful on sparc64 because you can dd it to a disk > > > > from solaris and then boot off it to install. I'm happy with having > > > > the option of not building it if it saves time but please make it an > > > > option. > > > > > > OK, then things will be left as is. There's already an option for > > > this; it's called NO_FLOPPIES (documented in the release(7) manpage). > > > > BUT the size of the "floppy" should be something like 10MB so that we > > know we will *never* overflow it during "make release". > > > Should the need arise for that, it's a two-line change to release/Makefile, > by just bumping MFSSIZE and BIGBOOTSIZE for sparc64. You're missing the point. The size should be set now to something that will *never* be too small. Waiting until "make release" is broken is stupid in this case. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "authenticated tftp"
On Fri, 25 Jul 2003, 13:22-0400, Robert Watson wrote: Yeah, seems like an oxy-moron, but this is a legitimate question, I promise. My linksys wireless router requires me to disable the admin password on it to tftp a firmware update to it--however, the Windows tftp client that Linksys ships appear to support some form of "Oh yeah, and here's a password". I found some code that claims to implement this extension (specifically for communicating with a Linksys device). Unfortunately, I couldn't find any copyright or license for the code, so I can't just pass it along. However, it looks like it just attaches an option called "password" whose value is the unencrypted password. RFC 2347 describes the format of TFTP options. Looks like a few lines added to makerequest() in tftp.c should handle it. Plus a few additional lines of code for the command-line option. Should be an evening's work for someone. Good luck, Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release broken [FIX]
On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote: > > On 22-Jul-2003 Ruslan Ermilov wrote: > > Hi! > > > > As many of you probably know, recent telnet commit broke snapshot > > building. Since I needed a working "make release" to go on with > > my task on floppy-less "make release" (for AMD64, etc.), I had to > > just fix it. Attached is the patch. It also fixes another issue > > with this telnet commit: it ensures that crypto telnet[d] do not > > end up in the "base" distribution. > > Why not simply enable 'NO_FLOPPIES' on the arch's that don't want > floppies? For one, its broken -- NO_FLOPPIES doesn't build the bootmfs floppy but still does the driver floppy. At least for Alpha this was true during 5.1 RC time. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make release broken [FIX]
On Fri, Jul 25, 2003 at 01:59:40PM -0700, David O'Brien wrote: > On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote: > > > > On 22-Jul-2003 Ruslan Ermilov wrote: > > > Hi! > > > > > > As many of you probably know, recent telnet commit broke snapshot > > > building. Since I needed a working "make release" to go on with > > > my task on floppy-less "make release" (for AMD64, etc.), I had to > > > just fix it. Attached is the patch. It also fixes another issue > > > with this telnet commit: it ensures that crypto telnet[d] do not > > > end up in the "base" distribution. > > > > Why not simply enable 'NO_FLOPPIES' on the arch's that don't want > > floppies? > > For one, its broken -- NO_FLOPPIES doesn't build the bootmfs floppy but > still does the driver floppy. At least for Alpha this was true during > 5.1 RC time. > Please look at the latest release/Makefile, then follow up in this thread. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Floppyless release build of sparc64
On Fri, Jul 25, 2003 at 01:39:14PM -0700, David O'Brien wrote: > On Thu, Jul 24, 2003 at 11:50:10PM +0300, Ruslan Ermilov wrote: > > > > > boot.flp is actually useful on sparc64 because you can dd it to a disk > > > > > from solaris and then boot off it to install. I'm happy with having > > > > > the option of not building it if it saves time but please make it an > > > > > option. > > > > > > > > OK, then things will be left as is. There's already an option for > > > > this; it's called NO_FLOPPIES (documented in the release(7) manpage). > > > > > > BUT the size of the "floppy" should be something like 10MB so that we > > > know we will *never* overflow it during "make release". > > > > > Should the need arise for that, it's a two-line change to release/Makefile, > > by just bumping MFSSIZE and BIGBOOTSIZE for sparc64. > > You're missing the point. The size should be set now to something that > will *never* be too small. Waiting until "make release" is broken is > stupid in this case. > I will leave this up to the sparc64 port maintainers, okay? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Alpha/EISA broken?
On Fri, Jul 25, 2003 at 05:49:15PM +0100, Mark Murray wrote: > Wilko Bulte writes: > > > GENERIC kernel also has above error. > > > > > > Remove eisa, and the boot goes straight to panic (no clock). > > > > That is because your clock sits behind eisa I think. ticso recently > > posted some days ago that eisa is now mandatory on alpha. > > I did not follow in detail to be honest. Check the archives. > > Well, that's left me hosed :-(. > > I looked through current@ and alpha@ (briefly) and saw nothing > obvious. What should I be looking for? > I think cvs-all@ would be more appropriate. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Buildworld problem in 5.1-CURRENT
On Fri, 25 Jul 2003, Craig Rodrigues wrote: > On Fri, Jul 25, 2003 at 08:13:58AM -0700, Christopher Johnson wrote: > > I cvsup'ed this morning and buildworld failed: > > > > ... > > > > ===> lib/libpam/modules/pam_echo > > cc -O2 -pipe -march=pentiumpro > > > What is in your /etc/make.conf? > I do not think that -O2 is supported in the build right now, > due to increased verbosity of warnings in gcc 3.3. > > > /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing > > type-punned pointer will break strict-aliasing rules > > *** Error code 1 > > Ahh yes, that fixed it. I've set it to -O, and it works fine. Chris Johnson [EMAIL PROTECTED] Dr. Evil: You're not quite evil enough. You're semi-evil. You're quasi-evil. You're the margarine of evil. You're the Diet Coke of evil, just one calorie, not evil enough. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld /rescue failures - fixed...
At 8:13 AM -0700 7/25/03, Christopher Johnson wrote: I should probably note that: -This was done with 'make -DNO_RESCUE buildworld' as per UPDATING Based on the results seen in another thread on this mailing list, I think it should be true that NO_RESCUE is no longer necessary. /usr/src/UPDATING should probably be revised to indicate that... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on powerpc/powerpc
TB --- 2003-07-25 22:07:54 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2003-07-25 22:07:54 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/powerpc/powerpc TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-25 22:09:47 - building world TB --- cd /home/des/tinderbox/CURRENT/powerpc/powerpc/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools [...] from /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc_tools/config.h:1, from /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/contrib/gcc/c-opts.c:22: /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/contrib/gcc/config/freebsd.h:72:1: warning: this is the location of the previous definition cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/home/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/usr\" -DCROSS_COMPILE -I/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I. -I/home/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/legacy/usr/include -static -L/home/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/leg! acy/usr/lib -o cc1 main.o c-parse+%DIKED.o c-lang.o c-decl.o c-opts.o /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a -legacy /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a(c-pragma.o): In function `init_pragma': c-pragma.o(.text+0x6a8): undefined reference to `rs6000_pragma_longcall' /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/i386/vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a(c-common.o): In function `cb_register_builtins': c-common.o(.text+0x8009): undefined reference to `rs6000_cpu_cpp_builtins' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc/cc1. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src/gnu/usr.bin/cc. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2003-07-25 22:15:38 - /usr/bin/make returned exit code 1 TB --- 2003-07-25 22:15:38 - ERROR: failed to build world TB --- 2003-07-25 22:15:38 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gcc related -current upgrade problems
hi, I'm attempting to upgrade a few month old -current: FreeBSD 8ball.rtp.freebsd.org. 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Apr 24 23:27:15 rm -rf src obj cd /usr cvs -Rqd /home/ncvs co -P src cd src make buildkernel . . . /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned "malloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:63:25: attempt to use poisoned "calloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:64:25: attempt to use poisoned "realloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:65:25: attempt to use poisoned "strdup" mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc1plus. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 This is with a newly checked out /usr/src and empty /usr/obj. UPDATING only mentions not using -DNOCLEAN and removing obj. Any ideas before I sink much more time into this? Thanks, John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc related -current upgrade problems
On Fri, Jul 25, 2003 at 06:46:50PM -0400, John wrote: > > rm -rf src obj > cd /usr > cvs -Rqd /home/ncvs co -P src > cd src > make buildkernel You can't buildkernel before buildworld. Do read UPDATING and the handbook. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc related -current upgrade problems
- Barney Wolff's Original Message - > On Fri, Jul 25, 2003 at 06:46:50PM -0400, John wrote: > > > > rm -rf src obj > > cd /usr > > cvs -Rqd /home/ncvs co -P src > > cd src > > make buildkernel ggrrr.. that should be: 13 make buildworld > /tmp/b.log 2>&1 & > You can't buildkernel before buildworld. Do read UPDATING and the handbook. Yes, I know. I just can't type... :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc related -current upgrade problems
Has anybody had problems compiling, kde most notably, with gcc3.3 in -current? I'd post the error, which seemed STL related, but I thought I'd ask first. I tried installing the stlport port on the offchance this would fix the problem, but that also came to (a much quicker) screeching halt. I believe it can't find ctime. It's been doing this for sometime, I'm also wondering if I have any dependencies missing since this last install is the first time I've ever installed kde without using source originally.. but I haven't been able to find anything that the ports system could be missing. On Friday 25 July 2003 19:10, Barney Wolff wrote: > On Fri, Jul 25, 2003 at 06:46:50PM -0400, John wrote: > > rm -rf src obj > > cd /usr > > cvs -Rqd /home/ncvs co -P src > > cd src > > make buildkernel > > You can't buildkernel before buildworld. Do read UPDATING and the > handbook. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc related -current upgrade problems
On Fri, 2003-07-25 at 16:38, James Tanis wrote: > Has anybody had problems compiling, kde most notably, with gcc3.3 in > -current? I'd post the error, which seemed STL related, but I thought I'd ask > first. I tried installing the stlport port on the offchance this would fix > the problem, but that also came to (a much quicker) screeching halt. I > believe it can't find ctime. It's been doing this for sometime, I'm also > wondering if I have any dependencies missing since this last install is the > first time I've ever installed kde without using source originally.. but I > haven't been able to find anything that the ports system could be missing. These issues have been addressed in KDE 3.1.3 if you're patient enough for Will to work out the kinks the ports will be updated in a week or less. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc related -current upgrade problems
On Fri, Jul 25, 2003 at 05:45:10PM -0700, Scott M. Likens wrote: > These issues have been addressed in KDE 3.1.3 if you're patient enough > for Will to work out the kinks the ports will be updated in a week or > less. Much more likely someone else on kde-freebsd is going to solve those problems, if they aren't already. regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
On Fri, 2003-07-25 at 15:00, Ahmed Al-Hindawi wrote: > dude, I have a third of my memory free!! Please read the following: http://www.daemonnews.org/21/freebsd_vm.html The above will give great indepth examples of how one version (I assume it's still the same roughly) of the FreeBSD VM works. -- Shawn <[EMAIL PROTECTED]> http://drevil.warpcore.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
xemacs hangs with -current
With these one week cvsup'd current, my xemacs hangs quite easily with operation like moving cursor beyond the end of line, some random mouse clicking, etc. (signal related??) Any fix, or suggestions? I am using ; A) FreeBSD 5.1-CURRENT #12: Fri Jul 25 23:37:43 JST 2003 CPU: Intel Pentium III (802.93-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387fbff real memory = 805240832 (767 MB) avail memory = 773910528 (738 MB) B) XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: FreeBSD 5.0 i386 [ELF] C) kde 3.1.2 D) xemacs 21.5.13 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LiveCD FBSD Current
Hi all I have made a liveCD of FreeBSD Current and it boot's and looks like it run ok.. The only problem i am haveing is with the md system.. it dus not let me do the newfs on the md dev, i have runing devfs and mounted the procfs.. mdcondig -a -t malloc -s 2m -u 0 <- work's ok newfs /dev/md0 -- 'pid xxx (newfs), uid 0: exited on signal 4 IIIegal instruction -- And with < mdmfs -M -s 2m md1 -tmp > i get the same error Can any one plz informe me on how to fix this or what am i duing bad... /* @@@ @@ @@@ @@! @@@ !@@ @@! @@@ @[EMAIL PROTECTED]@!@ !@@!! @!@ [EMAIL PROTECTED] !!: !!! !:! !!: !!! :: : :: ::.: : :: : : The Power To Kill LinuX */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: dude, I have a third of my memory free!! does vmstat agree? is kernel/userland in sync? -- Matthias Buelow; [EMAIL PROTECTED],informatik.uni-wuerzburg.de} ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LiveCD FBSD Current
On Sat, Jul 26, 2003 at 06:31:03AM +0200, Sebastian Yepes [ESN] wrote: > > Hi all > > I have made a liveCD of FreeBSD Current and it boot's and looks like it > run ok.. > > The only problem i am haveing is with the md system.. it dus not let me do > the newfs on the md dev, i have runing devfs and mounted the procfs.. > > > mdcondig -a -t malloc -s 2m -u 0 <- work's ok > newfs /dev/md0 > -- > 'pid xxx (newfs), uid 0: exited on signal 4 > IIIegal instruction > -- > And with < mdmfs -M -s 2m md1 -tmp > i get the same error > > Can any one plz informe me on how to fix this or what am i duing bad... This typically means you compiled the binary with CPU optimizations that are incorrect for the target system. Kris pgp0.pgp Description: PGP signature
Re: Memory Mangement Problem in 5.1-RELEASE
Shawn wrote: > On Fri, 2003-07-25 at 02:21, Terry Lambert wrote: > > You probably can't get away with the old gcc, since the binary > > format changed For No Good Reason(tm). > > Didn't the GNU people say they had to change it to be more ABI compliant > with the 'standard'? I will believe that when they upgrade their FORTRAN compiler to be more compliant with 'the standard'. Some standards are not worth complying with; I still have yet to see anyone tell me exactly what the practical benefit of doing this is. It's like the ELF standard instead of a.out; I was very much in favor of the change-over because it was supposed to let us have section attribution and multiple text and data segements that got loaded in the same executable. Is your FreeBSD kernel capable of defragging kernel memory to permit large contiguaous allocations for a device driver like the BT848 to happen well after boot time? Mine isn't. Is your FreeBSD kernel capable of dicarding the code and data for the probe routines that are not currently being executed and are not used in the common operational case? Mine isn't. Is your FreeBSD kernel capable of paging out any kernel page that's not in the paging path, so that if you, for example, have sound hardware and aren't using your sound driver, you have the ability to use the physical memory to instead open more sockets? Mine isn't. Is your FreeBSD kernel capable of loading *only* the probe code for a device, and, if it doesn't probe as being there, never loading the rest of the device driver and cotributing to KVA fragmentation? Mine isn't. Does your system have a libc.so linked against a libresolv.so that's totally seperate so that you can pull in new libraries from ISC whenever you need to do that the name lookups aren't serialized and make your Netscape slow? Mine doesn't. Is your entire system linked shared? Well, mine is. 8-). But it was under a.out, too. ELF promised a lot of things that never ended up having any practical value beyond what we already had with a.out, which was one BSS, one TEXT, and one DATA: just like before ELF. So what exactly is being promised by "being more standards compliant" in this particular instance? I can tell you what isn't: binaries are larger and compilation is slower than in previous releases; keeping up with GCC feels like running further and deeper into a swamp filled with molasses. Yeah, it's nice that we support 64 bit architectures (sorta) now, but that particular feature didn't need the binary format changed. Does anyone else ever suspect that some standards are written to cripple your competition, if they are stupid enough to fully comply with them? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuword(), suword(), etc.
Shawn wrote: > On Fri, 2003-07-25 at 01:42, Terry Lambert wrote: > > I do know that even if they remove the bridge, they are unlikely > > to provide enough documentation to boot and run natively on the > > hardware without having IBM code setting up the bus arbitration > > and other bits that are currently undocumented. > > Why would IBM try to hide this? Wouldn't they *want* people to take full > advantage of the processor for the best performance to help give their > product a good image? Adaptec didn't document their hardware to prevent people from cloning its interface in order to leverage the driver developement effort and advocacy it took to get their drivers into Windows. Diamond Multimedia didn't document their video cards because they had a hardware guy instead of a Real Software Engineer design their BIOS interface, and there was no non-Diamond-BIOS-accessible table of the PAL imputs vs. the video mode self-docmented in their BIOS, and they wanted to be able to change PAL and BIOS in tandem to add updated features to their cards, without changing their overall card design. There are a lot of comapnies who don't document their hardware for reasons of liability, when their documentation is incorrect and thus causes their hardware to fail, sometimes by cooking. Intel doesn't docuyment their full errata on their processors because then people wouldn't buy stock-on-hand, if they knew a stepping without a particular errata existed that didn't have the problem in question. How much of an excuse do they need? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: > It is simply swapping when it shouldn't. > > Opening Mozilla, Opera, Netscape, DrJava, jEdit, Emacs, PrBoom, XBubbles, > and Nautilus at the same time on a 233Mhz machine should fill up the memory > (160Mb) but instead it has decided to use the swap disk for a measly 50Mb > which I do have in RAM!! Please google for the phrase "write through cache". GG. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on amd64/amd64
TB --- 2003-07-26 05:34:55 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-26 05:34:55 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 05:36:55 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1: legacy release compatibility shims >>> stage 1: bootstrap tools >>> stage 2: cleaning up the object tree >>> stage 2: rebuilding the object tree >>> stage 2: build tools >>> stage 3: cross tools >>> stage 4: populating >>> /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include >>> stage 4: building libraries >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-07-26 06:36:49 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jul 26 06:36:49 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_ch.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_da.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_pass.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_sa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wst
Re: fuword(), suword(), etc.
geeze terry would you mind unhijacking this topic? The topic is "Should we have an suptr() and fuptr() to match suword() and fuword()?" On Fri, 25 Jul 2003, Terry Lambert wrote: [tonnes of absolutly irrelevant stuff] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: > dude, I have a third of my memory free!! Dude, there's a difference between "free" and "available". Dude, what makes you think that the swap in use doesn't refer to pages that are also in main memory, but marked clean because they've already been written to a backing store, but can be instantly reactivated in main memory without reading from swap? Dude, why do you thing FreeBSD is ever reading from swap at all when you are in this situation, and is not just writing it, in case you have a demand spike for memory so it can satisfy it immediately, instead of having to futz around with delaying your request until it can write the dirty things in main memory to swap? Dude, have you ever been through a drive through or even in line inside at a fast food place like Wendy's, where they send order takers into the line to proactively take your orders, so that all you have to do when you get to the front of the line is hand them your order ticket, instead of stating your order and delaying the whole line behind you by however long they were already delayed plus the time it takes you to give them your order? Dude, have you ever heard of "queueing theory" or have you ever google'd for "pool retention time" and "latency" in the same query? Dude, stop saying "dude". 8-) 8-). There are good reasons that FreeBSD acts the way it does, and why it is more responsive under a high load than certain other OS's written by people who are at best undergraduates and at worst High school students, and never cracked open a copy of "Knuth's Algorithms" in their lives, let alone owned one and put it up on their bookshelf. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make libstdc++ error
after cvsup'd from 5.0R to 5.1R and get error at installworld thx any info. c++ -O -pipe -mcpu=pentiumpro -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /usr/src/contrib/libstdc++/src/locale.cc -o locale.o /usr/src/contrib/libstdc++/src/locale.cc:454: `char std::locale::facet::_S_c_name[2]' is not a static member of `class std::locale::facet' *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
