Re: syscons update - stage 2 snopshot 17 May

1999-05-19 Thread Archie Cobbs
Vallo Kallaste writes:
  - History buffer (back-scroll buffer) management functions are moved
  to a new file, schistory.c.
 
 My question is slightly off-topic, but.. is it now possible (or in the 
 future) to choose which key combination to use for back-scroll buffer 
 handling? I personally prefer the Linux way, Shift+PgUpPgDown, no 
 flames please. I can live with current combination but it's the one 
 feature I miss.

Yeah, I'd like that too. It would make it consistent with xterm.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: Fatal Trap 12 (-current kernel w/MFS)

1999-05-19 Thread Sheldon Hearn


On Tue, 18 May 1999 17:04:56 MST, Doug White wrote:

 Fixed it earlier this week or last week in v1.63 (14 May) of
 /sys/ufs/mfs/mfs_vfsops.c. Resup.

I don't think so. Your changes didn't stop the panic for me. What _did_
fix it was Luoqi's change yesterday to kern_conf.c .

John, make sure you have kern_conf.c v1.40 and try again.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: MFS still hosed

1999-05-19 Thread Sheldon Hearn


On Wed, 19 May 1999 12:04:54 +1000, Bruce Evans wrote:

 dumping to dev (0, 131089), offset 524288
 dump device bad
 
 The dev_t changes obfuscated it by printing it in %d format instead of
 as part of the dev number in [0x]%x format.

So you reckon that whatever problem is making it imp[ossible for me to
take dumps, it was present before the dev_t changes and I should be
looking elsewhere?

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Jerry Alexandratos
Jonathan Lemon jle...@americantv.com says:
: 
: Not true.  VM86 is also required to support VESA.  Also, it is used
: for reliable memory detection (which is why I want to make it mandatory).
: No more My Stinkpad only detected 64M, what do I do now??! questions.

Actually, even with VM86, the kernel still doesn't correctly detect the
StinkPad's memory.

--Jerry

name:  Jerry Alexandratos ||  Open-Source software isn't a
phone: 302.521.1018   ||  matter of life or death...
email: jalex...@perspectives.net  ||  ...It's much more important
  ||  than that!


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: MFS still hosed

1999-05-19 Thread Bruce Evans
 dumping to dev (0, 131089), offset 524288
 dump device bad
 
 The dev_t changes obfuscated it by printing it in %d format instead of
 as part of the dev number in [0x]%x format.

So you reckon that whatever problem is making it imp[ossible for me to
take dumps, it was present before the dev_t changes and I should be
looking elsewhere?

dump device bad is printed for d_dump() returning ENXIO, which is
fairly unambiguous.  The new wd driver's d_dump would return ENODEV,
so you must be using the old wd driver.  The old wd_driver's d_dump
only returns ENXIO when the drive doesn't exist or has never been
opened or is not labeled.

Bruce


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: MFS still hosed

1999-05-19 Thread Sheldon Hearn


On Wed, 19 May 1999 17:40:50 +1000, Bruce Evans wrote:

 so you must be using the old wd driver.  The old wd_driver's d_dump
 only returns ENXIO when the drive doesn't exist or has never been
 opened or is not labeled.

I'm using the old wd driver (controller wdc in CURRENT). The disk is
labeled and I assume it's opened by swapon when it's configured as a
swap device.

So I'm at a loss as to why I get ENXIO (I did look at that part of the
source, but thought it best to avoid talking in source terms, since I
don't fully understand the meanings of the errors).

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



MTRR support for AMD K6-2?

1999-05-19 Thread Stephen Hocking-Senior Programmer PGS Tensor Perth

Do we have MTRR support for the AMD K6-2, and how's it done (e.g., if I want 
to allow mtrr support for my Voodoo Banshee)


Stephen
-- 
  The views expressed above are not those of PGS Tensor.

We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true.Robert Wilensky, University of California




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



RE: MTRR support for AMD K6-2?

1999-05-19 Thread Daniel O'Connor

On 19-May-99 Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:
  Do we have MTRR support for the AMD K6-2, and how's it done (e.g., if I want
  to allow mtrr support for my Voodoo Banshee)

I don't think its supported for the K6 (it only happens if you have i686). You
can use it by playing with memcontrol which does ioctl's on /dev/mem

Hmm.. memcontrol is a 'use the source' type of program at the mo, but its
pretty simple :)

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: XFree86 xsetpointer causes silo overflows (Was: Re: Fixed my MAMEd sio problem.)

1999-05-19 Thread David Dawes
On Wed, May 19, 1999 at 01:20:01AM +0930, Matthew Thyer wrote:
I have confirmed that the problem occurs if I just do:

  xsetpointer Joystick
  sleep 1
  xsetpointer pointer

