Mike Barcroft wrote:
> I don't have any objections to making this a supported legacy mode,
> but I think deprecated features (things we *want* to go away) should
> produce warnings.
Right-o no argument there. I'll wait for Joe to comment on the
patch then...
--
"We have known fr
Doug Barton <[EMAIL PROTECTED]> writes:
> Mike Barcroft wrote:
> > Deprecated features should generate warnings.
>
> Ok, then let's call it "Undocumented legacy support." I agree that
> features we don't want to support anymore should generate warnings that
> encourage users to change. Howe
:...
:> stuff (it was not used on that machine) and it booted fine, I think that
:> might just cure the SMP problem you are seeing too.
:
:Thanks for the suggestion.
:
:Unfortunately it still hangs with SMP enabled and the ATA drivers commented
:out of the GENERIC config.
:
:Ken
:--
:Kenneth
On Sun, 24 Feb 2002, Matthew Dillon wrote:
> :cpu_switch() certainly needs to do this if it can be called with the
> :interrupt enable flag[s] in different states. I need the sti's (actually
> :enable_intr()'s because I don't want fast interrupts to be disabled
> :during context switches. This
At 1:00 AM -0800 2/24/02, Julian Elischer wrote:
>On Sat, 23 Feb 2002, Garance A Drosihn wrote:
> > It is working fairly well for me too, on a dual-pentium machine.
>> I can't get vmware2 working, but most of everything else that I
>> do is working, and I'm not running into any mysterious crash
Mike Barcroft wrote:
>
> Doug Barton <[EMAIL PROTECTED]> writes:
> > A couple months ago an improvement was added to the color support of ls
> > to use a wider variety of colors, indicated by alphabet characters
> > instead of numbers. While I think this is a good change, it included a
> >
On Sun, 24 Feb 2002, Matthew Dillon wrote:
> :On Sun, 24 Feb 2002, Matthew Dillon wrote:
> :> * Additional cpu_critical_enter/exit() calls around icu_lock. Since
> :> critical_enter() no longer disables interrupts, special care must
> :> be taken when dealing with the icu_lock sp
:pid 214 guid/sec 687816Two TU's running, old critical_*()
:pid 214 guid/sec 6876321.454 uS/call
:pid 214 guid/sec 687857
:pid 214 guid/sec 687887
:pid 214 guid/sec 667454new critical_*()
:pid 214 guid/sec 6675621.496 uS/call
Hi Folks,
I'm now mirroring the CVS repository locally (with cvsup)
and then checking out the head of the tree with cvs co src to get
at -CURRENT. I'm trying to work with picobsd but I get the following
on the latest (24 Feb 2002, 22:25 Pacific Time) stuff when I just try
to --init the
:> :is written out, so I don't see much point in changing this do the masking
:> :in software and avoid the soft interrupt.
:>
:> I have no idea what you are talking about Jake. Could you supply
:> some context?
:
:Sorry, maybe I got ahead of myself. I was responding to your suggestion
Ok, I've done a more comprehensive test. TU = getuid() syscall test.
This is on a 2xCPU SMP box.
With one process running the syscall is 34 nS faster with the
new critical_*(). With two processes running the syscall is
41 nS faster with the new critical_*().
So, not 3
Apparently, On Sun, Feb 24, 2002 at 09:03:53PM -0800,
Matthew Dillon said words to the effect of;
> :...
> :interrupts; hard interrupts are rarely masked. The queueing is written
> :in assmebler and runs outside of the kernel so it is fast. Traps in
> :general are fast because they don'
Doug Barton <[EMAIL PROTECTED]> writes:
> A couple months ago an improvement was added to the color support of ls
> to use a wider variety of colors, indicated by alphabet characters
> instead of numbers. While I think this is a good change, it included a
> warning when users have the old st
In message: <[EMAIL PROTECTED]>
"David O'Brien" <[EMAIL PROTECTED]> writes:
: On Sun, Feb 24, 2002 at 10:15:44PM -0700, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > "David O'Brien" <[EMAIL PROTECTED]> writes:
: > : On Sun, Feb 24, 2002 at 08:46:45PM -0700,
null> After the cvs checkout completes:
Ah, big sorry... I just fixed in src/release/Makefile rev 1.658.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sun, Feb 24, 2002 at 10:15:44PM -0700, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "David O'Brien" <[EMAIL PROTECTED]> writes:
> : On Sun, Feb 24, 2002 at 08:46:45PM -0700, M. Warner Losh wrote:
> : > You need a different version for -current than for -stable. Make su
A couple months ago an improvement was added to the color support of ls
to use a wider variety of colors, indicated by alphabet characters
instead of numbers. While I think this is a good change, it included a
warning when users have the old style numeric flags in their LSCOLORS
variable.
:Removing cli and sti from the critical functions saves us 300 ns on
I'm going to make a correction here... I didn't realize I had WITNESS
turned on. 300ns of savings makes a lot of sense when WITNESS is turned
on because witness manipulates a number of spin locks.
I am goi
On Sun, Feb 24, 2002 at 09:02:25PM -0800, Doug Barton wrote:
> Steve Kargl wrote:
> >
> > cvsup sources from 24 FEB 02 at 14:42 PST. No local
> > patches (although I would like to play with Matt's
> > recent work).
>
> I cvsup'ed to this point:
>
> obrien 2002/02/24 13:26:07 PST
>
In message: <[EMAIL PROTECTED]>
"David O'Brien" <[EMAIL PROTECTED]> writes:
: On Sun, Feb 24, 2002 at 08:46:45PM -0700, M. Warner Losh wrote:
: > You need a different version for -current than for -stable. Make sure
: > you have the right version.
:
: I got the same problem with Xwra
t/Makefile,
>and fails to generate a Makefile for crunch binary.
>
>-- -
>Makoto `MAR' Matsushita
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
Makoto
I can't even get that far. On current as of today:
On Sun, Feb 24, 2002 at 08:46:45PM -0700, M. Warner Losh wrote:
> You need a different version for -current than for -stable. Make sure
> you have the right version.
I got the same problem with Xwrapper -- and it was compiled on this
5-CURRENT w/in the past 6 months.
To Unsubscribe: send mail t
:...
:interrupts; hard interrupts are rarely masked. The queueing is written
:in assmebler and runs outside of the kernel so it is fast. Traps in
:general are fast because they don't touch memory until the trapframe
:is written out, so I don't see much point in changing this do the masking
:in s
On Sun, Feb 24, 2002 at 09:02:02PM -0500, Glenn Gombert wrote:
> There is a problem in -Current now between SCSI card(s) and the ATA
> drivers,
For how long has this problem existed?
This is being typed from a dual Athlon system with 5 SCSI busses
(AHC,SYM,ISP) several disks, CD burnger; and wit
Steve Kargl wrote:
>
> cvsup sources from 24 FEB 02 at 14:42 PST. No local
> patches (although I would like to play with Matt's
> recent work).
I cvsup'ed to this point:
obrien 2002/02/24 13:26:07 PST
Modified files:
contrib/gcc.295/config/i386 freebsd.h
Log:
Use the d
In message: <[EMAIL PROTECTED]>
Doug Barton <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: >
: > You need a different version for -current than for -stable. Make sure
: > you have the right version.
:
: Version of what? There are no freebsd 5 binaries on xfree86.org's
"M. Warner Losh" wrote:
>
> You need a different version for -current than for -stable. Make sure
> you have the right version.
Version of what? There are no freebsd 5 binaries on xfree86.org's
website that I can see. I hope you're not saying that binary
compatability is broken by desig
Ouch.
matusita> src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target.
Of course that's normal, dhclient_clean target should be created by crunchgen.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the mes
Current 5-current fails 'make release' when processing release.4
target (making a crunch binary). Here's sample session:
===> doc
rm -f cpio.info cpio.info.gz
rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH
/usr/obj/usr/src/gnu/usr.bin/cpio/GRTAGS
/
Apparently, On Sun, Feb 24, 2002 at 11:12:22AM -0800,
Matthew Dillon said words to the effect of;
> NOTES:
>
> I would like to thank Bruce for supplying the sample code that allowed
> me to do this in a day instead of several days.
>
> * debug.critical_mode sysctl. This wil
You need a different version for -current than for -stable. Make sure
you have the right version.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Matt,
Thanks for the great explanation!
Hopefully, I'll get a chance to try this for alpha (though I won't
mind if somebody beats me to it).
I've also been meaning to get iprobe (kernel profiler) going again
too, to find out why -current on alpha sucks so badly right now.
(your gettimeofday()
On Sun, Feb 24, 2002 at 03:08:27PM +0100, Harald Schmalzbauer wrote:
> Since I changed my employer I made new subscriptions at bsdmall.com but
> I couldn't find any snapshot subscription.
Daemonnews has never sold snapshots, although that may be something
they will do in the future. You can bu
cvsup sources from 24 FEB 02 at 14:42 PST. No local
patches (although I would like to play with Matt's
recent work).
Standard update sequence (i.e., rm -rf /usr/obj/*
buildworld, buildkernel, installkernel, installworld,
mergemaster) yields
KLD linprocfs.ko: depends on linux - not available
lin
On Sun, Feb 24, 2002 at 21:02:02 -0500, Glenn Gombert wrote:
> There is a problem in -Current now between SCSI card(s) and the ATA
> drivers, On my Dell 410 Workstation at work I commetned out the ATA driver
> stuff (it was not used on that machine) and it booted fine, I think that
> might just cu
There is a problem in -Current now between SCSI card(s) and the ATA
drivers, On my Dell 410 Workstation at work I commetned out the ATA driver
stuff (it was not used on that machine) and it booted fine, I think that
might just cure the SMP problem you are seeing too.
At 11:15 AM 2/25/2002 +
:> up. One of the best things about this patch set is that it is really
:> flexible. We should be able to really make interrupts fly. In fact,
:> it should even be possible for one cpu to steal another cpu's pending
:> interrupt(s) fairly trivially, without having to resort to I
:I think you're making critical_enter()/critical_exit() cheaper by not
:actually messing with the interrupt hardware when they're called.
:Very much like what we do in 4-stable.
:
:Instead, you set/clear a per-cpu flag (or incr/decr a counter). If an
:interrupt comes in when you're inside a criti
+---[ Kenneth D. Merry ]--
|
| I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks
| HE-SL chipset, dual 1.26GHz Pentium III's.)
|
| It boots just fine with a GENERIC -current kernel (sources cvsupped
| yesterday at ~1500 MST), but hangs (at the "Wa
On Sun, 24 Feb 2002, Matthew Dillon wrote:
> Bruce, your sys.dif was *invaluable*! It would have taken me a lot
> longer to figure out the interrupt disablement requirement around
> the icu_lock, and the statclock and hardclock forwarding issues (which I
> got working by the way!
* Kenneth D. Merry <[EMAIL PROTECTED]> [020224 16:56] wrote:
>
> I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks
> HE-SL chipset, dual 1.26GHz Pentium III's.)
>
> It boots just fine with a GENERIC -current kernel (sources cvsupped
> yesterday at ~1500 MST), but hangs (
I'm not fluent in x86 asm, so can you confirm for me what you're
attempting to do here?
I think you're making critical_enter()/critical_exit() cheaper by not
actually messing with the interrupt hardware when they're called.
Very much like what we do in 4-stable.
Instead, you set/clear a per-cpu
I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks
HE-SL chipset, dual 1.26GHz Pentium III's.)
It boots just fine with a GENERIC -current kernel (sources cvsupped
yesterday at ~1500 MST), but hangs (at the "Waiting 15 seconds for SCSI
devices to settle" message) when SMP
I installed XFree86 version 4.2 in binary format from the xfree86.org
website. I just upgraded my -current installation to today's latest
bits, and now I can't log in with xdm. This is the output to the console
(minus date/host info for readability):
PAM unable to dlopen(/usr/lib/pam_uni
:
:On Sun, 24 Feb 2002, Matthew Dillon wrote:
:
:> * debug.critical_mode sysctl. This will not be in the final commit,
:> nor will any of the code that tests the variable. The final commit
:> will use code as if the critical_mode were '1'.
:
:Won't it be needed for longer for no
On Sun, 24 Feb 2002, Matthew Dillon wrote:
> NOTES:
>
> I would like to thank Bruce for supplying the sample code that allowed
> me to do this in a day instead of several days.
Thanks.
> * debug.critical_mode sysctl. This will not be in the final commit,
> nor will any of the
Terry Lambert wrote:
> > Question #1: are there plans to MFC these changes in the USB structures to
> > -stable in the near future?
Too late. Alfred is too fast.
> > Question #2: If not, is __FreeBSD_version >= 500030 the appropriate thing to
> > "key" off of in order to make a patch set for l
John Reynolds wrote:
> hello, I've got a -current-related question to ask. akbeech forwarded me
> his build log when trying to build the "linux" user-land libusb from the
> port which I maintain (it is below). At first I said "impossible" because I'd
> tested things thoroughly, but then noticed he
Alfred Perlstein wrote:
> * Terry Lambert <[EMAIL PROTECTED]> [020224 13:12] wrote:
> > Try the following patch; the failure message will be
> > somewhat less cryptic, since it will tell you the
> > proximal reason for failure out of the 5 possibles
> > for the message you are seeing. 8-).
>
> C
* John Reynolds <[EMAIL PROTECTED]> [020224 14:33] wrote:
>
> hello, I've got a -current-related question to ask. akbeech forwarded me
> his build log when trying to build the "linux" user-land libusb from the
> port which I maintain (it is below). At first I said "impossible" because I'd
> teste
hello, I've got a -current-related question to ask. akbeech forwarded me
his build log when trying to build the "linux" user-land libusb from the
port which I maintain (it is below). At first I said "impossible" because I'd
tested things thoroughly, but then noticed he was on a -current system. D
* Terry Lambert <[EMAIL PROTECTED]> [020224 13:12] wrote:
>
> Try the following patch; the failure message will be
> somewhat less cryptic, since it will tell you the
> proximal reason for failure out of the 5 possibles
> for the message you are seeing. 8-).
Cool explanation, the attached patch
In the last episode (Feb 24), Terry Lambert said:
> zhuravlev alexander wrote:
> > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
> > unknown: can't assign resources
> > unknown: can't assign resources
> > unknown: can't assign resources
> > unknown: can't assign resources
> > unknow
Michael Smith wrote:
> > It is if you have your BIOS configured incorrectly with
> > regard to whether you are running a "PNP OS".
>
> It's also normal if you have hints loaded for things that could have been
> autoconfigured, which is what the above seems to suggest.
OK. 8-). I've always seen
On Sun, 24 Feb 2002, Michael Smith wrote:
> Try grabbing Giant in acpi_tz_thread when it wakes up, then dropping it
> again before it goes to sleep. This is probably a hack, but I'd guess a
> required one for now.
>
> If that works, send me a diff and I'll commit it with thanks!
Yow! Works abso
> This is a multi-part message in MIME format.
> --741846253D1D9002AE8EAD96
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> zhuravlev alexander wrote:
> > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
> > unknown: can't assign resources
>
zhuravlev alexander wrote:
> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
> unknown: can't assign resources
> unknown: can't assign resources
> unknown: can't assign resources
> unknown: can't assign resources
> unknown: can't assign resources
> unknown: can't assign resources
>
Hi!
I wan't to know when will be suported
LC_NUMERIC and LC_MONETARY in FreeBSD, not hardcoded to C lang.
--
bye,
Uros
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
hi !
[zaa:/u/zaa]>uname -a
FreeBSD zaa.ulstu.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Feb 24 22:38:36
MSK 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC i386
- /var/run/dmesg.boot ---
sio1: type 16550A
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknow
> Wow! This did away with the once-a-minute error messages from Notify()s
> on processor objects on my laptop.
>
> However, I am now getting frequent panics from from a GIANT_REQUIRED
> assertion in kmem_malloc(). kmem_malloc() gets called via malloc() from
> AcpiOsAllocate(), without Giant loc
On Sat, 23 Feb 2002, Alfred Perlstein wrote:
> Usually when I see diff(1) output from you I usually expect a commit
> within the next half hour or so, I just wanted to make myself clear on
> the issue. No worries. :)
>
> Yes, and hopefully JeffR's allocator will fix our problems, that is if
>
On Sat, Feb 23, 2002 at 06:24:39PM +0100, Dag-Erling Smorgrav wrote:
> Thumbs up and big cheers to all of you (well, us) guys working on
> -CURRENT. It's pretty stable and has been for a while now - and even
> on my poor old 350 MHz K6-2, it performs well enough to make a kickass
> desktop & deve
Wow! This did away with the once-a-minute error messages from Notify()s
on processor objects on my laptop.
However, I am now getting frequent panics from from a GIANT_REQUIRED
assertion in kmem_malloc(). kmem_malloc() gets called via malloc() from
AcpiOsAllocate(), without Giant locked.
The ca
- Original Message -
From: "Szilveszter Adam" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 24, 2002 1:04 PM
Subject: Re: -CURRENT in pretty good shape, after all
> On Sun, Feb 24, 2002 at 06:22:11AM +0200, Giorgos Keramidas wrote:
> > It does work perfectly nice fo
NOTES:
I would like to thank Bruce for supplying the sample code that allowed
me to do this in a day instead of several days.
* debug.critical_mode sysctl. This will not be in the final commit,
nor will any of the code that tests the variable. The final commit
will use
On Sun, Feb 24, 2002 at 06:22:11AM +0200, Giorgos Keramidas wrote:
> It does work perfectly nice for me too, here. I've been building worlds
> without a single problem ever since Feb 7, 2002. Oh, and since I like
> living in the edge, I erased my 4-STABLE installation on Feb 10, and
> formatted
* George V. Neville-Neil ([EMAIL PROTECTED]) wrote:
> > BTW, why don't you want a FreeBSD WikiTerm?
>
> Well it's a bit odd. Anywhere you put the word FreeBSD lights up as a
> link. I guess we could put a generic page under it or something but
> it's annoying (to me at least) to see FreeBSD as
On 2002-02-23 18:24, Dag-Erling Smorgrav wrote:
> Thumbs up and big cheers to all of you (well, us) guys working on
> -CURRENT. It's pretty stable and has been for a while now - and even
> on my poor old 350 MHz K6-2, it performs well enough to make a kickass
> desktop & development platform. Le
Am Sa , 2002-02-23 um 18.24 schrieb Dag-Erling Smorgrav:
> Thumbs up and big cheers to all of you (well, us) guys working on
> -CURRENT. It's pretty stable and has been for a while now - and even
> on my poor old 350 MHz K6-2, it performs well enough to make a kickass
> desktop & development plat
On 15-Feb-2002 (22:17:10/GMT) Dan Nelson wrote:
> If you find out what killed /dev/speaker, let us know, too :)
On 23-Feb-2002 (22:03:56/GMT) Dag-Erling Smorgrav wrote:
>>> # kldload atspeaker
>> This doesn't work. I'm missing something obvious?
> Not that I can see... works for me
Now /dev/
I'm going to wait until tomorrow before posting it. I have a bunch of
cleanup to do.
Bruce, your sys.dif was *invaluable*! It would have taken me a lot
longer to figure out the interrupt disablement requirement around
the icu_lock, and the statclock and hardclock forwarding
Doug Barton wrote:
>
> Dag-Erling Smorgrav wrote:
> >
> > David Wolfskill <[EMAIL PROTECTED]> writes:
> > > Sounds like a botched (or not run) "mergemaster" execution:
> >
> > No - mergemaster will croak because it runs mtree to build its temp
> > directory, so if you're trying to update a pre-sm
SMP?
-- Terry
Julian Elischer wrote:
>
> h
>
> julian@jules:uname -a
> FreeBSD jules.elischer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Feb 21
> 00:32:02 PST 2002
> [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NMDM i386
> julian@jules:
>
> I'm using vmware2 to run turbotax to do my taxe
I'm just saying that if this is the "simple p->p_ucred => td->td_ucred
change that do only that and do the rewrite in a separate commit..
I'm not against doing hte commit as is however.. it's only 3 small
nits..
the one that may be real is the other one I mention (I think in another
email) wher
h
julian@jules:uname -a
FreeBSD jules.elischer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Feb 21
00:32:02 PST 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/NMDM i386
julian@jules:
I'm using vmware2 to run turbotax to do my taxes and it seems fine
On Sat, 23 Feb 2002, Garance A Dro
Alfred Perlstein wrote:
> * Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
> > This is approximately what I am thinking. Note that this gives us the
> > flexibility to create a larger infrastructure around the bucket cache,
> > such as implement per-cpu caches and so on and
Apparently, On Sat, Feb 23, 2002 at 11:21:24AM -0800,
Julian Elischer said words to the effect of;
>
>
> On Fri, 22 Feb 2002, John Baldwin wrote:
>
> >
> > http://www.FreeBSD.org/~jhb/patches/ucred.patch
>
>
> the structural rewriting in kern_proc.c should be done as a separate
> co
Jake Burkholder wrote:
> Jeff Roberson (jeff@) has been working on a slab allocator that goes
> a long way to making malloc(), free() and the zone allocator not require
> giant. I've reviewed what he's got so far and it looks pretty damn good
> to me, I'll see about getting him to post it. He's
78 matches
Mail list logo
