Re: RE: Current stalls...
> : > : > :I'll try- lots on plate to do. > : > :There's a lot of iffy stuff with ithreads on alpha. But this theory of yours > :doesn't match the situation where I can then still log in and ping, but that > :the NFS loopback mount is still hosed. > : > :I went back to building across NFS and that worked mucho better. > > I'm kinda shooting in the dark here, at least where -current is > concerned. It's very fragile. The source of this particular problem > could be anything. > > Maybe if we froze new development in -current and concentrated on > stabilizing it for a month we could bring it back up to snuff. Nope, I doubt it. It's about what I would expect it to be. Karnak predicts that things will be miserable for about two more months and then get a lot better. Freezing development (as if you could *really* folks to do that) will make that three months or maybe four. The time to have done a rational plan to stage all of this was last May, not now. I'm actually amazed that things work as well as they do. What we really need is a few more subsystems cleaned up lockwise (I have my eye on Justin's latest CAM patches and how that will play with locking) and somebody (that might be me when && if I get time for it- my current clients don't give a doodly about FreeBSD so it's hard to break loose time in a work context) to clean up the alpha ithreads stuff (I like what Doug has just passed out- I need to thank him and try it (Yes, Doug, if you're reading this, the proc holding Giant should inherit the hardware int priority)) and people to just beat on things and have things get shaken out. Given our very loose confederation, and given the downright absolute dislike some of us have for each other, this is probably the best of all possible software development worlds. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current stalls...(now also panic)
On Fri, Dec 29, 2000 at 04:02:08PM -0800, Thomas D. Dean wrote: > I have a -current stall or hang, also. > > I do NOT have USB support in my kernel. > > Running gdb on hello.c, the standard hello, world, will cause the > stall or hang. Keyboard input is echoed, but, no action. > > tomdean No, no USB devices (nor USB support in the kernel.) Also, I was not trying to use gdb (I tried that two days ago, with strikingly similar results though:-) This panic is somewhat elusive: I cannot readily trigger it it seems. Will stress system to see what gives. BTW: I do not know if it was intentional but I see a *lot* fewer pcm0: hwptr went backwards messages with very recent -CURRENT and indeed sound output is a lot more continous, even under load. Congrats to whoever did it! (probably cg) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs commit: src/sys/kern sys_process.c
Hello everybody! ps 2000/12/29 16:44:44 PST Modified files: sys/kern sys_process.c Log: Pass me the pointy hat. Do not hold sched_lock over psignal. Submitted by: alfred Revision ChangesPath 1.58 +2 -2 src/sys/kern/sys_process.c I think I will try this. Maybe it will help with the panic I saw yesterday. Will report back when I am done. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HDD Problem
Folks, [EMAIL PROTECTED]: >> I have a KT7 with an athlon 1.1, no problems with ATA66, don't have a 100 >> drive though. Works fine, does make worlds in a little over an hour with >> 384mb of pc133, but I do have to downclock the pc133 to 100 because these >> via chips have some problem with agp and pc133 at the moment. > >Another datapoint - I have an MSI 694D motherboard, with Via Apollo Pro >133A chipset, 2 x PIII-800EB, 4 x IBM 75GXP disks (two on ATA-66, two on >ATA-100). Works like a charm, extremely stable, runs continuous buildworld >and untar/rm ports with no problem. PC-133 memory, running at 133 Mhz. No >overclocking, adequate cooling. >FreeBSD 4.2-STABLE #2: Mon Dec 25 12:01:26 CET 2000 >[EMAIL PROTECTED]:/usr/local/freebsd/stable4/src/sys/compile/MGMTSRV >Timecounter "i8254" frequency 1193182 Hz >CPU: Pentium III/Pentium III Xeon/Celeron (801.82-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > >Features=0x383fbff >real memory = 536805376 (524224K bytes) >avail memory = 519806976 (507624K bytes) >Programming 24 pins in IOAPIC #0 >IOAPIC #0 intpin 2 -> irq 0 >FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 > cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 > io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Maybe this is misleading... But: I have an old HP Vectra XU with SCSI disks showing exactly the same behaviour. With SMP enabled it hangs under heavy disk activity, with single processor it works just fine. (Recent -STABLE of course, but it has been like this since 4.0.) Maybe this is not related to ATA at all? Is this an SMP issue (again)? Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Current stalls...
: : :I'll try- lots on plate to do. : :There's a lot of iffy stuff with ithreads on alpha. But this theory of yours :doesn't match the situation where I can then still log in and ping, but that :the NFS loopback mount is still hosed. : :I went back to building across NFS and that worked mucho better. I'm kinda shooting in the dark here, at least where -current is concerned. It's very fragile. The source of this particular problem could be anything. Maybe if we froze new development in -current and concentrated on stabilizing it for a month we could bring it back up to snuff. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Current stalls...
I'll try- lots on plate to do. There's a lot of iffy stuff with ithreads on alpha. But this theory of yours doesn't match the situation where I can then still log in and ping, but that the NFS loopback mount is still hosed. I went back to building across NFS and that worked mucho better. > > : > :I'm getting these on NFS for loopback. > > Can you verify that it's the same as Poul's by breaking into DDB > and doing a trace ? > > I have very little time, but what I think may be going on is that > current may be exposing a bug in the specfs fsync code related to > flushing dirty buffers which already have a background bitmap write > in progress. > > I think what is going on is that interrupt threads are not able to > run in -current, whereas interrupts do run in -stable, and an interrupt > completing the write on a buffer is what breaks us out of the > infinite loop. I noticed in Poul's 'ps' output that a number of > interrupt threads were runnable, but not getting any cpu to run. > > The way to test this hypothesis is to give up the cpu for a tick in the > specfs fsync loop, allowing interrupt threads to run. Maybe do a > tsleep for hz/10 every 500 iterations or something like that. > If this fixes the problem, then we have confirmation. > > Alternatively someone can work up a simple MARK/SCAN for specfs's fsync, > ala what we do in FFS's fsync, and try that. I think MARK/SCAN may > be the ultimate solution but we should home in on the problem before > tring it out. > > -Matt > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Current stalls...
: :I'm getting these on NFS for loopback. Can you verify that it's the same as Poul's by breaking into DDB and doing a trace ? I have very little time, but what I think may be going on is that current may be exposing a bug in the specfs fsync code related to flushing dirty buffers which already have a background bitmap write in progress. I think what is going on is that interrupt threads are not able to run in -current, whereas interrupts do run in -stable, and an interrupt completing the write on a buffer is what breaks us out of the infinite loop. I noticed in Poul's 'ps' output that a number of interrupt threads were runnable, but not getting any cpu to run. The way to test this hypothesis is to give up the cpu for a tick in the specfs fsync loop, allowing interrupt threads to run. Maybe do a tsleep for hz/10 every 500 iterations or something like that. If this fixes the problem, then we have confirmation. Alternatively someone can work up a simple MARK/SCAN for specfs's fsync, ala what we do in FFS's fsync, and try that. I think MARK/SCAN may be the ultimate solution but we should home in on the problem before tring it out. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem installing on T20
On Fri, Dec 29, 2000 at 06:44:28PM -0600, Wm Brian McCane scribbled: [Snip IBM T20 woe's] | Any ideas? see http://people.freebsd.org/~bmah/ThinkPad/ and -mobile archives within the last month for info. Basically, IBM messed up on their BIOS, it won't boot with a 165(FreeBSD) partition. I am surprised you got that much info from IBM Tech Support. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Current stalls...
I'm getting these on NFS for loopback. > > On 29-Dec-00 Poul-Henning Kamp wrote: > > > > I am totally unable to complete a > > cd /usr/src > > cvs -q update -P -d -A > > on any of my two -current systems. > > > > The systems stalls as described in my email yesterday. > > > > CCD is now out of the equation. > > I'm getting these hangs on my laptop as well, but only in the last few days. > An installworld from a previously built world hangs as well. > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: possible fix for gdb hanging the kernel
On 30-Dec-00 Alfred Perlstein wrote:
> I'd appreciate it if those who are having issues with gdb were to
> try this patch and let me know if it fixes things.
>
> Index: sys_process.c
> ===
> RCS file: /home/ncvs/src/sys/kern/sys_process.c,v
> retrieving revision 1.57
> diff -u -u -r1.57 sys_process.c
> --- sys_process.c 2000/12/28 08:34:21 1.57
> +++ sys_process.c 2000/12/30 00:24:38
> @@ -381,8 +381,8 @@
> if (p->p_stat == SSTOP) {
> p->p_xstat = uap->data;
> setrunnable(p);
> - psignal(p, SIGCONT);
> mtx_exit(&sched_lock, MTX_SPIN);
> + psignal(p, SIGCONT);
> } else {
> mtx_exit(&sched_lock, MTX_SPIN);
> if (uap->data) {
Egads! Did I do that? /me crawls off into a hole and dies..
Holding sched_lock over psignal() is probably a very Bad Thing(tm).
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
USB ethernet locking a little b0rked..
Currently the mutexes for the USB ethernet drivers don't play well with the USB code, and the kernel ends up sleeping with them held, which can deadlock the machine (it locked my machine up a couple of times when I would unplug my cue0 adapter.) I worked around it by just turning off the locking for now. Giant still protects all this, so this is safe: Index: dev/usb/if_cuereg.h === RCS file: /usr/cvs/src/sys/dev/usb/if_cuereg.h,v retrieving revision 1.6 diff -u -r1.6 if_cuereg.h --- dev/usb/if_cuereg.h 2000/10/24 22:38:54 1.6 +++ dev/usb/if_cuereg.h 2000/12/27 22:53:41 @@ -182,5 +182,10 @@ struct mtx cue_mtx; }; +#if 0 #defineCUE_LOCK(_sc) mtx_enter(&(_sc)->cue_mtx, MTX_DEF) #defineCUE_UNLOCK(_sc) mtx_exit(&(_sc)->cue_mtx, MTX_DEF) +#else +#defineCUE_LOCK(x) +#define CUE_UNLOCK(x) +#endif -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Current stalls...
On 29-Dec-00 Poul-Henning Kamp wrote: > > I am totally unable to complete a > cd /usr/src > cvs -q update -P -d -A > on any of my two -current systems. > > The systems stalls as described in my email yesterday. > > CCD is now out of the equation. I'm getting these hangs on my laptop as well, but only in the last few days. An installworld from a previously built world hangs as well. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem installing on T20
I have an IBM T20 laptop that I want to run FreeBSD on. I have run Partition Magic and shrunk the disk to 4GB (leaving 8GB for FreeBSD). I downloaded 4.2-RELEASE and installed it on the box. Everything looked good until I tried to reboot the machine. At that point, it would show the ThinkPad Logo, tinker, then the screen would dim, the hard drive light stuck on, and the box just sat there (for 3 hours, as a test 8). The company we lease the machine from had to give me a new hard drive to fix the problem. Luckily I don't keep anything I care about on this machine. Assuming the problem was a hardware issue, I tried it again, with the same results. This time I got IBM involved, and they said that the T20 checks for data on the hard drive (kinda sounded like the CMOS was too small for all the stuff they saved between boots). From what they told me, the data is stored somewhere in those 62 sectors after the boot block, before the first partition. Okay, so I am now on my third hard drive, and I decided to try it one more time (glutton for punishment). This time I tried a 5.0 snapshot dated 2000/12/23. The install looked good, and I even got it to boot both NT and FreeBSD from the drive (in that order). After I gave FreeBSD the 3-finger salute to shut it down, the system would no longer boot. Through experimentation, I have found that I can: 1) Pull hard drive out 2) power on and wait until red error saying drive is missing 3) plug drive in hot (don't tell IBM 8) 4) boot from FreeBSD boot/root disks 5) drive works when mounted using custom install option then a holographic shell. I can even copy files to/from the hard drive across the network (okay, I am bored and desparate). Everything works except booting from the drive. Using dd|od -c, it appears that boot0 is overlapping onto the second sector (which I thought was a no-no). Also, boot1 or boot2 (I forget which now) was in sectors 3-x, and I thought those should be in the boot area of the FreeBSD partition, right? I have attempted to replace the boot record (even using a standard MBR). I finally got so frustrated that I dd'd /dev/zero into those 62 sectors in hope the IBM would assume it was a new drive and re-create the data it needed. Any ideas? - brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
possible fix for gdb hanging the kernel
I'd appreciate it if those who are having issues with gdb were to
try this patch and let me know if it fixes things.
Index: sys_process.c
===
RCS file: /home/ncvs/src/sys/kern/sys_process.c,v
retrieving revision 1.57
diff -u -u -r1.57 sys_process.c
--- sys_process.c 2000/12/28 08:34:21 1.57
+++ sys_process.c 2000/12/30 00:24:38
@@ -381,8 +381,8 @@
if (p->p_stat == SSTOP) {
p->p_xstat = uap->data;
setrunnable(p);
- psignal(p, SIGCONT);
mtx_exit(&sched_lock, MTX_SPIN);
+ psignal(p, SIGCONT);
} else {
mtx_exit(&sched_lock, MTX_SPIN);
if (uap->data) {
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: termios.h patch for review
I wrote:
> Right, but stealing these small snippets from NetBSD wasn't very hard,
> see patch below.
Here's a better patch, including stty. If there are no objects, I'll
commit this.
/assar
Index: bin/stty/modes.c
===
RCS file: /home/ncvs/src/bin/stty/modes.c,v
retrieving revision 1.8
diff -u -w -r1.8 modes.c
--- bin/stty/modes.c1999/08/27 23:15:41 1.8
+++ bin/stty/modes.c2000/12/29 22:47:29
@@ -191,10 +191,16 @@
{ "-litout",OPOST, 0 },
{ "onlcr", ONLCR, 0 },
{ "-onlcr", 0, ONLCR },
+ { "ocrnl", OCRNL, 0 },
+ { "-ocrnl", 0, OCRNL },
{ "tabs", 0, OXTABS },/* "preserve" tabs */
{ "-tabs", OXTABS, 0 },
{ "oxtabs", OXTABS, 0 },
{ "-oxtabs",0, OXTABS },
+ { "onocr", ONOCR, 0 },
+ { "-onocr", 0, ONOCR },
+ { "onlret", ONLRET, 0 },
+ { "-onlret",0, ONLRET },
{ NULL },
};
Index: bin/stty/print.c
===
RCS file: /home/ncvs/src/bin/stty/print.c,v
retrieving revision 1.14
diff -u -w -r1.14 print.c
--- bin/stty/print.c2000/04/30 17:04:25 1.14
+++ bin/stty/print.c2000/12/29 22:47:29
@@ -148,7 +148,10 @@
binit("oflags");
put("-opost", OPOST, 1);
put("-onlcr", ONLCR, 1);
+ put("-ocrnl", OCRNL, 0);
put("-oxtabs", OXTABS, 1);
+ put("-onocr", OXTABS, 0);
+ put("-onlret", OXTABS, 0);
/* control flags (hardware state) */
tmp = tp->c_cflag;
Index: bin/stty/stty.1
===
RCS file: /home/ncvs/src/bin/stty/stty.1,v
retrieving revision 1.18
diff -u -w -r1.18 stty.1
--- bin/stty/stty.1 2000/11/28 19:48:06 1.18
+++ bin/stty/stty.1 2000/12/29 22:47:29
@@ -237,8 +237,18 @@
to
.Dv CR-NL
on output.
+.It Cm ocrnl Pq Fl ocrnl
+Map (do not map)
+.Dv CR
+to
+.Dv NL
+on output.
.It Cm oxtabs Pq Fl oxtabs
Expand (do not expand) tabs to spaces on output.
+.It Cm onocr Pq Fl onocr
+Do not (do) output CRs at column zero.
+.It Cm onlret Pq Fl onlret
+On the terminal NL performs (does not perform) the CR function.
.El
.Ss Local Modes:
.Pp
Index: share/man/man4/termios.4
===
RCS file: /home/ncvs/src/share/man/man4/termios.4,v
retrieving revision 1.17
diff -u -w -r1.17 termios.4
--- share/man/man4/termios.42000/11/22 16:10:59 1.17
+++ share/man/man4/termios.42000/12/29 22:48:23
@@ -991,6 +991,8 @@
/* map NL to CR-NL (ala
.Dv CRMOD)
*/
+.It Dv OCRNL
+/* map CR to NL */
.It Dv OXTABS
/* expand tabs to spaces */
.It Dv ONOEOT
@@ -998,6 +1000,10 @@
.Dv EOT Ns 's
.Ql \&^D
on output) */
+.It Dv ONOCR
+/* do not transmit CRs on column 0 */
+.It Dv ONLRET
+/* on the termianl NL performs the CR function */
.El
.Pp
If
@@ -1010,6 +1016,10 @@
is set, newlines are translated to carriage return, linefeeds.
.Pp
If
+.Dv OCRNL
+is set, carriage returns are translated to newlines.
+.Pp
+If
.Dv OXTABS
is set, tabs are expanded to the appropriate number of
spaces (assuming 8 column tab stops).
@@ -1020,6 +1030,15 @@
.Tn ASCII
.Dv EOT Ns 's
are discarded on output.
+.Pp
+If
+.Dv ONOCR
+is set, no CR character is transmitted when at column 0 (first position).
+.Pp
+If
+.Dv ONLRET
+is set, the NL character is assumed to do the carriage-return function;
+the column pointer will be set to 0.
.Ss Control Modes
Values of the
.Fa c_cflag
Index: sys/kern/tty.c
===
RCS file: /home/ncvs/src/sys/kern/tty.c,v
retrieving revision 1.142
diff -u -w -r1.142 tty.c
--- sys/kern/tty.c 2000/12/08 21:50:36 1.142
+++ sys/kern/tty.c 2000/12/29 22:48:54
@@ -663,9 +663,16 @@
if (c == '\n' && ISSET(tp->t_oflag, ONLCR)) {
tk_nout++;
tp->t_outcc++;
- if (putc('\r', &tp->t_outq))
+ if (!ISSET(tp->t_lflag, FLUSHO) && putc('\r', &tp->t_outq))
return (c);
}
+ /* If OCRNL is set, translate "\r" into "\n". */
+ else if (c == '\r' && ISSET(tp->t_oflag, OCRNL))
+ c = '\n';
+ /* If ONOCR is set, don't transmit CRs when on column 0. */
+ else if (c == '\r' && ISSET(tp->t_oflag, ONOCR) && tp->t_column == 0)
+ return (-1);
+
tk_nout++;
tp->t_outcc++;
if (!ISSET(tp->t_lflag, FLUSHO) && putc(c, &tp->t_outq))
@@ -680,6 +687,9 @@
case CONTROL:
break;
case NEWLINE:
+ if (ISSET(tp->t_oflag, ONLCR | ONLRET))
+ col = 0;
+ break;
case RETURN:
col = 0;
break;
Index: sys/sys/termios.h
===
RCS file: /home/ncvs/src/sys/sys/
Re: Current stalls...(now also panic)
I have a -current stall or hang, also. I do NOT have USB support in my kernel. Running gdb on hello.c, the standard hello, world, will cause the stall or hang. Keyboard input is echoed, but, no action. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current stalls...(now also panic)
> Maybe this is related, maybe not... I upgraded to the latest CURRENT > available this morning and now I also see occasional (albeit short) hangs > sometimes, although the machine seems to be responsive otherwise. I see this also. If you aren't using USB but have it compiled into your kernel try commenting out all the "device" entries after "# USB support" in the config file. A kernel built without USB may not show the hangs. I think there is a buglet that has krept into the USB code within the last couple of weeks. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current stalls...(now also panic)
Hi! Maybe this is related, maybe not... I upgraded to the latest CURRENT available this morning and now I also see occasional (albeit short) hangs sometimes, although the machine seems to be responsive otherwise. But, not only that, I also got a cool panic while trying to do some stuff (like compiling the docs) and pressing Ctrl-Z in another tty. No X, no nothing. I was dropped into the debugger, but since I am not a ddb artist, I tried to avoid to type the whole trace by hand and in the process managed to reboot the box... oh well. Next time I will know. But, the panic message was this: panic: blockable mtx_enter() of lockmgr interlock when not legal @ ../../kern/kern_lock.c:247 Maybe this rings a bell with someone. The error was appearently caught by WITNESS, which I also have enabled in my kernel (albeit without MUTEX_DEBUG, because *that* really made it impossible to do anything sensible on the machine...) Hardware-wise, nothing fancy here... UP PII-233, 128M non-ECC RAM, all-IDE, two disks, one CD-ROM. Next time, I promise to write down all the details... but just wanted to chime in quickly since this might be related to the hangs other people are seeing, but maybe they don't panic() because they don't have WITNESS enabled (just speculating) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: PalmPilot emulators don't work on CURRENT
On Fri, 29 Dec 2000, Daniel O'Connor wrote: > On 29-Dec-00 Juriy Goloveshkin wrote: > > Can anybody run any PalmPilot emulator on CURRENT? > > pose and xcopilot don't work. > > Perhaps if you submitted a bug report worthy of the name someone might be able to > help. > > Does it core? panic the machine? Run but not work as intended? Have you tried > recompiling the application and dependancies? It cores, in a getsockname() call from the fltk libraries. I dropped a note to the port maintainer a couple weeks ago and never heard anything. The same problem exists if you build independent of ports. It could be an issue with the fltk port though... -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PalmPilot emulators don't work on CURRENT
On Fri, 29 Dec 2000, Juriy Goloveshkin wrote: > Hello, > Can anybody run any PalmPilot emulator on CURRENT? > pose and xcopilot don't work. Nope. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing a.out compatibility
> It seems feasable to generate a new binary on a recent or an old patched > FreeBSD version. The question is which is better. I think the newer > the better. Otherwise, who is going to build the 2.2.8-stable box > to make this one binary? I've already built a binary on 4.2-release > that works. I've got a 2.2.8-stable box I am planning on building the ld.so binary on. I just have to find the time to do it. (Been on vacation for almost a week, and I've got 1600 FreeBSD emails to wade through first...) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current stalls...
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): > cd /usr/src > cvs -q update -P -d -A > on any of my two -current systems. > The systems stalls as described in my email yesterday. Maybe this is related: I had two complete hangs today on my FreeBSD cichlids.cichlids.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Dec 27 13:05:38 CET 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/cichlids i386 today, while I had *much* i/o on my xl0 NIC and on my hdd (UDMA33). This is the first time for months that I have stressed my xl0 that hard, and so I don't know if this is related or not. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld broken
In message <[EMAIL PROTECTED]>, Sheldon Hearn writes: > > >On Fri, 29 Dec 2000 14:42:18 +0100, German Tischler wrote: > >> Anyone else seeing this ? > >Yet another avoidable break caused by inadequate pre-commit testing. >Watch your cvs-all mail for commits to either the btree code or (more >likely) queue.h . Well, I have the patches sitting on my machine, but it's running -current which is totally hosed right now it seems. At least it stalls completely if I try to do anything relating to cvs on them :-( -- 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
Current stalls...
I am totally unable to complete a cd /usr/src cvs -q update -P -d -A on any of my two -current systems. The systems stalls as described in my email yesterday. CCD is now out of the equation. - 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
turning off vga_pci
Is there a nice way to stop vga_pci from attaching to my video card, or to allow another driver to attach to it after vga_pci has done its thing? At the moment I'm removing all traces of vga_pci from the Makefile in my kernel 'compile' directory (which works)... It is preventing the drm module from attaching to the card and I'm losing hardware 3D acceleration under X. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld broken
I just did a make world from sources updated less than 12 hours ago, and I did not have ANY problems.. Sheldon Hearn wrote: > On Fri, 29 Dec 2000 14:42:18 +0100, German Tischler wrote: > > > Anyone else seeing this ? > > Yet another avoidable break caused by inadequate pre-commit testing. > Watch your cvs-all mail for commits to either the btree code or (more > likely) queue.h . > > Ciao, > Sheldon. > > 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: buildworld broken
On Fri, 29 Dec 2000 14:42:18 +0100, German Tischler wrote: > Anyone else seeing this ? Yet another avoidable break caused by inadequate pre-commit testing. Watch your cvs-all mail for commits to either the btree code or (more likely) queue.h . Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld broken
On Fri, Dec 29, 2000 at 02:42:18PM +0100, German Tischler wrote: > cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D_ > _DBINTERFACE_PRIVATE -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/ > src/lib/libc/../libc/locale -DBROKEN_DES -DYP -DHESIOD -I/usr/obj/usr/src/i386/u > sr/include -c /usr/src/lib/libc/../libc/db/btree/bt_close.c -o bt_close.So > In file included from /usr/src/lib/libc/../libc/db/btree/btree.h:44, > from /usr/src/lib/libc/../libc/db/btree/bt_close.c:52: > /usr/obj/usr/src/i386/usr/include/mpool.h:54: syntax error before `CIRCLEQ_ENTRY > ' > /usr/obj/usr/src/i386/usr/include/mpool.h:65: syntax error before `CIRCLEQ_HEAD' Yes, it's true. Someone axed CIRCLEQ earlier, but apparently didn't test buildworld first. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld broken
Hi. Anyone else seeing this ? cc -fpic -DPIC -O -pipe -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D_ _DBINTERFACE_PRIVATE -DINET6 -I/usr/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/ src/lib/libc/../libc/locale -DBROKEN_DES -DYP -DHESIOD -I/usr/obj/usr/src/i386/u sr/include -c /usr/src/lib/libc/../libc/db/btree/bt_close.c -o bt_close.So In file included from /usr/src/lib/libc/../libc/db/btree/btree.h:44, from /usr/src/lib/libc/../libc/db/btree/bt_close.c:52: /usr/obj/usr/src/i386/usr/include/mpool.h:54: syntax error before `CIRCLEQ_ENTRY ' /usr/obj/usr/src/i386/usr/include/mpool.h:65: syntax error before `CIRCLEQ_HEAD' --gt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
happy!!
[NX}XI ¢ë`ñÈíÞÌGb`ªWª¯³êÄA ³¿Å©êéæB http://216.101.214.74/omankoheaven/ ·²[¢¾©çÉÈÉÅà©ÄÝÄËB ½Ü± To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