So M.A.M.E. is unrelated to the problem as Bruce Evans would suggest.

So the problem appears to be with XFree86 not closing the joystick
device after I've used it as a pointer with 'xsetpointer'.

The problem is in the joystick driver (or are silo overflows acceptable
while you actually want to use the joystick?).

I am sure I am using xsetpointer correctly as I can use my PC joystick
as a pointing device (once I calibrate it).

I was just using xsetpointer with an incorrectly calibrated joystick
so it moved the pointer to the top left corner of the screen in my
xmame.sh shell script (I'd like to know how to do this another way).

A better way would be a small X client that uses XWarpPointer(3).

David


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



hanging root device to da0s1a

1999-05-19 Thread Jordan K. Hubbard
No offense, but can we use something like assigning in place of the
rather loaded word hanging?  I can just see the user bug reports now;
My root device is hanging!  It says so every time I boot! HELP! :)

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: hanging root device to da0s1a

1999-05-19 Thread Ian Pallfreeman
 No offense, but can we use something like assigning in place of the
 rather loaded word hanging?  I can just see the user bug reports now;
 My root device is hanging!  It says so every time I boot! HELP! :)

Or better still, revert to printing the SCSI probe results on a line break,
rather than half-way through the changing root device message...

Ian.


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



some1 messed with the voxware drivers ?

1999-05-19 Thread Tomer Weller

im -current, lat build world was two days ago, it seems like in the past week
some1 has messed with the Voxware sound drivers, until last week i used a
SB-Pro emulation with Voxware, and it worked fine, now it still works, but
there are some annoying poping sound in the background (works FINE in windows),
while im at it, another thing with Voware, the config doesn't allow the
line : options SBC_IRQ=5 in the kernel configuration, though it works and is
needed (won't compile without it). 

waiting for responds :)

  
Tomer Weller
 s...@i.am
 well...@netvision.net.il
 Drugs are good, and if you do'em 
 pepole think that you're cool, NoFX
 


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



ATA driver problem ?

1999-05-19 Thread Tomer Weller

i've been using the ATA driver for a while now, but since my last word  kernel
i get WARNING: / was not properly dismounted at the end of the dmesg and i
have to fsck /. 
my last world was about 2 dayz ago.

dmesg output for that ATA driver : 
 ad1: WDC AC36400L/09.09M08 ATA-4 disk at ata0 as slave 
ad1: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S
ad1: piomode=4, dmamode=2, udmamode=2
ad1: 16 secs/int, 0 depth queue, DMA mode
 ==
 Tomer Weller
 s...@i.am
 well...@netvision.net.il
 Drugs are good, and if you do'em 
 pepole think that you're cool, NoFX
 


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Luoqi Chen
 Jonathan Lemon jle...@americantv.com says:
 : 
 : Not true.  VM86 is also required to support VESA.  Also, it is used
 : for reliable memory detection (which is why I want to make it mandatory).
 : No more My Stinkpad only detected 64M, what do I do now??! questions.
 
 Actually, even with VM86, the kernel still doesn't correctly detect the
 StinkPad's memory.
 
 --Jerry
 
 name:  Jerry Alexandratos ||  Open-Source software isn't a
 phone: 302.521.1018   ||  matter of life or death...
 email: jalex...@perspectives.net  ||  ...It's much more important
   ||  than that!

It just occurred to me that we might be able to use initial MTRR settings
by BIOS for memory detection (P6 and above, of course). Don't know how
reliable that is.

-lq


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: hanging root device to da0s1a

1999-05-19 Thread Chris Timmons

Heh.  Well, then you would have people asking you what ssigning root
devices means :)

The message seems to get garbled when the CAM probes (being done in the
background) emit their messages.  The c in my changing creates a new
device called cda4 in my log file:

Waiting 5 seconds for SCSI devices to settle
SMP: AP CPU #1 Launched!
cda4 at ahc1 bus 0 target 8 lun 0
da4: SEAGATE ST39102LW 0005 Fixed Direct Access SCSI-2 device 

-Chris 

On Wed, 19 May 1999, Jordan K. Hubbard wrote:

 No offense, but can we use something like assigning in place of the
 rather loaded word hanging?  I can just see the user bug reports now;
 My root device is hanging!  It says so every time I boot! HELP! :)
 
 - Jordan
 
 
 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-current in the body of the message
 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: Sound Strangeness

1999-05-19 Thread Thomas T. Veldhouse
Same settings under Windows and same I have used under Linux [with the 2.2
kernels].

