Re: Recommended MP development machines...
Chuck Robey wrote: > On Wed, 3 Jul 2002, David O'Brien wrote: > > > On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: > > > I know everyone says "they all work" but i'd like some recommendations on > > > MP machines for -CURRENT work. I'll be ordering one this week. > > > > There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness) . > > http://www.tyan.com/products/html/thunderk7.html. It comes in multiple > > flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit > > PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG > > model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') > > CPU's and it is a totally solid system. Various FreeBSD committers also > > have this system. > > > > There is a newer [more economic] version called the Thunder K7X. > > http://www.tyan.com/products/html/thunderk7x.html > > "more economic" is a poor way to describe it, seeing as it has all the > features, plus (1) an updated version of the AMD mp chipset and (2) a > fixed onboard usb port. The K7 had a broken on-board usb (the AMD > chipset had a PCI contention bug for the usb port, so the tin back panel > of the board blocked out the usb, and the K7 came with a PCI usb card, > which ate up one of your PCI slots. The K7X has a repaired on-board usb, > so you get that PCI slot back. Hm. Do you have any details on this? I've had occasional strange USB-related things happen on this box. Of course, it runs -current which puts me into the USB danger-zone enough as it is.. but what happens when this bug is triggered? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KSE status.
Well it's all fun and games her at KSE central.. We have a set of cascading hidden bugs.. bug 1 hides bug 2 hides bug 3 the current state of play: the system works well for a while however there is a leak in the system that gradually runs the system out memory. the wired memory count grows with time. My test system presently has 241MB of Wired memory out of a 512M system. This didn't affect systems before today because the code was hidden by another bug.. that wasn't evident because of another bug.. etc.. still I think I am making progress. Just remember to reboot your system whenever your wired memory gets too high :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
error in /usr/src/gnu/usr.bin/binutils/doc/
Sources checked out today, 3AM EST. makeinfo --no-validate -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/binutils -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/mi -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc --no-split -I /usr/src/gnu/usr.bin/binutils/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/binutils/binutils.texi -o binutils.info ln -sf /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/all-cfg.texi gdb-cfg.texi echo "@set GDBVN `sed q /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/version.in`" > GDBvn.texi cp /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc/hsuser.texinfo inc-hist.texinfo patch -b .orig < /usr/src/gnu/usr.bin/binutils/doc/inc-hist.diff makeinfo: Removing output file `gdbint.info' due to errors; use --force to preserve. *** Error code 2 Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$FreeBSD: src/gnu/usr.bin/binutils/doc/inc-hist.diff,v 1.4 2002/07/01 07:58:18 sheldonh Exp $ | |--- inc-hist.texinfo.orig Wed Apr 11 08:20:01 2001 |+++ inc-hist.texinfo Wed Apr 11 08:21:57 2001 -- Patching file inc-hist.texinfo using Plan A... Hunk #1 succeeded at 26. Hunk #2 succeeded at 39. done 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Doing a simple 'make' in the directory is fine, so I guess the buildworld is pulling different stunts. I'd make the effort to track it, but I'm too tired, maybe someone else will catch it in the morning or so. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recommended MP development machines...
On Wed, Jul 03, 2002 at 11:50:00PM -0400, Chuck Robey wrote: > (2) a > fixed onboard usb port. The K7 had a broken on-board usb (the AMD > chipset had a PCI contention bug for the usb port, so the tin back panel > of the board blocked out the usb, and the K7 came with a PCI usb card, > which ate up one of your PCI slots. Strange, my UCB works. I don't have a back panel (was an early release mobo), but I have used a USB Zip drive with this mobo. I haven't been able to get my USB printer working; but that seemed more due to our USB support than hardware. > I think the K7 had only AGP; the K7X has AGP-Pro; doesn't mean much yet, > but if you're a gaming maven, maybe it'll be important pretty quickly now. Mine has AGP-pro. Not saying the K7X isn't better. Just that maybe the Thunder K7 isn't so bad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recommended MP development machines...
On Wed, 3 Jul 2002, David O'Brien wrote: > On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: > > I know everyone says "they all work" but i'd like some recommendations on > > MP machines for -CURRENT work. I'll be ordering one this week. > > There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness). > http://www.tyan.com/products/html/thunderk7.html. It comes in multiple > flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit > PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG > model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') > CPU's and it is a totally solid system. Various FreeBSD committers also > have this system. > > There is a newer [more economic] version called the Thunder K7X. > http://www.tyan.com/products/html/thunderk7x.html "more economic" is a poor way to describe it, seeing as it has all the features, plus (1) an updated version of the AMD mp chipset and (2) a fixed onboard usb port. The K7 had a broken on-board usb (the AMD chipset had a PCI contention bug for the usb port, so the tin back panel of the board blocked out the usb, and the K7 came with a PCI usb card, which ate up one of your PCI slots. The K7X has a repaired on-board usb, so you get that PCI slot back. The main difference in the updated chipset is the fact that the 64 bit PCI slots now run at double-speed, giving double the throughput. No change for the 32 bit PCI slots. At least for me, the main usage of the 64 bit slot would be the disk; seeing as both the K7 and the K7X can be had with a very nice dual channel Adaptec Ultra160 controller, which means you don't use the 64 bit PCI slot for disk, that kills that. Added cost for the controller is about $100, not a bad deal. I think the K7 had only AGP; the K7X has AGP-Pro; doesn't mean much yet, but if you're a gaming maven, maybe it'll be important pretty quickly now. Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recommended MP development machines...
On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: > I know everyone says "they all work" but i'd like some recommendations on > MP machines for -CURRENT work. I'll be ordering one this week. There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness). http://www.tyan.com/products/html/thunderk7.html. It comes in multiple flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') CPU's and it is a totally solid system. Various FreeBSD committers also have this system. There is a newer [more economic] version called the Thunder K7X. http://www.tyan.com/products/html/thunderk7x.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1655] Re: ASUS CUSL2 panic on acpi
Not fixed yet, just a intermediate report... > > acpi0: on motherboard > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x16 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc04f9aca > > stack pointer = 0x10:0xc054ea14 > > frame pointer = 0x10:0xc054ea34 > > 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 = 0 (swapper) > > kernel: type 12 trap, code=0 > > Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax > > db> trace > > AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at >AcpiExReadDataFromField+0x5a # if my understanding on i386 asm is correct, I think this is at (exfield.c): 203:if (WalkState->MethodNode->Flags & ANOBJ_DATA_WIDTH_32) where WalkState->MethodNode is NULL, this caused page fault. I'm waiting for further debug info. but I'll try to find where WalkState->MethodNode suppose to be set... Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recommended MP development machines...
* George V. Neville-Neil <[EMAIL PROTECTED]> [020703 19:43] wrote: > Hi, > > I know everyone says "they all work" but i'd like some recommendations on > MP machines for -CURRENT work. I'll be ordering one this week. I got a dual AMD 1900 from monarchcomputer.com, it was pretty decently priced at the time and they seem to have decent service. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recommended MP development machines...
Hi, I know everyone says "they all work" but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. Thanks, George -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 patch for testing.
to keep the sparc 64 pmap up with the others..
I had a look at a couple of thread related points.
Here's a possible diff (1 bug found I think)
any sparc64 people care to comment?
(cat-n-pasted patch)
The last addition is I think needed to not leak KV space.
The first changes are because the conditional is not needed.
This function is only ever called for uninitialised (new)
thread structures now..
Index: pmap.c
===
RCS file: /home/ncvs/src/sys/sparc64/sparc64/pmap.c,v
retrieving revision 1.58
diff -u -r1.58 pmap.c
--- pmap.c 29 May 2002 06:12:13 - 1.58
+++ pmap.c 4 Jul 2002 01:44:34 -
@@ -962,27 +962,21 @@
/*
* Allocate object for the kstack,
*/
- ksobj = td->td_kstack_obj;
- if (ksobj == NULL) {
- ksobj = vm_object_allocate(OBJT_DEFAULT, KSTACK_PAGES);
- td->td_kstack_obj = ksobj;
- }
+ ksobj = vm_object_allocate(OBJT_DEFAULT, KSTACK_PAGES);
+ td->td_kstack_obj = ksobj;
/*
* Get a kernel virtual address for the kstack for this thread.
*/
- ks = td->td_kstack;
- if (ks == 0) {
- ks = kmem_alloc_nofault(kernel_map,
- (KSTACK_PAGES + KSTACK_GUARD_PAGES) * PAGE_SIZE);
- if (ks == 0)
- panic("pmap_new_thread: kstack allocation
failed");
- if (KSTACK_GUARD_PAGES != 0) {
- tlb_page_demap(TLB_DTLB, kernel_pmap, ks);
- ks += KSTACK_GUARD_PAGES * PAGE_SIZE;
- }
- td->td_kstack = ks;
+ ks = kmem_alloc_nofault(kernel_map,
+ (KSTACK_PAGES + KSTACK_GUARD_PAGES) * PAGE_SIZE);
+ if (ks == 0)
+ panic("pmap_new_thread: kstack allocation failed");
+ if (KSTACK_GUARD_PAGES != 0) {
+ tlb_page_demap(TLB_DTLB, kernel_pmap, ks);
+ ks += KSTACK_GUARD_PAGES * PAGE_SIZE;
}
+ td->td_kstack = ks;
for (i = 0; i < KSTACK_PAGES; i++) {
/*
@@ -1042,6 +1036,13 @@
td->td_kstack_obj = NULL;
vm_object_deallocate(ksobj);
}
+ /*
+* don't forget to free the kmem space we were using.
+* (including guard pages).
+*/
+ ks -= KSTACK_GUARD_PAGES * PAGE_SIZE;
+ kmem_free(kernel_map, ks,
+ (KSTACK_PAGES + KSTACK_GUARD_PAGES) * PAGE_SIZE);
}
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Timeout and SMP race
while we are getting rid of Giant, current race condition between softclock() and callout_stop() is unacceptable. the race causes two many places in source code would be modified to fit this new behaviour, besides this, everywhere callout_stop() is used need to hold sched_lock and do a mi_switch() and modify td_flags is also unacceptable, this SMP race should be resolved in kern_timeout.c. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: vm_page_free: freeing wired page
Julian,
You may have fixed over the last few, but I haven't
had a chance to cvsup new sources.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
panic: vm_page_free: freeing wired page
panic: from debugger
Uptime: 39m56s
Dumping 128 MB
16 32 48 64 80 96 112
---
#0 0xc019c5cb in doadump ()
(kgdb) bt
#0 0xc019c5cb in doadump ()
#1 0xc019caa8 in boot (howto=260)
#2 0xc019ccab in panic ()
#3 0xc01369e2 in db_panic ()
#4 0xc0136971 in db_command (last_cmdp=0xc02cc800, cmd_table=0xc02cc620,
aux_cmd_tablep=0xc02c5ff4, aux_cmd_tablep_end=0xc02c5ff8)
#5 0xc0136a68 in db_command_loop ()
#6 0xc01394b8 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:76
#7 0xc026d2a0 in kdb_trap (type=3, code=0, regs=0xcaeefb18)
at /usr/src/sys/i386/i386/db_interface.c:214
#8 0xc027cb34 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -880287744, tf_esi = 256, tf_ebp =
-890307740, tf_isp = -890307772, tf_ebx = 0, tf_edx = 0, tf_ecx = -890308068, tf_eax =
18, tf_trapno = 3, tf_err = 0, tf_eip = -1071196883, tf_cs = 8, tf_eflags = 662,
tf_esp = -1070861153, tf_ss = -1070963908})
at /usr/src/sys/i386/i386/trap.c:667
#9 0xc026d52d in Debugger (msg=0xc02a633c "panic")
#10 0xc019cc94 in panic (fmt=0xc02b8ba0 "vm_page_free: freeing wired page\n")
#11 0xc024a5e1 in vm_page_free_toq (m=0xc09eb7c0)
#12 0xc0249c34 in vm_page_free (m=0xc09eb7c0)
#13 0xc0278885 in pmap_dispose_thread (td=0xc1e1)
#14 0xc01a6be3 in thread_fini (mem=0xc1e1, size=184)
#15 0xc024f985 in zone_drain (zone=0xc0bb9000)
#16 0xc02504b5 in zone_foreach (zfunc=0xc024f6b0 )
#17 0xc02517a7 in uma_reclaim ()
#18 0xc024cc41 in vm_pageout_scan (pass=0)
#19 0xc024da52 in vm_pageout ()
#20 0xc01897dc in fork_exit (callout=0xc024d7f0 , arg=0x0,
frame=0xcaeefd48)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
hey don't give up yet.. there's still a couple of crashing bugs hiding in there you could have your chance yet.. On Wed, 3 Jul 2002, W Gerald Hicks wrote: > > On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote: > > > > > > > On Wed, 3 Jul 2002, Erik Greenwald wrote: > > > >> > >> Looks like I'm out of this one, I got up this morning, cvsup'd and > >> built > >> world just to make sure it was fresh, then I quit getting the > >> crashes. I > >> d'no if the issue was fixed by something someone else did or what... > >> > > > > It was solved, but thanks for trying and welcome to the club > > of people willing to get their fingers dirty :-) > > > > > > Well, I feel cheated. Damn thing never crashed on me. :-) > > (pushes harder) > > Cheers, > > Jerry Hicks > [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: additional queue macro
We've got local changes (which I've attached) where the name is
*_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the
temp variable is the second argument. I can't think of a way of doing it
without having the externally declare the temporary variable.
On Tue, Jul 02, 2002 at 04:54:43PM -0700, Julian Elischer wrote:
>
>
> On Tue, 2 Jul 2002, Julian Elischer wrote:
>
> Having just re-read my own mail
>
> I think I agree with jonathan now..
> I think we neeed to either:
> 1/ augment the man page giving an example of how to do
> multiple removes from a list/queue.
> 2/ Explain in detail why using _FOREACH()
> is bad for this, and showing the alternative.
> 3/ Add something to the API that makes this easy to do.
> designing the API addition is tricky. Jonathan's effort
> was quite good, though I wonder if there is any way we can get it done
> without needing the decalration of 'tmp' separatly.
> (I can't think of a way).
>
>
>
> > /*
> > * Move any threads that should be suspended from the run queue
> > * to the suspend queue.
> > */
> > TAILQ_FOREACH(from run queue) {
> > if (something) {
> > TAILQ_REMOVE(element from run queue)
> > TAILQ_INSERT_TAIL(onto suspend queue)
> > }
> > }
> >
> > Now, at first glance, the documentation suggests this should work, even
> > though we know it won't. but it doesn't crash.. it just terminates on the
> > first transfer because it reaches the end of the queue.. the suspend queue
> > that is..
>
> TAILQ_FOREACH_REMOVABLE or TAILQ_FOREACH_SAFE
> (I prefer the first) are my suggestions for the name.)
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
Neal Fachan
[EMAIL PROTECTED]
Index: share/man/man3/queue.3
===
RCS file: /usr/local/ncvs/atera/src/share/man/man3/queue.3,v
retrieving revision 1.1
diff -u -p -r1.1 queue.3
--- share/man/man3/queue.3 9 Mar 2002 02:34:15 - 1.1
+++ share/man/man3/queue.3 3 Jul 2002 20:46:19 -
@@ -1,4 +1,4 @@
-.\" Copyright (c) 1993
+tail queue Copyright (c) 1993
.\"The Regents of the University of California. All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
@@ -40,6 +40,7 @@
.Nm SLIST_ENTRY ,
.Nm SLIST_FIRST ,
.Nm SLIST_FOREACH ,
+.Nm SLIST_FOREACH_REMOVE ,
.Nm SLIST_HEAD ,
.Nm SLIST_HEAD_INITIALIZER ,
.Nm SLIST_INIT ,
@@ -52,6 +53,7 @@
.Nm STAILQ_ENTRY ,
.Nm STAILQ_FIRST ,
.Nm STAILQ_FOREACH ,
+.Nm STAILQ_FOREACH_REMOVE ,
.Nm STAILQ_HEAD ,
.Nm STAILQ_HEAD_INITIALIZER ,
.Nm STAILQ_INIT ,
@@ -66,6 +68,7 @@
.Nm LIST_ENTRY ,
.Nm LIST_FIRST ,
.Nm LIST_FOREACH ,
+.Nm LIST_FOREACH_REMOVE ,
.Nm LIST_HEAD ,
.Nm LIST_HEAD_INITIALIZER ,
.Nm LIST_INIT ,
@@ -78,6 +81,7 @@
.Nm TAILQ_ENTRY ,
.Nm TAILQ_FIRST ,
.Nm TAILQ_FOREACH ,
+.Nm TAILQ_FOREACH_REMOVE ,
.Nm TAILQ_FOREACH_REVERSE ,
.Nm TAILQ_HEAD ,
.Nm TAILQ_HEAD_INITIALIZER ,
@@ -99,6 +103,7 @@ lists and tail queues
.Fn SLIST_ENTRY "TYPE"
.Fn SLIST_FIRST "SLIST_HEAD *head"
.Fn SLIST_FOREACH "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_FOREACH_REMOVE "TYPE *var" "TYPE *tmpvar" "SLIST_HEAD *head" "SLIST_ENTRY
+NAME"
.Fn SLIST_HEAD "HEADNAME" "TYPE"
.Fn SLIST_HEAD_INITIALIZER "SLIST_HEAD head"
.Fn SLIST_INIT "SLIST_HEAD *head"
@@ -112,6 +117,7 @@ lists and tail queues
.Fn STAILQ_ENTRY "TYPE"
.Fn STAILQ_FIRST "STAILQ_HEAD *head"
.Fn STAILQ_FOREACH "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_FOREACH_REMOVE "TYPE *var" "TYPE *tmpvar" "STAILQ_HEAD *head"
+"STAILQ_ENTRY NAME"
.Fn STAILQ_HEAD "HEADNAME" "TYPE"
.Fn STAILQ_HEAD_INITIALIZER "STAILQ_HEAD head"
.Fn STAILQ_INIT "STAILQ_HEAD *head"
@@ -127,6 +133,7 @@ lists and tail queues
.Fn LIST_ENTRY "TYPE"
.Fn LIST_FIRST "LIST_HEAD *head"
.Fn LIST_FOREACH "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME"
+.Fn LIST_FOREACH_REMOVE "TYPE *var" "TYPE *tmpvar" "LIST_HEAD *head" "LIST_ENTRY NAME"
.Fn LIST_HEAD "HEADNAME" "TYPE"
.Fn LIST_HEAD_INITIALIZER "LIST_HEAD head"
.Fn LIST_INIT "LIST_HEAD *head"
@@ -140,6 +147,7 @@ lists and tail queues
.Fn TAILQ_ENTRY "TYPE"
.Fn TAILQ_FIRST "TAILQ_HEAD *head"
.Fn TAILQ_FOREACH "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_REMOVE "TYPE *var" "TYPE *tmpvar" "TAILQ_HEAD *head" "TAILQ_ENTRY
+NAME"
.Fn TAILQ_FOREACH_REVERSE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME"
.Fn TAILQ_HEAD "HEADNAME" "TYPE"
.Fn TAILQ_HEAD_INITIALIZER "TAILQ_HEAD head"
@@ -316,6 +324,24 @@ turn to
.Fa var .
.Pp
The macro
+.Nm SLIST_FOREACH_REMOVE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+Unlike
+.Nm SLIST_FOREACH ,
+.Fa var
+is never dereferenced after the body of the loop, making it legal to remove
+.Fa var
+from the list or to call
+.Nm free
+on
+.Fa var
+in the loop body.
+.P
Re: additional queue macro
I agree that it's unfortunately named. The idea was that it's safe to remove from within the iterator, not that the iterator is doing the removing... On Wed, Jul 03, 2002 at 04:04:53PM -0700, Julian Elischer wrote: > > > On Wed, 3 Jul 2002, Neal Fachan wrote: > > > We've got local changes (which I've attached) where the name is > > *_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the > > temp variable is the second argument. I can't think of a way of doing it > > without having the externally declare the temporary variable. > > > A I like it and you've even done thge man page.. > > *_FOREACH_REMOVE however suggests that it is going to try remove > something.. > > -- Neal Fachan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
> On Wed, 3 Jul 2002, Erik Greenwald wrote: > > > > > Looks like I'm out of this one, I got up this morning, cvsup'd and built > > > world just to make sure it was fresh, then I quit getting the crashes. I > > d'no if the issue was fixed by something someone else did or what... > > It was solved, but thanks for trying and welcome to the club > of people willing to get their fingers dirty :-) not the first time I've dug into the 'dirty' stuff, was just kinda hoping this time I'd be first to the solution :) ah well, no core segment to my name, but still a few ports, guess I'll have to keep trying until I luck out :) -- -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote: > > > On Wed, 3 Jul 2002, Erik Greenwald wrote: > >> >> Looks like I'm out of this one, I got up this morning, cvsup'd and >> built >> world just to make sure it was fresh, then I quit getting the >> crashes. I >> d'no if the issue was fixed by something someone else did or what... >> > > It was solved, but thanks for trying and welcome to the club > of people willing to get their fingers dirty :-) > > Well, I feel cheated. Damn thing never crashed on me. :-) (pushes harder) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 08:08:28PM +0300, Maxim Sobolev wrote:
> > > In file included from translate.c:779:
> > > ../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
> > >
> > > ../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
> > > (insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
> > > (plus:SF (reg:SF 8 st(0) [76])
> > > (reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
> > > )
> > > (expr_list:REG_DEAD (reg:SF 8 st(0) [76])
> > > (nil)))
> > > ../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
> > > eload, at reload1.c:5050
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See http://www.gnu.org/software/gcc/bugs.html> for instructions.
> > > *** Error code 1
> > ...
> > > Please investigate & fix.
Ok, ok, fixed. Please stop CC'ing me on GCC bug reports. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: additional queue macro
On Wed, 3 Jul 2002, Neal Fachan wrote: > We've got local changes (which I've attached) where the name is > *_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the > temp variable is the second argument. I can't think of a way of doing it > without having the externally declare the temporary variable. > A I like it and you've even done thge man page.. *_FOREACH_REMOVE however suggests that it is going to try remove something.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Wed, Jul 03, 2002 at 11:59:47AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Jul > ian Elischer writes: > > >aren't you suppost to be honeymooning from yesterday? > > I am, I'm not working, only doing things I do for fun :-) Like reading Linux source code? 8-) -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ASUS CUSL2 panic on acpi
Here's a me too.. running on an ASUS A7V266-E > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x16 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc04f9aca > stack pointer = 0x10:0xc054ea14 > frame pointer = 0x10:0xc054ea34 > 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 = 0 (swapper) > kernel: type 12 trap, code=0 > Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax I had a movb 0x16(%eax),%al > db> trace > AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at >AcpiExReadDataFromField+0x5a With ACPI disabled (hint.acpi.0.disable="1") the kernel runs without a problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
Jeremy Lea <[EMAIL PROTECTED]> writes:
> 1. What the patches actually do...
> 2. If we can use one shared ${WRKSRC}, since the ports build multiple
>copies of all of the libraries, and they use the wrong (unpatched)
>versions of the config files in some cases.
While you're at it:
Index: FreeBSD.cf
===
RCS file: /sec/xfree86/cvs/xc/config/cf/FreeBSD.cf,v
retrieving revision 3.116
diff -u -r3.116 FreeBSD.cf
--- FreeBSD.cf 4 Jun 2002 22:50:55 - 3.116
+++ FreeBSD.cf 3 Jul 2002 21:19:14 -
@@ -48,6 +48,7 @@
#define HasSnprintfYES
#define HasBSD44SocketsYES
#define HasDlopen YES
+#define HasSetProcTitleYES
#ifndef HasLibCrypt
# define HasLibCrypt YES
#endif
There may be more stuff missing, look through NetBSD.cf and OpenBSD.cf
to see what they have that we don't.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
Hi,
On Wed, Jul 03, 2002 at 01:10:08PM -0700, David O'Brien wrote:
> Some one needs to do thru these and really deal with them.
I didn't say they were right, just that they worked ;-)
> * The patch to use -O0 (or remove -O) is wrong, and a test case should be
> submitted to the GCC people.
I think Maxim has already done this.
> * The weak problem has been fixed in the FSF sources -- I could merge a
> a patch to our system GCC from the FSF sources.
Please, unless we are due for a complete upgrade soon... Do you know
when 3.1.1 is due?
> * Someone needs to talk with the XFree86 people to get them to stop using
> `cc' on C++ code. This is not just a FreeBSD issue for them.
They don't. They have all of the right macros in place, it's just that
we didn't have a macro defined for C++ shared libraries. I don't think
we're doing the right thing for the static library cases yet.
At the moment I'm trying to go through all of the XFree86-4 ports and
figure out:
1. What the patches actually do...
2. If we can use one shared ${WRKSRC}, since the ports build multiple
copies of all of the libraries, and they use the wrong (unpatched)
versions of the config files in some cases.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
On Wed, 3 Jul 2002, Erik Greenwald wrote: > > Looks like I'm out of this one, I got up this morning, cvsup'd and built > world just to make sure it was fresh, then I quit getting the crashes. I > d'no if the issue was fixed by something someone else did or what... > It was solved, but thanks for trying and welcome to the club of people willing to get their fingers dirty :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 08:56:02PM +0200, Jeremy Lea wrote: > I can build x11/XFree86-4 with the following patches, which I harvested > from various email's since the gcc 3.1 import. Which ones are really > needed, and why the X11 libraries are built four times during the build > of the meta port, are what I need to figure out next... Some one needs to do thru these and really deal with them. * The patch to use -O0 (or remove -O) is wrong, and a test case should be submitted to the GCC people. * The weak problem has been fixed in the FSF sources -- I could merge a a patch to our system GCC from the FSF sources. * Someone needs to talk with the XFree86 people to get them to stop using `cc' on C++ code. This is not just a FreeBSD issue for them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
> > You were possibly on the right track but we got the answer already :-) > there was a debug statement left in queue.h > > that was breaking some of the queues in libc_r > > possibly where the thread was taken off the run queue. > Now the very important thing is that you keep looking > and hacking :-) > Looks like I'm out of this one, I got up this morning, cvsup'd and built world just to make sure it was fresh, then I quit getting the crashes. I d'no if the issue was fixed by something someone else did or what... - -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KSE /VM question
Unfortunatly thre is a codepath in the KSE system that has not
been tested, due to a bug in the UVM system. Jeff fixed the UVM
problem for me ysesterday but that means that the following
stack trace (representing the code path in question) is now
used and teh resulting panic happens...
Is there a VM expert here that understands the mapping system who I can
tap to help me figure out what I did wrong..
This is a clasic case of one bug hiding another..
Debugger(c030265c) at Debugger+0x45
panic(c0328ee0,1d,1,c0b889d8,1) at panic+0x74
vm_page_free_toq(c0b889d8,c0b889d8,40,c0b889d8,cca32c14) at
vm_page_free_toq+0xd0
vm_page_free(c0b889d8,c0b889d8,0) at vm_page_free+0x15
pmap_dispose_thread(c2a25000,cca32c4c,c02b2fed,c2a25000,b8) at
pmap_dispose_thread+0x84
thread_fini(c2a25000,b8) at thread_fini+0x28
zone_drain(c0ede000) at zone_drain+0x29d
zone_foreach(c02b2d50,cca32d08,c02b0924,c03542c0,1) at zone_foreach+0x2f
uma_reclaim(c03542c0,1,c03296c2,287,c03542c0) at uma_reclaim+0x12
vm_pageout_scan(0,c1cf10c0,cca32d34,c019066c,0) at vm_pageout_scan+0x30
vm_pageout(0,cca32d48,c1cf10c0,c02b13f4,0) at vm_pageout+0x22d
fork_exit(c02b13f4,0,cca32d48) at fork_exit+0xd8
fork_trampoline() at fork_trampoline+0x37
db> gdb
Next trap will enter GDB remote protocol mode
db> s
Stopped at Debugger+0x4e: leave
db> x/s 0xc0328ee0
vm_object_print_pages_cmd+0x3c4:vm_page_free: invalid wire count
(%d), pindex: 0x%lx
if (m->wire_count != 0) {
if (m->wire_count > 1) {
panic("vm_page_free: invalid wire count (%d),
pindex: 0x%lx",
m->wire_count, (long)m->pindex);
}
panic("vm_page_free: freeing wired page\n");
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic at boot in ffs_valloc
I'm also suddenly having a panics - every 5 minutes actually, since my
latest cvsup a few hours ago. They seem to be related to some ufs
and ffs calls..
I'm not able to read my core dumps for some reason (gdb says "kernel
symbol 'cpuhead' not found.") and I don't have the time to scratch a
backtrace down by hand just now.
The panicstring is: "bremfree: bp 0xc77e8670 not locked"
Sincerely,
Rasmus Skaasrup
On Wed, 3 Jul 2002, Andrew R. Reiter wrote:
> :I cvsup'd and built world+kernel a few hours ago and was happy to see
> :KDE working again, but I got a spontaneous reboot while trying to track
> :down a segfault in a mozilla build component. I "boot -v"'ed and as
> :soon as the login prompt came up I hit a panic. I'm guessing the
> :backgorund fsck had something to do with it. I'll hand-copy the trace
> :here; any debugging info needed while my box is stuck at the debugger,
> :lemme know:
>
>
> I don't have the output to show people since I was trying to reproduce but
> couldnt, but i got essentially the same panic, but it came only from a
> syscall to open() that called ufs_create() -> ufs_makeinode ->
> ffs_valloc() -> panic.
>
> I can try and reproduce (tho, mine occured when just running cscope) and
> get a dump.
>
> Cheers,
> Andrew
>
> :FreeBSD/i386 (foo) (ttyv0)
> :
> :login: mode = 041777, inum = 12871, fs = /usr
> :panic: ffs_valloc: dup alloc
> :cpuid = 0; lapic.id =
> :Debugger("panic")
> :Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
> :db> trace
> :Debugger(c02d9eda) at Debugger+0x46
> :panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6
> :ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141
> :ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58
> :ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26
> :ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13
> :ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at
> :ffs_snapshot+0x2a0
> :ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48
> :vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc
> :mount(c159f300,d6afdd14,4,1,202) at mount+0x6a
> :syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c
> :syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> :--- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc,
> :ebp = 0xbfbffd48 ---
> :db>
> :
> :--
> :Anthony Jenkins
> :http://www.mindspring.com/~abjenkins/
> :
> :
> :
> :To Unsubscribe: send mail to [EMAIL PROTECTED]
> :with "unsubscribe freebsd-current" in the body of the message
> :
>
> --
> Andrew R. Reiter
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: what does it take to rsh as root now days?
"David O'Brien" <[EMAIL PROTECTED]> wrote: > I can rlogin to a -CURRENT box as root. However `rsh box id' comes back > with: > > Jul 3 00:11:33 box rshd[4916]: root@dragon as rootk: permission denied > (authentication error). cmd='id' man pam_rhosts should explain that. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
Hi,
On Wed, Jul 03, 2002 at 02:15:13PM -0400, Garance A Drosihn wrote:
> Fwiw, I am also using the system toolchain (as cvsup'ed late last
> night), and not the port.
I can build x11/XFree86-4 with the following patches, which I harvested
from various email's since the gcc 3.1 import. Which ones are really
needed, and why the X11 libraries are built four times during the build
of the meta port, are what I need to figure out next...
Stock -CURRENT just before KSE3, no relevant ports installed before the
build (only cvsup).
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
devel/imake-4:
Maintainer: [EMAIL PROTECTED]
Changes: Makefile
Adds : files/patch-config::cf::FreeBSD.cf files/patch-config::cf::bsdLib.tmpl
Removes: files/patch-d files/patch-xthreads
x11-servers/XFree86-4-Server:
Maintainer: [EMAIL PROTECTED]
Changes:
Adds : files/patch-GL_mesa_src_Imakefile files/patch-OSmesa-Imakefile
files/patch-gcc31
Removes:
x11/XFree86-4-libraries:
Maintainer: [EMAIL PROTECTED]
Changes: files/patch-UIThrStubs.c files/patch-z32 files/patch-z45
Adds : files/patch-bsdLib.rules
Removes:
--- /usr/ports.ref/devel/imake-4/Makefile Thu May 23 10:49:32 2002
+++ devel/imake-4/Makefile Tue Jul 2 00:32:01 2002
@@ -21,6 +21,7 @@
MAINTAINER=[EMAIL PROTECTED]
PREFIX?= ${X11BASE}
+USE_PERL5= yes
.include
@@ -127,6 +128,10 @@
# It's a traditional place ;-)
# InstallXserverSetUID=NO : use Xwrapper.
# End of XFree86 configrations
+
+pre-patch:
+ @${PERL} -pi -e 's|\#\!/usr/bin/perl|\#\!${PERL}|g ' \
+ ${WRKSRC}/util/mkhtmlindex.pl
post-install:
@${MKHTMLINDEX} ${PREFIX}/lib/X11/doc/html
--- /usr/ports.ref/devel/imake-4/files/patch-config::cf::FreeBSD.cf Thu Jan 1
02:00:00 1970
+++ devel/imake-4/files/patch-config::cf::FreeBSD.cfWed Jun 26 22:38:58 2002
@@ -0,0 +1,34 @@
+--- cf/FreeBSD.cf.orig Wed Jun 26 15:44:29 2002
cf/FreeBSD.cf Wed Jun 26 16:21:18 2002
+@@ -80,7 +80,6 @@
+ /*
+ * math.h uses _REENTRANT and stdio.h uses _THREAD_SAFE, so define both.
+ */
+-# define SystemMTDefines -D_REENTRANT -D_THREAD_SAFE
+ /*
+ * FreeBSD has tread-safe api but no getpwnam_r yet.
+ */
+@@ -91,8 +90,13 @@
+ # else
+ # define BuildThreadStubLibrary YES
+ # define NeedUIThrStubs YES
+-# define ThreadsCompileFlags -pthread
+-# define ThreadsLibraries-pthread
++# if (OSRelVersion >= 500016)
++# define SystemMTDefines-D_REENTRANT -D_THREAD_SAFE
++# define ThreadsLibraries -lc_r
++# else
++# define SystemMTDefines-D_REENTRANT -D_THREAD_SAFE
++# define ThreadsLibraries -pthread
++# endif
+ # define SharedX11Reqs $(LDPRELIB) $(XTHRSTUBLIB)
+ # define SharedXtReqs$(LDPRELIB) $(XLIBONLY) $(SMLIB) $(ICELIB)
+$(XTHRSTUBLIB)
+ # endif
+@@ -151,6 +154,7 @@
+ # define CcCmdcc
+ # define CplusplusCmd c++
+ #endif
++#define CplusplusLibC -lstdc++
+
+ #define CppCmd/usr/bin/cpp
+ #define PreProcessCmd CppCmd
--- /usr/ports.ref/devel/imake-4/files/patch-config::cf::bsdLib.tmplThu Jan 1
02:00:00 1970
+++ devel/imake-4/files/patch-config::cf::bsdLib.tmpl Wed Jun 26 22:38:18 2002
@@ -0,0 +1,13 @@
+--- cf/bsdLib.tmpl.origWed Jun 26 16:19:42 2002
cf/bsdLib.tmpl Wed Jun 26 16:20:34 2002
+@@ -39,7 +39,9 @@
+ #define XawClientLibs $(XAWLIB) $(XMULIBONLY) $(XTOOLLIB) $(XPMLIB) $(XLIB)
+ #endif
+
+-#define CplusplusLibC
++#ifndef CplusplusLibC
++#define CplusplusLibC $(CXX)
++#endif
+ #define FrescoSysLibs CplusplusLibC MathLibrary
+
+ /* Allow for libpthread, as overridden by OS definitions */
--- /usr/ports.ref/devel/imake-4/files/patch-d Tue Jun 12 16:59:11 2001
+++ devel/imake-4/files/patch-d Wed Jun 26 22:01:35 2002
@@ -1,19 +0,0 @@
cf/FreeBSD.cf.orig Fri May 4 05:12:35 2001
-+++ cf/FreeBSD.cf Mon Jun 4 19:31:27 2001
-@@ -444,14 +444,14 @@
- /* The GCC strength-reduce bug is fixed for FreeBSD 2.1.5 and later */
- #ifndef DefaultGcc2i386Opt
- #if OSMajorVersion > 2 || (OSMajorVersion == 2 && OSMinorVersion > 1) ||
(OSMajorVersion == 2 && OSMinorVersion == 1 && OSTeenyVersion >= 5)
--#define DefaultGcc2i386Opt -O2
-+#define DefaultGcc2i386Opt
- #endif
- #endif
-
- #ifdef i386Architecture
- # define OptimizedCDebugFlags DefaultGcc2i386Opt
- #else
--# define OptimizedCDebugFlags -O
-+# define OptimizedCDebugFlags
- #endif
-
- #ifndef PreIncDir
--- /usr/ports.ref/devel/imake-4/files/patch-xthreads Tue Jun 12 16:59:11 2001
+++ devel/imake-4/files/patch-xthreads Wed Jun 26 22:02:08 2002
@@ -1,25 +0,0 @@
cf/FreeBSD.cf.orig Thu Jun 7 16:25:47 2001
-+++ cf/FreeBSD.cf Thu Jun 7 16:28:30 2001
-@@ -80,7 +80,6 @@
- /*
- * math.h uses _REENTRANT and stdio.h uses _THREAD_SAFE, so define both.
- */
--# define SystemMTDefines
Re: panic at boot in ffs_valloc
:I cvsup'd and built world+kernel a few hours ago and was happy to see
:KDE working again, but I got a spontaneous reboot while trying to track
:down a segfault in a mozilla build component. I "boot -v"'ed and as
:soon as the login prompt came up I hit a panic. I'm guessing the
:backgorund fsck had something to do with it. I'll hand-copy the trace
:here; any debugging info needed while my box is stuck at the debugger,
:lemme know:
I don't have the output to show people since I was trying to reproduce but
couldnt, but i got essentially the same panic, but it came only from a
syscall to open() that called ufs_create() -> ufs_makeinode ->
ffs_valloc() -> panic.
I can try and reproduce (tho, mine occured when just running cscope) and
get a dump.
Cheers,
Andrew
:FreeBSD/i386 (foo) (ttyv0)
:
:login: mode = 041777, inum = 12871, fs = /usr
:panic: ffs_valloc: dup alloc
:cpuid = 0; lapic.id =
:Debugger("panic")
:Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
:db> trace
:Debugger(c02d9eda) at Debugger+0x46
:panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6
:ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141
:ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58
:ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26
:ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13
:ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at
:ffs_snapshot+0x2a0
:ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48
:vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc
:mount(c159f300,d6afdd14,4,1,202) at mount+0x6a
:syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c
:syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
:--- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc,
:ebp = 0xbfbffd48 ---
:db>
:
:--
:Anthony Jenkins
:http://www.mindspring.com/~abjenkins/
:
:
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with "unsubscribe freebsd-current" in the body of the message
:
--
Andrew R. Reiter
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic at boot in ffs_valloc
I cvsup'd and built world+kernel a few hours ago and was happy to see
KDE working again, but I got a spontaneous reboot while trying to track
down a segfault in a mozilla build component. I "boot -v"'ed and as
soon as the login prompt came up I hit a panic. I'm guessing the
backgorund fsck had something to do with it. I'll hand-copy the trace
here; any debugging info needed while my box is stuck at the debugger,
lemme know:
--
Anthony Jenkins
Additional TCP options:.
Starting background filesystem checks
Wed Jul 3 13:24:09 EDT 2002
FreeBSD/i386 (foo) (ttyv0)
login: mode = 041777, inum = 12871, fs = /usr
panic: ffs_valloc: dup alloc
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c02d9eda) at Debugger+0x46
panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6
ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141
ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58
ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26
ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13
ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at
ffs_snapshot+0x2a0
ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48
vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc
mount(c159f300,d6afdd14,4,1,202) at mount+0x6a
syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc,
ebp = 0xbfbffd48 ---
db>
--
Anthony Jenkins
http://www.mindspring.com/~abjenkins/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
At 8:07 PM +0200 7/3/02, Sheldon Hearn wrote: >Yes, remember that you're building the MATROX stuff, which I'm not. Yes, I should have mentioned that. Is Maxim compiling the matrox drivers? Perhaps I should retry without those. >Also, remember that my patches were for the base system's toolchain, >not lang/gcc31's. Fwiw, I am also using the system toolchain (as cvsup'ed late last night), and not the port. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On (2002/07/03 13:29), Garance A Drosihn wrote: > With his patches I was able to compile and install imake. I was > able to compile XFree86-4-libraries, but the 'make install' of it > fails for me after getting most of the way through. I suspect > this is a build problem, not a cc problem. Yes, remember that you're building the MATROX stuff, which I'm not. Also, remember that my patches were for the base system's toolchain, not lang/gcc31's. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: additional queue macro
At 10:38 AM -0700 7/3/02, Terry Lambert wrote: >Julian Elischer wrote: >> TAILQ_FOREACH_REMOVABLE or TAILQ_FOREACH_SAFE >> (I prefer the first) are my suggestions for the name.) > >TAILQ_FOREACH_MODIFY ? I sense great material for a bikeshed... :-) For mine, how about: TAILQ_FOREACH_VOLATILE -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
Bruce Evans wrote: > On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Mario Goebbels writes: > > >And the second is, when will it be officially activated? Seems to work > > >fine yet (toying around with it). > > > > Some bits are missing yet, for instance the ioctls to change > > disklabels etc. when they're done and it works also with sysinstall > > it'll be standard. > > It shouldn't be standard, because then using it wouldn't be optional. Are you kidding?!? That's why it *should* be standard! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: additional queue macro
Julian Elischer wrote: > TAILQ_FOREACH_REMOVABLE or TAILQ_FOREACH_SAFE > (I prefer the first) are my suggestions for the name.) TAILQ_FOREACH_MODIFY ? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
At 9:27 AM -0700 7/3/02, David O'Brien wrote: >On Wed, Jul 03, 2002, Garance A Drosihn wrote: > > Sheldon has a few informative messages which include > > some patches to test. (although I don't think the patches >> are a complete fix for the problems we're seeing -- see my >> replies to that thread which were sent just last night...) > >I thought Sheldon's patches deal with using C (cc) vs. C++ (c++) >to do the linking. > >Perhaps someone could summarize what is "known". I'm afraid I only have a vague idea. Certainly part of what Sheldon was sorting out was C vs C++, and just general "build problems". With his patches I was able to compile and install imake. I was able to compile XFree86-4-libraries, but the 'make install' of it fails for me after getting most of the way through. I suspect this is a build problem, not a cc problem. I was not able to compile XFree86-4-Server, as I ran into the same compiler error that Maxim reported. Or at least, it looked about the same. After that build failed, I happened to retry the same build (again with the patches Sheldon had recommended) after setting CPUTYPE=i686 in /etc/make.conf. This time the build succeeded, and I was able to install it. At that point I can start XDM, and everything seems fine until I try to log into XDM. At that point, my machine instantly reboots. I have no idea why, but I suspect that the incomplete 'make install' of XFree86-4-libraries probably does not help... It could easily be million other things, too. That's how much I had figured out as of 4am this morning... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
On 03-Jul-2002 Julian Elischer wrote:
> congratulations.. I think that you win the Matt Dillon "got both
> processors to enter the ddb at the same time" award..
>
> On Wed, 3 Jul 2002, David Wolfskill wrote:
>
>> login: panic: vm_page_free: invalid wire count (360), pindex: 0x1
>> cpuid = 0; lapic.id =
>> Debugger("panic")
>> uernteilm etoruatp s9t owpiptihn gi nctpeursr
>> Sttso pdpiesda balte d
>> in_Debugger.0x46: xchgl %ebx,
>> db>
>> al trap 9: general protectinuwlppippelo
>> u 1lcd i10
>> irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx
>> = DPL 0, pres 1, def32 1, gran 1
>> processor eflags= resume, IOPL = 0
>> current process = c)elt r,o=
>> S
>> Xc
>> pDcXKK`K$KhK,KpK4KxK
>
> doing an nm and figuring out where the processor was
> might be informative.
If you have a valid eip you can use addr2line to get the
exact source line. We probably need to not allow concurrent
panics. We already don't allow concurrent ddb sessions, but
we do let both processors panic at the same time I think.
Hmm, this should already be happening though:
panic(const char *fmt, ...)
{
int bootopt;
va_list ap;
static char buf[256];
#ifdef SMP
/*
* We don't want multiple CPU's to panic at the same time, so we
* use panic_cpu as a simple spinlock. We have to keep checking
* panic_cpu if we are spinning in case the panic on the first
* CPU is canceled.
*/
if (panic_cpu != PCPU_GET(cpuid))
while (atomic_cmpset_int(&panic_cpu, NOCPU,
PCPU_GET(cpuid)) == 0)
while (panic_cpu != NOCPU)
; /* nothing */
#endif
I suppose this could be broken if we migrate. I'll try to
think of a better solution. Probably using curthread instead
of cpuid. Try this untested diff (warning, my mailer will
probably botch this):
Index: kern_shutdown.c
===
RCS file: /usr/cvs/src/sys/kern/kern_shutdown.c,v
retrieving revision 1.128
diff -u -r1.128 kern_shutdown.c
--- kern_shutdown.c 12 May 2002 18:27:28 - 1.128
+++ kern_shutdown.c 3 Jul 2002 17:12:32 -
@@ -421,7 +421,7 @@
}
#ifdef SMP
-static u_int panic_cpu = NOCPU;
+static uintptr_t panic_thread = NULL;
#endif
/*
@@ -441,15 +441,17 @@
#ifdef SMP
/*
* We don't want multiple CPU's to panic at the same time, so we
-* use panic_cpu as a simple spinlock. We have to keep checking
-* panic_cpu if we are spinning in case the panic on the first
+* use panic_thread as a simple spinlock. We have to keep checking
+* panic_thread if we are spinning in case the panic on the first
* CPU is canceled.
*/
- if (panic_cpu != PCPU_GET(cpuid))
- while (atomic_cmpset_int(&panic_cpu, NOCPU,
- PCPU_GET(cpuid)) == 0)
- while (panic_cpu != NOCPU)
- ; /* nothing */
+ if (panic_thread != curthread)
+ while (atomic_cmpset_ptr(&panic_thread, NULL, curthread) == 0)
+ while (panic_thread != NULL) {
+#ifdef __i386__
+ ia32_pause();
+#endif
+ }
#endif
bootopt = RB_AUTOBOOT | RB_DUMP;
@@ -479,7 +481,7 @@
/* See if the user aborted the panic, in which case we continue. */
if (panicstr == NULL) {
#ifdef SMP
- atomic_store_rel_int(&panic_cpu, NOCPU);
+ atomic_store_rel_ptr(&panic_thread, NULL);
#endif
return;
}
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
David O'Brien wrote:
>
> On Wed, Jul 03, 2002 at 05:26:50PM +0300, Maxim Sobolev wrote:
> > Hi,
> >
> > I am trying to upgrade installed XFree86-4-Server package, but found that
> > a new gcc can't compile it. Following is relevant error output:
> ...
> > In file included from translate.c:779:
> > ../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
> >
> > ../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
> > (insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
> > (plus:SF (reg:SF 8 st(0) [76])
> > (reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
> > )
> > (expr_list:REG_DEAD (reg:SF 8 st(0) [76])
> > (nil)))
> > ../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
> > eload, at reload1.c:5050
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://www.gnu.org/software/gcc/bugs.html> for instructions.
> > *** Error code 1
> ...
> > Please investigate & fix.
>
> A fix is to "submit a full bug report, with preprocessed source if
> appropriate.".
Oh, I supposed that those dirt is not necessary for majestic FreeBSD
users. :(
Anyway, I've submitted it along with pre-processed source (c/7200), so
that it should be fairly easy to reproduce. There is a similar one
(c/7190), but it is without pre-processed sources, so that I think
that mine is better.
> You can try the gcc31 port and see if it gets any farther.
Could you please try to compile translate.i attached to c/7200 with
gcc from ports (the right command to do it is also in the report) and
let me know if it works or not, because I have neither a time nor
spare bandwith to download/compile gcc just to test it.
Thanks!
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
congratulations.. I think that you win the Matt Dillon "got both
processors to enter the ddb at the same time" award..
On Wed, 3 Jul 2002, David Wolfskill wrote:
> login: panic: vm_page_free: invalid wire count (360), pindex: 0x1
> cpuid = 0; lapic.id =
> Debugger("panic")
> uernteilm etoruatp s9t owpiptihn gi nctpeursr
> Sttso pdpiesda balte d
> in_Debugger.0x46: xchgl %ebx,
> db>
> al trap 9: general protectinuwlppippelo
> u 1lcd i10
> irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = c)elt r,o=
> S
> Xc
> pDcXKK`K$KhK,KpK4KxK
doing an nm and figuring out where the processor was
might be informative.
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
On 03-Jul-2002 Julian Elischer wrote: > > > On Wed, 3 Jul 2002, John Baldwin wrote: > >> >> The argument could be made that you shouldn't be checking in stuff >> until you know how it works, etc., or that you could commit in smaller >> pieces (say, get multiple threads per process for kernel processes >> working in the scheduler and just ignoring userland-only things like >> signals until you have the other working). > > You can't do those separatly unfortulatly.. Sure you could, just have kernel-only KSE processes at first and use some special kernel processes for testing. They would never return to userland but would be adequate to test that all the various run and sleep queues, etc. worked fine. > anyhow, it's not that I don't understand it, it's just that > it's complicated.. That part of my message was overly harsh. I'm sorry. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent bsd.lib.mk changes
On Fri, Jun 21, 2002 at 07:11:16PM -0400, Mikhail Teterin wrote: > On Friday 21 June 2002 06:02 pm, David O'Brien wrote: > = On Fri, Jun 21, 2002 at 05:46:17PM -0400, Mikhail Teterin wrote: > > = > Why can't we have some way to explicitly list what is and what is not > = > needed? > = > = Feel free to send a patch adding "ONLYSHAREDLIBS". "INTERNALLIB" in no > = logical way I can think of would lead someone to think that only shared > = libs should be built and they should be installed. > > Here I agree completely. I have always been puzzled by the naming of this > knob. But it was the only way to achieve the goal. It is now a different > knob entirely -- but under the same name, which is quite confusing. > > I am thinking, however, of something explicit like: > > WANT_SHARED_LIB ?= yes > WANT_STATIC_LIB ?= yes > WANT_PIC_LIB?= yes > > with the existing NOPROFILE and others to remain as "compatibility" > interfaces for a while, for example: > > .ifndef WANT_PIC_LIB > .ifndef NOPROFILE > WANT_PIC_LIB = yes > .else > WANT_PIC_LIB = no > .endif > .endif > > The last change broke not only some ports, but who knows how many > personal projects, which where doing the Right Thing (IMO) and used > the bsd.*.mk > The lost functionality should now be available again in revision 1.132. > I will not have time to make a patch in a while :-\, however... > > Any way to determine quickly from inside the Makefile, which version > of the bsd.lib.mk is installed? > OSVERSION. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg40392/pgp0.pgp Description: PGP signature
Re: KSE signal problems still
On Wed, 3 Jul 2002, John Baldwin wrote: > > The argument could be made that you shouldn't be checking in stuff > until you know how it works, etc., or that you could commit in smaller > pieces (say, get multiple threads per process for kernel processes > working in the scheduler and just ignoring userland-only things like > signals until you have the other working). You can't do those separatly unfortulatly.. anyhow, it's not that I don't understand it, it's just that it's complicated.. The new version is as clse as I can get quickly but it still needs some cleaning. > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power > Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
Sick sick sick :-) On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Jul > ian Elischer writes: > > >aren't you suppost to be honeymooning from yesterday? > > I am, I'm not working, only doing things I do for fun :-) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 11:45:19AM -0400, Garance A Drosihn wrote: > which has been seeing sporadic messages over the past week > or two. Sheldon has a few informative messages which include > some patches to test. (although I don't think the patches > are a complete fix for the problems we're seeing -- see my > replies to that thread which were sent just last night...) I thought Sheldon's patches deal with using C (cc) vs. C++ (c++) to do the linking. Herhaps someone could summarize what is "known". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange netstat output on Intel pro/1000 netperf testing
In article <[EMAIL PROTECTED]>, zhang jack <[EMAIL PROTECTED]> wrote: > Hi, > When I using netperf to test Intel Pro/1000 performance, > I got strange netstat output: > > #./netperf -H 10.0.0.2 > TCP STREAM TEST to 10.0.0.2 > > on 10.0.0.2, I start netstat -w 1 , but got strange output: > it seems the link is dowm and up ceaselessly. > > input(Total) output > packets errs bytespackets errs bytes colls > 1 01212460 1 0 9462 0 > 553 01206100277 0 10458 0 > 1 01203800 1 0 9291 0 > 554 01214652278 0 10461 0 > 1 01203816 1 0 9291 0 > 553 01214636277 0 10461 0 > 1 01203888 1 0 9291 0 > 553 01214636277 0 10461 0 > 4 01203784 2 0 9291 0 > 555 01214692277 0 10465 0 > 1 01195140 1 0 9225 0 > 551 01214596276 0 10457 0 > 1 01203768 1 0 9291 0 > 553 01214652277 0 10461 0 That is just because the interface statistics are only updated once per second, and your 1-second netstat delays are in sync with the stats updates. If you do "netstat -w 2" or more, this artifact vanishes. John -- John Polstra John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
After building today's -CURRENT successfully (CVSup started at 0347 hrs.
Pacific (7 hrs. west of GMT/UTC at this time of year) from cvsup14, with
the addition of Ruslan's updates to the src/share/mk/bsd.*.mk files),
I thought it might be of use to just let this SMP (2x866 PIII) box sit
in a "make -j8 buildworld" loop for a while and see how far it gets.
The answer would appear to be "not as far as I would have expected" --
I tried to ssh back into the machine, was getting no response, so I
resumed the "screen" session on another machine that had a "tip" going
to the test machine's serial console. This is what I see (modulo tab/space
replacement):
Local package initialization:Creating DISK md10
md10: invalid primary partition table: no magic
md10: invalid primary partition table: no magic
[1] 234 Floating point exception (core dumped)
Jul 3 07:21:37 freebeast kernel: pid 234 (newfs), uid 0: exited on signal 8 (core
dumped)
apache cvsupd
.
Additional TCP options:.
Starting background filesystem checks
Wed Jul 3 07:21:38 PDT 2002
FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)
login: panic: vm_page_free: invalid wire count (360), pindex: 0x1
cpuid = 0; lapic.id =
Debugger("panic")
uernteilm etoruatp s9t owpiptihn gi nctpeursr
Sttso pdpiesda balte d
in_Debugger.0x46: xchgl %ebx,
db>
al trap 9: general protectinuwlppippelo
u 1lcd i10
irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = c)elt r,o=
S
Xc
pDcXKK`K$KhK,KpK4KxK
Fatal trap 12: page fault while in kernel mode
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x199
fault code = supervisor read, page not present
instruction pointer = 0x1ba0:0x9b
stack pointer = 0x10:0xc03d39a8
frame pointer = 0x10:0xc0361ba0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, IOPL = 0
current process = 92825 (cc1)
kernel: type 12 trap, code=0
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db>
which isn't all that bad, in that it should provide some access to poke
around and get some clues as to what broke.
Unfortunately, that serial console appears to be completely unresponsive:
I tried typing "tr" at it; nothing. Sent a break; nothing.
Is there anything anyone can suggest for getting some additional
information out of this? I don't have a critical need for the machine
until tomorrow morning, so the only disadvantage to leaving it on is that
it consumes electricity & generates heat.
Thanks,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Trying to support or use Microsoft products makes about as much sense
as painting the outside of a house with watercolors.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
At 5:26 PM +0300 7/3/02, Maxim Sobolev wrote: >Hi, > >I am trying to upgrade installed XFree86-4-Server package, >but found that a new gcc can't compile it. Following is >relevant error output: [...skipped...] >Please investigate & fix. Some information is in the email-thread under the subject: Re: What's the right way to build XFree86-4 now? which has been seeing sporadic messages over the past week or two. Sheldon has a few informative messages which include some patches to test. (although I don't think the patches are a complete fix for the problems we're seeing -- see my replies to that thread which were sent just last night...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On Wed, Jul 03, 2002 at 05:26:50PM +0300, Maxim Sobolev wrote:
> Hi,
>
> I am trying to upgrade installed XFree86-4-Server package, but found that
> a new gcc can't compile it. Following is relevant error output:
...
> In file included from translate.c:779:
> ../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
>
> ../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
> (insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
> (plus:SF (reg:SF 8 st(0) [76])
> (reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
> )
> (expr_list:REG_DEAD (reg:SF 8 st(0) [76])
> (nil)))
> ../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
> eload, at reload1.c:5050
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://www.gnu.org/software/gcc/bugs.html> for instructions.
> *** Error code 1
...
> Please investigate & fix.
A fix is to "submit a full bug report, with preprocessed source if
appropriate.".
You can try the gcc31 port and see if it gets any farther.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
dump(8) is hosed
On a 27-June-2002 23:02:00 UTC system (just before ipfw2 went in, pre-KSE3), dump will not complete dumping more than 5GB. At that point it stops responding properly to ^T, which should give "DUMP: 47.52% done, finished in 1:19". At the 5GB mark, ^T gives: load: 0.00 cmd: dump 3981 [physstr] 2.11u 43.06s 0% 1536k and never changes. The user and system times never advance. Anybody have any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Xmms
Andrzej Kwiatkowski <[EMAIL PROTECTED]> wrote: > I've upgrade my FreeBSD 5.0 two days ago. > Yesterday when i have compile XMMS from ports, Threads were broken. Update and try again. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gcc 3.1 can't compile XFree86-4-Server
Hi,
I am trying to upgrade installed XFree86-4-Server package, but found that
a new gcc can't compile it. Following is relevant error output:
rm -f texutil.o
LD_LIBRARY_PATH=../../../../exports/lib cc -c -pipe -O -mpreferred-stack-boundar
y=2 -march=pentium-mmx -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I..
/../../../exports/include -I../../../../exports/include/X11 -I../../../../includ
e/extensions-I../../../../extras/Mesa/src -I../../../../lib/GL/dri
-I../../../.. -I../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNAR
ROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURN
S_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA
-DUSE_X86_ASM -DUSE_MMX_ASM -ansi -pedantic -Dasm=__asm -W
all -Wpointer-arith -I../../../../exports/include -I../../../../exports/include
/X11 -I../../../../include/extensions -I../../../../extras/Mesa/src -I
../../../../lib/GL/dri -I../../../.. -I../../../../exports/include -DCSRG_BAS
ED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWD
API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_U
SE_DLOPEN -DGLX_USE_MESA-DUSE_X86_ASM -DUSE_MMX_ASM-fPIC
texutil.c
rm -f translate.o
LD_LIBRARY_PATH=../../../../exports/lib cc -c -pipe -O -mpreferred-stack-boundar
y=2 -march=pentium-mmx -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I..
/../../../exports/include -I../../../../exports/include/X11 -I../../../../includ
e/extensions-I../../../../extras/Mesa/src -I../../../../lib/GL/dri
-I../../../.. -I../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNAR
ROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURN
S_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA
-DUSE_X86_ASM -DUSE_MMX_ASM -ansi -pedantic -Dasm=__asm -W
all -Wpointer-arith -I../../../../exports/include -I../../../../exports/include
/X11 -I../../../../include/extensions -I../../../../extras/Mesa/src -I
../../../../lib/GL/dri -I../../../.. -I../../../../exports/include -DCSRG_BAS
ED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWD
API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_U
SE_DLOPEN -DGLX_USE_MESA-DUSE_X86_ASM -DUSE_MMX_ASM-fPIC
translate.c
In file included from translate.c:779:
../../../../extras/Mesa/src/trans_tmp.h: In function `trans_1_GLdouble_1ub_elt':
../../../../extras/Mesa/src/trans_tmp.h:124: could not find a spill register
(insn 96 94 97 (set (subreg:SF (reg:QI 75) 0)
(plus:SF (reg:SF 8 st(0) [76])
(reg:SF 9 st(1) [80]))) 525 {*fop_sf_comm_nosse} (insn_list 87 (nil)
)
(expr_list:REG_DEAD (reg:SF 8 st(0) [76])
(nil)))
../../../../extras/Mesa/src/trans_tmp.h:124: Internal compiler error in failed_r
eload, at reload1.c:5050
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
*** Error code 1
Stop in /tmp/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/lib/GL/mes
a/src.
*** Error code 1
Stop in /tmp/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/lib/GL.
*** Error code 1
Please investigate & fix.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Bruce Evans writes: >> >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: >> >> Some bits are missing yet, for instance the ioctls to change >> >> disklabels etc. when they're done and it works also with sysinstall >> >> it'll be standard. >> > >> >It shouldn't be standard, because then using it wouldn't be optional. >> >> It will be standard because the current code does not support at >> least two of our platforms for normal disk sizes and none of our >> platforms for big disk sizes. > >This is mostly because resources have been diverted away from updating >working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > >> Some bits are missing yet, for instance the ioctls to change > >> disklabels etc. when they're done and it works also with sysinstall > >> it'll be standard. > > > >It shouldn't be standard, because then using it wouldn't be optional. > > It will be standard because the current code does not support at > least two of our platforms for normal disk sizes and none of our > platforms for big disk sizes. This is mostly because resources have been diverted away from updating working code to write a second system. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ASUS CUSL2 panic on acpi
On Tue, Jul 02, 2002 at 11:55:18AM -0700, Shizuka Kudo wrote: > Dear all, > > I wonder if anyone experienced the same issue as mime. I have an ASUS CUSL2 running >-current and > starting about three days ago, it panic when acpi is autoloaded. If I unset >acpi_load at the boot > prompt, the machine works fine. > > Here's the panic message and a trace for those interested > > acpi0: on motherboard > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x16 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc04f9aca > stack pointer = 0x10:0xc054ea14 > frame pointer = 0x10:0xc054ea34 > 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 = 0 (swapper) > kernel: type 12 trap, code=0 > Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax > db> trace > AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at >AcpiExReadDataFromField+0x5a > AcpiExResolveNodeToValue(c0f005b0,c0f00400,1,c0ed6d40,c054eab0) at >AcpiExResolveNodeToValue+0xd9 > AcpiExResolveToValue(c0f005b0,c0f00400,c0f00400,0,c054eab0) at >AcpiExResolveToValue+0x53 > AcpiExResolveOperands(5b80,c0f005b4,c0f00400,c0efbe00,c0f00400) at >AcpiExResolveOperands+0x1cf > AcpiDsEvalRegionOperands(c0f00400,c25d6480,c050411e,c25d6480,0) at >AcpiDsEvalRegionOperands+0x50 > AcpiDsExecEndOp(c0f00400,c054eb14,c0f00414,c0f0040c,cdd4f1b1) at >AcpiDsExecEndOp+0x258 > AcpiPsParseLoop(c0f00400,c257f900,c054eb74,0,0) at AcpiPsParseLoop+0x579 > AcpiPsParseAml(c0f00400,c25dcc40,0,cdd4f1a6,e) at AcpiPsParseAml+0x7c > AcpiDsExecuteArguments(c0efbe00,c051de10,e,cdd4f1a6,c257fdc0) at >AcpiDsExecuteArguments+0x182 > AcpiDsGetRegionArguments(c257fdc0,0,c0efbe00,1,c054ec10) at >AcpiDsGetRegionArguments+0x56 > AcpiNsInitOneObject(c0efbe00,1,c054ec60,0,0) at AcpiNsInitOneObject+0xd8 > AcpiNsWalkNamespace(0,,,1,c0500620) at AcpiNsWalkNamespace+0xad > AcpiWalkNamespace(0,,,c0500620,c054ec60) at AcpiWalkNamespace+0x77 > AcpiNsInitializeObjects(0,c054ecc8,c050b8ab,0,2) at AcpiNsInitializeObjects+0x4d > AcpiEnableSubsystem(0,2,c04fd110,0,0) at AcpiEnableSubsystem+0x8a > acpi_attach(c25d7580,c25b5090,c03d3590,c0ed4d00,c0f04c80) at acpi_attach+0x13b > device_probe_and_attach(c25d7580,c0f04c80,c054ed2c,c0368864,c0f04c80) at > device_probe_and_attach+0xaf > bus_generic_attach(c0f04c80,0,c0ed4d00,c0efda80,c0f04c80) at bus_generic_attach+0x28 > nexus_attach(c0f04c80,c2596090,c03d3590,c03c4480,0) at nexus_attach+0x14 > device_probe_and_attach(c0f04c80,c0ef9780,c054ed80,c035b5e5,c0f04f00) at > device_probe_and_attach+0xaf > root_bus_configure(c0f04f00,c03c4480,0,c054ed98,c020b175) at root_bus_configure+0x28 > configure(0,54b000,54bc00,54b000,0) at configure+0x35 > mi_startup() at mi_startup+0xb5 > begin() at begin+0x43 > db> > Hi, I'm getting a similar message with my Asus A7M266 (Yesterday's sources). What is the best way to record those messages at boot time? Writing them down by hand is pretty suboptimal and I don´t have a serial console installed. TIA, Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Mario Goebbels writes: >> >And the second is, when will it be officially activated? Seems to work >> >fine yet (toying around with it). >> >> Some bits are missing yet, for instance the ioctls to change >> disklabels etc. when they're done and it works also with sysinstall >> it'll be standard. > >It shouldn't be standard, because then using it wouldn't be optional. It will be standard because the current code does not support at least two of our platforms for normal disk sizes and none of our platforms for big disk sizes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Mario Goebbels writes: > >And the second is, when will it be officially activated? Seems to work > >fine yet (toying around with it). > > Some bits are missing yet, for instance the ioctls to change > disklabels etc. when they're done and it works also with sysinstall > it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current results (was something funny with soft updates?)
Thus spake Terry Lambert <[EMAIL PROTECTED]>: > Personally, I prefer knowing my code should work before giving > it to the compiler, rather than using the compiler to think > about things I'm too lazy/incapable of thinking of on my own. > Given that, I would always favor a trade for faster run time > and slower compile time. Error checking can be a good thing, but then there's... javac: Variable MIGHT have been used uninitialized. I don't really know because I can't do dataflow analysis, but I will refuse to compile until you change your code. On the topic of good commercial compilers, I always liked the old versions of Borland TurboC (later BorlandC). They generated compact, efficient code with a number of reasonable optimizations. (I suppose that isn't hard when your target platforms range from the 8086 to the 80386.) For the record, TurboC 1.0 on an 8088 is roughly half as fast as GCC 2.95 on a 450MHz Pentium 3. ``For every change in hardware capacity, there is an equal and opposite change in software efficiency.'' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current results (was something funny with soft updates?)
On Wed, 3 Jul 2002, Garance A Drosihn wrote: > At 11:01 PM -0700 7/2/02, Matthew Dillon wrote: > > I get just about the same performance for GCC2 as I > > do for GCC3 in the tests I've run so far. It makes > > me wonder what the hell GCC3 is burning all that > > cpu *on*. > > One of the guys here at RPI (dec, actually) claims he got > buildworld under current to run at more reasonable speeds > by explicitly setting the CPUTYPE. I haven't had the time > to run any experiments with that yet. I got some improvements in generated code for a microbenchmark by compiling with -march=. gcc on i386's now likes to "optimize" "andb $1,%al" and "testb $1,%al" as "andl $1,%eax" and "testl $1,%eax", respectively. This tends to give a large pessimization (50% for the above in a loop) on at least PentiumPro's and PII's due to a partal register stall. Compiling with -march=pentium2 regains the original speed on a Celeron400 at least by zero-extending %eax before using it, but double-crosses itself by going back to using %al and not actually using %eax. Manually changing the code back to use %eax gave a 5% speedup for the loop relative to the old version. The manual change also gave a 5% speedup for an AthlonXP. AthlonXP's don't have partial register stalls and all versions generated by gcc gave the same results (-march=athlon-xp generated the same code as -march=pentium2). Summary: we can break even on all tested arches with gcc-3 for the microbenchmark by setting CPUTYPE right. We can beat gcc-2 by tweaking the generated code to be what gcc-3 apparently intended. But I don't like setting CPUTYPE or use -march, since I want to run the same code on different (i386-sub-)arches. I have 2 different ones on active machines and 3 more on inactive machines). Releases need to run on even more arches. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
On Wed, 2002-07-03 at 10:59, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Jul > ian Elischer writes: > > >aren't you suppost to be honeymooning from yesterday? > > I am, I'm not working, only doing things I do for fun :-) Isn't it a bit worrying when the two overlap? :) -- Simon Dick [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Jul ian Elischer writes: >aren't you suppost to be honeymooning from yesterday? I am, I'm not working, only doing things I do for fun :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
On 03-Jul-2002 Julian Elischer wrote: > > Expanding on my own mail: > > On Wed, 3 Jul 2002, Julian Elischer wrote: > >> On Wed, 3 Jul 2002, John Baldwin wrote: >> >> > >> > Well then it must be full of races then that were fixed since DP1. >> > *sigh* I wonder how many other things were lost and need to be >> > reimplemented. >> > > > Almost anything you checked into psignal will need looking at. > It may not be mising but since signals for threaded processes are > fundamentally different than signals for non threaded processes, some > things "just don't apply". > > for example if you checked in something to code that just doesn;t exist > any more in a KSE kernel, what is the correct integration? > > Each one has to be evaluated on it's own.. The one in question here was fairly simple, it just expanded the sched_lock locking some. The argument could be made that you shouldn't be checking in stuff until you know how it works, etc., or that you could commit in smaller pieces (say, get multiple threads per process for kernel processes working in the scheduler and just ignoring userland-only things like signals until you have the other working). -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
Expanding on my own mail: On Wed, 3 Jul 2002, Julian Elischer wrote: > On Wed, 3 Jul 2002, John Baldwin wrote: > > > > > Well then it must be full of races then that were fixed since DP1. > > *sigh* I wonder how many other things were lost and need to be > > reimplemented. > > Almost anything you checked into psignal will need looking at. It may not be mising but since signals for threaded processes are fundamentally different than signals for non threaded processes, some things "just don't apply". for example if you checked in something to code that just doesn;t exist any more in a KSE kernel, what is the correct integration? Each one has to be evaluated on it's own.. > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw divert not accepted
Operator error, sorry for the false alarm. I had removed all of my IPFIREWALL options from my config in an attempt to find the cause of instability. I'm surprised that ipfw(8) did anything useful at all with that kernel. -- Thanks a lot, Georg. Am Mi, 2002-07-03 um 10.48 schrieb Maxim Sobolev: > "Georg-W. Koltermann" wrote: > > > > hunter# ipfw add 50 divert natd all from any to any via fxp0 > > ipfw: getsockopt(IP_FW_ADD): Invalid argument > > Add "option IPFIREWALL_FORWARD" into your kernel config. > > -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
On Wed, 3 Jul 2002, John Baldwin wrote: > > On 03-Jul-2002 Julian Elischer wrote: > > > > > > On Wed, 3 Jul 2002, John Baldwin wrote: > > > >> > >> Erm, I thought I changd signotify() to require sched_lock and made the > >> second half of psignal() (the whole case statement) lock sched_lock. > >> Did you change that? (To Julian) > > > > psignal as a whole hasn't existed in the KSE tree since December. > > > > I must have missed it in the complicated merge that came from that in P4. > > > > I just checked it in like this for now to stop > > the panics until I can work out what he equivalent > > change to your is.. > > > > (feel free to check out the new psignal/tdsignal > > combination.) > > Well then it must be full of races then that were fixed since DP1. > *sigh* I wonder how many other things were lost and need to be > reimplemented. > Psignal is asside from kern_switch.c probably the largest single casualty. I'm just checking in a cleanup now.. wait a few minutes. > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
aren't you suppost to be honeymooning from yesterday? On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
Julian Elischer wrote: > Should ALL threads be awakened, or is it enough if ONE thread awakens to > deliver the thread. > > For right now it's mostly important that single threaded processs act > as they used to. We can always change how multithreaded processes > work. POSIX makes no guarantees for threads delivery of signals. Specifically, signals are not thread-things, they are process things, and there are seperate threads-things for sending the moral equivalents (e.g. pthread_kill) to threads on an individual basis, but the system is not expected to make a distinction on signal delivery as to what theread is running, nor are there expected to be per thread masking, etc.. Garrett would probably be the right person to ask; he's a much better POSIX lawyer. This is really the problem I tried to explain earlier when it came to the disabling on SIG_POLL on a per descriptor basis. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw divert not accepted
"Georg-W. Koltermann" wrote: > > hunter# ipfw add 50 divert natd all from any to any via fxp0 > ipfw: getsockopt(IP_FW_ADD): Invalid argument Add "option IPFIREWALL_FORWARD" into your kernel config. -Maxim > hunter# ipfw list > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 65000 allow ip from any to any > 65535 deny ip from any to any > hunter# ifconfig fxp0 > fxp0: flags=8843 mtu 1500 > inet6 fe80::2c0:9fff:fe05:9a1f%fxp0 prefixlen 64 scopeid 0x1 > inet 172.17.22.32 netmask 0xff00 broadcast 172.17.22.255 > ether 00:c0:9f:05:9a:1f > media: Ethernet autoselect (100baseTX ) > status: active > hunter# ps ax | grep nat > 188 ?? Is 0:00,00 /sbin/natd -t 255.255.255.255 -n fxp0 > 1059 p1 RV 0:00,00 grep nat (csh) > hunter# > > > > This is with a -current of date=2002.06.27.22.00.00. > > -- > Regards, > Georg. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About GEOM...
In message <[EMAIL PROTECTED]>, Mario Goebbels writes: >Hi! > >I have some questions about it. > >The first one is, when I compiled GEOM into the kernel, will physical >disks be controlled by it already? Or does it apply to md mounted >devices yet? all disks should be GEOM'ized. >And the second is, when will it be officially activated? Seems to work >fine yet (toying around with it). Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. Before 5.0 if at all possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
On 03-Jul-2002 Julian Elischer wrote: > > > On Wed, 3 Jul 2002, John Baldwin wrote: > >> >> Erm, I thought I changd signotify() to require sched_lock and made the >> second half of psignal() (the whole case statement) lock sched_lock. >> Did you change that? (To Julian) > > psignal as a whole hasn't existed in the KSE tree since December. > > I must have missed it in the complicated merge that came from that in P4. > > I just checked it in like this for now to stop > the panics until I can work out what he equivalent > change to your is.. > > (feel free to check out the new psignal/tdsignal > combination.) Well then it must be full of races then that were fixed since DP1. *sigh* I wonder how many other things were lost and need to be reimplemented. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
On Wed, 3 Jul 2002, Bruce Evans wrote:
> On Tue, 2 Jul 2002, Julian Elischer wrote:
>
> Maybe just remove the foot-shooting that releases it?
Yes I'm rationalising it at the moment..
turns out that just holding it for all of tdsignal works well.
Also removing it from setrunnable() is ok as all the callers I could find
have already locked it.
I checked in a stopgap to stop panics but I'm reworking it now.
the trouble is that thread semantics are really not well
defined for multi thread processes.
What does it mean to make a process run when it has many threads?
Should ALL threads be awakened, or is it enough if ONE thread awakens to
deliver the thread.
For right now it's mostly important that single threaded processs act
as they used to. We can always change how multithreaded processes
work.
>
> % Index: kern_sig.c
> % ===
> % RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
> % retrieving revision 1.170
> % retrieving revision 1.171
> % diff -u -1 -r1.170 -r1.171
> % --- kern_sig.c 29 Jun 2002 02:00:01 - 1.170
> % +++ kern_sig.c 29 Jun 2002 17:26:18 - 1.171
> % @@ -1486,15 +1540,9 @@
> % */
> % - if (p->p_stat == SRUN) {
> % + mtx_unlock_spin(&sched_lock);
> ^ shoot foot
> % + if (td->td_state == TDS_RUNQ ||
> % + td->td_state == TDS_RUNNING) {
>
> I think sched_lock is needed for checking td_state too (strictly to use
> the result of the check, so the lock is not critical if the use doesn't
> do anything harmful), but there is no lock indication for td_state
> in proc.h like there used to be for p_stat.
>
> % + signotify(td->td_proc);
>
> Holding sched_lock when calling signotify() used to be an error, but that
> was changed in rev.1.155. This signotify() call seems to be bogus anyway.
> signotify() should only be called after the signal mask is changed. The
> call to signotify() here was removed in rev.1.154 when the semantics of
> signotify() was changed a little. Bogus calls to signotify() just waste
> time.
Signotify is already calledin psignal so I've removed this one
from my version.
>
> % #ifdef SMP
> % - struct kse *ke;
> % - struct thread *td = curthread;
> % -/* we should only deliver to one thread.. but which one? */
> % - FOREACH_KSEGRP_IN_PROC(p, kg) {
> % - FOREACH_KSE_IN_GROUP(kg, ke) {
> % - if (ke->ke_thread == td) {
> % - continue;
> % - }
> % - forward_signal(ke->ke_thread);
> % - }
> % - }
> % + if (td->td_state == TDS_RUNNING && td != curthread)
> % + forward_signal(td);
> % #endif
>
> forward_signal() was called with sched_lock held in rev.1.170, and
> forward_signal() still requires it to be held. I think sched_lock is
> needed for checking td_state too, as above. Here it is fairly clear
> that calling forward_signal() bogusly after losing a race is harmless.
> It just wakes up td to look for a signal that isn't there or can't
> be handled yet. Since this only happens if we lose a race, it may be
> more efficient to let it happen (rarely) than to lock (always) to prevent
> it happening. But we already held the lock so the locking was free
> except for latency issues.
much of what you say will be in my next commit
I told Andrew Gallatin that I would work on cleaning up
tdsignal and maybe psignal tonight, so that's what I've been doing..
it's not perfect tough..
but it clears it up a bit..
I'm just testing it at the moment.
>
> Bruce
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
At 4:00 AM -0400 7/3/02, Garance A Drosihn wrote: >I started up XDM, and that also worked. Not only that, but my >machine didn't instantly reboot when XDM started, which had been >happening to me for the last few days... Bah humbug. I went to log into XDM, and the machine sat there for awhile, and then rebooted. That might have been because the -libraries were only partially installed, though... Still, it's a step forward. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
At 3:18 AM -0400 7/3/02, Garance A Drosihn wrote: >At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote: >>c) ports/x11-servers/XFree86-4-Server: >> >>Add the attached patch-gcc31, taken from Motoyuki Konno's post to >><[EMAIL PROTECTED]> with the following Message-ID: >> >> <[EMAIL PROTECTED]> > >I thought I'd pretend that #b worked perfectly, and try this too. >In my case, I also wanted the matrox drives, so I have > export WITH_MATROX_GXX_DRIVER=yes > >but that still died with "internal compiler error in failed_reload, >at reload1.c:5050", while compiling translate.c, while processing >included file ../../../../extras/Mesa/src/trans_tmp.h. > >So, no joy in mudville just yet... So As I mentioned in another thread, [EMAIL PROTECTED] had been telling me that compiles under gcc3 go faster when he sets CPUTIME. So just for the fun of it I added CPUTIME=i686 in my /etc/make.conf, and tried to recompile the XFree86-4-Server. This time it compiled. I tried a 'make install', and that also worked. I started up XDM, and that also worked. Not only that, but my machine didn't instantly reboot when XDM started, which had been happening to me for the last few days... [this on a dual-CPU, 650 MHz, Pentium 3 machine. No gnome, no KDE, just plain X with twm as the window manager...] So, mudville is a bit tired, but this is a definite step forward! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfw divert not accepted
hunter# ipfw add 50 divert natd all from any to any via fxp0 ipfw: getsockopt(IP_FW_ADD): Invalid argument hunter# ipfw list 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 deny ip from any to any hunter# ifconfig fxp0 fxp0: flags=8843 mtu 1500 inet6 fe80::2c0:9fff:fe05:9a1f%fxp0 prefixlen 64 scopeid 0x1 inet 172.17.22.32 netmask 0xff00 broadcast 172.17.22.255 ether 00:c0:9f:05:9a:1f media: Ethernet autoselect (100baseTX ) status: active hunter# ps ax | grep nat 188 ?? Is 0:00,00 /sbin/natd -t 255.255.255.255 -n fxp0 1059 p1 RV 0:00,00 grep nat (csh) hunter# This is with a -current of date=2002.06.27.22.00.00. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current results (was something funny with soft updates?)
On Tue, Jul 02, 2002 at 11:01:14PM -0700, Matthew Dillon wrote: > (csh built with GCC2, -O3) > test3:/home/dillon> time ./x.csh > 0.832u 0.848s 0:01.68 99.4% 881+645k 0+0io 0pf+0w > test3:/home/dillon> time ./x.csh > 0.926u 0.755s 0:01.68 99.4% 889+654k 0+0io 0pf+0w > > (csh built with GCC3, -O3) You aren't taking advantage of what GCC 3.1 gives you. Try optimizing for your CPU also, -march=pentium4. Also the extra slowdown with Gcc 3.1 is all the changes needed in the backend to handle ISO-C++ and Java. I guess I should just stay out of this type of discussion... but I hate it when people are extra-critical about a piece of software w/o learning something about it first. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE signal problems still
On Wed, 3 Jul 2002, Bruce Evans wrote:
> Maybe just remove the foot-shooting that releases it?
>
> % Index: kern_sig.c
> % ===
> % RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
> % retrieving revision 1.170
> % retrieving revision 1.171
> % diff -u -1 -r1.170 -r1.171
> % --- kern_sig.c 29 Jun 2002 02:00:01 - 1.170
> % +++ kern_sig.c 29 Jun 2002 17:26:18 - 1.171
> % @@ -1486,15 +1540,9 @@
> % */
> % - if (p->p_stat == SRUN) {
> % + mtx_unlock_spin(&sched_lock);
> ^ shoot foot
> % + if (td->td_state == TDS_RUNQ ||
> % + td->td_state == TDS_RUNNING) {
>
> I think sched_lock is needed for checking td_state too (strictly to use
> the result of the check, so the lock is not critical if the use doesn't
> do anything harmful), but there is no lock indication for td_state
> in proc.h like there used to be for p_stat.
>
> % + signotify(td->td_proc);
>
> Holding sched_lock when calling signotify() used to be an error, but that
> was changed in rev.1.155. This signotify() call seems to be bogus anyway.
> signotify() should only be called after the signal mask is changed. The
> call to signotify() here was removed in rev.1.154 when the semantics of
> signotify() was changed a little. Bogus calls to signotify() just waste
> time.
>
> % #ifdef SMP
> % - struct kse *ke;
> % - struct thread *td = curthread;
> % -/* we should only deliver to one thread.. but which one? */
> % - FOREACH_KSEGRP_IN_PROC(p, kg) {
> % - FOREACH_KSE_IN_GROUP(kg, ke) {
> % - if (ke->ke_thread == td) {
> % - continue;
> % - }
> % - forward_signal(ke->ke_thread);
> % - }
> % - }
> % + if (td->td_state == TDS_RUNNING && td != curthread)
> % + forward_signal(td);
> % #endif
>
> forward_signal() was called with sched_lock held in rev.1.170, and
> forward_signal() still requires it to be held. I think sched_lock is
> needed for checking td_state too, as above. Here it is fairly clear
> that calling forward_signal() bogusly after losing a race is harmless.
> It just wakes up td to look for a signal that isn't there or can't
> be handled yet. Since this only happens if we lose a race, it may be
> more efficient to let it happen (rarely) than to lock (always) to prevent
> it happening. But we already held the lock so the locking was free
> except for latency issues.
>
> Bruce
Untested fix for thes bugs and some style bugs in tdsignal():
Index: kern_sig.c
===
RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.171
diff -u -2 -r1.171 kern_sig.c
--- kern_sig.c 29 Jun 2002 17:26:18 - 1.171
+++ kern_sig.c 3 Jul 2002 07:42:31 -
@@ -1468,5 +1449,5 @@
/*
* The force of a signal has been directed against a single
- * thread. We need to see what we can do about knocking it
+ * thread. We need to see what we can do about knocking it
* out of any sleep it may be in etc.
*/
@@ -1485,8 +1466,7 @@
*/
mtx_lock_spin(&sched_lock);
- if ((action == SIG_DFL) && (prop & SA_KILL)) {
- if (td->td_priority > PUSER) {
+ if (action == SIG_DFL && (prop & SA_KILL)) {
+ if (td->td_priority > PUSER)
td->td_priority = PUSER;
- }
}
mtx_unlock_spin(&sched_lock);
@@ -1496,7 +1476,7 @@
* except that stopped processes must be continued by SIGCONT.
*/
- if (action == SIG_HOLD) {
+ if (action == SIG_HOLD)
goto out;
- }
+
mtx_lock_spin(&sched_lock);
if (td->td_state == TDS_SLP) {
@@ -1531,24 +1511,17 @@
}
goto runfast;
- /* NOTREACHED */
-
} else {
/*
-* Other states do nothing with the signal immediatly,
+* Other states do nothing with the signal immediately,
* other than kicking ourselves if we are running.
* It will either never be noticed, or noticed very soon.
*/
- mtx_unlock_spin(&sched_lock);
- if (td->td_state == TDS_RUNQ ||
- td->td_state == TDS_RUNNING) {
- signotify(td->td_proc);
#ifdef SMP
- if (td->td_state == TDS_RUNNING && td != curthread)
- forward_signal(td);
+ if (td->td_state == TDS_RUNNING && td != curthread)
+ forward_signal(td);
#endif
- }
+
Re: KSE signal problems still
On Tue, 2 Jul 2002, Julian Elischer wrote:
> On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> >
> > An easy way to induce a panic w/a post KSE -current is to ^C gdb as it
> > starts on an SMP machine:
>
> A possibly related breakage is:
>
> type ^Z while doing "make buiildworld" (or something similar).
>
> when you type 'fg' there is a high change the build will abort..
> >
> > # gdb -k /var/crash/kernel.1 /var/crash/vmcore.1
> > GNU gdb 5.2.0 (FreeBSD) 20020627
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and
> > you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for
> > details.
> > This GDB was configured as "i386-undermydesk-freebsd"...
> > ^C
> >
> > panic: mutex sched lock not owned at ../../../kern/subr_smp.c:126
> > cpuid = 1; lapic.id = 0100
> > Debugger("panic")
> > Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
> > db> where
> > No such command
> > db> tr
> > Debugger(c02dbf5a) at Debugger+0x46
> > panic(c02db1a8,c02db318,c02df736,7e,c4445540) at panic+0xd6
> > _mtx_assert(c0315440,1,c02df736,7e) at _mtx_assert+0xa8
> > forward_signal(c4445540) at forward_signal+0x1a
> > tdsignal(c4445540,2,2) at tdsignal+0x182
> > psignal(c443d558,2) at psignal+0x3c8
> > pgsignal(c441ad00,2,1,c441ad1c,0) at pgsignal+0x63
> > ttyinput(3,c41e8e30,c41e8e00,0,c0347903) at ttyinput+0x316
> > ptcwrite(c4307a00,d7d5ec88,7f0011,1,d7d5ebc4) at ptcwrite+0x17f
> > spec_write(d7d5ebf0,d7d5ec3c,c0204cc8,d7d5ebf0,7f0011) at spec_write+0x5a
> > spec_vnoperate(d7d5ebf0) at spec_vnoperate+0x13
> > vn_write(c41ded5c,d7d5ec88,c440cd80,0,c409e780) at vn_write+0x1c8
> > dofilewrite(c409e780,c41ded5c,5,8088000,1) at dofilewrite+0xaf
> > write(c409e780,d7d5ed14,3,b,282) at write+0x39
> > syscall(2f,2f,2f,1,8073410) at syscall+0x23c
> > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> > --- syscall (4, FreeBSD ELF, write), eip = 0x281fb3a3, esp =
> > 0xbfbff37c, ebp = 0xbfbff3e8 ---
> >
> >
>
> hum
>
> so, the question is:
> where should we get the sched lock?
Maybe just remove the foot-shooting that releases it?
% Index: kern_sig.c
% ===
% RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
% retrieving revision 1.170
% retrieving revision 1.171
% diff -u -1 -r1.170 -r1.171
% --- kern_sig.c29 Jun 2002 02:00:01 - 1.170
% +++ kern_sig.c29 Jun 2002 17:26:18 - 1.171
% @@ -1486,15 +1540,9 @@
%*/
% - if (p->p_stat == SRUN) {
% + mtx_unlock_spin(&sched_lock);
^ shoot foot
% + if (td->td_state == TDS_RUNQ ||
% + td->td_state == TDS_RUNNING) {
I think sched_lock is needed for checking td_state too (strictly to use
the result of the check, so the lock is not critical if the use doesn't
do anything harmful), but there is no lock indication for td_state
in proc.h like there used to be for p_stat.
% + signotify(td->td_proc);
Holding sched_lock when calling signotify() used to be an error, but that
was changed in rev.1.155. This signotify() call seems to be bogus anyway.
signotify() should only be called after the signal mask is changed. The
call to signotify() here was removed in rev.1.154 when the semantics of
signotify() was changed a little. Bogus calls to signotify() just waste
time.
% #ifdef SMP
% - struct kse *ke;
% - struct thread *td = curthread;
% -/* we should only deliver to one thread.. but which one? */
% - FOREACH_KSEGRP_IN_PROC(p, kg) {
% - FOREACH_KSE_IN_GROUP(kg, ke) {
% - if (ke->ke_thread == td) {
% - continue;
% - }
% - forward_signal(ke->ke_thread);
% - }
% - }
% + if (td->td_state == TDS_RUNNING && td != curthread)
% + forward_signal(td);
% #endif
forward_signal() was called with sched_lock held in rev.1.170, and
forward_signal() still requires it to be held. I think sched_lock is
needed for checking td_state too, as above. Here it is fairly clear
that calling forward_signal() bogusly after losing a race is harmless.
It just wakes up td to look for a signal that isn't there or can't
be handled yet. Since this only happens if we lose a race, it may be
more efficient to let it happen (rarely) than to lock (always) to prevent
it happening. But we already held the lock so the locking was free
except for latency issues.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curre
