Problems in making world

Hi! I have a following problem in making world for some time already: ===> gnu/usr.bin/binutils/strip cc -O -pipe -D_GNU_SOURCE -I- -I. -I/usr/src/gnu/usr.bin/binutils/strip -I/usr/src/gnu/usr.bin/binutils/strip/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/strip/../../../../contrib/binutils/in

Re: ATI Rage Mobility and VESA driver

> > >However, using vidcontrol and attempting to set any VESA modes still > >produces "operation not supported by device". > > Just checking, but do you have > > optionsVGA_NO_MODE_CHANGE # don't change video modes Nope. But maybe I'm just expecting more modes than I can get. I ca

Re: bin/20311: src/release/Makefile: broken CHECKSUM.MD5

(forward to stable/current also, to open this problem widely) matusita> * CHECKSUM.MD5 is still broken. It also affected to 4.1.1-RELEASE I cannot believe that this problem is still there, and CHECKSUM.MD5s of 4.2-RELEASE/{src,crypto} are also broken. However, it's easy to fix just like this (

make buildworld trouble

I just finished getting all the source, using cvsup. When I do a make buildworld, i get the following errors plus more but they are all related to the symhacks.h included from the crypto file. In file included from /usr/obj/usr/src/secure/lib/libcrypto/openssl/bio.h:67, from /u

Re: [jhb@FreeBSD.org: RE: Panic in -current]

Sorry, I guess I should specify that this is a desktop with APM enabled in the BIOS, but not being used otherwise... VESA module loaded. #uname -a FreeBSD cae88-102-101.sc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Dec 2 16:07:54 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RHIANNON

Re: [jhb@FreeBSD.org: RE: Panic in -current]

Just as a data point, I just tried this as well... The daemon saver was ok, the fire saver was ok, but as soon as I loaded logo_saver and it activated, I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after that... I could switch vtys, but could not type anything. The fire_sa

Re: [jhb@FreeBSD.org: RE: Panic in -current]

On 05-Dec-00 Andrea Campi wrote: >> > More details: this is an IBM Thinkpad laptop with APM enabled and in the >> > kernel. >> > As usual, any hint is more than welcome. This used to work... >> >> Which screen saver? Does it do it with all of them? Just graphical ones, >> just >> text ones, ju

Re: [jhb@FreeBSD.org: RE: Panic in -current]

> > More details: this is an IBM Thinkpad laptop with APM enabled and in the > > kernel. > > As usual, any hint is more than welcome. This used to work... > > Which screen saver? Does it do it with all of them? Just graphical ones, just > text ones, just green_saver, etc.? Rrrright... I can as

Re: [jhb@FreeBSD.org: RE: Panic in -current]

On 05-Dec-00 Andrea Campi wrote: >> > >> > db> x/i,10 0xc025ad3c >> > scrn_timer: pushl %ebp >> > [...] >> > >> > nm just confirmed this, so it definitely looks like scrn_timer is to blame >> > here. Any other instructions? ;-) For the time being, vidcontrol -t off >> > (seems to) keep the

Re: [jhb@FreeBSD.org: RE: Panic in -current]

> > > > db> x/i,10 0xc025ad3c > > scrn_timer: pushl %ebp > > [...] > > > > nm just confirmed this, so it definitely looks like scrn_timer is to blame > > here. Any other instructions? ;-) For the time being, vidcontrol -t off > > (seems to) keep the machine up. > > > > Bye, > > Andrea

Re: current paging strategy

>On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: >> >Interesting. THis needs about two bytes per page for the counter? >> >>Actually, we found that a single byte per page was sufficient. Pages tended >> to be either heavily accessed or rarely accessed. Even in the unusual case

Re: current paging strategy

:On Mon, Dec 04, 2000 at 11:41:26PM +0100, Bernd Walter wrote: :> On Mon, Dec 04, 2000 at 02:36:44PM -0700, [EMAIL PROTECTED] wrote: :> > what exacly do you mean with critical path, here? :> :> Performance critical. :> Most RISC platforms are optimized for 32 and maybe 64 bit structures. :> E.g.

Re: current paging strategy