Tom Veldhouse
ve...@visi.com

-Original Message-
From: Doug White dwh...@resnet.uoregon.edu
To: Thomas T. Veldhouse ve...@visi.com
Cc: FreeBSD-Current freebsd-current@FreeBSD.ORG
Date: Tuesday, May 18, 1999 7:10 PM
Subject: Re: Sound Strangeness


This is usually indicitive of a resource problem with your soundcard (bad
IRQ).  Check your settings.

Doug White
Internet:  dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve
http://gladstone.uoregon.edu/~dwhite| www.freebsd.org





To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)

1999-05-19 Thread Matthew Thyer
The problem is that recent versions of MS-DOS (version 7 and above ?
...definitely the DOS that comes with Windows 98 and I think the DOS
with Windows 95 under some circumstances) change various vectors which
destroy FBSDBOOTs ability to work (this is because there is no way to
determine where these vectors used to point and the original addresses
are required for correct operation of either FBSDBOOT or the kernel/
loader).

What I do know is that at least some older versions of MS-DOS do not
do this.

Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22
boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel
and hence the whole system.

Hopefully now that Carlos Tapang has updated FBSDBOOT.EXE for ELF, such
a boot floppy could boot a 3.1, 3.2 or -CURRENT system.

Unfortunately the project cannot guarantee anything when you are booting
from another vendor's operating system (such as MS-DOS) so its a lot
easier to say that FBSDBOOT.EXE has been retired.   Given the number of
different DOSes that exist, that's an entirely understandable policy.

I hope this clears things up (and adds a good summary to the archives).

Carlos C. Tapang wrote:
 
 Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I
 would like to fix it, so please describe exactly what the problem is. What
 do you mean by the need to reboot the system to restore various vectors
 that DOS destroys? Do you mean that prior to executing the FreeBSD kernel
 init routines, DOS does something to the loaded area? I'm sorry I can't find
 any info on this either in the mail threads or in freebsd.org. Probably I'm
 not looking hard enough, but I believe it would be more efficient to just
 ask you.
 
 Carlos C. Tapang
 http://www.genericwindows.com
 
 -Original Message-
 From: Mike Smith m...@smith.net.au
 To: Carlos C. Tapang ctap...@easystreet.com
 Cc: Bob Bishop r...@gid.co.uk; Mike Smith m...@smith.net.au;
 curr...@freebsd.org curr...@freebsd.org
 Date: Sunday, May 16, 1999 7:28 PM
 Subject: Re: FBSDBOOT.EXE
 
  It doesn't work.  Don't use it.  You need to reboot the system to
  restore various vectors that DOS destroys.  Please see the previous
  threads on this topic, especially anything from Robert Nordier.
  
  The most relevant piece I can find from R. Nordier is the following:
  The fbsdboot.exe program should probably be considered obsolete.  It
  should (in theory) be possible to use it to load /boot/loader, which
  can then load the kernel, but there are various reasons this doesn't
  work too well.
 
 These reasons were also expounded, and I did summarise them in another
 message on this thread.
 
  I have not tested the updated program with /boot/loader. /boot/loader does
  not help me because my root directory is in a memory file system, and I can
  not assume that my users will want to reformat their DOS drives or even
  repartition it. So all FreeBSD files are in the DOS file system.
 
 The loader won't help you because you are booting from under DOS, but
 the loader will boot the kernel just fine off a DOS filesystem.
 
 --
 \\  Sometimes you're ahead,   \\  Mike Smith
 \\  sometimes you're behind.  \\  m...@smith.net.au
 \\  The race is long, and in the  \\  msm...@freebsd.org
 \\  end it's only with yourself.  \\  msm...@cdrom.com
 
 
 
 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-current in the body of the message

-- 
/===\
| Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au |
\===/
If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time.
 E. P. Tryon   from Nature Vol.246 Dec.14, 1973


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: XFree86 xsetpointer causes silo overflows (Was: Re: Fixed my MAMEd sio problem.)

1999-05-19 Thread Matthew Thyer
The big problem is that the silo overflows continue after I have
returned the pointer to the mouse (with xsetpointer pointer).

This should close the joystick device shouldn't it ?

If it doesn't then there is a problem with either the X server
or FreeBSD.

Bruce has already indicated that there is a problem with the
FreeBSD joystick driver but he thought it should stop when the
joystick device is closed but I see that the problem continues
until I restart the X server so that would seem to indicate a
problem with the X server.

