Re: PXE build?
On Nov 14, Jeff Roberson wrote: > Does anyone know of any current issues with PXE? I've searched the mailing > lists and I don't see any mention of a problem similar to mine. > > I'm running FreeBSD-CURRENT from 2000 09 15 on a server. The client has an > Intel 21143 based ethernet card that claims it has PXE 2.0 (Build 74) > support. I've setup bootp/tftp on the server which the client successfully > uses to pull down the 'pxeboot' file. After the client retrieves pxeboot it > just hangs. There is no further output from the machine. > > Does anyone know which particular build of PXE 2.0 works with pxeboot? Or > is this even a problem with my firmware? Hello Jeff, You didn't specify if you set-up NFS for the loader to fetch it's configuration and the kernel and such. Assuming you have an otherwise working PXE environment: I've had problems with Intel card at work. I'm at home now and don't remember off-hand what specific model of card or the flash version. Depending on what motherboard was used, I would see crashes and hangs in the loader when configured for tftp (with some), nfs (with others). However, recently someone on -questions referenced a flash upgrade available and I found it on the Intel web site. It fixed all my problems. --Mat > > Thanks, > Jeff -- Mathew Kanner <[EMAIL PROTECTED]> SOCS McGill University Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Typo in secure/lib/libcrypto/Makefile
=== RCS file: /home/ncvs/src/secure/lib/libcrypto/Makefile,v retrieving revision 1.26 retrieving revision 1.27 diff -u -p -r1.26 -r1.27 --- src/secure/lib/libcrypto/Makefile 2000/11/13 02:21:37 1.26 +++ src/secure/lib/libcrypto/Makefile 2000/11/14 22:12:02 1.27 @@ -1,4 +1,4 @@ -# $FreeBSD: src/secure/lib/libcrypto/Makefile,v 1.26 2000/11/13 +.# $FreeBSD: src/secure/lib/libcrypto/Makefile,v 1.27 2000/11/14 22:12 ^ A period before the comment somehow crept into the commit. -- Mike Heffner <[EMAIL PROTECTED]> Blacksburg, VA ICQ# 882073 http://my.ispchannel.com/~mheffner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Foundation: Examples of FreeBSD as teaching aid/research plat
eirvine wrote: > > Hi Justin, > > You might like to take a look at some of the links > near the bottom of my (humble) home page. A little > dated, but never mind: > > http://www1.tpg.com.au/users/eirvine/ > > Eddie. > A collection of such 'good works' might not be out of place somewhere on the website once it's been collected. > > "Justin T. Gibbs" wrote: > > > > As some of you may know, I'm working on a 501(c)3 (tax exempt/non-profit) > > determination for the FreeBSD Foundation. The IRS seems to be a little > > confused about the nature of FreeBSD and we're currenlty working on > > a response to an initial determination from the IRS that was not > > favorable. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current has hosed the i8254 timecounter...
>I'm seeing something similar with -current on this laptop here. Magically, >if I jiggle the mouse whilst playing an mp3, things start to skip and the >clock goes *way* off way (sometimes by a few seconds in a few seconds. :) I've had this for a few weeks now (the skipage). It has been explained as IRQ latency due to SMPNG code. Can someone make a guestimate on when this will be fixed? Also I was dd'ing the install floppies today, and when I was in X with xmms playing I got about 300-600 bytes/s transfer rate to fd0. After a reboot and being on the commandline I got 27K/s. Except when I moved my mouse, then the transfer top floppy would slow down straight away. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current has hosed the i8254 timecounter...
On 14-Nov-00 Adrian Chadd wrote: > On Mon, Nov 13, 2000, Poul-Henning Kamp wrote: >> >> It seems that something recently toasted the quasi-magic i8254 timecounter >> code to the point of unusability. >> >> On my laptop I run a ntpdate every minute, and the result looks like this: >> > > I'm seeing something similar with -current on this laptop here. Magically, > if I jiggle the mouse whilst playing an mp3, things start to skip and the > clock goes *way* off way (sometimes by a few seconds in a few seconds. :) That is probably due to the random harvesting thread. Or rather, that the overhead of ithreads together with the random kthread and the load of playing mp3's is starving your CPU. Do you have any idle time at all when this happens? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ISA PnP resource allocation
Warner Losh schrieb:
>
> In message <[EMAIL PROTECTED]> Daniel Rock writes:
> : I already filed a PR for this problem but my first solution was a real
> : hack (kern/21461).
> :
> : [another solution would be to introduce another flag for
> : rman_reserve_resource() not to search for alternate regions.
>
> Would the alignment stuff I added for cardbus help any?
I think, my patch basically uses now the same alignment options from
the resource manager like cardbus does now.
I have cleaned up the code a little bit: Now the code uses the
rman_get_XXX() macros and also checks if the region returned is below the
end mark.
Daniel
Index: sys/isa/isa_common.c
===
RCS file: /data/cvs/src/sys/isa/isa_common.c,v
retrieving revision 1.18
diff -u -r1.18 isa_common.c
--- sys/isa/isa_common.c2000/07/12 00:42:08 1.18
+++ sys/isa/isa_common.c2000/11/14 21:27:34
@@ -133,31 +133,30 @@
result->ic_nmem = config->ic_nmem;
for (i = 0; i < config->ic_nmem; i++) {
u_int32_t start, end, size, align;
- for (start = config->ic_mem[i].ir_start,
-end = config->ic_mem[i].ir_end,
-size = config->ic_mem[i].ir_size,
-align = config->ic_mem[i].ir_align;
-start + size - 1 <= end;
-start += align) {
- bus_set_resource(child, SYS_RES_MEMORY, i,
-start, size);
- res[i] = bus_alloc_resource(child,
- SYS_RES_MEMORY, &i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
- if (res[i]) {
- result->ic_mem[i].ir_start = start;
- result->ic_mem[i].ir_end = start + size - 1;
- result->ic_mem[i].ir_size = size;
- result->ic_mem[i].ir_align = align;
+
+ start = config->ic_mem[i].ir_start;
+ end = config->ic_mem[i].ir_end;
+ size = config->ic_mem[i].ir_size;
+ align = config->ic_mem[i].ir_align;
+ if(!align)
+ align = 1;
+ bus_set_resource(child, SYS_RES_MEMORY, i,
+start, size);
+ res[i] = bus_alloc_resource(child,
+ SYS_RES_MEMORY, &i,
+ 0, ~0, 1,
+ rman_make_alignment_flags(align));
+ if (res[i]) {
+ if(rman_get_start(res[i]) > end) {
+ success = 0;
break;
}
+ result->ic_mem[i].ir_start = rman_get_start(res[i]);
+ result->ic_mem[i].ir_end = rman_get_end(res[i]);
+ result->ic_mem[i].ir_size = rman_get_size(res[i]);
+ result->ic_mem[i].ir_align = align;
}
-
- /*
-* If we didn't find a place for memory range i, then
-* give up now.
-*/
- if (!res[i]) {
+ else {
success = 0;
break;
}
@@ -197,31 +196,31 @@
result->ic_nport = config->ic_nport;
for (i = 0; i < config->ic_nport; i++) {
u_int32_t start, end, size, align;
- for (start = config->ic_port[i].ir_start,
-end = config->ic_port[i].ir_end,
-size = config->ic_port[i].ir_size,
-align = config->ic_port[i].ir_align;
-start + size - 1 <= end;
-start += align) {
- bus_set_resource(child, SYS_RES_IOPORT, i,
-start, size);
- res[i] = bus_alloc_resource(child,
- SYS_RES_IOPORT, &i,
- 0, ~0, 1, 0 /* !RF_ACTIVE */);
- if (res[i]) {
- result->ic_port[i].ir_start = start;
- result->ic_port[i].ir_end = start + size - 1;
- result->ic_port[i].ir_size = size;
- result->ic_port[i].ir_align = align;
+
+ start = config->ic_port[i].ir_start;
+ end = config->ic_port[i].ir_end;
+ size = config->ic_port[i].ir_size;
+ align = config->ic_port[i].ir_align;
+ if(!align)
+ align = 1;
+
+ bus_set_resource(child, SYS_RES_IOPORT, i,
+
Re: Current has hosed the i8254 timecounter...
On Mon, Nov 13, 2000, Poul-Henning Kamp wrote: > > It seems that something recently toasted the quasi-magic i8254 timecounter > code to the point of unusability. > > On my laptop I run a ntpdate every minute, and the result looks like this: > I'm seeing something similar with -current on this laptop here. Magically, if I jiggle the mouse whilst playing an mp3, things start to skip and the clock goes *way* off way (sometimes by a few seconds in a few seconds. :) Adrian -- Adrian Chadd"Programming is like sex: <[EMAIL PROTECTED]> One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Build errors in latest -current
OK. Maybe I'm just being stupid... But I've had a buildworld fail twice now in build secure/libcrypto with a syntax error. Is this known, or do I need a better bug report than this vauge message? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new zero copy sockets and NFS snapshot
[ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early November 14th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - The "localhost panic" problem has hopefully been fixed. The fix was to avoid page-flipping pages with a wire count greater than 0. I believe this is the right fix, but I would welcome feedback from someone more familiar with the VM system. - The new external mbuf code has been integrated. As of this release, there are no known problems with the code. If anyone wants to challenge that, I'll gladly accept bug reports, code comments, etc. :) For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Zero copy send and receive code, written by Drew Gallatin <[EMAIL PROTECTED]>. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which kindly agreed to let me release the code. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RQ review: [was: Re: "make modules" kicks the first module directory twice]
David O'Brien wrote:
>
> > > modules-depend:
> > > @mkdir -p ${.OBJDIR}/modules
> > > ! cd $S/modules; env ${MKMODULESENV} ${MAKE} obj
> > > ! env ${MKMODULESENV} ${MAKE} depend
>
> This is broken for non -j case.
Yes, this was known. The right diff was given at the beginning of the
message including the comment that the original patch had this breakage
:-)
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408) 447-4222
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "make modules" kicks the first module directory twice
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : [stable dropped, this should have only been in a single list to start with!!] Agreed. My summary: o We disagree about the support impact o Peter's stuff may OBE this whole thread o My change shouldn't be committed until we know it will have no support impact, or it can be fixed to be more robust. : On Tue, Nov 14, 2000 at 01:27:32PM -0700, Warner Losh wrote: : > : I'd rather take a major compile time hit and be deterministic than not. : > : > I'd rather not. We don't do an implicit make obj in the rest of the : > tree. : : It is in `make world' if /usr/obj exists. Otherwise how does all the : .o's get in /usr/obj/ ? I should have stated this more clearly. We don't have an implicit make obj anywhere else in the tree for the default "all" target. We do have it for other, special targets. : > If I go build the world, and then someone adds a new program to : > the tree, you are in the same boat. : : Nope, `make world' will DTRT. No. Not if you compile that one file. Also, make all won't do the right thing. That's my point. We have extra special targets that are all singing all dancing that do the right thing, but the plain vanilla ones act in a plain vanilla way. Again, make world isn't the default target. It is an extra special target that does special things. I've been burned by the example that I sighted. : > If you cd to that program and type make it will wind up in . rather : > than /usr/obj. : : Yes, and how many times do we have to tell people to run : ``make cleandir && make cleandir'' or : ``rm -rf /usr/obj/* ; cd /usr/src ; make cleandir '' A few, but a lot less than I'd expect :-). : > Completely deterministic, the same thing will happen every time you do : > the scenario. : : Ok, completely deterministic given enough detail -- detail which 99% of : the time will not be provided in email to the lists saying this and that : is broken. True. But it would be rare enough that people would have two different kernels, with different revs of the sources in the same source tree and that those differences would cause problems. It would sure be hard to find it, I'll grant that. I think it would be rare enough that we won't get mail on it, but I could be wrong about that. : > But before making major changes to this, let's see Peter Wemm's new : > all singing all dancing config work does for us. I'd rather see what : > he's come up with than argue further on this. : : Earlier today, I too I was wondering if his plan makes all this OBE. He sure has been silent on all of this. :-) I do think that we're all in agreement that make obj all should be changed to make obj\n make all to make the parallel case work. The rest shouldn't be committed until we have it more robust. I'll take alook to see if there's a robust way to know if we need to run make obj or not. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PXE build?
Title: PXE build? Does anyone know of any current issues with PXE? I've searched the mailing lists and I don't see any mention of a problem similar to mine. I'm running FreeBSD-CURRENT from 2000 09 15 on a server. The client has an Intel 21143 based ethernet card that claims it has PXE 2.0 (Build 74) support. I've setup bootp/tftp on the server which the client successfully uses to pull down the 'pxeboot' file. After the client retrieves pxeboot it just hangs. There is no further output from the machine. Does anyone know which particular build of PXE 2.0 works with pxeboot? Or is this even a problem with my firmware? Thanks, Jeff
Re[2]: if_tap and linprocfs modules are broken in -current
Hello Harti, Tuesday, November 14, 2000, 3:55:01 PM, you wrote: >> when i try to kldload if_tap module, the kernel says "symbol lminor >> undefined" and fails to load the module. for linprocfs module the >> message is "symbol tsleep undefined". these modules are necessary for >> VMWare 2.0 port. >> >> >How-To-Repeat: >> >> kldload if_tap >> kldstat linprocfs HB> No problems here with source from today 6.00 MET. if_tap was HB> fixed on 09/19. it's ok, i'm expiriencing them right now, with today's kernel/modules (built on 13:07 MSK). HB> NB: there is a commit request pending for if_tap. It is currently unusable HB> with devfs. Would be REALLY nice if a committer could look at the patch. i do not use devfs. anyway, the patch by Maksim Yevmenkin doesn't help. kernel still reports "link_elf: symbol lminor undefined". and what's wrong with linprocfs? it seems to be broken too. -- Best regards, Ilyamailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "make modules" kicks the first module directory twice
[stable dropped, this should have only been in a single list to start with!!] On Tue, Nov 14, 2000 at 01:27:32PM -0700, Warner Losh wrote: > : I'd rather take a major compile time hit and be deterministic than not. > > I'd rather not. We don't do an implicit make obj in the rest of the > tree. It is in `make world' if /usr/obj exists. Otherwise how does all the .o's get in /usr/obj/ ? > If I go build the world, and then someone adds a new program to > the tree, you are in the same boat. Nope, `make world' will DTRT. > If you cd to that program and type make it will wind up in . rather > than /usr/obj. Yes, and how many times do we have to tell people to run ``make cleandir && make cleandir'' or ``rm -rf /usr/obj/* ; cd /usr/src ; make cleandir '' > Completely deterministic, the same thing will happen every time you do > the scenario. Ok, completely deterministic given enough detail -- detail which 99% of the time will not be provided in email to the lists saying this and that is broken. > But before making major changes to this, let's see Peter Wemm's new > all singing all dancing config work does for us. I'd rather see what > he's come up with than argue further on this. Earlier today, I too I was wondering if his plan makes all this OBE. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "make modules" kicks the first module directory twice
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : On Mon, Nov 13, 2000 at 09:17:54PM -0700, Warner Losh wrote: : > The implications are that make obj isn't done unless you've run make : > depend first. If a new directory is added and a make depend isn't : > run, then the modules won't get built into the obj tree, but instead : > will be built into $S/modules. : : Having modules wind up in two trees is not acceptable IMHO. But they are both in the $S tree. :-) : I'd rather take a major compile time hit and be deterministic than not. I'd rather not. We don't do an implicit make obj in the rest of the tree. If I go build the world, and then someone adds a new program to the tree, you are in the same boat. If you cd to that program and type make it will wind up in . rather than /usr/obj. Completely deterministic, the same thing will happen every time you do the scenario. make depend is already *REQUIRED* when you are updating a kernel from an older version of the kernel. For config -r FOO kernels it isn't. Even a make clean after a make depend will require that make depend be run again. But before making major changes to this, let's see Peter Wemm's new all singing all dancing config work does for us. I'd rather see what he's come up with than argue further on this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RQ review: [was: Re: "make modules" kicks the first module directory twice]
On Mon, Nov 13, 2000 at 08:02:47PM -0800, Marcel Moolenaar wrote:
> Any objections?
Yes.
> (patches follow for your convenience)
[its easier to read patches when they aren't quoted in their entirety ;-)]
> > modules-depend:
> > @mkdir -p ${.OBJDIR}/modules
> > ! cd $S/modules; env ${MKMODULESENV} ${MAKE} obj
> > ! env ${MKMODULESENV} ${MAKE} depend
This is broken for non -j case.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "make modules" kicks the first module directory twice
On Mon, Nov 13, 2000 at 09:17:54PM -0700, Warner Losh wrote: > The implications are that make obj isn't done unless you've run make > depend first. If a new directory is added and a make depend isn't > run, then the modules won't get built into the obj tree, but instead > will be built into $S/modules. Having modules wind up in two trees is not acceptable IMHO. I'd rather take a major compile time hit and be deterministic than not. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getty bug when run by hand
- Bruce Evans's Original Message -
> On Mon, 13 Nov 2000, John W. De Boskey wrote:
>
> >When the following command is run as root:
> >
> > /usr/obj/usr/src/libexec/getty/getty std.38400 ttyd1
> >
> >the call to login_tty() fails in the opentty() function:
> >
> > else {
> > login_tty(i);
> > return 1;
> > }
> >
> >However, the return code is not checked. File descripters 0,
> > 1, and 2 are not modified to point at ttyd1, and the getty then
> > proceeds to run on the current terminal session.
> >
> >At a minimum, I'd like to commit the following patch. It would
> > have helped avoid some frustrating moments...
> >
> > ===
> > RCS file: /home/ncvs/src/libexec/getty/main.c,v
> > retrieving revision 1.31
> > diff -u -r1.31 main.c
> > --- main.c 2000/10/10 01:53:00 1.31
> > +++ main.c 2000/11/14 02:25:31
> > @@ -444,7 +444,10 @@
> > return 0;
> > }
> > else {
> > - login_tty(i);
> > + if (login_tty(i) < 0) {
> > + syslog(LOG_ERR, "login_tty %s: %m", ttyn);
> > + return 0;
> > + }
> > return 1;
> > }
> > }
>
> This needs a "close(i);" for the error case.
>
> >This of course then leads to the question of why the
> > TIOCSCTTY ioctl call failes. From the above change:
> >
> > Nov 13 17:25:47 mail getty[1236]: login_tty /dev/ttyd1: Operation not
> > permitted
>
> This is because the process isn't a session leader. It isn't a session
> leader because the setsid() call before the ioctl failed (and it wasn't
> a session leader before that). The result of the setsid() is ignored,
> which is correct if setsid() failed due to the process already being a
> session leader, but obfuscates the error otherwise. setsid() fails
> because the process is a process group leader. This is the normal
> environment for processes started from shells. Session, process group
> and controlling terminal stuff is all set up for normal job control, and
> is difficult of impossible to change except in a new process.
>
> getty works when it is started from init because init doesn't do much
> setup for getty. It only sets up a controlling terminal for running
> /etc/rc and for single user mode...
>
> Bruce
I re-written the patch to fix the error case, and to allow getty
to be run from a command line and DTRT. I have this running on
my system right now (from /etc/ttys, and from a console). I'd like
to commit this unless anyone sees any fatal mistakes I've made.
Thanks,
-John
freefall:/d/home/jwd/src/src/libexec/getty/main.c
cvs diff: Diffing .
Index: main.c
===
RCS file: /home/ncvs/src/libexec/getty/main.c,v
retrieving revision 1.31
diff -u -r1.31 main.c
--- main.c 2000/10/10 01:53:00 1.31
+++ main.c 2000/11/14 19:26:17
@@ -444,7 +444,18 @@
return 0;
}
else {
- login_tty(i);
+ if (login_tty(i) < 0) {
+ if (daemon(0,0) < 0) {
+ syslog(LOG_ERR,"daemon: %m");
+ close(i);
+ return 0;
+ }
+ if (login_tty(i) < 0) {
+ syslog(LOG_ERR, "login_tty %s: %m", ttyn);
+ close(i);
+ return 0;
+ }
+ }
return 1;
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: OpenH323 Core Dumps and gdb reports ptrace(PT_GETDBREGS)
On Tue, 14 Nov 2000, Roger Hardiman wrote: > Hi > > Since cvsup'ing -current box, I've got a port which > core dumps immediatly. > > When I tried to run a debug version of the program under > GDB I just got this > > > ptrace(PT_GETDBREGS) failed: Operation not permitted > ptrace(PT_GETDBREGS) failed: Operation not permitted > Cannot insert breakpoint -1: > Error accessing memory address 0x28260ea8: Bad address. > > > The port is net/OpenH323 and the program is asnparser. > (an internal program built by one part of the port and used > in another part of the port) I was suppose to look at this problem and I forgot to get back to you about it. I wasn't able to reproduce this under a -current built over the weekend (fresh kernel also). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenH323 Core Dumps and gdb reports ptrace(PT_GETDBREGS)
Hi Since cvsup'ing -current box, I've got a port which core dumps immediatly. When I tried to run a debug version of the program under GDB I just got this ptrace(PT_GETDBREGS) failed: Operation not permitted ptrace(PT_GETDBREGS) failed: Operation not permitted Cannot insert breakpoint -1: Error accessing memory address 0x28260ea8: Bad address. The port is net/OpenH323 and the program is asnparser. (an internal program built by one part of the port and used in another part of the port) I noticed bento (the ports builder) core dumps on asnparser too now, so the problem is not just on my machine. The code runs fine on 4.2-RC and 3.x boxes. Can someone help work out what is going on. Cheers Roger -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
Should be fixed. > Savecore isn't working in -current, dying in my case with "read: > invalid argument". (This is on an Alpha -- I don't have an i386 > -current machine to test it on at the moment.) I traced it down to > the fact that getbootfile() is returning "kernel" -- not the full > pathname as the man page promises. This seems to be because the > "kern.bootfile" sysctl variable isn't getting set correctly: > > alpha# sysctl kern.bootfile > kern.bootfile: kernel > > Because I had an old "/kernel" file and savecore runs in "/", it was > finding the wrong kernel. > > This seems to be some sort of coordination problem between the loader > and the kernel and, maybe, the Alpha SRM. Can anybody shed some light > on it? > > Also, in "src/sys/boot/common/boot.c" we still have this: > > static const char *default_bootfiles = "kernel.ko"; > > which isn't right any more. > > John > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_tap and linprocfs modules are brokern in -current
On Tue, 14 Nov 2000 [EMAIL PROTECTED] wrote: > > when i try to kldload if_tap module, the kernel says "symbol lminor > undefined" and fails to load the module. for linprocfs module the > message is "symbol tsleep undefined". these modules are necessary for > VMWare 2.0 port. > > >How-To-Repeat: > > kldload if_tap > kldstat linprocfs No problems here with source from today 6.00 MET. if_tap was fixed on 09/19. NB: there is a commit request pending for if_tap. It is currently unusable with devfs. Would be REALLY nice if a committer could look at the patch. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Soundcard AC'97
Hi! Does current support this soundcard? AC´97 Driver, Intel 82801AA controller I'am not in this list, so please replay to [EMAIL PROTECTED] Best regards Johan -- Spray Network Services Stockholm | Sweden Cell: +46(0)708 402 836 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: getty bug when run by hand
On Mon, 13 Nov 2000, John W. De Boskey wrote:
>When the following command is run as root:
>
> /usr/obj/usr/src/libexec/getty/getty std.38400 ttyd1
>
>the call to login_tty() fails in the opentty() function:
>
> else {
> login_tty(i);
> return 1;
> }
>
>However, the return code is not checked. File descripters 0,
> 1, and 2 are not modified to point at ttyd1, and the getty then
> proceeds to run on the current terminal session.
>
>At a minimum, I'd like to commit the following patch. It would
> have helped avoid some frustrating moments...
>
> ===
> RCS file: /home/ncvs/src/libexec/getty/main.c,v
> retrieving revision 1.31
> diff -u -r1.31 main.c
> --- main.c 2000/10/10 01:53:00 1.31
> +++ main.c 2000/11/14 02:25:31
> @@ -444,7 +444,10 @@
> return 0;
> }
> else {
> - login_tty(i);
> + if (login_tty(i) < 0) {
> + syslog(LOG_ERR, "login_tty %s: %m", ttyn);
> + return 0;
> + }
> return 1;
> }
> }
This needs a "close(i);" for the error case.
>This of course then leads to the question of why the
> TIOCSCTTY ioctl call failes. From the above change:
>
> Nov 13 17:25:47 mail getty[1236]: login_tty /dev/ttyd1: Operation not
> permitted
This is because the process isn't a session leader. It isn't a session
leader because the setsid() call before the ioctl failed (and it wasn't
a session leader before that). The result of the setsid() is ignored,
which is correct if setsid() failed due to the process already being a
session leader, but obfuscates the error otherwise. setsid() fails
because the process is a process group leader. This is the normal
environment for processes started from shells. Session, process group
and controlling terminal stuff is all set up for normal job control, and
is difficult of impossible to change except in a new process.
getty works when it is started from init because init doesn't do much
setup for getty. It only sets up a controlling terminal for running
/etc/rc and for single user mode...
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
if_tap and linprocfs modules are brokern in -current
>Category: kern >Submitter-Id: current-users >Originator:Ilya Naumov >Organization: NIIAVIA >Confidential: no >Synopsis: if_tap and linprocfs modules are brokern in -current >Severity: non-critical >Priority: medium >Class: sw-bug >Release: FreeBSD 5.0-CURRENT i386 >Environment: System: FreeBSD camel.avias.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Nov 14 13:07:22 MSK 2000 [EMAIL PROTECTED]:/garbage/obj/garbage/src/sys/CAMEL i386 >Description: when i try to kldload if_tap module, the kernel says "symbol lminor undefined" and fails to load the module. for linprocfs module the message is "symbol tsleep undefined". these modules are necessary for VMWare 2.0 port. >How-To-Repeat: kldload if_tap kldstat linprocfs To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
