Re: make kernel failure: pecoff: machine/lock.h
On Wed, 28 Feb 2001, John Baldwin wrote: > On 28-Feb-01 Bruce Evans wrote: > > Most of the pcb actually has the same persistence as the kernel stack > > (both mainly store the process's context while the process is in the > > kernel). But it is silly to put the pcb below the stack instead of > > above it. Perhaps the idea is to get a panic sooner when something > > is corrupted. > > That is the idea. Not all of the pcb is just used while in the kernel. The > pcb_ext that points to a TSS on the i386 for example. The problem I think > people are having with the ltr panic is that the stack gets deep enough to > overwrite that field of the pcb, and we die later on when we try to access an > invalid pointer there. Perhaps pcb_ext, pcb_ldt, and other things that are > persistent across kernel entry/exit should be stored in p_md instead of p_addr. I think that at least the pointers belong in p_md. I had some panics that looked a bit like the ltr one. These turned out to be caused by priority inversion (related to the native priority bugs) preventing an ithread from running. The ithread held a pointer to a process and the process exited before the pointer was used. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
In message <[EMAIL PROTECTED]> Edwin Culp writes: : I had that, and many other problems, about a week ago and I am not : sure but i think that I ended up doing an rm -rf /usr/sys/modules/* : , cvsuped made world and built new kernel with no problem. I : remember that I had to erase all the modules directory but I'm not : comeletely sure that it was this problem. Sorry, it's old age. Likely it is stale .depend files in the src/sys/modules hierarchy. That's why killing it worked. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : On Tue, Feb 27, 2001 at 11:28:37AM -0800, John Baldwin wrote: : > Have you tried running make depend? : : I've got the same problem about a bogus dependancy on machine/lock.h. : And yes, this is after a `make depend' on a /sys I *just* CVSup'ed. :-( find /sys -name .depend | xargs egrep machine/lock.h was how I found the problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
In message <[EMAIL PROTECTED]> Leif Neland writes: : ===> pecoff : make: don't know how to make machine/lock.h. Stop If you are making from pure, clean sources, like I think you said you were, you may need to rm src/sys/modules/pecoff/.depend. I had a few of these kicking around and it caused me problems, even on a clean build :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
On 28-Feb-01 Bruce Evans wrote: > On Tue, 27 Feb 2001, John Baldwin wrote: > >> Ok. It may be that we are overflowing the kernel stack and corrupting the >> pcb >> in the process. One idea atm is to move the pcb off of the stack (since it >> stores persistent data it's a bad place for it anyways) and to add a red >> zone >> at the bottom of the stack to catch overflows. > > Most of the pcb actually has the same persistence as the kernel stack > (both mainly store the process's context while the process is in the > kernel). But it is silly to put the pcb below the stack instead of > above it. Perhaps the idea is to get a panic sooner when something > is corrupted. That is the idea. Not all of the pcb is just used while in the kernel. The pcb_ext that points to a TSS on the i386 for example. The problem I think people are having with the ltr panic is that the stack gets deep enough to overwrite that field of the pcb, and we die later on when we try to access an invalid pointer there. Perhaps pcb_ext, pcb_ldt, and other things that are persistent across kernel entry/exit should be stored in p_md instead of p_addr. However, I would like the machine to panic when it overflows the stack rather than trash the pcb, yes. > Bruce -- 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: make kernel failure: pecoff: machine/lock.h
Bruce Evans wrote: > > On Tue, 27 Feb 2001, Julian Elischer wrote: > > > Bruce Evans wrote: > > > Most of the pcb actually has the same persistence as the kernel stack > > > (both mainly store the process's context while the process is in the > > > kernel). But it is silly to put the pcb below the stack instead of > > > above it. Perhaps the idea is to get a panic sooner when something > > > is corrupted. > > > > I have never understood why the context is not ON the stack. > > At least on i386's, it is because the context is not all saved in LIFO > order. The pcb gets the non-LIFO stuff. E.g., the FP state is saved > lazily, not pushed on every entry to the kernel. We could push the pcb onto the stack as easily as have it somewhere else. It's not compulsory to access stack memeory in sequential order. > > Bruce > > 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-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
On Tue, 27 Feb 2001, Julian Elischer wrote: > Bruce Evans wrote: > > Most of the pcb actually has the same persistence as the kernel stack > > (both mainly store the process's context while the process is in the > > kernel). But it is silly to put the pcb below the stack instead of > > above it. Perhaps the idea is to get a panic sooner when something > > is corrupted. > > I have never understood why the context is not ON the stack. At least on i386's, it is because the context is not all saved in LIFO order. The pcb gets the non-LIFO stuff. E.g., the FP state is saved lazily, not pushed on every entry to the kernel. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
Bruce Evans wrote: > > On Tue, 27 Feb 2001, John Baldwin wrote: > > > Ok. It may be that we are overflowing the kernel stack and corrupting the pcb > > in the process. One idea atm is to move the pcb off of the stack (since it > > stores persistent data it's a bad place for it anyways) and to add a red zone > > at the bottom of the stack to catch overflows. > > Most of the pcb actually has the same persistence as the kernel stack > (both mainly store the process's context while the process is in the > kernel). But it is silly to put the pcb below the stack instead of > above it. Perhaps the idea is to get a panic sooner when something > is corrupted. I have never understood why the context is not ON the stack. > > Bruce > > 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-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
On Tue, 27 Feb 2001, John Baldwin wrote: > Ok. It may be that we are overflowing the kernel stack and corrupting the pcb > in the process. One idea atm is to move the pcb off of the stack (since it > stores persistent data it's a bad place for it anyways) and to add a red zone > at the bottom of the stack to catch overflows. Most of the pcb actually has the same persistence as the kernel stack (both mainly store the process's context while the process is in the kernel). But it is silly to put the pcb below the stack instead of above it. Perhaps the idea is to get a panic sooner when something is corrupted. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
On Tue, Feb 27, 2001 at 11:28:37AM -0800, John Baldwin wrote: > Have you tried running make depend? I've got the same problem about a bogus dependancy on machine/lock.h. And yes, this is after a `make depend' on a /sys I *just* CVSup'ed. :-( -- -- 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 kernel failure: pecoff: machine/lock.h
I had that, and many other problems, about a week ago and I am not sure but i think that I ended up doing an rm -rf /usr/sys/modules/* , cvsuped made world and built new kernel with no problem. I remember that I had to erase all the modules directory but I'm not comeletely sure that it was this problem. Sorry, it's old age. ed Quoting Leif Neland <[EMAIL PROTECTED]>: > > > On Tue, 27 Feb 2001, Gary Jennejohn wrote: > > > John Baldwin writes: > > > > > > On 27-Feb-01 Leif Neland wrote: > > > > This happens with both my custom and GENERIC kernel. > > > > > > > > It has failed for some days, and also with source cvsup'ed today. > > > > A kernel built with "make buildkernel -k" works... > > > > > > > > Leif > > > > > > Have you tried running make depend? > > > > > > > > > Failing that, trying deleting your /sys/compile/ directory > > and re-config'ing your kernel. This has always worked for me. > > > I'm building the kernel "the new way", ie cd /usr/src > make buildkernel KERNCONF= > > So the kernel is build in /usr/obj/usr/src/sys/GENERIC > > I deleted this, which buildkernel does itself, and config'ing it does too, > and as I expected, it didn't make any difference. > > Leif > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- EnContacto.Net - InternetSalon.Org - CafeMania.Net - EnContacto.Net - CafeMania.Net - InternetSalon.Org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
On 27-Feb-01 Leif Neland wrote: > > > On Tue, 27 Feb 2001, John Baldwin wrote: > >> >> On 27-Feb-01 Leif Neland wrote: >> > >> > >> > On Tue, 27 Feb 2001, Gary Jennejohn wrote: >> > >> >> John Baldwin writes: >> >> > >> >> > On 27-Feb-01 Leif Neland wrote: >> >> > > This happens with both my custom and GENERIC kernel. >> >> > > >> >> > > It has failed for some days, and also with source cvsup'ed today. >> >> > > A kernel built with "make buildkernel -k" works... >> >> > > >> >> > > Leif >> >> > >> >> > Have you tried running make depend? >> >> > >> >> >> >> >> >> Failing that, trying deleting your /sys/compile/ directory >> >> and re-config'ing your kernel. This has always worked for me. >> >> >> > I'm building the kernel "the new way", ie cd /usr/src >> > make buildkernel KERNCONF= >> > >> > So the kernel is build in /usr/obj/usr/src/sys/GENERIC >> > >> > I deleted this, which buildkernel does itself, and config'ing it does too, >> > and as I expected, it didn't make any difference. >> > >> > Leif >> >> Ok. It may be that we are overflowing the kernel stack and corrupting the >> pcb >> in the process. One idea atm is to move the pcb off of the stack (since it >> stores persistent data it's a bad place for it anyways) and to add a red >> zone >> at the bottom of the stack to catch overflows. >> > Do you really thinks it is something this complicated? > To me it just sounds like a makefile bug, as going to the pecoff directory > and typing make gives the same error. But what do I know... Oh, crossed wires. I was referring to the 'ltr' panics. Umm, you should only get this error if you have a stale .depend file. Note that config -r doesn't exist anymore, so it actually doesn't get automatically deleted by config or buildkernel. Can you build a kernel the old way? > Leif -- 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: make kernel failure: pecoff: machine/lock.h
On Tue, 27 Feb 2001, John Baldwin wrote: > > On 27-Feb-01 Leif Neland wrote: > > > > > > On Tue, 27 Feb 2001, Gary Jennejohn wrote: > > > >> John Baldwin writes: > >> > > >> > On 27-Feb-01 Leif Neland wrote: > >> > > This happens with both my custom and GENERIC kernel. > >> > > > >> > > It has failed for some days, and also with source cvsup'ed today. > >> > > A kernel built with "make buildkernel -k" works... > >> > > > >> > > Leif > >> > > >> > Have you tried running make depend? > >> > > >> > >> > >> Failing that, trying deleting your /sys/compile/ directory > >> and re-config'ing your kernel. This has always worked for me. > >> > > I'm building the kernel "the new way", ie cd /usr/src > > make buildkernel KERNCONF= > > > > So the kernel is build in /usr/obj/usr/src/sys/GENERIC > > > > I deleted this, which buildkernel does itself, and config'ing it does too, > > and as I expected, it didn't make any difference. > > > > Leif > > Ok. It may be that we are overflowing the kernel stack and corrupting the pcb > in the process. One idea atm is to move the pcb off of the stack (since it > stores persistent data it's a bad place for it anyways) and to add a red zone > at the bottom of the stack to catch overflows. > Do you really thinks it is something this complicated? To me it just sounds like a makefile bug, as going to the pecoff directory and typing make gives the same error. But what do I know... Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
On 27-Feb-01 Leif Neland wrote: > > > On Tue, 27 Feb 2001, Gary Jennejohn wrote: > >> John Baldwin writes: >> > >> > On 27-Feb-01 Leif Neland wrote: >> > > This happens with both my custom and GENERIC kernel. >> > > >> > > It has failed for some days, and also with source cvsup'ed today. >> > > A kernel built with "make buildkernel -k" works... >> > > >> > > Leif >> > >> > Have you tried running make depend? >> > >> >> >> Failing that, trying deleting your /sys/compile/ directory >> and re-config'ing your kernel. This has always worked for me. >> > I'm building the kernel "the new way", ie cd /usr/src > make buildkernel KERNCONF= > > So the kernel is build in /usr/obj/usr/src/sys/GENERIC > > I deleted this, which buildkernel does itself, and config'ing it does too, > and as I expected, it didn't make any difference. > > Leif Ok. It may be that we are overflowing the kernel stack and corrupting the pcb in the process. One idea atm is to move the pcb off of the stack (since it stores persistent data it's a bad place for it anyways) and to add a red zone at the bottom of the stack to catch overflows. -- 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: make kernel failure: pecoff: machine/lock.h
On Tue, 27 Feb 2001, Gary Jennejohn wrote: > John Baldwin writes: > > > > On 27-Feb-01 Leif Neland wrote: > > > This happens with both my custom and GENERIC kernel. > > > > > > It has failed for some days, and also with source cvsup'ed today. > > > A kernel built with "make buildkernel -k" works... > > > > > > Leif > > > > Have you tried running make depend? > > > > > Failing that, trying deleting your /sys/compile/ directory > and re-config'ing your kernel. This has always worked for me. > I'm building the kernel "the new way", ie cd /usr/src make buildkernel KERNCONF= So the kernel is build in /usr/obj/usr/src/sys/GENERIC I deleted this, which buildkernel does itself, and config'ing it does too, and as I expected, it didn't make any difference. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make kernel failure: pecoff: machine/lock.h
John Baldwin writes: > > On 27-Feb-01 Leif Neland wrote: > > This happens with both my custom and GENERIC kernel. > > > > It has failed for some days, and also with source cvsup'ed today. > > A kernel built with "make buildkernel -k" works... > > > > Leif > > Have you tried running make depend? > Failing that, trying deleting your /sys/compile/ directory and re-config'ing your kernel. This has always worked for me. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: make kernel failure: pecoff: machine/lock.h
On 27-Feb-01 Leif Neland wrote: > This happens with both my custom and GENERIC kernel. > > It has failed for some days, and also with source cvsup'ed today. > A kernel built with "make buildkernel -k" works... > > Leif Have you tried running make depend? -- 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