David Dawes wrote:
 
 On Wed, May 19, 1999 at 01:20:01AM +0930, Matthew Thyer wrote:
 I have confirmed that the problem occurs if I just do:
 
   xsetpointer Joystick
   sleep 1
   xsetpointer pointer
 
 So M.A.M.E. is unrelated to the problem as Bruce Evans would suggest.
 
 So the problem appears to be with XFree86 not closing the joystick
 device after I've used it as a pointer with 'xsetpointer'.
 
 The problem is in the joystick driver (or are silo overflows acceptable
 while you actually want to use the joystick?).
 
 I am sure I am using xsetpointer correctly as I can use my PC joystick
 as a pointing device (once I calibrate it).
 
 I was just using xsetpointer with an incorrectly calibrated joystick
 so it moved the pointer to the top left corner of the screen in my
 xmame.sh shell script (I'd like to know how to do this another way).
 
 A better way would be a small X client that uses XWarpPointer(3).
 
 David
 
 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-current in the body of the message

-- 
/===\
| Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au |
\===/
If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time.
 E. P. Tryon   from Nature Vol.246 Dec.14, 1973


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)

1999-05-19 Thread Maxim Sobolev
Matthew Thyer wrote:

 Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22
 boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel
 and hence the whole system.

Obviously it makes no sense at all to make special DOS boot floppy with older 
DOS
just to run FBSDBOOT - it simply enough to make native FreeBSD boot floppy 
with
/boot/loader and hacked /boot/loader.conf to boot kernel from your hard drive, 
so it
seems that FBSDBOOT now totally useless :(

Sincerely,

Maxim



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: hanging root device to da0s1a

1999-05-19 Thread Mike Smith
 No offense, but can we use something like assigning in place of the
 rather loaded word hanging?  I can just see the user bug reports now;
 My root device is hanging!  It says so every time I boot! HELP! :)

Actually, it says changing, but the 'c' gets printed and then all of 
the interrupt context stuff happens for the outstanding SCSI probes, so 
all that's left to print at the end is 'hanging...'

I'm not sure why it happens like this; try putting a DELAY() just 
before we actually set the root device and see if you can put it off.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Mike Smith
  Jonathan Lemon jle...@americantv.com says:
  : 
  : Not true.  VM86 is also required to support VESA.  Also, it is used
  : for reliable memory detection (which is why I want to make it mandatory).
  : No more My Stinkpad only detected 64M, what do I do now??! questions.
  
  Actually, even with VM86, the kernel still doesn't correctly detect the
  StinkPad's memory.

This is because the BIOS probe results are still ignored. 8(

 It just occurred to me that we might be able to use initial MTRR settings
 by BIOS for memory detection (P6 and above, of course). Don't know how
 reliable that is.

Not at all.  If there's 640k chopped off the end of eg. 128M of 
physical memory, you'd have to use a 64M segment, a 32M segment, a 16M 
segment, an 8M segment, a 4M segment, a 2M segment, a 1M segment, a 
256k segment and a 128k segment to map it accurately.  That's 9 
variable MTRRs, and the P6 only has 8.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: zzz crashing in current OR inthand_remove not removing handlers properly

1999-05-19 Thread Warner Losh
In message 199905171500.jaa22...@mt.sri.com Nate Williams writes:
: The solution is to not poll and to make sure insertion/removal events
: generate an interrupt which can inform the card's interrupt handlers
: that there is no more card.
: 
: (That's one of the main reasons polling is a very bad idea.)

Agreed.  It is far better to figure out which interrupt lines are
connected and how.  I know the curretn code does a horrible job of
figuring these things out...

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: ed0/probe solved (Was: re: ed0/probe problem in 4.0-CURRENT)

1999-05-19 Thread Daniel C. Sobral
Steven Ames wrote:
 
 *sigh* No suprise here. As 90% of these things are this was yet
 another Dumb User Error. I had a base address conflict that kept
 the card from being probed.

So, can we say it was due? ;-)

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

If at first you don't succeed, skydiving is not for you.




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Luoqi Chen
 Not at all.  If there's 640k chopped off the end of eg. 128M of 
 physical memory, you'd have to use a 64M segment, a 32M segment, a 16M 
 segment, an 8M segment, a 4M segment, a 2M segment, a 1M segment, a 
 256k segment and a 128k segment to map it accurately.  That's 9 
 variable MTRRs, and the P6 only has 8.
 
No you don't need that many, fixed MTRRs take precedence over variable MTRRs,
so you can just use one variable segment covering 0-128M and override with
fixed MTRRs in the low memory area.

 -- 
 \\  The mind's the standard   \\  Mike Smith
 \\  of the man.   \\  msm...@freebsd.org
 \\-- Joseph Merrick   \\  msm...@cdrom.com
 
 
 

-lq


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)

