so use sysctl (was: Re: libkvm sucks)
On Mon, 17 May 1999, Marc Slemko wrote:
The premise: libkvm is fatally flawed by design, and fixing it is not an
easy proposition.
The reasoning: reading from kernel data structures without any locking has
obvious race conditions.
This is why any identd that uses libkvm sucks and gets into loops all the
time, etc.
This is why netstat will often bail out in the middle with kvm errors on a
busy machine with lots of TCP connections, especially if you slow it down
by doing hostname lookups.
In fact, on BSDI systems I have even seen identd hang the entire machine
hard by reading from the wrong address that the IO APIC is mapped at (BSDI
maps it starting at 0x, which much worse than a random address
for accidental reads).
In general, I'm no fan of the Linux style proc (by Linux style I mean
going crazy with the types of info there and the huge amount of formatting
done in the kernel), but in this case it can work a whole lot better, even
if it is somewhat less efficient.
I'm sure this isn't a new problem, but I don't recall hearing of any
suggested solutions and I'm not aware of any alternative interface to get
the same info on FreeBSD. Anyone?
unf!
part of a multithreaded ident server that i got bored with...
i'm not entirely sure it still works:
uid_t get_sok_uid(u_short lport, u_short fport, int *err){
/* mostly stolen from netstat */
char*mibvar = net.inet.tcp.pcblist;
char*buf;
int proto = IPPROTO_TCP;
uid_t retval = 0;
struct tcpcb *tp;
struct inpcb *inp;
struct xinpgen *xig, *oxig;
struct xsocket *so;
size_t len = 0;
*err = NO_ERR;
if (sysctlbyname(mibvar, 0, len, 0, 0) 0) {
*err = ERR_SYSCTL;
return(0);
}
if ((buf = (char *) malloc(len)) == 0) {
*err = ERR_MALLOC;
return(0);
}
if (sysctlbyname(mibvar, buf, len, 0, 0) 0) {
*err = ERR_SYSCTL;
free(buf);
return(0);
}
oxig = xig = (struct xinpgen *)buf;
for (xig = (struct xinpgen *)((char *)xig + xig-xig_len);
xig-xig_len sizeof(struct xinpgen);
xig = (struct xinpgen *)((char *)xig + xig-xig_len)) {
tp = ((struct xtcpcb *)xig)-xt_tp;
inp = ((struct xtcpcb *)xig)-xt_inp;
so = ((struct xtcpcb *)xig)-xt_socket;
/* Ignore sockets for protocols other than the desired one. */
if (so-xso_protocol != proto)
continue;
/* Ignore PCBs which were freed during copyout. */
if (inp-inp_gencnt oxig-xig_gen)
continue;
/* check port */
if (htons(inp-inp_fport) == fport
htons(inp-inp_lport) == lport){
printf(pgid = %d\n, so-so_pgid);
retval = so-so_uid;
free(buf);
return( retval );
}
}
*err = ERR_NOUSER;
free(buf);
}
enjoy,
-Alfred
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
forgot some stuff about sysctl: Re: libkvm sucks
On Mon, 17 May 1999, Marc Slemko wrote:
The premise: libkvm is fatally flawed by design, and fixing it is not an
easy proposition.
The reasoning: reading from kernel data structures without any locking has
obvious race conditions.
This is why any identd that uses libkvm sucks and gets into loops all the
time, etc.
This is why netstat will often bail out in the middle with kvm errors on a
busy machine with lots of TCP connections, especially if you slow it down
by doing hostname lookups.
In fact, on BSDI systems I have even seen identd hang the entire machine
hard by reading from the wrong address that the IO APIC is mapped at (BSDI
maps it starting at 0x, which much worse than a random address
for accidental reads).
In general, I'm no fan of the Linux style proc (by Linux style I mean
going crazy with the types of info there and the huge amount of formatting
done in the kernel), but in this case it can work a whole lot better, even
if it is somewhat less efficient.
I'm sure this isn't a new problem, but I don't recall hearing of any
suggested solutions and I'm not aware of any alternative interface to get
the same info on FreeBSD. Anyone?
doh: you also need a buncha headers:
#include stdio.h
#include unistd.h
#include pthread.h
#include string.h
#include stdarg.h
#include sys/types.h
#include pwd.h
#include sys/time.h
#include sys/socket.h
#include sys/socketvar.h
#include sys/sysctl.h
#include net/route.h
#include netinet/in.h
#include netinet/in_systm.h
#include netinet/ip.h
#include netinet/in_pcb.h
#include netinet/ip_var.h
#include netinet/tcp.h
#include netinet/tcpip.h
#include netinet/tcp_seq.h
#define TCPSTATES
#include netinet/tcp_fsm.h
#include netinet/tcp_timer.h
#include netinet/tcp_var.h
#include netinet/tcp_debug.h
#define NO_ERR 0
#define ERR_SYSCTL 1
#define ERR_MALLOC 2
#define ERR_NOUSER 3
#define ERR_READ4
#define ERR_TIMEOUT_READ5
#define ERR_WRITE 6
#define ERR_TIMEOUT_WRITE 7
you may be able to trim this list, and here's that function again:
uid_t get_sok_uid(u_short lport, u_short fport, int *err){
/* mostly stolen from netstat */
char*mibvar = net.inet.tcp.pcblist;
char*buf;
int proto = IPPROTO_TCP;
uid_t retval = 0;
struct tcpcb *tp;
struct inpcb *inp;
struct xinpgen *xig, *oxig;
struct xsocket *so;
size_t len = 0;
*err = NO_ERR;
if (sysctlbyname(mibvar, 0, len, 0, 0) 0) {
*err = ERR_SYSCTL;
return(0);
}
if ((buf = (char *) malloc(len)) == 0) {
*err = ERR_MALLOC;
return(0);
}
if (sysctlbyname(mibvar, buf, len, 0, 0) 0) {
*err = ERR_SYSCTL;
free(buf);
return(0);
}
oxig = xig = (struct xinpgen *)buf;
for (xig = (struct xinpgen *)((char *)xig + xig-xig_len);
xig-xig_len sizeof(struct xinpgen);
xig = (struct xinpgen *)((char *)xig + xig-xig_len)) {
tp = ((struct xtcpcb *)xig)-xt_tp;
inp = ((struct xtcpcb *)xig)-xt_inp;
so = ((struct xtcpcb *)xig)-xt_socket;
/* Ignore sockets for protocols other than the desired one. */
if (so-xso_protocol != proto)
continue;
/* Ignore PCBs which were freed during copyout. */
if (inp-inp_gencnt oxig-xig_gen)
continue;
/* check port */
if (htons(inp-inp_fport) == fport
htons(inp-inp_lport) == lport){
printf(pgid = %d\n, so-so_pgid);
retval = so-so_uid;
free(buf);
return( retval );
}
}
*err = ERR_NOUSER;
free(buf);
}
-Alfred
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: so use sysctl (was: Re: libkvm sucks)
On Tue, 18 May 1999, Alfred Perlstein wrote: [...] unf! part of a multithreaded ident server that i got bored with... i'm not entirely sure it still works: Yea, that idea works, thanks. I didn't notice that the way this is done was changed in 3.x to add the sysctl option. I do wonder about the quantity of raw information it exposes to anyone without it being filtered through some trusted code that hides any private information, especially if any such info is added at a later time to existing structures. In any case, it makes sense, and is a reasonable alternative. Unfortunately it isn't portable, but that's life. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
It seems Kelly Yancey wrote: I admit that they are less common than say 320x240 mode x...but they are linear and don't require any hacking to support from applications which would use graphics modes (unlike the unchained modex modes). I absolutely agree that we should keep the kernel as lean as possible. And I would *love* to put the modes into a module (that was my original plan)...but to do that, I need get_mode_param to be extern'ed from vga_isa.c so that the module can access the BIOS mode table (or else re-implement the code in vga_isa.c to access the mode table). All I am looking for is the OK to make that routine extern in my patches and I'll make a module. My biggest concern is that get_mode_param is obviously considered an internal API and thus subject to change...change which would then break my KLD. :( With a module, I would suggest moving the implemention of the 320x240 modex mode there also (or else remove it altogether...but with a module, removing it would be unnessicary). And with a module, there would be no harm in implementing the other 6 modex modes (320x400, 320x480, 360x200, 360x240, 360x400, 360x480). If I can get past the get_mode_param hangup, then there would be no reason no to implement 2 KLD's: one for the tweaked video modes and one for the 90-column text modes. Hmm, I see no problem in publicising get_mode_param, the only thing is that it might change over time, but thats another matter... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Debugging
On Mon, 17 May 1999 09:58:10 +0100, Doug Rabson wrote: I don't think LINT in current mentions the new debug flag. Are you talking about this: # The `makeoptions' parameter allows variables to be passed to the # generated Makefile in the build area. DEBUG happens to be magic. [...] #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols ? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Debugging
On Tuesday, 18 May 1999 at 9:00:49 +0200, Sheldon Hearn wrote: On Mon, 17 May 1999 09:58:10 +0100, Doug Rabson wrote: I don't think LINT in current mentions the new debug flag. Are you talking about this: # The `makeoptions' parameter allows variables to be passed to the # generated Makefile in the build area. DEBUG happens to be magic. [...] #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols No. Doug's right, it appears. The flags are for the serial ports (sio0, etc). LINT says: # `flags' for serial drivers that support consoles (only for sio now): # 0x10enable console support for this unit. The other console flags # are ignored unless this is set. Enabling console support does # not make the unit the preferred console - boot with -h or set # the 0x20 flag for that. Currently, at most one unit can have # console support; the first one (in config file order) with # this flag set is preferred. Setting this flag for sio0 gives # the old behaviour. # 0x20force this unit to be the console (unless there is another # higher priority console). This replaces the COMCONSOLE option. # 0x40reserve this unit for low level console operations. Do not # access the device in any normal way. In fact, there's also a 0x80, which you need to set (along with 0x10, it appears) to run remote debugging. I'm guessing a bit at this, since I haven't had time to look at the code, but 0x90 works for me. Doug? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Debugging
On Tue, 18 May 1999 16:34:55 +0930, Greg Lehey wrote: In fact, there's also a 0x80, which you need to set (along with 0x10, it appears) to run remote debugging. I'm guessing a bit at this, since I haven't had time to look at the code, but 0x90 works for me. This is something new since about 4 months ago, then? I used 0x10 on a 4.0-CURRENT machine a while back and managed to do remote debugging successfully (after a little help from you, in fact). :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
Hi hackers, I'm pleased to participate in such cool project. Is anybody kind enough to tell me how to run this program while the FreeBSD box is idle? Thanks in advance, -- Kazukiyo Ueda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ASUS P2B-DS and SMP
* David E. Cross | I dug through the archives and found peopel with similiar problems to | what I am experiencing, but I didn't find any answers that have worked | for me. Here are the problem I am having: | [..] I've experienced this problem too, and have found a solution: (Should have posted it ages ago). Try flashing your BIOS to v1.006 (or older). Yes, it works! I've tested it on two motherboards, and both work with BIOS versions prior to v1.007. -- Andreas Dobloug : email: andre...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ASUS P2B-DS and SMP
* sth...@nethelp.no | 1: The built-in SCSI ROM is v2.01, there was mention of BIOS 1008 including | 2.11. I applied the 1008 flash and I am still v2.01 (I don't know if | this matters at all) | At least for the P2B-S, you need 1008B, not 1008. The file I got from I haven't tested 1.008(b), but I did test 1.009 two days ago. It still didn't work properly. -- Andreas Dobloug : email: andre...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Debugging
On Tue, 18 May 1999, Greg Lehey wrote: In fact, there's also a 0x80, which you need to set (along with 0x10, it appears) to run remote debugging. I'm guessing a bit at this, since I haven't had time to look at the code, but 0x90 works for me. Doug? I used to use 0x50 but now 0x80 works fine. I'm not sure why the debug flag changed from 0x40 to 0x80 but the new systems seems to allow both serial console and serial debugging at the same time so I'm not complaining. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
My experience is that most modern (and many older) PC NIC's are able to change their MAC address. The question really is, how should I do this from within FreeBSD. Is there a standard entry into the drivers to do this? If you are wondering why I want to do this, I am looking at hot standby and redundant takeover stuff for high availability systems. Steve On Fri, 14 May 1999, Nate Williams wrote: I know it's possible to bridge ethernet segments under linux, and the only way that bridging can be implemented is if the MAC address be changed in software on a per-packet basis. What do you mean 'bridge ethernet segments'? A bridge will listen on two specific ethernet ports and decide which MAC addresses are on which side of the bridge and only forward those packets which need to cross the bridge. In addition, bridges use the IEEE spanning protocol to get rid of possible loops when there are multiple bridges and switches connected together. An ethernet switch is in essence a bridge with alot of ports. Very likely there are not kernel facilities to do this, but the existence of bridging code convinces me that it must be possible to alter mac address. Not that I'm aware of. Too many licensing schemes rely on mac addresses to provide the unique 'fingerprint' to have this be something that is easily doable. You're too stubborn here. If a linux box can bridge, then it logically must be able to change MAC address on a per-packet basis. Also when a PC runs a DECNET client, it must also be able to change ehternet addresses from the base value in the card. -- C. Mott To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Debugging
On Tuesday, 18 May 1999 at 9:17:03 +0200, Sheldon Hearn wrote: On Tue, 18 May 1999 16:34:55 +0930, Greg Lehey wrote: In fact, there's also a 0x80, which you need to set (along with 0x10, it appears) to run remote debugging. I'm guessing a bit at this, since I haven't had time to look at the code, but 0x90 works for me. This is something new since about 4 months ago, then? I used 0x10 on a 4.0-CURRENT machine a while back and managed to do remote debugging successfully (after a little help from you, in fact). :-) On Tuesday, 18 May 1999 at 9:09:34 +0100, Doug Rabson wrote: On Tue, 18 May 1999, Greg Lehey wrote: In fact, there's also a 0x80, which you need to set (along with 0x10, it appears) to run remote debugging. I'm guessing a bit at this, since I haven't had time to look at the code, but 0x90 works for me. Doug? I used to use 0x50 but now 0x80 works fine. I'm not sure why the debug flag changed from 0x40 to 0x80 but the new systems seems to allow both serial console and serial debugging at the same time so I'm not complaining. Kirk committed some stuff a week or two ago. And yes, IIRC it was to allow the same serial port to be used for both purposes. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Repeatable kernel panic for 3.2-RELEASE NFS server
cro...@cs.rpi.edu (David E. Cross) writes: One of our users way able to reliably crash an NFS server 3 times today. I have since copied his program and have reliably crashed a seperate and unloaded machine with the exact same panic, lockmgr: locking against myself. I check the recent DG patches that went in after -RELEASE and they Are you sure this is NFS related? I can certainly reliably reproduce that and other panics (reported in kern/11629, includes a fix). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
On Tue, 18 May 1999, Ueda, Kazukiyo wrote: I'm pleased to participate in such cool project. Is anybody kind enough to tell me how to run this program while the FreeBSD box is idle? Install the astro/setiathome port. One thing I've been meaning to look at though is that it seems to run it at niceness 1, which isn't exactly friendly to the other consumers of CPU. You should be able to tweak it easily, though. Kris - That suit's sharper than a page of Oscar Wilde witticisms that's been rolled up into a point, sprinkled with lemon juice and jabbed into someone's eye Wow, that's sharp! - Ace Rimmer and the Cat, _Red Dwarf_ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
Hi, At 16:48 18/05/99 +0900, Ueda, Kazukiyo wrote: I'm pleased to participate in such cool project. Is anybody kind enough to tell me how to run this program while the FreeBSD box is idle? man nice -- Bob Bishop +44 118 977 4017 r...@gid.co.uk fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
speaking of Ensoniq... Is anyone working on ES1371 drivers? -- Steve Rubin - s...@tch.org - http://www.tch.org/~ser/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
At 02:36 -0700 05/18/99, Steve Rubin wrote: Is anyone working on ES1371 drivers? Yes. I'm working on ES1371 drivers with SB PCI128. -- KEK, High Energy Accelerator Research Organization Shin-ichi YOSHIMOTO yosim...@mail.kek.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: so use sysctl (was: Re: libkvm sucks)
Marc Slemko wrote: In any case, it makes sense, and is a reasonable alternative. Unfortunately it isn't portable, but that's life. And linux /proc is portable? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org If at first you don't succeed, skydiving is not for you. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
On 18-May-99 Shin-ichi YOSHIMOTO wrote: Is anyone working on ES1371 drivers? Yes. I'm working on ES1371 drivers with SB PCI128. Hmm.. I have access to an SB Ensoniq Audio PCI which has the ES1371 on it. I can test patches etc. The machine is running 3.2-BETA. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: libkvm sucks
On Mon, 17 May 1999, Marc Slemko wrote: The reasoning: reading from kernel data structures without any locking has obvious race conditions. [...] This is why netstat will often bail out in the middle with kvm errors on a busy machine with lots of TCP connections, especially if you slow it down by doing hostname lookups. I agree that locking, in one form or another, is required to traverse dynamic chains. However, this applies to the functionality wherever it is implemented. Moving the formatting to the kernel does not change anything. If you are concerned about the time that it takes to do hostname lookups, that time is not any shorter in the kernel. There are two fundamental approaches that work. 1) Lock the structure Make a snapshot copy Unlock the structure Generate the report from the copy Destroy the copy This technique can be used in either userland or kernel implementation. Even without the structure locks, the failure window is considerably smaller for those operations that require a long time to format the report. 2) Use list traversal protocols that prevent the actual deletes from occurring while there is another list reader in that portion of the list. Again, the only requirement in the kernel is the ability set and clear the lock. The remainder of the formatting can occur outside the kernel because the structures being viewed and not destroyed during the traversal. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
At 19:31 +0930 05/18/99, Daniel O'Connor wrote: Hmm.. I have access to an SB Ensoniq Audio PCI which has the ES1371 on it. I also tried an Ensoniq Audio PCI with the ES1371 at first. But this card did not work. Then I tried a CREATIVE SB PCI128 which has the CREATIVE 5507 on it. It was working fine on ES1370 drivers. My machine is running 3.2-stable and I only add the following line to my kernel configuration file: device pcm0 at isa ? port? tty irq 7 drq 1 -- KEK, High Energy Accelerator Research Organization Shin-ichi YOSHIMOTO yosim...@mail.kek.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: libkvm sucks
The premise: libkvm is fatally flawed by design, and fixing it is not an easy proposition. The reasoning: reading from kernel data structures without any locking has obvious race conditions. This is why any identd that uses libkvm sucks and gets into loops all the time, etc. This is why netstat will often bail out in the middle with kvm errors on a busy machine with lots of TCP connections, especially if you slow it down by doing hostname lookups. In fact, on BSDI systems I have even seen identd hang the entire machine hard by reading from the wrong address that the IO APIC is mapped at (BSDI maps it starting at 0x, which much worse than a random address for accidental reads). In general, I'm no fan of the Linux style proc (by Linux style I mean going crazy with the types of info there and the huge amount of formatting done in the kernel), but in this case it can work a whole lot better, even if it is somewhat less efficient. I'm sure this isn't a new problem, but I don't recall hearing of any suggested solutions and I'm not aware of any alternative interface to get the same info on FreeBSD. Anyone? Generally we've been moving towards using sysctl for reading kernel data. procfs/kernfs is usually the wrong tool for the job in most cases (my subjective opinion of course). -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ed driver probe changes?
Last night I switched from 3.1-STABLE to 4.0-CURRENT. Everything went great except for one spot. I have two ethernet cards in this machine. Both use the 'ed' driver. One is PCI the other is ISA. In the 3.1 machine I had a line in the config that said: device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 So the 'isa' card would come up. The PCI card was always detected first and given ed1 (since ed0 was bound to ISA). Under the 4.0 kernel the PCI card is given ed0 and a message is displayed saying ed0 already in use giving next number. The isa card is _NEVER_ probed. I don't even get a message saying it was probed and not found. Is there any probe debugging I can turn on to get more verbose output? Does anyone have a solution for the above? I've tried disabling the pnp controller in the kernel and it has zero effect on anything. The same thing occurs (ie the PCI card gets assigned ed0 and the ISA card is never found). -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
On Tue, 18 May 1999, Kazutaka YOKOTA wrote: I think you just nailed the problem here. It requires a prohibitive amount of effort to support modex video modes given the return. What I am thinking about is removing the 320x240 mode (since it is impossibly difficult to deal with)...no one is using it now so no one would be affected. I would also like to add a comment into one of the source files indicating why we have chosen not to support unchained VGA modes (ie. modex modes) so that we can prevent this question from arising again in the future. On a slightly related note, I am currently in the process of developing patches to add more useful tweaked modes to the video driver: graphics 720x480, 16 colors (90x30 8x16 character cells) graphics 256x256, 256 colors (32x32 8x8 character cells) graphics 296x220, 256 colors (37x27 8x8 character cells) text 90x25, 90x30, 90x43, 90x50, 90x60 The patches will also update vidcontrol to allow selecting any of the modes. Please have a look at my latest syscons update patch: http://www.freebsd.org/~yokota/syscons-update.17May.tar.gz It includes 90-column text mode patch you previously submitted (PR: i386/7510)! Very cool. Thanks! I listed the character cell sizes I picked for the graphics modes...which brings me to an interesting question: how come we pick a single character cell size for video modes? For video modes 640x480 or more it would be nice to select what size the character cells are (for example, selecting an 8x8 cell size rather than 8x16 to double the number of characters which could be written). Um, I have not advertised this before, but... Syscons in 3.X and 4.0-CURRENT already can do this not only for the VESA 800x600 mode but also for certain other video modes. Holding out on us, huh? :) I'm not really sure what practical use there is for using graphics modes to render text (and hence why character cell sizes for graphics modes would even be used). But currently syscons can do it from VESA 800x600 (syscons renders the text). Presumably, though, if it is useful, there isn't anything preventing the implementation from being extended to all graphics modes (except for modex that is...but I'm now of the impression that should be axed). Finally, with syscons having the ability to render text fonts in graphics modes, shouldn't we be able to redefine the notion of character cell size for graphics modes to be the default character cell size and allow any available text font be used to render text in graphics modes? Yes, it can be extended to support all graphics modes (except mode X :-). But, how useful will it be? The VESA 800x600 raster text mode was a kludge for some laptop systems, so it was justifiable. But, how about others? 1024x768 mode can contain only 128 columns if we are to use 8-dot wide font. This is not as good as 132 column text modes provided by VESA. Yeah, I can see that. I was basically just curious if the plan was originally to support this sort of thing since real character cell size values were included for each graphics mode too...which might imply that there was some intention to implement text rendering in all text modes at some point. On the other hand, maybe it was just for the sake of completeness :)...that's really what I was trying to find out. Now I know it is the latter. Thanks for the great feedback, Kelly ~kby...@alcnet.com~ FreeBSD - The Power To Serve - http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
netbooting a freebsd kernel with 3c905B (fwd)
(Already posted to freebsd-net) I'm currently doing a FreeBSD installation from network, a bit like jumpstart. So,I need to find a freeware to netboot a freebsd kernel with 3c905B Ken Yap from the etherboot site, told me about a special etherboot that freebsd people had done to make etherboot boot freebsd kernel. A complete RFC 1048 support would be great, because it could allow me to secure the installation by mfs mounting the R/W partitions and NFS export the Read only ones. Every piece of information interest me can someone help me?? Thanks a lot Bye To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: netbooting a freebsd kernel with 3c905B (fwd)
I'm currently doing a FreeBSD installation from network, a bit like jumpstart. So,I need to find a freeware to netboot a freebsd kernel with 3c905B Ken Yap from the etherboot site, told me about a special etherboot that freebsd people had done to make etherboot boot freebsd kernel. A complete RFC 1048 support would be great, because it could allow me to secure the installation by mfs mounting the R/W partitions and NFS export the Read only ones. Every piece of information interest me can someone help me?? Doug Ambrisko came up with some patches, you can find an early version attached to PR 9480, there may be more recent versions around now. I've got it working with an MFS kernel, if you need other help feel free to mail me. Andrew. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
On Tue, 18 May 1999, Soren Schmidt wrote: It seems Kelly Yancey wrote: I admit that they are less common than say 320x240 mode x...but they are linear and don't require any hacking to support from applications which would use graphics modes (unlike the unchained modex modes). I absolutely agree that we should keep the kernel as lean as possible. And I would *love* to put the modes into a module (that was my original plan)...but to do that, I need get_mode_param to be extern'ed from vga_isa.c so that the module can access the BIOS mode table (or else re-implement the code in vga_isa.c to access the mode table). All I am looking for is the OK to make that routine extern in my patches and I'll make a module. My biggest concern is that get_mode_param is obviously considered an internal API and thus subject to change...change which would then break my KLD. :( With a module, I would suggest moving the implemention of the 320x240 modex mode there also (or else remove it altogether...but with a module, removing it would be unnessicary). And with a module, there would be no harm in implementing the other 6 modex modes (320x400, 320x480, 360x200, 360x240, 360x400, 360x480). If I can get past the get_mode_param hangup, then there would be no reason no to implement 2 KLD's: one for the tweaked video modes and one for the 90-column text modes. Hmm, I see no problem in publicising get_mode_param, the only thing is that it might change over time, but thats another matter... -S?ren Well, Kazutaka apparently is already putting the text modes in syscons (it is really just a few extra lines of code to support). But I'll get together a patch set which externs get_mode_param and includes a new module for the 6 modex modes and the other 3 linear modes we've been bouncing around. I'm not going to attempt it at first, but perhaps we could move the existing 320x240 modex mode into the KLD down the road too. I'll post those patches as soon as I'm done with them. Thanks everyone for all the input, Kelly ~kby...@alcnet.com~ FreeBSD - The Power To Serve - http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
I'm not really sure what practical use there is for using graphics modes to render text (and hence why character cell sizes for graphics modes What if FreeBSD ends up supporting mips or sparc? These machines don't have anything like VGA text modes, and PROM consoles suck. that should be axed). Finally, with syscons having the ability to render text fonts in graphics modes, shouldn't we be able to redefine the notion of character cell size for graphics modes to be the default character cell size and allow any available text font be used to render text in graphics modes? NetBSD-current already does this particularly well, in all the common colordepths (but not Mode-X ;): sys/dev/wsfont (in-kernel font table) sys/dev/rasops (raster console operation sets) sys/dev/wscons (the MI console) Andy. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
Kris Kennaway kkenn...@physics.adelaide.edu.au wrote:
On Tue, 18 May 1999, Ueda, Kazukiyo wrote:
I'm pleased to participate in such cool project. Is anybody kind
enough to tell me how to run this program while the FreeBSD box is
idle?
Install the astro/setiathome port.
Make sure you have the newest version of the port (for setiathome-1.1).
Pre-1.1 version don't work anymore. Unfortunatly, the release of 1.1 came
too late for the 3.2 CDs. Even more unfortunate is the fact that all
versions (including 1.1) try to send mail by invoking /usr/lib/sendmail...
I guess I'll be changing the port quite rapidly for the next few days as
next version comes out, which is supposed to fix the sendmail as well as
the proxy problem.
One thing I've been meaning to look at though is that it seems to run it
at niceness 1, which isn't exactly friendly to the other consumers of
CPU. You should be able to tweak it easily, though.
Would you suggest a different default nice level, then, and what should it
be?
One can easily modifiy ${PREFIX}/etc/rc.d/setiathome.sh to run it with
-nice 100, and I'm open to making a level other that 1 the default.
Stefan
--
Mühlendamm 12 | Voice +49-40-256848, +49-177-3504009
D-22089 Hamburg | e-mail: stefan.bet...@hanse.de
Germany | s...@freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
ed0/probe problem in 4.0-CURRENT
Last night switched from 3.1 to 4.0. Smooth transition. The only error I've seen is one of my ethernet cards is no longer detected. In the previous kernel (3.1-STABLE) I had the following config line: device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 When the system booted it would detect 'ed1' on the PCI bus and 'ed0' on the isa bus. All was good. Under 4.0 things changed. Now when the system boots the PCI card is assigned to 'ed0' and then a message is printed saying 'ed0' is already used, using next number. But my ISA card isn't probed. I switched the ISA card to 'ed1'. The 'already used' message stopped but my ISA card is still not detected. The PCI card is: ed0: NE2000 PCI Ethernet (RealTek 8029) irq 11 at device 15.0 on pci0 ed0: address 52:54:00:dc:08:ca, type NE2000 (16 bit) the ISA card is MIA. I don't even get a 'ed1 not found at' message. Can anyone point me in the right direction? Or tell me how to make the device probing more verbose? -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: libkvm sucks
However, this applies to the functionality wherever it is implemented. Moving the formatting to the kernel does not change anything. It changes thinks in that it unnecessarily bloats the kernel. If you are concerned about the time that it takes to do hostname lookups, that time is not any shorter in the kernel. You can't perform hostname lookups in the kernel. There are two fundamental approaches that work. 1) Lock the structure Make a snapshot copy Unlock the structure Generate the report from the copy Destroy the copy This technique can be used in either userland or kernel implementation. You can't lock kernel datastructures from userland (except for certain very specific cases where the lock is a side-effect of another operation). 2) Use list traversal protocols that prevent the actual deletes from occurring while there is another list reader in that portion of the list. Again, the only requirement in the kernel is the ability set and clear the lock. The remainder of the formatting can occur outside the kernel because the structures being viewed and not destroyed during the traversal. This is where sysctl is preferable; the system call allows the kernel to perform whatever locking protocol is required to complete the call in a timely and efficient fashion, and all formatting can be performed in userland while the kernel holds no locks. Consider the similarities to NFS directory traversals, and the cookie approach used in NFSv3 to deal with server-side state changes during traversal by the client. You're arguing about a problem that already has several tried and tested solutions. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ed driver probe changes?
Steven Ames wrote: Under the 4.0 kernel the PCI card is given ed0 and a message is displayed saying ed0 already in use giving next number. The isa card is _NEVER_ probed. I don't even get a message saying it was probed and not found. I've tried disabling the pnp controller in the kernel and it has zero effect on anything. The same thing occurs (ie the PCI card gets assigned ed0 and the ISA card is never found). Try changing the ISA card to ed1 in the config? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
#define quoting(Stefan Bethke)
// Kris Kennaway kkenn...@physics.adelaide.edu.au wrote:
// On Tue, 18 May 1999, Ueda, Kazukiyo wrote:
// One thing I've been meaning to look at though is that it seems to run it
// at niceness 1, which isn't exactly friendly to the other consumers of
// CPU. You should be able to tweak it easily, though.
//
// Would you suggest a different default nice level, then, and what should it
// be?
//
// One can easily modifiy ${PREFIX}/etc/rc.d/setiathome.sh to run it with
// -nice 100, and I'm open to making a level other that 1 the default.
What about idprio ? And the installer or manual could also suggest
the sysctl tweaks to avoid lazy CPU response.
Jonny
--
João Carlos Mendes Luís jo...@jonny.eng.br
Networking Enginner j...@ieee.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: libkvm sucks
David Greenman wrote: Generally we've been moving towards using sysctl for reading kernel data. procfs/kernfs is usually the wrong tool for the job in most cases (my subjective opinion of course). And afterwards, if someone really wants it, you could reimplement procfs using sysctl, taking advantage of the fine-grained access that has already been implemented. Not that procfs gains you anything over sysctl, except some sort of compability with Linux. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
Stefan Bethke wrote:
Make sure you have the newest version of the port (for setiathome-1.1).
Pre-1.1 version don't work anymore. Unfortunatly, the release of 1.1 came
too late for the 3.2 CDs. Even more unfortunate is the fact that all
versions (including 1.1) try to send mail by invoking /usr/lib/sendmail...
I guess I'll be changing the port quite rapidly for the next few days as
next version comes out, which is supposed to fix the sendmail as well as
the proxy problem.
Thank you.
One thing I've been meaning to look at though is that it seems to run it
at niceness 1, which isn't exactly friendly to the other consumers of
CPU. You should be able to tweak it easily, though.
Would you suggest a different default nice level, then, and what should it
be?
RTP_PRIO_IDLE of course. See rtprio(2).
One can easily modifiy ${PREFIX}/etc/rc.d/setiathome.sh to run it with
-nice 100, and I'm open to making a level other that 1 the default.
In that case, make the start script run it at idprio:
idprio setiathome
Phew! That was tough, huh? ;^)
--
Where am I, and what am I doing in this handbasket?
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr w...@softweyr.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: libkvm sucks
On Tue, 18 May 1999, Mike Smith wrote: However, this applies to the functionality wherever it is implemented. Moving the formatting to the kernel does not change anything. It changes things in that it unnecessarily bloats the kernel. I agree. My reference was in relation to the the need for locks. Whether you are in the kernel or in userland, you need locks to get around race conditions. If you are concerned about the time that it takes to do hostname lookups, that time is not any shorter in the kernel. You can't perform hostname lookups in the kernel. Today... (And I see no reason to add that functionality there) There are two fundamental approaches that work. 1) Lock the structure Make a snapshot copy Unlock the structure Generate the report from the copy Destroy the copy This technique can be used in either userland or kernel implementation. You can't lock kernel datastructures from userland (except for certain very specific cases where the lock is a side-effect of another operation). I again agree. The lock, copy, unlock sequence would probably be a single operation that userland requests the kernel to perform. 2) Use list traversal protocols that prevent the actual deletes from occurring while there is another list reader in that portion of the list. Again, the only requirement in the kernel is the ability set and clear the lock. The remainder of the formatting can occur outside the kernel because the structures being viewed and not destroyed during the traversal. This is where sysctl is preferable; the system call allows the kernel to perform whatever locking protocol is required to complete the call in a timely and efficient fashion, and all formatting can be performed in userland while the kernel holds no locks. Consider the similarities to NFS directory traversals, and the cookie approach used in NFSv3 to deal with server-side state changes during traversal by the client. You're arguing about a problem that already has several tried and tested solutions. I'm not arguing about anything. I'm stating that the technique is one possible solution to the race problem. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ed driver probe changes?
Wes Peters wrote: Steven Ames wrote: Under the 4.0 kernel the PCI card is given ed0 and a message is displayed saying ed0 already in use giving next number. The isa card is _NEVER_ probed. I don't even get a message saying it was probed and not found. I've tried disabling the pnp controller in the kernel and it has zero effect on anything. The same thing occurs (ie the PCI card gets assigned ed0 and the ISA card is never found). Try changing the ISA card to ed1 in the config? Been there. No luck. And still no probe messages. -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
In the last episode (May 18), Wes Peters said:
Stefan Bethke wrote:
Would you suggest a different default nice level, then, and what
should it be?
RTP_PRIO_IDLE of course. See rtprio(2).
One can easily modifiy ${PREFIX}/etc/rc.d/setiathome.sh to run it
-with nice 100, and I'm open to making a level other that 1 the
-default.
In that case, make the start script run it at idprio:
idprio setiathome
Phew! That was tough, huh? ;^)
Problem is that idprio isn't safe. I used to idprio the rc5client, but
within a day or do the machine would lock up. Rc5client would get a
lock on the root of the filesystem at idprio, and if there was another
process running at 100% CPU, rc5client would never get a chance to
unlock, causing all the other processes on the system to hang.
See PR kern/5641.
-Dan Nelson
dnel...@emsphone.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: libkvm sucks
On Tue, 18 May 1999, Richard Wackerbarth wrote: On Mon, 17 May 1999, Marc Slemko wrote: The reasoning: reading from kernel data structures without any locking has obvious race conditions. [...] This is why netstat will often bail out in the middle with kvm errors on a busy machine with lots of TCP connections, especially if you slow it down by doing hostname lookups. I agree that locking, in one form or another, is required to traverse dynamic chains. However, this applies to the functionality wherever it is implemented. Moving the formatting to the kernel does not change anything. If you are concerned about the time that it takes to do hostname lookups, that time is not any shorter in the kernel. I never suggested it was. The only thing I was saying is that doing the locking from libkvm ranges between difficult and impossible due to the API, and even if the libkvm API was different you still can't have (or want, IMHO) userland arbitrarily locking kernel data structures without doing evil things. However you do it, the only sane way is to move more functionality to the kernel as compared to the libkvm way. That doesn't have to be the formatting code, and probably shouldn't be. On Tue, 18 May 1999, Daniel C. Sobral wrote: Marc Slemko wrote: In any case, it makes sense, and is a reasonable alternative. Unfortunately it isn't portable, but that's life. And linux /proc is portable? I wasn't thinking about that, but obviously no; Linux /proc isn't portable. A lot of the time it isn't even portable across different Linux kernel versions. However, libkvm accesses are actually somewhat portable to a certain extent. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Debugging
On Tue, 18 May 1999, Greg Lehey wrote: Kirk committed some stuff a week or two ago. And yes, IIRC it was to allow the same serial port to be used for both purposes. Actually it's to allow DIFFERENT serial ports to be used.. Greg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3.2-RELEASE and netscape problem.
It breaks because compat22 is installing _everything_ in /usr/lib/compat/aout. We've reproduced this locally - compat22 is hosed. Will fix this. I followed the lead of the unoffical compat22 which was built from libs on Hub. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
a.out lib placment (was: 3.2-RELEASE and netscape problem.)
It breaks because compat22 is installing _everything_ in
/usr/lib/compat/aout. We've reproduced this locally - compat22 is
hosed.
I *knew* this was going to bite us in the ass. I brought it up at E-day
time... and was ignored.
Some body please decide where bits should live. *IF* you upgrade from
2.2.x to 3.x, your /usr/lib a.out libs are moved to /usr/lib/aout, *AND*
your /usr/lib/compat a.out libs are moved to /usr/lib/compat/aout. Fine.
NOW if you look at the compat2{0,1} bits we shipped with 3.2, they
install into /usr/lib/compat/. Thus we have no consistancy. So compat22
is no more broken than ``make aout-to-elf''.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: VMware--anyone playing with it?
On Mon, 17 May 1999 23:40:03 +0200 Andreas Braukmann braukm...@tse-online.de wrote: ... and the Connectix Virtual PC is available for FreeBSD? No, it's a MacOS program. that's for sure, ... from a theoretically point of view at least. But I suppose, that the virtual machine approach would lead to more performant designs? dunno... the VirtualPC certainly didn't seem to have any performance shortcomings. And, on a 350MHz PowerPC G3, who cares if it's emulated at the instruction level? -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FW: Question on rename()
Could you guys please give yer own opinions on that? I will compile some of the better arguments and resend them to the Posix revision list... -FW: 990518120639.zm1...@tamarix.rdg.opengroup.org- Date: Tue, 18 May 1999 13:06:40 +0100 From: Andrew Josey ajo...@rdg.opengroup.org To: austin-gr...@opengroup.org Subject: Question on rename() All, The following question was raised to my attention. I'd appreciate thoughts on this and recommendations on the next step best regards Andrew --- Forwarded mail In POSIX 1003.1 1996 in 5.5.3.2 there is the rather unfortunate part If the old argument and the new argument both refer to links to the same existing file, the rename() function shall return successfully and perform no other action.. In SUSV2 it is stated that If the old argument and the new argument both refer to, and both link to the same existing file, rename() returns successfully and performs no other action. People are quite bothered by the fact that the Linux kernel follows this, possibly too literally. One consequence is that after a successful rename(aa, bb); it is possible that aa still exists, i.e., that stat(aa, buf); still succeeds. Another is that on a filesystem where filenames are case-sensitive upon readdir() and creat() but case-insensitive for open(), it may be impossible to do rename(austin,Austin); and rename(austin,aux); rename(aux,Austin); would be required. The rationale does not mention such strange cases and just says that the sentence is meant to ensure that rename(x, x); does not remove the file x. -- ---End of forwarded mail - Andrew JoseyThe Open Group Austin Group Chair Apex Plaza,Forbury Road, Email: a.jo...@opengroup.orgReading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 --End of forwarded message- --- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The FreeBSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Accept no limitations... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
Dan Nelson wrote: Problem is that idprio isn't safe. I used to idprio the rc5client, but within a day or do the machine would lock up. Rc5client would get a lock on the root of the filesystem at idprio, and if there was another process running at 100% CPU, rc5client would never get a chance to unlock, causing all the other processes on the system to hang. See PR kern/5641. Hmmm. Can you say inversion proof semaphore? Bad news, huh? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
:Dan Nelson wrote: : : Problem is that idprio isn't safe. I used to idprio the rc5client, but : within a day or do the machine would lock up. Rc5client would get a : lock on the root of the filesystem at idprio, and if there was another : process running at 100% CPU, rc5client would never get a chance to : unlock, causing all the other processes on the system to hang. : : See PR kern/5641. : :Hmmm. Can you say inversion proof semaphore? Bad news, huh? : :-- : Where am I, and what am I doing in this handbasket? : :Wes Peters Softweyr LLC :http://www.softweyr.com/~softweyr w...@softweyr.com Yes, this is a very real problem. I forgot to mention it. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ed0/probe problem in 4.0-CURRENT
Wow. I don't think that should ever happen but at this point I'll try a lot of things :) Tried it. didn't work. really, isn't there a way to enable more verbose probing so that it says 'ed0 not found at 0x280' or some such? When I upgraded, my ed0 became ep0 you might want to try that. Brandon Hicks - Gate Keeper Technologies Trixster bhi...@gatekeep.net -Original Message- From: Steven Ames st...@virtual-voodoo.com To: freebsd-hackers@FreeBSD.ORG freebsd-hackers@FreeBSD.ORG Date: Tuesday, May 18, 1999 10:10 AM Subject: ed0/probe problem in 4.0-CURRENT Last night switched from 3.1 to 4.0. Smooth transition. The only error I've seen is one of my ethernet cards is no longer detected. In the previous kernel (3.1-STABLE) I had the following config line: device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 When the system booted it would detect 'ed1' on the PCI bus and 'ed0' on the isa bus. All was good. Under 4.0 things changed. Now when the system boots the PCI card is assigned to 'ed0' and then a message is printed saying 'ed0' is already used, using next number. But my ISA card isn't probed. I switched the ISA card to 'ed1'. The 'already used' message stopped but my ISA card is still not detected. The PCI card is: ed0: NE2000 PCI Ethernet (RealTek 8029) irq 11 at device 15.0 on pci0 ed0: address 52:54:00:dc:08:ca, type NE2000 (16 bit) the ISA card is MIA. I don't even get a 'ed1 not found at' message. Can anyone point me in the right direction? Or tell me how to make the device probing more verbose? -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a.out lib placment (was: 3.2-RELEASE and netscape problem.)
David O'Brien wrote:
It breaks because compat22 is installing _everything_ in
/usr/lib/compat/aout. We've reproduced this locally - compat22 is
hosed.
I *knew* this was going to bite us in the ass. I brought it up at E-day
time... and was ignored.
I hear what you say - I just don't agree
Some body please decide where bits should live. *IF* you upgrade from
2.2.x to 3.x, your /usr/lib a.out libs are moved to /usr/lib/aout, *AND*
your /usr/lib/compat a.out libs are moved to /usr/lib/compat/aout. Fine.
NOW if you look at the compat2{0,1} bits we shipped with 3.2, they
install into /usr/lib/compat/. Thus we have no consistancy. So compat22
is no more broken than ``make aout-to-elf''.
In an elf world, /usr/lib and /usr/lib/compat are for things in elf format.
/usr/lib/aout and /usr/lib/compat/aout are legacy directories for things in
aout format. I think you are abusing compat22 by adding the aout (legacy)
stuff. Why not just build a legacy library bundle and install it where it
belongs.
--
John Birrell - j...@cimlogic.com.au; j...@freebsd.org
http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a.out lib placment (was: 3.2-RELEASE and netscape problem.)
NOW if you look at the compat2{0,1} bits we shipped with 3.2, they
install into /usr/lib/compat/. Thus we have no consistancy. So compat22
is no more broken than ``make aout-to-elf''.
I think you are abusing compat22 by adding the aout (legacy) stuff.
Why not just build a legacy library bundle and install it where it
belongs.
Huh? I don't follow you here.
What non-a.out stuff should be in compat22? The everything in the
compat22 I made is a.out.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a.out lib placment (was: 3.2-RELEASE and netscape problem.)
David O'Brien wrote:
NOW if you look at the compat2{0,1} bits we shipped with 3.2, they
install into /usr/lib/compat/. Thus we have no consistancy. So compat22
is no more broken than ``make aout-to-elf''.
I think you are abusing compat22 by adding the aout (legacy) stuff.
Why not just build a legacy library bundle and install it where it
belongs.
Huh? I don't follow you here.
What non-a.out stuff should be in compat22? The everything in the
compat22 I made is a.out.
So you are just installing it in the wrong place then.
[ I haven't installed 3.2, so I haven't seen the problem. I'm responding
to things people have _said_. ]
--
John Birrell - j...@cimlogic.com.au; j...@freebsd.org
http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
Hi, On Tue, May 18, 1999 at 12:17:48PM -0500, Dan Nelson wrote: Problem is that idprio isn't safe. I used to idprio the rc5client, but within a day or do the machine would lock up. oops. That's new for me. I'm running the 'rc5client' on various machines (2.2.6-stable, 2.2.8-stable, 3.1-stable, 3.2-stable, 4.0-current) at the lowest idle priority. I had definately no problems so far. Rc5client would get a lock on the root of the filesystem at idprio, and if there was another process running at 100% CPU, rc5client would never get a chance to ^^ at least 3 of the machines are on 'heavy cpu-duty' and are very used to run 100% cpu processes. (e.g. batch graphic filtering, 3D-rendering, etc.) See PR kern/5641. I'll have a look ... -Andreas -- : Anti-Spam Petition: http://www.politik-digital.de/spam/: : PGP-Key:http://www.tse-online.de/~ab/public-key: : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/astro/setiathome Makefile ports/astro/setiathome/files setiathome.sh setiathome.1 ports/astro/setiathome/pkg INSTALL
[ crossposted to -ports, please follow up to -hackers ] s...@freebsd.org wrote: - Added support for SMP systems to etc/rc.d/setiathome.sh - Added etc/setiathome.conf with options to set the nice level, the max. number of processes to run, the working directory, and the the user id to run as. - setiathome.1 was missing from Makefile (and +CONTENTS subsequently) - Updated the man page to reflect the changes. I've left out idprio(8) for now. If someone could point me to a man page explaining the use of kern.quantum, and when it might be useful to fiddle with that knob, I'll happily add that reference to the setiathome man page. Stefan -- Stefan Bethke Muehlendamm 12Phone: +49-40-256848, +49-177-3504009 D-22087 Hamburg stefan.bet...@hanse.de Hamburg, Germany s...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No sound (Ensoniq Audio PCI 1370)
On 18-May-99 Shin-ichi YOSHIMOTO wrote: Hmm.. I have access to an SB Ensoniq Audio PCI which has the ES1371 on it. I also tried an Ensoniq Audio PCI with the ES1371 at first. But this card did not work. Then I tried a CREATIVE SB PCI128 which has the CREATIVE 5507 on it. It was working fine on ES1370 drivers. My machine is running 3.2-stable and I only add the following line to my kernel configuration file: device pcm0 at isa ? port? tty irq 7 drq 1 Shouldn't it just be 'device pcm0'? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ed0/probe solved (Was: re: ed0/probe problem in 4.0-CURRENT)
*sigh* No suprise here. As 90% of these things are this was yet another Dumb User Error. I had a base address conflict that kept the card from being probed. Thanks for everyone's help. As always FreeBSD is working just great! -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/astro/setiathome Makefile ports/astro/setiathome/files setiathome.sh setiathome.1 ports/astro/setiathome/pkg INSTALL
On Wed, 19 May 1999, Stefan Bethke wrote: I've left out idprio(8) for now. If someone could point me to a man page explaining the use of kern.quantum, and when it might be useful to fiddle with that knob, I'll happily add that reference to the setiathome man page. In 3.2 kern.quantum is set to be teh frequency of how often the kernel re-evaluates the scheduling. Defualt is 10 (10 times per second). changing it to 50 (sysctl -w kern.quantum=50) would make it re-evaluate this more often. in -current and post 3.2 (as of a few minutes ago) it is measured as uSeconds thus the default is 10 and the equivalent new value would be 2. (sysctl -w kern.quantum=2) There were various reasons for the change and hopefully few people had used the (new) kern.quantum feature so the changeover will hopefully impact few people. julian Stefan -- Stefan Bethke Muehlendamm 12Phone: +49-40-256848, +49-177-3504009 D-22087 Hamburg stefan.bet...@hanse.de Hamburg, Germany s...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Any interest in GPS NTP servers ?
Trimble is selling a gps kit that can be used to create a Stratum 1 GPS referenced NTP server. Qty 1 cost is $995 Qty 10 cost is $525 Are there 9 other people interested out there ? I'd like to try put together a group purchase. Joe Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-969-2203 Cell: 650-207-0372 Fax: 650-969-2124 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
