Re: syscons update - stage 2 snopshot 17 May
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)
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
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
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
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
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?
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?
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.)
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
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
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 ?
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 ?
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
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
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
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)
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.)
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)
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
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
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
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)
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
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)
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
-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
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
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)
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
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
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)
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
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?
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)
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?
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?
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
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
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)
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
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'')
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
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