1999-05-19 Thread Luoqi Chen
  Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22
  boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel
  and hence the whole system.
 
 Obviously it makes no sense at all to make special DOS boot floppy with older 
 DOS
 just to run FBSDBOOT - it simply enough to make native FreeBSD boot floppy 
 with
 /boot/loader and hacked /boot/loader.conf to boot kernel from your hard 
 drive, so it
 seems that FBSDBOOT now totally useless :(
 
 Sincerely,
 
 Maxim
 
Why can't we make a copy of the vector table and save to file and have
fbsdboot use the table from the file?

-lq


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



WDM maddness

1999-05-19 Thread Chris Silva
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have installed 4.0-CURRENT however, It seems that wdm is still broken.
Here is the tail end of a make install for wdm:

ras# make install  tmp
ras# more tmp
===  Extracting for wdm-1.0
 Checksum OK for wdm/wdm-1.0.tar.gz.
 Checksum OK for wdm/daemon1-HQ-1280x960.jpg.
===   wdm-1.0 depends on shared library: Xpm.4 - found
===   wdm-1.0 depends on shared library: gif.3 - found
===   wdm-1.0 depends on shared library: jpeg.9 - found
===   wdm-1.0 depends on shared library: png.3 - found
===   wdm-1.0 depends on shared library: tiff.4 - found
===   wdm-1.0 depends on shared library: wraster.2 - not found
===Verifying install for wraster.2 in /usr/ports/x11-wm/windowmaker
===   Returning to build of wdm-1.0
Error: shared library wraster.2 does not exist
*** Error code 1

Stop.

Are there plans to fix this?

TIA
Chris
_

RSA Key Fingerprint = 6D0B 5536 7825 3D09 9093 384A 9694 FDB6
RSA Key Fingerprint = 4390 44E5 E316 F2AA A11E 5755 F3F9 D69B
DH/DSS Fingerprint = 089B 0B5C 75C7 A7B4 B050 DD14 2D65 5DD6 E87D 239A

PGP Mail encouraged / preferred - keys available on common keyservers
_




-BEGIN PGP SIGNATURE-
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBN0LuWi1lXdbofSOaEQLZPACfTrtxieMsDmr2eTkApTYFuU+1o/QAoISS
9FxYpIDgRWKqtqLKBb7KBMDu
=nz9q
-END PGP SIGNATURE-



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Jonathan Lemon
On May 05, 1999 at 03:38:05AM -0400, Jerry Alexandratos wrote:
 Jonathan Lemon jle...@americantv.com says:
 : 
 : Not true.  VM86 is also required to support VESA.  Also, it is used
 : for reliable memory detection (which is why I want to make it mandatory).
 : No more My Stinkpad only detected 64M, what do I do now??! questions.
 
 Actually, even with VM86, the kernel still doesn't correctly detect the
 StinkPad's memory.

Hm, if that's so, then it's an implementation bug.  Can you try the
following patch, boot the system with the -v flag, and mail me back
the result of the dmesg output?
--
Jonathan


Index: i386/i386/vm86.c
===
RCS file: /tuna/ncvs/src/sys/i386/i386/vm86.c,v
retrieving revision 1.25
diff -u -r1.25 vm86.c
--- vm86.c  1999/05/12 21:38:45 1.25
+++ vm86.c  1999/05/19 15:47:10
@@ -41,6 +41,7 @@
 #include vm/vm_page.h
 #include vm/vm_param.h
 
+#include sys/reboot.h
 #include sys/user.h
 
 #include machine/md_var.h
@@ -524,6 +525,13 @@
*pte = (1  PAGE_SHIFT) | PG_RW | PG_V;
 
/*
+* use whatever is leftover of the vm86 page layout as a
+* message buffer so we can capture early output.
+*/
+   msgbufinit((vm_offset_t)vm86paddr + sizeof(struct vm86_layout),
+   ctob(3) - sizeof(struct vm86_layout));
+
+   /*
 * get memory map with INT 15:E820
 */
 #define SMAPSIZsizeof(*smap)
@@ -541,6 +549,13 @@
i = vm86_datacall(0x15, vmf, vmc);
if (i || vmf.vmf_eax != SMAP_SIG)
break;
+   if (boothowto  RB_VERBOSE)
+   printf(SMAP type=%02x base=%08x %08x len=%08x %08x\n,
+   smap-type,
+   *(u_int32_t *)((char *)smap-base + 4),
+   (u_int32_t)smap-base,
+   *(u_int32_t *)((char *)smap-length + 4),
+   (u_int32_t)smap-length);
if (smap-type == 0x01  smap-base = highwat) {
*extmem += (smap-length / 1024);
highwat = smap-base + smap-length;
Index: kern/subr_prf.c
===
RCS file: /tuna/ncvs/src/sys/kern/subr_prf.c,v
retrieving revision 1.51
diff -u -r1.51 subr_prf.c
--- subr_prf.c  1998/12/03 04:45:56 1.51
+++ subr_prf.c  1999/03/19 19:10:47
@@ -674,10 +674,24 @@
}
 }
 
