Re: AMD AGP Bug
Steve Kargl wrote: > > This sounds cool. > > > > Do you have references to the page attribute stuff? The > > books I have here don't discuss it; the only thing I see > > are 3 bits (9,10,11) that are "available" in the PDE and > > PTE? > > > > Well, twice in this thread you've offered info for > $1. I'm sure Peter can reciprocate with the > info you seek for a similar price. 8-). The info I offered is unrelated to FreeBSD. It lets the Linux people and the Windows people turn the PSE back on. They can afford it where FreeBSD can't. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Pam problems today
> Same thing happened to me yesterday after a make install world and mergemaster. > Took awhile to figure out. Building and installing libpam does not install >pam_login_access.so > Manfred I'm glad I'm not alone. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Pam problems today
At 09:49 PM 1/31/2002 -0600, David W. Chapman Jr. wrote: >I cvsuped a few hours ago, did the normal buildworld and >installworld, new kernel and mergemaster, but when I rebooted I could >not login, I had to comment a few lines in /etc/pam.d/login > >#accountrequiredpam_login_access.so >#accountrequiredpam_securetty.so > >#sessionrequiredpam_lastlog.so > >are the lines I had to comment out. I checked and I don't have >pam_login_access.so. I know that there have been a bunch of changes >recently, so if this is a known problem I apologize. > >-- >David W. Chapman Jr. >[EMAIL PROTECTED] Raintree Network Services, Inc. >[EMAIL PROTECTED] FreeBSD Committer > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message Same thing happened to me yesterday after a make install world and mergemaster. Took awhile to figure out. Building and installing libpam does not install pam_login_access.so Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Pam problems today
I cvsuped a few hours ago, did the normal buildworld and installworld, new kernel and mergemaster, but when I rebooted I could not login, I had to comment a few lines in /etc/pam.d/login #accountrequiredpam_login_access.so #accountrequiredpam_securetty.so #sessionrequiredpam_lastlog.so are the lines I had to comment out. I checked and I don't have pam_login_access.so. I know that there have been a bunch of changes recently, so if this is a known problem I apologize. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
On Thu, Jan 31, 2002 at 07:22:25PM -0800, Terry Lambert wrote: > Peter Wemm wrote: > > We need to use the PAT cpu_features feature. This gives us 8 page attribute > > modes instead of simple no-cache / writethrough flags. We can (and must) > > control more carefully the speculative hardware prefetch, for example. > > > > I've been thinking about this with the pmap revamp that I'm working on. > > It may solve the athlon problems too. > > This sounds cool. > > Do you have references to the page attribute stuff? The > books I have here don't discuss it; the only thing I see > are 3 bits (9,10,11) that are "available" in the PDE and > PTE? > Well, twice in this thread you've offered info for $1. I'm sure Peter can reciprocate with the info you seek for a similar price. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
Peter Wemm wrote: > > No. FreeBSD does not make active use of 4M pages for anything > > other than the initial kernel text and data, which is obvious, > > if you look at /sys/i386/machdep.c. > > Actually, it is obvious if you actually do look at the pmap.c that we *do* > use 4MB pages for device mappings. The "active use" I was referring to was kernel space, and this sets PG_U, so there are not fault handler invocations on attempts to write the pages. This code also does not set the PG_G bit, like Linux does. This code has a requirement that the address mapping occur on a 4M boundary, and that it be an even multiple of 4M. My reading of the AGPGART kernel module indicates to me that this code is not triggered in normal use. Correct me if my interpretation here is wrong (I'd like to know *how*; the default aperture appears to be 1M, unless it is overridden, and the alignment isn't on the right boundary). In any case, let's say that it gets invoked on the AGP hardware, and establishes a 4M mapping on FreeBSD, as well. I think the Linux problem has more to do with having *both* 4K and 4M mappings to the same physical memory area at the same time. FreeBSD avoids doing this to active pages; the initial setup replaces the PDE and "loses" the 4K worth of 4K mapping tables, and the later code that you reference doesn't replace any existing entries. It's accidental, but still, it should mean that FreeBSD is not succeptible to the problem. The real hint in characterizing the problem is to ask "why does it happen with 4M pages, but doesn't also happen with 4K pages?". This indicates that the problem is really a TLB problem, and therefore a real processor problem: the problem should happen no matter what, if it's a problem with writing to mapped memory use by the AGP not giving an invalidation signal to the CPU on writes, rather than a problem in the CPUs handling of 4M page invalidation itself, a problem that does not exist in the 4K invalidation case. Unfortuantely, I would need to upgrade both my FreeBSD and my XFree86 to try this with the AGP on my AMD box (it has a 0x7121 ID, and so can't GARTIOCINFO correctly) to be able to even try to repeat the problem, and Fry's does not appear to be selling FreeBSD CDROM sets any more, even with the books attached. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
Peter Wemm wrote: > We need to use the PAT cpu_features feature. This gives us 8 page attribute > modes instead of simple no-cache / writethrough flags. We can (and must) > control more carefully the speculative hardware prefetch, for example. > > I've been thinking about this with the pmap revamp that I'm working on. > It may solve the athlon problems too. This sounds cool. Do you have references to the page attribute stuff? The books I have here don't discuss it; the only thing I see are 3 bits (9,10,11) that are "available" in the PDE and PTE? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
Kenneth Culver wrote: > Yeah, that's what I saw on linux-kernel... > > Ken We need to use the PAT cpu_features feature. This gives us 8 page attribute modes instead of simple no-cache / writethrough flags. We can (and must) control more carefully the speculative hardware prefetch, for example. I've been thinking about this with the pmap revamp that I'm working on. It may solve the athlon problems too. > On Thu, 31 Jan 2002, Cameron, Frank wrote: > > > From what was posted on the linux-kernel list the problem is the OS > > doing the wrong thing not the hardware. I originally asked the > > question (albeit not worded as clearly as I should have) because if > > Microsoft and Linux programmers made the same mistake, might > > FreeBSD have also. > > > > > -Original Message- > > > From: Kenneth Culver [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, January 31, 2002 10:42 AM > > > To: Terry Lambert > > > Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]'; > > > '[EMAIL PROTECTED]' > > > Subject: Re: AMD AGP Bug > > > > > > > > > > There's actually a seperate TLB bug, but FreeBSD doesn't > > > > trigger that one, either (Linux can tickle it, when there > > > > are certain specific circumstances met). > > > > > > > Well, I think I know what you're talking about, linux > > > allocates agpgart > > > memory without setting a "non-cacheable" bit, and then the > > > agp card writes > > > to that memory, but the cpu cached it already, which makes > > > the cache wrong > > > or something like that, and causes the crashes/hangs. I know this is a > > > greatly simplified version of the real problem, but I think this is a > > > linux bug not necesarily an amd bug. > > > > > > Ken > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-bugs" in the body of the message > Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
Terry Lambert wrote:
> "Cameron, Frank" wrote:
> > From what was posted on the linux-kernel list the problem is the OS
> > doing the wrong thing not the hardware. I originally asked the
> > question (albeit not worded as clearly as I should have) because if
> > Microsoft and Linux programmers made the same mistake, might
> > FreeBSD have also.
>
> No. FreeBSD does not make active use of 4M pages for anything
> other than the initial kernel text and data, which is obvious,
> if you look at /sys/i386/machdep.c.
Actually, it is obvious if you actually do look at the pmap.c that we *do*
use 4MB pages for device mappings.
/*
* This code maps large physical mmap regions into the
* processor address space. Note that some shortcuts
* are taken, but the code works.
*/
if (pseflag && (object->type == OBJT_DEVICE) &&
((addr & (NBPDR - 1)) == 0) && ((size & (NBPDR - 1)) == 0)) {
...
for(i = 0; i < npdes; i++) {
pmap->pm_pdir[ptepindex] =
ptepa | PG_U | PG_RW | PG_V | PG_PS;
ptepa += NBPDR;
ptepindex += 1;
}
...
Even doing a simple grep for the 4MB page flag (PG_PS) and using a
little initiative would have shown this.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
I was under the impression that they were writing into the cache not out of it... I really need to read that article again :-D Ken On Thu, 31 Jan 2002, Jason Evans wrote: > On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: > > > > Linux can be fixed, but the useless writes of the existing Athlons from > > the very fast cache to the relatively very slow memory cannot. And all > > Athlon users may well pay this penalty under any OS... unless we want to > > disable caching. :) > > Have you done benchmarks to show that the speculative writes are useless > often enough to cause enough memory bus contention that overall performance > is degraded, despite the speedups when the speculative writes are valid? I > suspect that AMD in fact performed such tests; otherwise they wouldn't have > gone to the trouble of implementing speculative writes. > > Jason > > 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: AMD AGP Bug
On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: > > Linux can be fixed, but the useless writes of the existing Athlons from > the very fast cache to the relatively very slow memory cannot. And all > Athlon users may well pay this penalty under any OS... unless we want to > disable caching. :) Have you done benchmarks to show that the speculative writes are useless often enough to cause enough memory bus contention that overall performance is degraded, despite the speedups when the speculative writes are valid? I suspect that AMD in fact performed such tests; otherwise they wouldn't have gone to the trouble of implementing speculative writes. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: AMD AGP Bug
I'm thinking you may have misunderstood, the people at amd themselves said this wasn't an amd bug... why would you write from cache to memory, I think it's the other way around, stuff getting written to cache from memory... (being retrieved by the cpu) I'll have to read the article again to be sure since it was a week ago when I read it. Ken On Wed, 30 Jan 2002, [ISO-8859-1] Gérard Roudier wrote: > > > On Thu, 31 Jan 2002, Kenneth Culver wrote: > > > Yeah, that's what I saw on linux-kernel... > > You probably didn't see the whole story or just did a too selective > reading. You should re-read, in my opinion, since you may have just missed > the important part. > > What I understood is that the Athlon allocates cache lines for speculative > writes (if write may hit cachable) and such cache lines are flushed to > memory even if the write does not happen. As a result, numerous useless > writes to memory may happen under any OS. > > This does not cause visible issue for memory that is required to be cache > coherent. Just AGP accesses are not required to be snooped by cache for > performance concerns and as memory given to AGP is intended to contain > data as textures that should not need tight synchronisation with CPU. > > Indeed Linux has cached mapping to AGP memory and this could be avoided. > Nevertheless, only strange issues like the AMD AGP bug we are talking > about could turn this into a real problem. > > Linux can be fixed, but the useless writes of the existing Athlons from > the very fast cache to the relatively very slow memory cannot. And all > Athlon users may well pay this penalty under any OS... unless we want to > disable caching. :) > > Btw, I have 2 Athlon 1.2GHz machines that work just fine and fast for me. > > Gérard. > > > > Ken > > > > On Thu, 31 Jan 2002, Cameron, Frank wrote: > > > > > From what was posted on the linux-kernel list the problem is the OS > > > doing the wrong thing not the hardware. I originally asked the > > > question (albeit not worded as clearly as I should have) because if > > > Microsoft and Linux programmers made the same mistake, might > > > FreeBSD have also. > > > > > > > -Original Message- > > > > From: Kenneth Culver [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, January 31, 2002 10:42 AM > > > > To: Terry Lambert > > > > Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]'; > > > > '[EMAIL PROTECTED]' > > > > Subject: Re: AMD AGP Bug > > > > > > > > > > > > > There's actually a seperate TLB bug, but FreeBSD doesn't > > > > > trigger that one, either (Linux can tickle it, when there > > > > > are certain specific circumstances met). > > > > > > > > > Well, I think I know what you're talking about, linux > > > > allocates agpgart > > > > memory without setting a "non-cacheable" bit, and then the > > > > agp card writes > > > > to that memory, but the cpu cached it already, which makes > > > > the cache wrong > > > > or something like that, and causes the crashes/hangs. I know this is a > > > > greatly simplified version of the real problem, but I think this is a > > > > linux bug not necesarily an amd bug. > > > > > > > > Ken > > > > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-bugs" in the body of the message > > > > > > > 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: AMD AGP Bug
"Cameron, Frank" wrote: > From what was posted on the linux-kernel list the problem is the OS > doing the wrong thing not the hardware. I originally asked the > question (albeit not worded as clearly as I should have) because if > Microsoft and Linux programmers made the same mistake, might > FreeBSD have also. No. FreeBSD does not make active use of 4M pages for anything other than the initial kernel text and data, which is obvious, if you look at /sys/i386/machdep.c. For Linux and Windows, the obvious thing is to not map the memory into an aperture marked cacheable and in a 4M page; it's a coding problem with the use of 4M pages, when memory in them is allocated to AGP. This still doesn't get around the other bug, which happens if you use 4M pages certain obviously useful ways, without waving a dead chicken over certain things. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
Kenneth Culver wrote: > > There's actually a seperate TLB bug, but FreeBSD doesn't > > trigger that one, either (Linux can tickle it, when there > > are certain specific circumstances met). > > Well, I think I know what you're talking about, linux allocates agpgart > memory without setting a "non-cacheable" bit, and then the agp card writes > to that memory, but the cpu cached it already, which makes the cache wrong > or something like that, and causes the crashes/hangs. I know this is a > greatly simplified version of the real problem, but I think this is a > linux bug not necesarily an amd bug. No, you are describing the coherency bug in the chipset used for the AGP with AMD processors, which should enforce a coherency cycle, and cache invalidation for AGP based writes of the shared memory region. They are treating it as if it were non-cacheable dual ported SDRAM. There *really* is a bug in P4 and above and in late model AMD chips with 4M pages. It is very easy to reproduce with a few small kernel modifications (to actively use 4M pages) and 256M-512M of RAM. I'll characterize it further and provide the software workaround, for $10,000. It's about 16 machine instructions, if you write it out as code. Meanwhile, Linux and Windows can keep turning off the PSE, and losing 4-14% of their performance, depending on their application. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in vfs_syscalls
Alfred Perlstein wrote: > * Michael Nottebrock <[EMAIL PROTECTED]> [020131 12:19] wrote: > >>I'm getting these kind of panics with yesterday's kernel every time I >>try to use rpm. >> > > Thanks, I'm pretty sure I know what the fix is, but won't be able > to take a shot until later tonight, for now you can just remove > all FILEDESC_LOCK/UNLOCK calls from chroot_refuse_vdir_fds and > that should keep you panic free. It does indeed. Thanks! -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: AMD AGP Bug
On Thu, 31 Jan 2002, Kenneth Culver wrote: > Yeah, that's what I saw on linux-kernel... You probably didn't see the whole story or just did a too selective reading. You should re-read, in my opinion, since you may have just missed the important part. What I understood is that the Athlon allocates cache lines for speculative writes (if write may hit cachable) and such cache lines are flushed to memory even if the write does not happen. As a result, numerous useless writes to memory may happen under any OS. This does not cause visible issue for memory that is required to be cache coherent. Just AGP accesses are not required to be snooped by cache for performance concerns and as memory given to AGP is intended to contain data as textures that should not need tight synchronisation with CPU. Indeed Linux has cached mapping to AGP memory and this could be avoided. Nevertheless, only strange issues like the AMD AGP bug we are talking about could turn this into a real problem. Linux can be fixed, but the useless writes of the existing Athlons from the very fast cache to the relatively very slow memory cannot. And all Athlon users may well pay this penalty under any OS... unless we want to disable caching. :) Btw, I have 2 Athlon 1.2GHz machines that work just fine and fast for me. Gérard. > Ken > > On Thu, 31 Jan 2002, Cameron, Frank wrote: > > > From what was posted on the linux-kernel list the problem is the OS > > doing the wrong thing not the hardware. I originally asked the > > question (albeit not worded as clearly as I should have) because if > > Microsoft and Linux programmers made the same mistake, might > > FreeBSD have also. > > > > > -Original Message- > > > From: Kenneth Culver [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, January 31, 2002 10:42 AM > > > To: Terry Lambert > > > Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]'; > > > '[EMAIL PROTECTED]' > > > Subject: Re: AMD AGP Bug > > > > > > > > > > There's actually a seperate TLB bug, but FreeBSD doesn't > > > > trigger that one, either (Linux can tickle it, when there > > > > are certain specific circumstances met). > > > > > > > Well, I think I know what you're talking about, linux > > > allocates agpgart > > > memory without setting a "non-cacheable" bit, and then the > > > agp card writes > > > to that memory, but the cpu cached it already, which makes > > > the cache wrong > > > or something like that, and causes the crashes/hangs. I know this is a > > > greatly simplified version of the real problem, but I think this is a > > > linux bug not necesarily an amd bug. > > > > > > Ken > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-bugs" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in vfs_syscalls
* Michael Nottebrock <[EMAIL PROTECTED]> [020131 12:19] wrote:
> I'm getting these kind of panics with yesterday's kernel every time I
> try to use rpm.
Thanks, I'm pretty sure I know what the fix is, but won't be able
to take a shot until later tonight, for now you can just remove
all FILEDESC_LOCK/UNLOCK calls from chroot_refuse_vdir_fds and
that should keep you panic free.
>
> [[EMAIL PROTECTED]]:~ > rpm -Uhv --root=/compat/linux
> /home/lofi/libpng-1.0.9-1.i386.rpm
> recursed on non-recursive lock (sleep mutex) filedesc structure @
> ../../../kern/vfs_syscalls.c:3573
> first acquired @ ../../../kern/vfs_syscalls.c:998
> panic: recurse
> Debugger("panic")
> Stopped at Debugger+0x44: pushl %ebx
> db>trace
> Debugger(c03f7828,c4219334,df5,c03fc830,0) at panic+0x70
> witness_lock(c4219334,8,c03fc830,df5,0) at witness_lock+0x1a6
> _mtx_lock_flags(c4219334,0,c03fc830,df5) at _mtx_lock_flags+0x72
> getvnode(c4219300,0,deb2dc74) at getvnode+0x31
> chroot_refuse_vdir_fds(c4219300,c4219334,0,c03fc830,41e) at
> chroot_refuse_vdir_fds+0x3f
> chroot(dea33104,deb2dd20,8131be0,bfbff7c8,8122,ec6) at chroot+0x78
> syscall(2f,2f,2f,8122ec6,bfbff7c8) at syscall+0x250
> syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> --- syscall (61, FreeBSD ELF, chroot), eip = 0x80a4677, esp =
> 0xbfbff75c, ebp
> = 0xbfbff9b8 ---
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pkg_version on -CURRENT
On Thursday 31 January 2002 21:24, Kris Kennaway wrote: Hi Kris, > If you installed it from the port, reinstall the port. > > portupgrade -f p5-\* > > should do the trick. That did it, thanks! Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pkg_version on -CURRENT
On Thu, Jan 31, 2002 at 06:34:32PM +0100, Miguel Mendez wrote: > Hi there, > > Some days ago I upgraded a 4.4-RC box to 5.0-CURRENT, and pkg_version is no > longer working. Being it a perl script, is this due to the fact that current > uses 5.6? How to fix this then? If you installed it from the port, reinstall the port. portupgrade -f p5-\* should do the trick. Kris msg33958/pgp0.pgp Description: PGP signature
panic in vfs_syscalls
I'm getting these kind of panics with yesterday's kernel every time I
try to use rpm.
[[EMAIL PROTECTED]]:~ > rpm -Uhv --root=/compat/linux
/home/lofi/libpng-1.0.9-1.i386.rpm
recursed on non-recursive lock (sleep mutex) filedesc structure @
../../../kern/vfs_syscalls.c:3573
first acquired @ ../../../kern/vfs_syscalls.c:998
panic: recurse
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db>trace
Debugger(c03f7828,c4219334,df5,c03fc830,0) at panic+0x70
witness_lock(c4219334,8,c03fc830,df5,0) at witness_lock+0x1a6
_mtx_lock_flags(c4219334,0,c03fc830,df5) at _mtx_lock_flags+0x72
getvnode(c4219300,0,deb2dc74) at getvnode+0x31
chroot_refuse_vdir_fds(c4219300,c4219334,0,c03fc830,41e) at
chroot_refuse_vdir_fds+0x3f
chroot(dea33104,deb2dd20,8131be0,bfbff7c8,8122,ec6) at chroot+0x78
syscall(2f,2f,2f,8122ec6,bfbff7c8) at syscall+0x250
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (61, FreeBSD ELF, chroot), eip = 0x80a4677, esp =
0xbfbff75c, ebp
= 0xbfbff9b8 ---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: AMD AGP Bug
Yeah, that's what I saw on linux-kernel... Ken On Thu, 31 Jan 2002, Cameron, Frank wrote: > From what was posted on the linux-kernel list the problem is the OS > doing the wrong thing not the hardware. I originally asked the > question (albeit not worded as clearly as I should have) because if > Microsoft and Linux programmers made the same mistake, might > FreeBSD have also. > > > -Original Message- > > From: Kenneth Culver [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, January 31, 2002 10:42 AM > > To: Terry Lambert > > Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]'; > > '[EMAIL PROTECTED]' > > Subject: Re: AMD AGP Bug > > > > > > > There's actually a seperate TLB bug, but FreeBSD doesn't > > > trigger that one, either (Linux can tickle it, when there > > > are certain specific circumstances met). > > > > > Well, I think I know what you're talking about, linux > > allocates agpgart > > memory without setting a "non-cacheable" bit, and then the > > agp card writes > > to that memory, but the cpu cached it already, which makes > > the cache wrong > > or something like that, and causes the crashes/hangs. I know this is a > > greatly simplified version of the real problem, but I think this is a > > linux bug not necesarily an amd bug. > > > > Ken > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock reversal in fdalloc()
* Bruce Evans <[EMAIL PROTECTED]> [020131 09:42] wrote:
> Jan 31 18:27:29 gamplex kernel: lock order reversal
> Jan 31 18:27:29 gamplex kernel: 1st 0xc26ea034 filedesc structure @
>./@/kern/kern_descrip.c:925
> Jan 31 18:27:29 gamplex kernel: 2nd 0xc031eca0 Giant @ ./@/kern/kern_descrip.c:959
>
> %%%
> Index: kern_descrip.c
> ===
> RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
> retrieving revision 1.122
> diff -u -2 -r1.122 kern_descrip.c
> --- kern_descrip.c29 Jan 2002 22:54:19 - 1.122
> +++ kern_descrip.c31 Jan 2002 07:32:43 -
> @@ -957,7 +967,9 @@
> fdexpand++;
> if (oldofile != NULL) {
> + FILEDESC_UNLOCK(fdp);
> mtx_lock(&Giant);
> FREE(oldofile, M_FILEDESC);
> mtx_unlock(&Giant);
> + FILEDESC_LOCK(fdp);
> }
> }
> %%%
>
> I'm not sure that releasing the lock here is safe, but other parts of
> fdalloc() do this.
I don't think this is safe at a glance, I think it's only safe right
before return'ing from the function. I'll look at it later tonight.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vmware
I've got the 20020112 snapshot running in vmware. I did have similar trouble booting initially; I was installing a base system off an old 4.2- RELEASE CD I had and cvsuping straight to 5-CURRENT, and the system would always hang when attempting to mount the root partition. I got it working by cvsuping to 4-STABLE and installing that system first, then upgrading to -CURRENT. Jason Rhodes > > Should -current work under vmware by default, or are there steps i > should take to make it work? > > thanks > > thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: many copies of make running while building a port...
Dan Nelson heeft op woensdag 30 januari 2002 om 22:18 het volgende geschreven: >> Is USE_GCC30 actually supported? Should I just keep my hands off >> that? Or will it be a valid knob to switch over in the near future? > > That was me, actually. I forgot to mention that I had a local hack in > bsd.port.mk to fix a little recursion problem with USE_GCC30 :) So it's your fault I saw this very alpha 'feature' and wanted to test it? :-) Thanks for the patch, I will test it. Cheers, Emiel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vmware
rwatson> If someone has a commercial license, it would make sense rwatson> submitting this via a trouble ticket, as well as providing rwatson> the VMware support people with some brief directions on rwatson> installing 5.0. I've just filed an incident (I have a license of VMware 3.0). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock reversal in fdalloc()
Jan 31 18:27:29 gamplex kernel: lock order reversal
Jan 31 18:27:29 gamplex kernel: 1st 0xc26ea034 filedesc structure @
./@/kern/kern_descrip.c:925
Jan 31 18:27:29 gamplex kernel: 2nd 0xc031eca0 Giant @ ./@/kern/kern_descrip.c:959
%%%
Index: kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.122
diff -u -2 -r1.122 kern_descrip.c
--- kern_descrip.c 29 Jan 2002 22:54:19 - 1.122
+++ kern_descrip.c 31 Jan 2002 07:32:43 -
@@ -957,7 +967,9 @@
fdexpand++;
if (oldofile != NULL) {
+ FILEDESC_UNLOCK(fdp);
mtx_lock(&Giant);
FREE(oldofile, M_FILEDESC);
mtx_unlock(&Giant);
+ FILEDESC_LOCK(fdp);
}
}
%%%
I'm not sure that releasing the lock here is safe, but other parts of
fdalloc() do this.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vmware
Have to wonder if it wouldn't be worth e-mailing the VMware people about
this -- they'd probably rather know in advance if there's a potential
problem hosting future versions of FreeBSD under VMWare. If someone has a
commercial license, it would make sense submitting this via a trouble
ticket, as well as providing the VMware support people with some brief
directions on installing 5.0.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Thu, 31 Jan 2002, Glenn Gombert wrote:
> Here is an item that was mentioned sometime ago on the mailing list,
> -CURRENT runs just fine under VMWare Workstation 3.0 (on Win2K
> Professional) once this patch is made:
>
> Glenn G.
>
> >>>
>
> Someone mentioned on a list somewhere that vmware takes forever to
> emulate the cmpxchg instruction, and that using the I386_CPU version
> of atomic_cmpset_int() helps a lot. I noticed a major vmware slowdown
> with -current sometime in September, so I tried avoiding the
> cmpxchg's and things got much faster. Below is the patch I use
> (using this outside vmware on SMP hardware is a bad idea :-).
>
> Ian
>
> Index: atomic.h
> ===
> RCS file: /dump/FreeBSD-CVS/src/sys/i386/include/atomic.h,v
> retrieving revision 1.21
> diff -u -r1.21 atomic.h
> --- atomic.h 2001/10/08 20:58:24 1.21
> +++ atomic.h 2001/10/09 18:35:25
> @@ -111,7 +111,7 @@
> * Returns 0 on failure, non-zero on success
> */
>
> -#if defined(I386_CPU)
> +#if defined(I386_CPU) || 1
> static __inline int
> atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
> {
>
>
>
> At 12:56 AM 2/1/2002 +1100, Logan weaponx wrote:
> >hi,
> > I was wondering if there are any tricks required to make freebsd
> >5.0-current work under vmware 3.0 (Windows XP host). When I try and boot
> >(from the 20020127 snapshot) it fails to boot. It hangs at different stages
> >in the boot each time, but the furthest it has ever gotten is trying to load
> >/sbin/init. I can boot from kern.flp and then use my root partition, but
> >things dont load correctly (network, filesystems, etc). I looked through the
> >archives and noted a few posts regarding different vmware issues and a
> >patch.
> >
>
> Glenn Gombert
> [EMAIL PROTECTED]
>
> 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
pkg_version on -CURRENT
Hi there, Some days ago I upgraded a 4.4-RC box to 5.0-CURRENT, and pkg_version is no longer working. Being it a perl script, is this due to the fact that current uses 5.6? How to fix this then? Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vmware
Here is an item that was mentioned sometime ago on the mailing list,
-CURRENT runs just fine under VMWare Workstation 3.0 (on Win2K
Professional) once this patch is made:
Glenn G.
>>>
Someone mentioned on a list somewhere that vmware takes forever to
emulate the cmpxchg instruction, and that using the I386_CPU version
of atomic_cmpset_int() helps a lot. I noticed a major vmware slowdown
with -current sometime in September, so I tried avoiding the
cmpxchg's and things got much faster. Below is the patch I use
(using this outside vmware on SMP hardware is a bad idea :-).
Ian
Index: atomic.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/i386/include/atomic.h,v
retrieving revision 1.21
diff -u -r1.21 atomic.h
--- atomic.h2001/10/08 20:58:24 1.21
+++ atomic.h2001/10/09 18:35:25
@@ -111,7 +111,7 @@
* Returns 0 on failure, non-zero on success
*/
-#if defined(I386_CPU)
+#if defined(I386_CPU) || 1
static __inline int
atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
{
At 12:56 AM 2/1/2002 +1100, Logan weaponx wrote:
>hi,
> I was wondering if there are any tricks required to make freebsd
>5.0-current work under vmware 3.0 (Windows XP host). When I try and boot
>(from the 20020127 snapshot) it fails to boot. It hangs at different stages
>in the boot each time, but the furthest it has ever gotten is trying to load
>/sbin/init. I can boot from kern.flp and then use my root partition, but
>things dont load correctly (network, filesystems, etc). I looked through the
>archives and noted a few posts regarding different vmware issues and a
>patch.
>
Glenn Gombert
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: AMD AGP Bug
>From what was posted on the linux-kernel list the problem is the OS doing the wrong thing not the hardware. I originally asked the question (albeit not worded as clearly as I should have) because if Microsoft and Linux programmers made the same mistake, might FreeBSD have also. > -Original Message- > From: Kenneth Culver [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 31, 2002 10:42 AM > To: Terry Lambert > Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]'; > '[EMAIL PROTECTED]' > Subject: Re: AMD AGP Bug > > > > There's actually a seperate TLB bug, but FreeBSD doesn't > > trigger that one, either (Linux can tickle it, when there > > are certain specific circumstances met). > > > Well, I think I know what you're talking about, linux > allocates agpgart > memory without setting a "non-cacheable" bit, and then the > agp card writes > to that memory, but the cpu cached it already, which makes > the cache wrong > or something like that, and causes the crashes/hangs. I know this is a > greatly simplified version of the real problem, but I think this is a > linux bug not necesarily an amd bug. > > Ken > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
> There's actually a seperate TLB bug, but FreeBSD doesn't > trigger that one, either (Linux can tickle it, when there > are certain specific circumstances met). > Well, I think I know what you're talking about, linux allocates agpgart memory without setting a "non-cacheable" bit, and then the agp card writes to that memory, but the cpu cached it already, which makes the cache wrong or something like that, and causes the crashes/hangs. I know this is a greatly simplified version of the real problem, but I think this is a linux bug not necesarily an amd bug. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Wed, 23 Jan 2002, Bruce Evans wrote: > On Sun, 20 Jan 2002, k Macy wrote: > > > Should I file a PR to track this or is that overkill? > > Yes, it would be overkill. Remind me if it's not fixed in a week or two. I tested and committed the fix. Please report any other profiling bugs for SMP. I'm mainly interested in things that work for !SMP but not even as well as possible for SMP (no attempt is made to separate stats for each CPU so all we can hope for now is proper merging of the stats). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vmware
hi, I was wondering if there are any tricks required to make freebsd 5.0-current work under vmware 3.0 (Windows XP host). When I try and boot (from the 20020127 snapshot) it fails to boot. It hangs at different stages in the boot each time, but the furthest it has ever gotten is trying to load /sbin/init. I can boot from kern.flp and then use my root partition, but things dont load correctly (network, filesystems, etc). I looked through the archives and noted a few posts regarding different vmware issues and a patch. Should -current work under vmware by default, or are there steps i should take to make it work? thanks thomas _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
Kenneth Culver wrote: > Actually FreeBSD does make use of them, but in a way that doesn't cause a > problem. There's actually a seperate TLB bug, but FreeBSD doesn't trigger that one, either (Linux can tickle it, when there are certain specific circumstances met). $10,000, and I'll tell you how to fix it. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: many copies of make running while building a port...
Alan Eldridge heeft op woensdag 30 januari 2002 om 23:09 het volgende geschreven: >> Hmm, curious. The symptoms disappeared when I commented the line >> USE_GCC30=TRUE out of my make.conf. I switched it on because I read on >> the current@ list that someone enabled it and didn't have any >> problems... > > Umm, this may be a stupid question, but do you have gcc30 installed and > have you verified that it works? Yes, gcc30 works and I got it installed. No problems building except for this niggle Cheers, Emiel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
