Re: Gnome2 terminal will not work right
On Fri, Mar 07, 2003 at 11:30:34PM -0800, Lars Eggert wrote: > Hi, > > this may be unrelated, but for about ten days or so, I have problems > where gnometerminal will stop updating after a while. I can still use > the menus, close it, etc. - but all output is suspended. Most of the > time, selecting "Reset" from the menu repeatedly will eventually get me > back to a working state again. It also seems that pasting multi-line > text into a gnometerminal (as opposed to typing or it displaying output) > will trigger this frequently. Me too I tend to think it happens more often with maximized windows than not and also when long lines are involved. A reset most of the time gets me back, but I do occasionally have to kill gnome-terminal completely when all the terminals are dead. Unfortunately I don't have the time to dig into it, but I'm probably going to switch window manager and see if that makes a difference. For some reason I'm suspicious about Metacity. Not necessarily because of this... JFYI, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCHED_ULE ok again. feedback please?
On Fri, 7 Mar 2003, Kris Kennaway wrote:
> On Fri, Mar 07, 2003 at 09:41:07AM +0200, Vallo Kallaste wrote:
> > Althought much better, KDE is still almost unusable, XFree and KDE
> > startup takes a lot more time and starting plain xterm under KDE
> > takes x3 time than usual. When I kill one of the seti processes, all
> > comes down to normal. The one remaining seti process takes 53% of
> > CPU constantly. Don't know how top calculates process CPU usage, but
> > if the 100% is spread over the two processors, then the seti process
> > monopolises one of the processors constantly. Doesn't matter will it
> > run nice 19 or idprio 31.
>
> As noted in Jeff's original mail, niced processes do not behave nicely
> yet.
Niceness is quite broken in -current with the 4bsd scheduler too. It
works a bit better in RELENG_4 since RELENG_4 is missing rev.103 of
proc.h and related changes. I recently started uses my old fixes for
the limited range of {p,kg}_estcpu. In my version, the scaling from
niceness to %CPU is table-driven and has an essentially arbitrary
dynamic range, while the current scaling is built into the algorithm
in an unobvious undocumented way and has a much too small dynamic
range. With my version and a logarithmic relative scaling of
pow(2.0, kg_nice / 4.0), the results of running:
for i in -20 -16 -12 -8 -4 0 4 8 12 16 20
do
nice -$i sh -c "while :; do echo -n;done" &
done
top -o cpu
overnight look like this:
%%%
last pid: 2627; load averages: 11.00, 11.00, 11.00 up 0+12:11:2117:55:21
41 processes: 12 running, 29 sleeping
Mem: 6576K Active, 24M Inact, 26M Wired, 48K Cache, 138M Buf, 191M Free
Swap:
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
1439 root 92 -20 800K 556K RUN265:09 43.99% 43.99% sh
1440 root 95 -16 800K 556K RUN153:07 26.17% 26.17% sh
1441 root 95 -12 800K 556K RUN 80:30 13.04% 13.04% sh
1442 root 96 -8 800K 556K RUN 40:13 6.01% 6.01% sh
1443 root 96 -4 800K 556K RUN 20:34 2.78% 2.78% sh
1444 root 960 800K 556K RUN 9:12 1.03% 1.03% sh
1445 root 964 800K 556K RUN 5:50 0.05% 0.05% sh
1446 root 968 800K 556K RUN 2:58 0.00% 0.00% sh
1447 root 102 12 800K 556K RUN 1:43 0.00% 0.00% sh
1448 root 105 16 800K 556K RUN 1:00 0.00% 0.00% sh
1449 root 100 20 800K 556K RUN 0:36 0.00% 0.00% sh
297 root 760 552K 384K select 0:01 0.00% 0.00% rlogind
726 root 760 792K 528K select 0:01 0.00% 0.00% ntpd
261 root 760 1932K 1576K select 0:01 0.00% 0.00% sendmail
246 root 40 524K 320K nfsd 0:01 0.00% 0.00% nfsd
1 root 80 664K 340K wait 0:00 0.00% 0.00% init
299 bde80 1696K 1556K wait 0:00 0.00% 0.00% bash
258 root 760 1504K 1004K select 0:00 0.00% 0.00% sshd
%%%
(output produced by non-interactive top).
The dynamic range available to users (from nice -0 to nice -20) is
32:1 in theory (according to the table) and (9:12):(0:36) = 15:1 in
practice (according to top). Theory matches practice better for the
negatively niced processes (28:1)
With -current and SCHED_4BSD, the dynamic range for users is slightly
less than 2:1, which is not good enough for setiathome and similar
processors, so idprio should be used. I think the priority inversion
bugs in idprio are supposed to be fixed in -current, and I have had
no problems using it, but there are still many cases where the kernel
doesn't switch to the highest priority process as soon as possible.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Gnome2 terminal will not work right
Hi, this may be unrelated, but for about ten days or so, I have problems where gnometerminal will stop updating after a while. I can still use the menus, close it, etc. - but all output is suspended. Most of the time, selecting "Reset" from the menu repeatedly will eventually get me back to a working state again. It also seems that pasting multi-line text into a gnometerminal (as opposed to typing or it displaying output) will trigger this frequently. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Gnome2 terminal will not work right
On Sat, 2003-03-08 at 00:15, Tom Parquette wrote: > People have been saying that 5.0-CURRENT problems belong here. > I don't know if this is Gnome2 or Xfree86... Both work fine for me in -CURRENT. > > I noticed tonight that the Gnome2 desktop terminal stopped working. What changed between the last known working date and tonight? > > The X logs are inconclusive. > However, I'll include one that hints at a failure. > "Fatal server error: xf86OpenConsole: VT_SETMODE VT_PROCESS failed" > I've had this happen to root and to my non uid0 personal account. > Any ideas folks? What do you have in your ~/.xinitrc? Can you also send the output of pkg_info? Also, have you tried removing ~/.gnome2/session, and see if that helps? Joe > > > > __ > > XFree86 Version 4.2.1 / X Window System > (protocol Version 11, revision 0, vendor release 6600) > Release Date: 3 September 2002 > If the server is older than 6-12 months, or if your card is > newer than the above date, look for a newer version before > reporting problems. (See http://www.XFree86.Org/) > Build Operating System: FreeBSD 5.0-CURRENT i386 [ELF] > Module Loader present > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/XFree86.1.log", Time: Fri Mar 7 17:49:40 2003 > (==) Using config file: "/etc/X11/XF86Config" > (==) ServerLayout "XFree86 Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Card0" > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > (==) Keyboard: CustomKeycode disabled > (**) FontPath set to > "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" > (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" > (**) ModulePath set to "/usr/X11R6/lib/modules" > (--) Using syscons driver with X support (version 2.0) > (++) using VT number 9 > > > Fatal server error: > xf86OpenConsole: VT_SETMODE VT_PROCESS failed > > > When reporting a problem related to a server crash, please send > the full server output, not just the last messages. > This can be found in the log file "/var/log/XFree86.1.log". > Please report problems to [EMAIL PROTECTED] -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
failed to set signal flags properly for ast()
I've been getting a few of these on 5.0 lately: Mar 7 21:31:07 bento kernel: failed to set signal flags properly for ast() Is there any additional debugging information I can provide to help track this down? Kris pgp0.pgp Description: PGP signature
Gnome2 terminal will not work right
People have been saying that 5.0-CURRENT problems belong here. I don't know if this is Gnome2 or Xfree86... I noticed tonight that the Gnome2 desktop terminal stopped working. When I open a terminal window, I do not get a command prompt. I have a flashing solid block cursor in the top left corner of the window. I tried various key combinations and nothing seems to get its attention. If I file/close or hit the "X" in the top right corner, I get kicked out to the command prompt, where I entered startx, or to the GDM2 signon screen. I'm reading this as an X server crash. I'm seeing some dumps for "Interfearance" but I do not think that is related. Nothing else appears to be broken at this point. The X logs are inconclusive. However, I'll include one that hints at a failure. "Fatal server error: xf86OpenConsole: VT_SETMODE VT_PROCESS failed" I've had this happen to root and to my non uid0 personal account. Any ideas folks? XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: FreeBSD 5.0-CURRENT i386 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.1.log", Time: Fri Mar 7 17:49:40 2003 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "XFree86 Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (**) ModulePath set to "/usr/X11R6/lib/modules" (--) Using syscons driver with X support (version 2.0) (++) using VT number 9 Fatal server error: xf86OpenConsole: VT_SETMODE VT_PROCESS failed When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.1.log". Please report problems to [EMAIL PROTECTED]
GDB kernel debug new command
Hi All,
To help myself more easily check the kernel dump, I added two new command. One
is ps, the other is kldstat. I know we can print the kernel data manually to
get the same information. I still think this is useful. This can help the
newbies to get the information without many knowledge about the kernel. This
also can help the experienced user to get the data more quickly.
Here is the new file. Just put it in /usr/src/gnu/usr.bin/binutils/gdb. And
add the file to Makefile. Please give me some comments if this is garbage. :)
Jun Su
--/usr/src/gnu/usr.bin/binutils/gdb/fbsd-kgdbpack.c--
#include "fbsd-kgdb.h"
#include "defs.h"
#include "command.h"
#include "symtab.h"
#define _KERNEL
#include
#include
#undef _KERNEL
#include
static void
kgdbpack_kldstat_cmd(char* arg, int from_tty)
{
CORE_ADDR allfile_addr;
CORE_ADDR startfile;
struct minimal_symbol *sym;
char buf[sizeof(struct linker_file)];
char namebuf[256];
sym = lookup_minimal_symbol("linker_files",NULL,NULL);
if (!sym)
error ("can not find the linker_files symbosl.\n");
allfile_addr = SYMBOL_VALUE_ADDRESS(sym);
namebuf[255]=0;
struct linker_file *lf = (struct linker_file *)buf;
target_read_memory(allfile_addr, &startfile, sizeof(startfile));
printf("Id\tRefs\tAddress \tSize\tName\n");
while(startfile)
{
target_read_memory(startfile, buf, sizeof(struct linker_file));
target_read_memory((int)lf->filename, namebuf, 254);
printf ("%d\t%d\t0x%8X\t%x\t%s\n", lf->id, lf->refs, lf->address,
lf->size, namebuf);
startfile = (CORE_ADDR)lf->link.tqe_next;
}
return;
}
static void
kgdbpack_ps_cmd(char* argv, int from_tty)
{
CORE_ADDR allproc_addr;
CORE_ADDR procstart;
struct minimal_symbol *sym;
sym = lookup_minimal_symbol("allproc",NULL,NULL);
if (!sym)
error ("No symbol allproc found.");
allproc_addr = SYMBOL_VALUE_ADDRESS(sym);
target_read_memory(allproc_addr, &procstart, sizeof(int));
char buf[sizeof(struct proc)];
struct proc *p = (struct proc*)buf;
printf("ADDRESS\tPID\tSTAT\tCOMMAND\n");
while (procstart) {
target_read_memory(procstart, buf, sizeof(struct proc));
printf("%08x\t%d\t0\t%s\n", procstart, p->p_pid, p->p_comm);
procstart = p->p_list.le_next;
}
}
void
_initialize_kgdbpack()
{
add_com ("kldstat", class_obscure, kgdbpack_kldstat_cmd, "KLDSTAT cmd
clone");
add_com ("ps", class_obscure, kgdbpack_ps_cmd, "PS cmd clone");
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Witness problem with sound
On Wednesday 05 March 2003 07:42, Pete Carah wrote: > I don't know how system-specific this problem is, but: > > Sony VAIO R505ES > Sound is Intel ICH3 + Yamaha. > > This or something closely related has been happening for weeks. > Several times earlier this week and last week sound panic'd, and > also sometimes there was a panic (several different kinds) on boot. > Late last week X wouldn't start due to not being able to see the > VESA modes. > All those except the sound problems currently appear fixed... > > This may or may not be related to the fact that acpi puts nearly all > device interrupts on irq 9 (which causes other problems). > > > There are other problems (mostly with pcmcia, which is left out of > this kernel; it causes hangs on init), but this one is obvious and > does leave the system running. > > A remaining one that bothers multi-type usb card readers is that CAM/XPT > only scans LUN 0 for any device it finds. All my card readers show > as only CF because of this, and I have to give 4 camcontrol commands to > get the system to see the rest (at least it does work with manual > intervention!!). > > -- Pete > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message I got the same error message from my R505DC. And the sound also doesn;t work correctly. Jun Su To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OSS SBLive driver causes kernel panic with 5.0 current
I'd been keeping up with current (world/kernel) every other week or so, and until this week I had no real problems. But after the build I did on March 3rd my soundcard driver (4Front's SBLive/Audigy driver) causes a kernel panic on load. If I don't load the driver the system boots fine, and runs with no other problems. This is the message I get from the debugger when I load the driver: panic: Invalid major (-1030904368) in make_dev I've posted this info to their support forums also, their last responce was to "see what they broke". Jody To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DVArchive + jdk1.4.1
I'm hoping some of you have played with dvarchive in the past or may have a use for it in the future. http://dvarchive.sourceforge.net It seems to work okayish with linux-sun-jdk141 With jdk-1.4.1p3, it almost works. It has a server component that launches and binds two sockets. Port 80 and one other. When this server comes up, it says that it cannot open the server socket because the address is already in use. However, looking at netstat and sockstat, I see that it did open the sockets. tcp4 0 0 192.168.235.1.http *.*LISTEN tcp4 0 0 192.168.235.1.8042 *.*LISTEN root java 60398 17 tcp4 192.168.235.1:8042*:* root java 60398 19 tcp4 192.168.235.1:80 *:* I don't know how to get any useful debug info for anyone to look at. I've gotten this behavior in patchset2, pre3, and 3. Thanks. James. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sis chipset
On Wednesday, 26 February 2003 21:13, C. Kukulies wrote: > My ASUS board has a SiS 963 chip and I would like to get rid from the extra > 3COM card I have presently in my system. > > Is there a chance to get the built in 100MBit network adapter in the > chipset working somehow? I have an ASUS P4S8X with the SiS 963 South Bridge. The RealTek network chip works fine. I added "device miibus" and "device rl" to my kernel conf. I also added a startup script to set the device media to 100baseTX. 100baseTX-FDX for some reason returns "unknown media subtype: 100baseTX-FDX" even thou the kernel reports that mode on startup. HTH -Al To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Can't compile today's (3/7) kernel
I'm getting this error when trying to compile kernels for the last few days: cc -c -O -pipe -march=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-p rototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-e xtensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/s rc/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt _global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffr eestanding -Werror /usr/src/sys/kern/subr_trap.c cc -c -O -pipe -march=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-p rototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-e xtensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/s rc/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt _global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffr eestanding -Werror /usr/src/sys/kern/subr_witness.c cc1: warnings being treated as errors /usr/src/sys/kern/subr_witness.c:1443: warning: `witness_list' defined but not u sed *** Error code 1 I have -DNO_WERROR in my make line but (obviously) that doesn't get around the "warnings being treated as errors" issue here. Thoughts? -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Big IDE drive + little IDE controller + freebsd
Okay... Perhaps I'm just a dumbass with a failing drive? For the longest time, I've thought the hardware needed to support the large drives. From the reading I've just done, that doesn't seem to be the case. I certainly hope this brand new drive isn't failing tho. I really hate doing hardware warranty returns. James. On Fri, 7 Mar 2003 14:20:24 -0800 James Satterfield <[EMAIL PROTECTED]> wrote: > I've got a 160GB ide drive in my FBSD box. It's got an old ide controller that > doesn't support big ide drives. Yet freebsd recognizes the drives full capacity, > allows me to partition it, and newfs it. After writing about 47GB of data to the > drive, I start getting these. > ad5: WRITE command timeout tag=0 serv=0 - resetting > ata2: resetting devices .. > > > atapci1: port > 0xef00-0xef3f,0xefe0-0xefe3,0xefa8-0xefaf,0xefe4-0xefe7,0xeff0-0xeff7 mem > 0xffae-0xffaf irq 10 at device 20.0 on pci0 > ad5: 156334MB [317632/16/63] at ata2-slave UDMA66 > > > James. > > 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
Big IDE drive + little IDE controller + freebsd
I've got a 160GB ide drive in my FBSD box. It's got an old ide controller that doesn't support big ide drives. Yet freebsd recognizes the drives full capacity, allows me to partition it, and newfs it. After writing about 47GB of data to the drive, I start getting these. ad5: WRITE command timeout tag=0 serv=0 - resetting ata2: resetting devices .. atapci1: port 0xef00-0xef3f,0xefe0-0xefe3,0xefa8-0xefaf,0xefe4-0xefe7,0xeff0-0xeff7 mem 0xffae-0xffaf irq 10 at device 20.0 on pci0 ad5: 156334MB [317632/16/63] at ata2-slave UDMA66 James. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
In article you write: >Petri Helenius wrote: >> > There's probably a tightloop of frees going on somewhere. It's tough >> > for me to analyze this as I cannot reproduce it. Have you tried >> > running your tests over loopback to see if the same thing happens? >> >> What is the definition of "tightloop"? The received packet mbufs are freed >> when the packets get processed/discarded which happens once for >> a packet. The received packet rate is 5-15 packets per second. >> > >> > If so, and it does, can you please explain how to exactly replicate >> > the test? >> >> Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable >> promisc and monitor so it drops the packets after interrupt processing. >> The overhead beyond that is neglible compared to mb_free. > >Ah. You are receiver livelocked. Try enabling polling; it will >help up to the first stall barrier (NETISR not getting a chance >to run protocol processing to completion because of interrupt >overhead); there are two other stall barriers after that, and >another in user space is possible depending on whether the >application layer is request/response. Actually, in -current, we now have a sysctl (net.isr.enable) that will switch the netisr from queuing into a direct dispatch mechanism. In other words, the packet is pushed all the way through the TCP stack to the socket buffer by the network card's interrupt. You can toggle it on and off at runtime, so you can play with it and see if there is any difference. My initial performance tests showed it to be a wash, but ttcp testing today shows it gives a 30% performance boost when run over a gigabit link. YMMV, I guess. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
Petri Helenius wrote: > > There's probably a tightloop of frees going on somewhere. It's tough > > for me to analyze this as I cannot reproduce it. Have you tried > > running your tests over loopback to see if the same thing happens? > > What is the definition of "tightloop"? The received packet mbufs are freed > when the packets get processed/discarded which happens once for > a packet. The received packet rate is 5-15 packets per second. > > > > If so, and it does, can you please explain how to exactly replicate > > the test? > > Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable > promisc and monitor so it drops the packets after interrupt processing. > The overhead beyond that is neglible compared to mb_free. Ah. You are receiver livelocked. Try enabling polling; it will help up to the first stall barrier (NETISR not getting a chance to run protocol processing to completion because of interrupt overhead); there are two other stall barriers after that, and another in user space is possible depending on whether the application layer is request/response. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kerberos5 breaks -DNOCLEAN builds
Gang, During the make depend stage of buildworld, I get the following: ===> kerberos5/libexec/hpropd ===> kerberos5/libexec/k5admind cp /p/scratch/marcel/ia64/kerberos5/libexec/k5admind/../../../crypto/heimdal/lib/kadm5/private.h kadm5/private.h cp: kadm5/private.h: Permission denied *** Error code 1 Looking at the permissions in the object directory I see: total 18 drwxr-xr-x 2 marcel wheel 512 Mar 3 03:35 . drwxr-xr-x 3 marcel wheel 512 Mar 3 07:03 .. -r--r--r-- 1 marcel wheel 7684 Mar 3 03:35 admin.h lrwxr-xr-x 1 marcel wheel14 Mar 3 03:35 kadm5_err.h -> ../kadm5_err.h -r--r--r-- 1 marcel wheel 4300 Mar 3 03:35 private.h It appears that if the source files are read only (as is the case when using Perforce) the header files copied to the object dir. will be too. Q: Why are these header files copied instead of being links (like kadm5_err.et in the parent directory)? Q: Why not use install (which in that phase will be the install script under tools in the source directory)? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SCHED_ULE ok again. feedback please?
On Fri, Mar 07, 2003 at 08:57:01AM -0800, Kris Kennaway <[EMAIL PROTECTED]> wrote: > As noted in Jeff's original mail, niced processes do not behave nicely > yet. Yes, I'm sorry that slipped off my first reading. Otherwise, the new scheduler is very useable for me. Thanks for pointing out, Kris. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: lock? panic in networking swi
On 07-Mar-2003 Juli Mallett wrote: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x20 > fault code= supervisor read, page not present > instruction pointer = 0x8:0xc01d47c6 > stack pointer = 0x10:0xc5d33a90 > frame pointer = 0x10:0xc5d33ab4 > 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 = 14 (swi1: net) > trap number = 12 > panic: page fault > > No core, of course, nm says the ip is likely: > _mtx_unlock_sleep > > Thoughts? This is a kernel from last weekend, I'll try to get something > more recent soon. Probably an uninitialized mutex or some such. A stack trace would help. -- 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: SCHED_ULE ok again. feedback please?
On Fri, Mar 07, 2003 at 09:41:07AM +0200, Vallo Kallaste wrote: > > > All interactive tasks are very responsive. My nice -5'd looping process > > > is getting 70% of the cpu and my compile is taking the rest. nice +20 may > > > not behave as well as in sched_4bsd right now. I'm going to work on that. > Althought much better, KDE is still almost unusable, XFree and KDE > startup takes a lot more time and starting plain xterm under KDE > takes x3 time than usual. When I kill one of the seti processes, all > comes down to normal. The one remaining seti process takes 53% of > CPU constantly. Don't know how top calculates process CPU usage, but > if the 100% is spread over the two processors, then the seti process > monopolises one of the processors constantly. Doesn't matter will it > run nice 19 or idprio 31. As noted in Jeff's original mail, niced processes do not behave nicely yet. Kris pgp0.pgp Description: PGP signature
HEADS UP! KerberosIV is being retired!
Hello all Mission control has launched the retro-rocket module to de-orbit KerberosIV (AKA eBones). This package has had a long and illustrious career with FreeBSD; it is now time for a graceful retirement in the ports tree. The de-orbiting process will happen this weekend, in stages. Long live Kerberos 5 !! M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -O2 broke ppp NAT
On Fri, Mar 07, 2003 at 10:47:17PM +0800, Khairil Yusof wrote: > On Fri, 2003-03-07 at 01:24, Bruce Cran wrote: > > On Thu, Mar 06, 2003 at 09:22:06PM +0800, Khairil Yusof wrote: > > > On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote: > > > > > > > For the first time I compile current-p3 -> current-p4 with > > > > -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok > > > > except ppp -nat. NAT just don't work on my network. All machines are > > > > able to ping except ftp, http, etc. > > > > > > I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It > > > compiles cleanly though, but I don't know enough about gcc optimizations > > > to find out how O2 might break it. > > Upon further testing (recompiling usr.sbin/ppp) with no optimizations > except -O -pipe. -nat still fails to work with anything other than ICMP > traffic. > > I'm gonna try rebuild world without -O2, but that's not gonna help trace > where the problem is. :( I can tell you for shure that the problem is in libalias. Natd is staticaly compiled so you need to relink it, for ppp it is sufficient to just replace libalias.so. I have not recompiled the binaries but replaced them with older versions, so I can't say for shure that it depend on compiler options. Someone else already found out, that the calculated checksums are wrong. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
On Fri, Mar 07, 2003 at 05:00:42PM +0200, Petri Helenius wrote: > > There's probably a tightloop of frees going on somewhere. It's tough > > for me to analyze this as I cannot reproduce it. Have you tried > > running your tests over loopback to see if the same thing happens? > > What is the definition of "tightloop"? The received packet mbufs are freed > when the packets get processed/discarded which happens once for > a packet. The received packet rate is 5-15 packets per second. > > > > If so, and it does, can you please explain how to exactly replicate > > the test? > > Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable > promisc and monitor so it drops the packets after interrupt processing. > The overhead beyond that is neglible compared to mb_free. > > Pete Ok I have a patch that makes mb_free() a lot smaller by moving out everything not in the common case to seperate functions. I'm going to wait until I get home to give it a test run before I send it to you. At least this way you'll be able to profile again and tell me whether it's really the common case of mb_free() that's being expensive or if you're often hitting non-common-cases (in which case the auxilary routines should register the higher CPU usage). -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf cache
> There's probably a tightloop of frees going on somewhere. It's tough > for me to analyze this as I cannot reproduce it. Have you tried > running your tests over loopback to see if the same thing happens? What is the definition of "tightloop"? The received packet mbufs are freed when the packets get processed/discarded which happens once for a packet. The received packet rate is 5-15 packets per second. > > If so, and it does, can you please explain how to exactly replicate > the test? Mirror a port with ~300-800Mbps of IP traffic to an em port. Just enable promisc and monitor so it drops the packets after interrupt processing. The overhead beyond that is neglible compared to mb_free. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -O2 broke ppp NAT
On Fri, 2003-03-07 at 01:24, Bruce Cran wrote: > On Thu, Mar 06, 2003 at 09:22:06PM +0800, Khairil Yusof wrote: > > On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote: > > > > > For the first time I compile current-p3 -> current-p4 with > > > -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok > > > except ppp -nat. NAT just don't work on my network. All machines are > > > able to ping except ftp, http, etc. > > > > I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It > > compiles cleanly though, but I don't know enough about gcc optimizations > > to find out how O2 might break it. Upon further testing (recompiling usr.sbin/ppp) with no optimizations except -O -pipe. -nat still fails to work with anything other than ICMP traffic. I'm gonna try rebuild world without -O2, but that's not gonna help trace where the problem is. :( -- Khairil Yusof <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: mbuf cache
On Wed, Mar 05, 2003 at 10:07:35AM +0200, Petri Helenius wrote: > I think there is nothing really special about the driver there? The mbufs > are allocated in the driver and then freed when other parts in the kernel > are done with the packet? The issue I´m having is that mb_free takes > almost four times the cycles than mb_alloc for each call which does > not seem to be right? I shouldn´t be having lock contention in mb_alloc > because the whole thing is still under Giant, right? There's probably a tightloop of frees going on somewhere. It's tough for me to analyze this as I cannot reproduce it. Have you tried running your tests over loopback to see if the same thing happens? If so, and it does, can you please explain how to exactly replicate the test? -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[patch]Asus WL100 patch for -current
I am posting on behalf of [EMAIL PROTECTED] Attached is his patch for Asus WL100 wireless lan card. Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming ASUS_WL100_diff_FreeBSD5.tar.gz Description: application/tar-gz pgp0.pgp Description: PGP signature
lock? panic in networking swi
Fatal trap 12: page fault while in kernel mode fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01d47c6 stack pointer = 0x10:0xc5d33a90 frame pointer = 0x10:0xc5d33ab4 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 = 14 (swi1: net) trap number = 12 panic: page fault No core, of course, nm says the ip is likely: _mtx_unlock_sleep Thoughts? This is a kernel from last weekend, I'll try to get something more recent soon. FWIW, I'm reproducing these by running gtk-gnutella and telling it to auto-download anything with "talk talk" in it, which due to its wonderful anti-foot-shooting algorithms means it downloads everything with "talk" in it, which is quite a lot. Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xl: discard frame without packet header
Juli Mallett (Fri, Mar 07, 2003 at 12:18:38AM -0600) wrote: > This fixed yet? > > > xl0: discard frame w/o packet header > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x1 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc01fbcf8 > stack pointer = 0x10:0xc5d6fc34 > frame pointer = 0x10:0xc5d6fc58 > 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 = 20 (irq10: xl0) > trap number = 12 > panic: page fault > > If not I'll be able to take a quick stab at it tomorrow. Right. This has been fixed in revision 1.31 of if_xl.c. Update your sources, and you should be fine. Cheers. -- Hiten To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