+static void
+msgbufcopy(struct msgbuf *oldp)
+{
+   int pos;
+
+   pos = oldp-msg_bufr;
+   while (pos != oldp-msg_bufx) {
+   msglogchar(oldp-msg_ptr[pos], NULL);
+   if (++pos = oldp-msg_size)
+   pos = 0;
+   }
+}
+
 void
 msgbufinit(void *ptr, size_t size)
 {
char *cp;
+   static struct msgbuf *oldp = NULL;
 
cp = (char *)ptr;
msgbufp = (struct msgbuf *) (cp + size - sizeof(*msgbufp));
@@ -687,7 +701,10 @@
msgbufp-msg_size = (char *)msgbufp - cp;
msgbufp-msg_ptr = cp;
}
+   if (msgbufmapped  oldp != msgbufp)
+   msgbufcopy(oldp);
msgbufmapped = 1;
+   oldp = msgbufp;
 }
 
 #include opt_ddb.h


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Mike Smith
  Not at all.  If there's 640k chopped off the end of eg. 128M of 
  physical memory, you'd have to use a 64M segment, a 32M segment, a 16M 
  segment, an 8M segment, a 4M segment, a 2M segment, a 1M segment, a 
  256k segment and a 128k segment to map it accurately.  That's 9 
  variable MTRRs, and the P6 only has 8.
  
 No you don't need that many, fixed MTRRs take precedence over variable MTRRs,
 so you can just use one variable segment covering 0-128M and override with
 fixed MTRRs in the low memory area.

I specifically said 640k chopped off the end, referring to the 
possibly non-aligned _end_ of physical memory.  

The issue here is that the BIOS will tell us how much memory we are 
_allowed_to_use_, which is not always the same as the amount of 
physical memory present in the system.  Some memory may be (is 
sometimes) reserved for use by eg. APM/ACPI.  We fare badly at the 
moment on these systems because we ignore this and use all the memory 
we can find.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)

1999-05-19 Thread Mike Smith
   Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22
   boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel
   and hence the whole system.
  
  Obviously it makes no sense at all to make special DOS boot floppy with 
  older DOS
  just to run FBSDBOOT - it simply enough to make native FreeBSD boot 
  floppy with
  /boot/loader and hacked /boot/loader.conf to boot kernel from your hard 
  drive, so it
  seems that FBSDBOOT now totally useless :(
  
  Sincerely,
  
  Maxim
  
 Why can't we make a copy of the vector table and save to file and have
 fbsdboot use the table from the file?

How do we get this vector table in the first place?

How do we keep it updated?

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Jonathan Lemon
On May 05, 1999 at 12:27:31PM -0700, Mike Smith wrote:
 The issue here is that the BIOS will tell us how much memory we are 
 _allowed_to_use_, which is not always the same as the amount of 
 physical memory present in the system.  Some memory may be (is 
 sometimes) reserved for use by eg. APM/ACPI.  We fare badly at the 
 moment on these systems because we ignore this and use all the memory 
 we can find.

Yup.  That's probably the problem with the Thinkpads; the code patch
I just sent out will dump the ACPI System Address map, so I can figure
out what is happening.  I bet that it declares one memory range for all
the ram, and then overlays a second reserved address on top of it.  Right
now, I don't handle that correctly.  It should be simple to write
some code to aggregate this map and fill in the phys_avail[] structure;
then the entire memory probe in machdep.c can go away.
--
Jonathan


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: syscons update - stage 2 snopshot 17 May

1999-05-19 Thread Gregory Sutter
On Tue, May 18, 1999 at 11:48:40PM -0700, Archie Cobbs wrote:
 Vallo Kallaste writes:
   - History buffer (back-scroll buffer) management functions are moved
   to a new file, schistory.c.
  
  My question is slightly off-topic, but.. is it now possible (or in the 
  future) to choose which key combination to use for back-scroll buffer 
  handling? I personally prefer the Linux way, Shift+PgUpPgDown, no 
  flames please. I can live with current combination but it's the one 
  feature I miss.
 
 Yeah, I'd like that too. It would make it consistent with xterm.

I think I've tried to find a way to make the older syscons do that on
three separate occasions, each time getting interrupted by something of
higher priority.  Sure would be nice to have an easily configurable
buffer-scroll sequence... defaulting to shift-pg{up,down} of course. :)