On Mon, Dec 04, 2000 at 11:41:26PM +0100, Bernd Walter wrote: > On Mon, Dec 04, 2000 at 02:36:44PM -0700, [EMAIL PROTECTED] wrote: > > what exacly do you mean with critical path, here? > > Performance critical. > Most RISC platforms are optimized for 32 and maybe 64 bit structures. > E.g. First g

Re: current paging strategy

On Mon, Dec 04, 2000 at 02:36:44PM -0700, [EMAIL PROTECTED] wrote: > what exacly do you mean with critical path, here? Performance critical. Most RISC platforms are optimized for 32 and maybe 64 bit structures. E.g. First generation alphas (without BWX) can't even access anything smaller than 32b

-current kernel panic: ufs_ihashget

Hi, I'm getting the following panic when I run the following command: tar -cvf - . | compress | dd bs=64m of=/dev/sa0 running with a blocksize of 2,4,8,16, or 32meg on the dd command run to completion with no problems. Fatal trap 12: page fault while in kernel mode fault virtual address

Re: current paging strategy

what exacly do you mean with critical path, here? JAn On Sun, 5 Nov 2000, Bernd Walter wrote: > On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: > > >Interesting. THis needs about two bytes per page for the counter? > > > >Actually, we found that a single byte per page was su

Re: Lucent Orinoco Gold PCCard?

John Baldwin wrote: > [...] > > 0 == bronze > 40 == silver > 128 == gold FWIW, it is more correct to say either 0 == bronze 40 == silver 104 == gold or 0 == bronze 64 == silver 128 == gold WEP has a 24 bit sequence number that perturbs the encryption. The fact that 24 bit sequence numbers

Making {open,close,read,tell,seek}dir thread-safe.

I started a cleanup of libc to make it thread-safe. I would like to get rid of the hash table in libc/gen/telldir.c and maintain telldir position information on a per-DIR basis. A summary of the changes are as follows: o Add a LIST_HEAD to DIR to contain a queue of telldir positions. Als

Re: current paging strategy

On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: > >Interesting. THis needs about two bytes per page for the counter? > >Actually, we found that a single byte per page was sufficient. Pages tended > to be either heavily accessed or rarely accessed. Even in the unusual case > wh

Re: Lucent Orinoco Gold PCCard?

On 04-Dec-00 Warner Losh wrote: > In message <[EMAIL PROTECTED]> Wes Peters writes: >: Dell is selling a Lucent-OEMed card for $139. I don't know if it is a >: Silver or Gold, though. > > http://www.comready.com/dlindwwirlan.html > > is selling what appears to be a lucentOEM'd card for $119.

Re: Lucent Orinoco Gold PCCard?

On Mon, 04 Dec 2000, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Wes Peters writes: > Dell is selling a Lucent-OEMed card for $139. I don't know if it is a > Silver or Gold, though. > > > is selling what appears to be a lucentOEM'd card fo

Re: Lucent Orinoco Gold PCCard?

In message <[EMAIL PROTECTED]> Wes Peters writes: : Dell is selling a Lucent-OEMed card for $139. I don't know if it is a : Silver or Gold, though. http://www.comready.com/dlindwwirlan.html is selling what appears to be a lucentOEM'd card for $119. It has 40-bit WEP, so I don't know what metal

Re: Lucent Orinoco Gold PCCard?

Sascha Luck wrote: > > Thus spoke Warner Losh: > > In message <[EMAIL PROTECTED]> John Baldwin writes: > > : I'm sending this e-mail over a WaveLAN Gold, and from my > > : understanding the Orinoco card is the same card with a different > > : name and a different sticker, so it should work fine.

ATI Rage Mobility and VESA driver

Hi again With regard to my earlier message, I mentioned: > My laptop has an ATI Rage Mobility AGP card in it. According to ATI rech > support, this card is VESA-compliant - but FreeBSD doesn't recognise it > as such. > I searched the mailing list archives, and found >> /usr/src/sys/i386/isa/ve

Re: Lucent Orinoco Gold PCCard?

Thus spoke Warner Losh: > In message <[EMAIL PROTECTED]> John Baldwin writes: > : I'm sending this e-mail over a WaveLAN Gold, and from my > : understanding the Orinoco card is the same card with a different > : name and a different sticker, so it should work fine. > > I'm doing the same thing.