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
>
> 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.
[EM
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_lo
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_secu
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 pref
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
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 rev
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.
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 mad
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
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
> disabl
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 sur
"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
> Fre
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-
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, fo
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 alloc
* 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_
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.ne
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 t
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 @ ../.
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
* 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
>
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 cv
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
>
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).
-- -
Mako
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
===
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
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.
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 inst
>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
> 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
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.
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 lo
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
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
>> pr
35 matches
Mail list logo