Greg
-- 
Gregory S. Sutter Madness takes its toll.  
mailto:gsut...@pobox.com  Please have exact change.
http://www.pobox.com/~gsutter/
PGP DSS public key 0x40AE3052


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)

1999-05-19 Thread Robert Nordier
Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22
boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel
and hence the whole system.
  
   Obviously it makes no sense at all to make special DOS boot floppy with 
   old
 er DOS
   just to run FBSDBOOT - it simply enough to make native FreeBSD boot 
   flopp
 y with
   /boot/loader and hacked /boot/loader.conf to boot kernel from your hard 
   dri
 ve, so it
   seems that FBSDBOOT now totally useless :(
  
   Sincerely,
  
   Maxim
  
  Why can't we make a copy of the vector table and save to file and have
  fbsdboot use the table from the file?
 
 How do we get this vector table in the first place?
 
 How do we keep it updated?

The flags and values in the BIOS data area would not necessarily
be at their default values, so restoring the vectors might itself
crash the BIOS (because it's reconfigured itself for the present
vectors/drivers, not the default ones).

Some hardware (eg. popular SCSI controllers) also configures itself
differently when it finds it's running on DOS/Windows.  This kind
of thing in any scenario in which we start DOS then kill it would
have the potential to seriously confuse matters.

Incidentally (to correct a point made in an earlier post) *all*
versions of DOS since 1.x have changed interrupt vectors.  This is
not a DOS 7+ phenomenon.  The reason FBSDBOOT.EXE is deprecated at
this stage is that, in the future, VM86 will be increasingly relied
on by FreeBSD.  And FBSDBOOT.EXE has *never* worked reliably in a
VM86 context.

-- 
Robert Nordier


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



X11 aout compat pack

1999-05-19 Thread Marc van Woerkom
May I suggest to add the XFree86 aout libraries to src/compat, or to 
add them as port - for easy update via make.

Background: 
Netscape 4.6 installation complained that I need X11 aout libs,
so I had to download xlib.tgz (3.3M) just for the aout libs (0.7M).

Or am I missing some opportunity elsewhere, to get these libs
reinstalled on my system?


Regards,
Marc




 


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: MTRR support for AMD K6-2?

1999-05-19 Thread Mike Smith
 
 Do we have MTRR support for the AMD K6-2, and how's it done (e.g., if I want 
 to allow mtrr support for my Voodoo Banshee)

It's being worked on.  The K6 is a problematic device, as it only 
supports two memory ranges, as opposed to the eight the P6 does.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  msm...@freebsd.org
\\-- Joseph Merrick   \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)

1999-05-19 Thread Carlos C. Tapang
Thanks to all who pitched in their input to this issue. Most users of my
system are running Windows and don't want to have to reformat or repartition
their hard disk. So I am stuck with the DOS file system. I think the best
solution is to have my users use a FreeBSD boot floppy. The floppy will have
/boot/loader which I will point to the DOS-formatted hard disk in which the
kernel resides.

The flags and values in the BIOS data area would not necessarily
be at their default values, so restoring the vectors might itself
crash the BIOS (because it's reconfigured itself for the present
vectors/drivers, not the default ones).

Some hardware (eg. popular SCSI controllers) also configures itself
differently when it finds it's running on DOS/Windows.  This kind
of thing in any scenario in which we start DOS then kill it would
have the potential to seriously confuse matters.

Incidentally (to correct a point made in an earlier post) *all*
versions of DOS since 1.x have changed interrupt vectors.  This is
not a DOS 7+ phenomenon.  The reason FBSDBOOT.EXE is deprecated at
this stage is that, in the future, VM86 will be increasingly relied
on by FreeBSD.  And FBSDBOOT.EXE has *never* worked reliably in a
VM86 context.

--
Robert Nordier


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: pccard status?

1999-05-19 Thread Warner Losh
The pccard code kinda sorta works on some systems, but not on others.
The support for sio and fdc no longer works on any system.  I'm
working on a rewrite in the new bus framework.  I have pcic
interrupting now, and hope to have I/O and memory mapping working
again to allow pccards to work again shortly.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: pccard status?

1999-05-19 Thread Warner Losh
In message pine.bsf.4.05.9905171457340.509-100...@herring.nlsystems.com Doug 
Rabson writes:
: The sio support will need to wait until Warner Losh commits his changes to
: clean up the pccard driver.

I'm hoping to have this done before I take off for Memorial Day
weekend.

Warner


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: hanging root device to da0s1a

1999-05-19 Thread Justin T. Gibbs
In article 199905191637.jaa03...@dingo.cdrom.com you wrote:
 I'm not sure why it happens like this; try putting a DELAY() just 
 before we actually set the root device and see if you can put it off.

Why not just spl() protect that printf call so that its output is
dumped contiguously into the console buffer?

--
Justin


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



calcru and upages

1999-05-19 Thread Dmitrij Tejblum
calcru() access p_stats, which is in upages. Therefore, as I understand, 
it should not be called on a swapped out process. Neither calcru() nor 
its callers seem to ensure this. At least the call in procfs_dostatus()
may happen on a swapped out process. (It test for P_INMEM for another 
access to p_stats several lines before :-/)

Dima




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)

1999-05-19 Thread Greg Childers
Sounds like you want something like a FreeBSD version of DOS Linux.  See
http://www.tux.org/pub/people/kent-robotti/index.html.  How do they
overcome this problem?

Greg

At 02:45 PM 5/19/99 -0700, Carlos C. Tapang wrote:
Thanks to all who pitched in their input to this issue. Most users of my
system are running Windows and don't want to have to reformat or repartition
their hard disk. So I am stuck with the DOS file system. I think the best
solution is to have my users use a FreeBSD boot floppy. The floppy will have
/boot/loader which I will point to the DOS-formatted hard disk in which the
kernel resides.

The flags and values in the BIOS data area would not necessarily
be at their default values, so restoring the vectors might itself
crash the BIOS (because it's reconfigured itself for the present
vectors/drivers, not the default ones).

Some hardware (eg. popular SCSI controllers) also configures itself
differently when it finds it's running on DOS/Windows.  This kind
of thing in any scenario in which we start DOS then kill it would
have the potential to seriously confuse matters.

Incidentally (to correct a point made in an earlier post) *all*
versions of DOS since 1.x have changed interrupt vectors.  This is
not a DOS 7+ phenomenon.  The reason FBSDBOOT.EXE is deprecated at
this stage is that, in the future, VM86 will be increasingly relied
on by FreeBSD.  And FBSDBOOT.EXE has *never* worked reliably in a
VM86 context.

--
Robert Nordier


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



Re: FBSDBOOT.EXE

1999-05-19 Thread Brian Feldman
On Wed, 19 May 1999, Luoqi Chen wrote:

  Jonathan Lemon jle...@americantv.com says:
  : 
  : Not true.  VM86 is also required to support VESA.  Also, it is used
  : for reliable memory detection (which is why I want to make it mandatory).
  : No more My Stinkpad only detected 64M, what do I do now??! questions.
  
  Actually, even with VM86, the kernel still doesn't correctly detect the
  StinkPad's memory.
  
  --Jerry
  
  name:  Jerry Alexandratos ||  Open-Source software isn't a
  phone: 302.521.1018   ||  matter of life or death...
  email: jalex...@perspectives.net  ||  ...It's much more important
||  than that!
 
 It just occurred to me that we might be able to use initial MTRR settings
 by BIOS for memory detection (P6 and above, of course). Don't know how
 reliable that is.

And K6-family processors with newer BIOSes are usually write allocate-enabled
and that can be used too.

 
 -lq
 
 
 To Unsubscribe: send mail to majord...@freebsd.org
 with unsubscribe freebsd-current in the body of the message
 

 Brian Feldman_ __ ___   ___ ___ ___  
 gr...@unixhelp.org_ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!  _ __ | _ \ _ \ |) |
 http://www.freebsd.org   _ |___)___/___/ 



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



mount_mfs panics (Was: ``65536-byte tape record bigger than suplied buffer'')

1999-05-19 Thread Joel Ray Holveck
 Well, I'll recheck mine...
 It'd be interesting to see if you (and others) can reproduce this too.

Using a May 17 15:00 CDT -current, I also have gotten a panic mounting
MFS.  The line from fstab is:

/dev/da0s2b /tmpmfs rw  0   0

I commented it out, and things work fine.  Since no dumpdev was
configured yet, I don't have a dump, but can try to produce one now if
somebody would find a backtrace useful.

Happy hacking,
joelh

-- 
Joel Ray Holveck - jo...@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message



SGI to release XFS under Open Source license

1999-05-19 Thread Stephen Hocking-Senior Programmer PGS Tensor Perth

Some of you may already know this - I'm wondering about the pain involved in 
fitting it to our architecture. Journaling. Hmmm.


http://www.news.com/News/Item/0,4,36807,00.html?owv
-- 
  The views expressed above are not those of PGS Tensor.

We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true.Robert Wilensky, University of California




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message