> For those want to fix ATA code, I have another problem
> with CURRENT. I have a Tyan Tiger 230T which is based
> on VIA Apollo 133T, south bridge is VIA 686B.
> On second IDE, I have a Mitsubishi 52X cdrom as master,
> and a Sony 16X CD R/W as slave, when startup, kernel
> is always stuck at "M
> Good year everybody
>
> Luigi, I converted your patch to CURRENT, there were only
> minor changes to do and it seems to work !
>
> sis0: port 0x2000-0x20ff mem
> 0xec005000-0xec005fff irq 1$
> at device 4.0 on pci0
> sis0: Ethernet address: 00:00:e2:94:66:99
> miibus0: on sis0
> ukphy0: on
> Hi,
>
> > > Dec 23 15:17:03 kernel: sis0: Ethernet address: ff:ff:ff:ff:ff:ff
> > > Dec 23 15:17:03 kernel: sis0: MII without any PHY!
> > > Dec 23 15:17:03 kernel: device_probe_and_attach: sis0 attach
> returned 6
> > > Dec 23 15:17:03 kernel: sis0: port
> 0x2000-0x20ff mem
> > > 0xec005
> #7 0xc017a726 in vput (vp=0xc8710840) at vnode_if.h:794
> #8 0xc01aee87 in ffs_sync (mp=0xc0ade800, waitfor=2, cred=0xc0721700,
> p=0xc026d5e0) at ../../ufs/ffs/ffs_vfsops.c:955
Change the vput(vp) call at line 955 of ffs_vfsops.c back to two separate
calls (see previous revision):
Because there is no write-only hardware page protection on ia32,
a write-only page fault is handled just like a read/write one.
But the mi vm layer distinguishes between the write-only and the
read/write protections, so if the fault takes place in a write-only
region, the vm layer would think that
> In <[EMAIL PROTECTED]>, Luoqi Chen wrote:
> > It is not the loader's job to detect the underlying
> > hardware configuration.
>
> I disagree. I would like to tell which machine I am booting on to
> choose an appropriate kernel.
>
Eventually (it may t
> >> Background:
>
> >> Ideally struct buf should have had a real OO like operations vector
> >> like vnodes have it, and struct bioops is the first step towards that.
> >>
> >struct buf will eventually become merely an iocmd structure, so why do
> >we want to complicate things here?
>
> No, st
> Background:
>
> The bioops operation vector is a list of OO-like operations which can
> be performed on struct buf. They are used by the softupdates code
> to handle dependencies.
>
> Ideally struct buf should have had a real OO like operations vector
> like vnodes have it, and struct bioops
> > a larger issue. It is not the loader's job to detect the underlying
> > hardware configuration.
>
> Actually, in a broad fashion, it _is_. This is why the loader
> understands PCI and PnP, for example.
>
Why do we want to do that? Are we going to offload device probe routines to
the loader
> Given the way VMware works, I'd have nothing against making it a FICL
> words, except...
>
> ...VMware is a port. For some reason, I dislike the idea of having
> support targetted at exclusively one specific port. Though we have
> features added specifically to deal with certain ports, they wer
> This is the third time this happened to a 4.0-STABLE host of ours.
>
> The problem starts with havnig a number of processes which are unable to
> be killed. So we want to reboot the box.
>
> All goes well, bufdaemon and syncer stop normally.
>
> Then it gets to
>
> syncing disks
> done.
>
> As for setting registers ti specific values... huh? Why does this
> matter? Can you explain exactly what your code does and how?
>
VMware intercepts the inb/outb instruction to port 0x5658 when the eax
register is set to a magic value, otherwise it would be handled as any
other ports.
-lq
T
> We have inb and outb. Can't vmware be written in Forth? If inl cannot be
> replaced with inb, I'd rather add inl than vmware.
>
But we can't set registers to specific values before inb/outb, which also
means our inb/outb are quite useless in making BIOS calls.
> IMHO, it would be better to add
Would anyone object if I add a ficl word to detect whether we're booting
from a vmware virtual machine? I find it extremely useful when I'm running
FreeBSD as a guest under NT. Because it is a dual cpu box, I can't use a
single kernel to boot both directly or inside the virtual machine. With this
> Hi folks,
>
> Shouldn't I be able to show the current tuneables for a given filesystem?
>
> # tunefs -p /usr
> tunefs: cannot work on read-write mounted file system
>
> This is on a recent CURRENT.
>
> Ciao,
> Sheldon.
>
You were supposed to use a raw device for a mounted fs, but that no lo
> Kernel:
> ===
> FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Feb
> 14 23:00:42 GMT 2000
> [EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
>
> Background:
>
> 3 users. One with X running , and two users running breakwidgets
> , which make use of a
> I have tried doing this on -current but it doesnt make any difference. I have
> also removed every non-essential item out of the kernel.
> I am using boot -dv with "options DIAGNOSTIC" in the kernel and it doesnt tell
> me what the PnP probe is hanging on.
>
> Any other suggestions?
>
I don't
> I think it is difficult to implement such conversion because:
>
> - Not only bus space stuff also resource manager stuff need to
> perform such conversion.
Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be
opaque types. Resource manager needs not know the implementation
> > Why have two files bus_at386.h and bus_pc98.h? I386_BUS_PIO_IND should be
> > able to live with I386_BUS_PIO and I386_BUS_MEMIO happily together.
>
> Because they are different in the type of bus_space_tag_t from each
> other. It is the u_long in PC/AT and the structure in PC-98. For
> exam
> Do you have any comment anout the patch? If there isn't any big
> problem, I hope to commit it to current.
>
> Thank you.
>
>
> I wrote:
> > Do you remember this topic? I have revised the indirection support
> > patch. What I have changed are:
> > - to make diff files more readable
> >
> In an effort to chase down a libc_r bug, I compiled libc_r with CFLAGS=-g
> (and later CFLAGS=-g3), but ran into linker problems as a result.
>
> blitz:~> gcc poll.c -pthread
> /usr/lib/libc_r.so: undefined reference to `__sigisempty'
>
> Even the simplest of C programs will get this linker er
> Hi,
> I am using the FreeBSD-4.0 snapshot from 3rd January 2000. This version
> used to panic when configured as an SMP but with less CPUs than there are
> actually in the machine (I had 4 processors but only wanted to use 1). Someone
> mailed me patches for fixing this problem (attached
> Hi all,
>
> on two 4.0-CURRENT boxes (cvsuped today) I got the following response when
> trying to rlogin to it:
>
> # rlogin indiana
> assword:
>
> A typed-in password is echoed in cleartext.
>
> The only thing that helps is to comment out the second-last line in
> /etc/pam.conf:
>
> # ot
This discussion is not going anywhere. Why can't everyone calm down and
find a comprise? Here's my proposal:
1. leave the the code and config option in the source tree for now
2. remove all traces of wd in documentation/GENERIC/LINT/MAKEDEV
that is, anyone who wants to use the wd driver still ca
> >I'd like to add something about the last buffer wouldn't sync. This occurs
> >when a shutdown syscall is issued when the syncer process is asleep waiting
> >for a buffer write to complete. The write will never complete, because the
> >syncer won't be given a chance to run again, and the buffer
> I've seen this exact same thing before too. In fact it was two rather
> annoying things, one being a single solitary last buffer that wouldn't
> sync and thus left the whole fs marked dirty, and then fsck would check
> it, see it was fine, but mount wouldn't recognize that it was clean.
>
> 'C
Since sometime last month, rc5des failed to start from my rc.local. I did
a little investigation and it turned out that rc5des was started but later
terminated by a SIGHUP. During its brief lifetime, /dev/console was its
control terminal. Does anyone know what was going on?
-lq
To Unsubscribe:
> The latest port of wine references PR 14652
> for patches to make -current work.
> some of these ptches are however in areas I don't understand.
> In particular signals, register contexts, etc.
This refers to validity of segment registers fs/gs in sigcontext.
Under -stable both of them are unus
> Here is the patch I've been working on (before I 1st got BDE's reply).
> The changes are mostly from OpenBSD + style changes for the way we do
> things. Can you also test this one?
>
>
> Index: bus.h
> ===
> RCS file: /home/ncvs/
> Hi.
>
> I've been experiencing problems with my machine crashing when in X,
> when idle overnight.
>
> Normally it panics with XF86_S3. Today however the machine returned
> something a little different, which I haven't seen before.
> I hope this helps someone.
>
> The machine worlds with no p
> Luoqi Chen wrote:
> >
> > I compiled a kernel for -stable, but was unable to boot from it. Does anyone
> > know if there is any incompatibility between the -current boot loader and a
> > -stable kernel?
>
> AFAIK, there is no difference between them (the loade
> Luoqi Chen wrote:
> >
> > I've ported it to -stable, but I don't have a machine to test it, please
> > if you could. The code is in http://www.freebsd.org/~luoqi/aic/stable,
> > apply patch files.diff, copy aic_isa.c to i386/isa, the rest goes to dev/aic
> I also tried to experiment with the aic driver (and also failed, little
> similar to Ilya's problems)
>
Could you download the new set of files and see if it helps?
> as devices. What puzzles me is why the probe at the aic0 wants to look
> at bus 0. Shouldn't that be bus 1? Or should I add a s
> cd0 at aic0 bus 0 target 0 lun 0
> cd0: Removable Worm SCSI-2 device
> cd0: 3.300MB/s transfers
> cd0: cd present [1 x 77747 byte records]
^
These numbers don't look right...
> but, unfortunately, scsi probe precedure seems to be relatively
> unstable. _sometimes_ (o
> On Mon, 18 Oct 1999, Chris Dillon wrote:
>
> > Should this apply cleanly to -stable? If so, I'll give it a shot when
> > I get home.
>
> I'll answer my own question (which, oddly enough, still hasn't made it
> to the list after about two hours). I forgot about newbus. It
> doesn't work, of
> i've tried new "camfied" aic driver today and failed. here is a brief
> report.
>
> my configuration:
>
> Chaintech 6BTM mainboard with Celeron 416A processor and 128 Mb of memory
> Adaptec AIC-6360 SCSI controller (port 0x340 irq 9), irq 9 is reserved for
> Legacy/ISA card in bios setup
> Pin
After the recent signal related changes, the pre-cam kernel I saved a long
time ago no longer works with (even statically compiled) user applications,
which meant I had no way to access my files on an old disk hanging off an
aic6360 card. So I decided to bite the bullet and camify the aic driver
m
> Luoqi Chen wrote:
>
> > > o restoring %gs is now handled in the proper sigreturn.
> >
> > Restoration of %gs should not be in the kernel because it comes from
> > user application and maybe invalid, if you restore it inside the kernel
> > it could b
> Hi,
>
> It seems that the trampoline code got too long and resulted in the
> coredumps people reported. The following patch solves that. it basicly
> works as follows:
>
> o Simplify the trampoline code so that it doesn't have to distinguish
>between an old- and new sigframe and also rest
> Hi,
>
> It seems that the trampoline code got too long and resulted in the
> coredumps people reported. The following patch solves that. it basicly
> works as follows:
>
> o Simplify the trampoline code so that it doesn't have to distinguish
>between an old- and new sigframe and also rest
> Kenneth Culver writes:
>
> >I reinstalled -current today, and for some reason there is an extra device
> >generating interrupts. When I do a systat -vm 1 I find that there is a
> >device called rtc at irq8 generating 128 interrupts. What is it? I didn't
> >configure it, and it wasn't there befo
> >TSC is initialized to 0 at hardware reset, which should happen to all CPUs
> >at the same time (invalid assumption?), in another words, all TSCs should be
> >automatically synchronized.
>
> They are not. The PLL is local to each cpu and every single
> clock-stop/start event has then inching a
> If you have a PIIX4 based SMP system and run current, could you
> please try out this patch:
>
> http://phk.freebsd.dk/piix/
>
> I'm very interested in hearing if there are any measurable difference
> apart from clock granularity being 3 times better.
>
> --
> Poul-Henning Kamp
> > There have been discussions about the xdm entry /etc/ttys does not guarantee
> > the X server being started on the particular vty. So I wrote a shell script
> > to explicitly tell xdm to start X server on a specific vty.
>
> I *like* it. I think you should share it with the XFree86 folks, an
There have been discussions about the xdm entry /etc/ttys does not guarantee
the X server being started on the particular vty. So I wrote a shell script
to explicitly tell xdm to start X server on a specific vty. It's been working
great. I'd like to share it with you, maybe we could include it in
> That's exactly what I have. This is just so weird. I am now reading the
> debug register chapter of intel's manual, it is virtually impossible to
> pinpoint the location by single-stepping through the code...
>
The debug register trick worked, and the discovery was quite unexpected:
because the
> > I too have problems with my on board CS4236 sound chip and it is of a very
> > strange nature: in the new isa pnp code, function isa_assign_resources()
> > mysteriously overwrites the isa_device structure and sets logical_id to 0,
> > and as a result subsequent probe would not recognize it any
> Could you send the output of dmesg. It could be that your BIOS has
> rearranged the irq settings and has put another card on that IRQ. Is the
> sound card PNP? If not, could you check that the card's IRQ is marked as
> legacy in the BIOS?
>
> Nick
>
> > My sound card used to work, and with a
After the import of ncurses 5.0 (beta?), I noticed strange behavior of clear
on my xterm. I tracked it down to an API change of tgetstr(), here is the
new code:
char *tgetstr(NCURSES_CONST char *id, char **area GCC_UNUSED)
{
int i;
T((T_CALLED("tgetstr(%s,%p)"), id,
> Ian Whalley <[EMAIL PROTECTED]> wrote:
> >My card is identified as <3Com 3c905B-TX Fast Etherlink XL>.
>
> FWIW, I'm running a kernel about 30 hours old with a <3Com 3c905-TX
> Fast Etherlink XL> and I'm not seeing this problem.
>
> At a quick quess, something in the miibus support broke the 3
> Bruce Evans wrote:
> > >"make buildworld" completes without a problem.
> > >
> > >"make -j 4 buildworld" gives:
> >
> > libncurses now has lots of internal utilities. Apparently the
> > dependencies for them are incomplete. The utilities are are also
> > built at the wrong time and break cros
> I'm generating a core dump. Please note that as tara is my test machine, I use
> "INVARIANT" & "INVARIANT_SUPPORT". Should I remove them ?
>
> It seems that from my reading of the code, the panic would not had happened
> without INVARIANT.
>
It is these options that caused the panic, you eith
> I realise that will stop the panic from looking at the source code, but
> surely it's just covering up the problem and waiting for it to happen
> later?
>
I'm pretty it's caused by the INVARIANTS option, similar incidents have been
reported many times before. The problem with INVARIANTS is that
> I've been getting this panic when I've installed new kernels the last
> couple of times. The panic is occuring when I have freshly booted the
> system with a new kernel and logged on for the first time. It appears
> to occur at the point at which I start fetchmail in my profile, FWIW.
>
Get r
> do away with the lock prefix on non-SMP machines. I don't know if the
> SMP variable is accessible from within the i386/include/atomic.h header
> file, though.
>
SMP is globally defined (in opt_global.h).
-lq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe free
> We don't need the lock prefix for the current SMP implementation. A lock
> prefix would be needed in a multithreaded implementation but should not be
> added unless the kernel is an SMP kernel otherwise UP performance would
> suffer.
>
> --
> Doug Rabson Mail: [EMAIL
> I have added more debugging messages, and the crash appears to be inside
> mp_start(). I don't have a log because this is too early in the boot
> to get the messages saved anywhere, and they go by too quickly to
> write it down. The evidence that this is an SMP problem is simple -
> with 2 cpu
> > Do you mean messages like these?
> > FreeBSD/SMP: Multiprocessor motherboard
> > cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000
> > cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000
> > io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0
> > By
> Hi,
>
> I've been trying to install 19990604-CURRENT on a couple of SC450NX
> boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's
> falls over very quickly (I think while it's setting up the APIC
> stuff, or very shortly after - the messages about APIC bus ids appear
> on the scre
> > 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 sim
> 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, an
> Jonathan Lemon 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 st
> Hi,
>
> I have been getting a panic lately with every -current kernel that I
> have built for the past week or so (-current cvsupped daily). Even the
> GENERIC kernel panics. It is occuring when the mount for a /tmp mfs
> filesystem is attempted. If I boot an old kernel from 5/11 or remove
>
> On Mon, May 17, 1999 at 01:02:29PM -0400, Luoqi Chen wrote:
> > Are you sure you have the latest -current? I committed a fix Friday night.
>
> I'm quite positive, because I experimented with a fresh -current/kernel
> yesterday. Changing NUMCDEV from 256 to 255 in kern_c
> With todays -current, mounting /tmp using
> swap /tmp mfs rw,nosuid,nodev,-s=32768 0 0
> yields a
>
Are you sure you have the latest -current? I committed a fix Friday night.
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> Well, this is just a quick note to anyone more knowledgable than me.
>
> screen 3.7.6 panics a current kernel.
>
>
> --
> [gjvc] "We're not laughing at you; we're laughing with you."
> "But I'm not laughing."
>
I committed a fix yesterday afternoon, c
> > This was due to a kludge in mfs implementation. Try change NUMCDEV in
> > kern_conf.c to 255.
>
> Are you saying that there is a bug in the mfs implementation and a fix
> will be commited soon? (and change NUMCDEV until then)
>
> Or are you saying, the mfs implementation is now considered co
> It seems that screen was trying to flush the master pty, before the slave
> tty was even open. We were lucky that this didn't crash our machines before
> the dev_t changes, it only caused the console to be flushed instead. But
> after the dev_t changes, it is fatal. Try this fix (band-aid only, b
It seems that screen was trying to flush the master pty, before the slave
tty was even open. We were lucky that this didn't crash our machines before
the dev_t changes, it only caused the console to be flushed instead. But
after the dev_t changes, it is fatal. Try this fix (band-aid only, better
fi
> This also fixes the panic that I got with mfs_mount:
> (with "options MFS" in the config file, 'cvsup'ed at May 13th 19:43 UTC)
>
> Fatal trap 12: page fault while inkernel mode
> fault virtual address = 0x9d19fd34
> fault code= supervisor read, page not present
> instruction pointer
> After make world this morning I received this panic :
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x14
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc0155ca4
> stack pointer = 0x10:0xc6864d64
> frame pointer = 0x10:0xc6864d78
> co
> Hi,
> Has anyone tried having APM and SMP in the same kernel? It panic()'s mine :)
>
> Basically the machine panics a few seconds after I do 'apmconf -e'. apm seems
> to return normal values though.
>
> I've attached a sample output from APM, dmesg and my kernel config.
>
> I get a trap 12: pa
> Yeah, well, it didn't look likely to me either but.. :-/
>
> Here is part of nm kernel.debug | sort
> ...
> c0208a30 T Xnmi
> c0208a3c T Xbpt
> c0208a50 T Xofl
> ...
>
Did you actually boot from kernel.debug? If not, use the kernel you booted
from, the symbols should still be there.
> I'll giv
> Hi,
> Has anyone tried having APM and SMP in the same kernel? It panic()'s mine :)
>
> Basically the machine panics a few seconds after I do 'apmconf -e'. apm seems
> to return normal values though.
>
> I've attached a sample output from APM, dmesg and my kernel config.
>
> I get a trap 12: pa
> In message <199904272349.taa28...@lor.watermarkgroup.com>, Luoqi Chen writes:
> >I'm about to commit the SMP vmspace sharing patch (the %fs approach). All
> >kernel modules will need to be recompiled. Recompilation is not neccessary
> >for user land applications
I'm about to commit the SMP vmspace sharing patch (the %fs approach). All
kernel modules will need to be recompiled. Recompilation is not neccessary
for user land applications including ps, libkvm and friends.
In this %fs approach, per-processor private pages are no longer mapped at
identical virt
> It works here fine, but I can't pretend that I understand it. :-) Will you
> commit it?
>
> Cheers,
> -Peter
>
There's some problems with one I posted (e.g. can't deal with cases where
a keyword is followed immediately by a number like irq1), I'll commit a
better one.
-lq
To Unsubscribe: se
> > On Sun, Apr 25, 1999, a.leidin...@wurzelausix.cs.uni-sb.de wrote:
> > > Hi,
> > >=20
> > > # ident LINT
> > > LINT:
> > > $Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $
> > >=20
> > > with:
> > > option NO_F00F_HACK
> > >=20
> > > # config WORK
> > > WORK:15: unknown option "NO_F0F_HACK
> Steve Kargl wrote:
> >
> > > > That's a little foolish since we've still not found all the egcs
> > > > optimizer bugs and whatnot; didn't you guys see the one Luigi found
> > > > the other day for ftpd? Now *that* had to be some obscure debugging
> > > > work! :-)
> > >
> > > Clearly, that goe
An egcs optimizer bug caused incorrect tcp checksum recalculation in libalias
for the rewritten PORT command packet and the server subsequently discard the
packet.
The following piece of C code (from TcpChecksum() in alias_util.c)
u_short *ptr;
int sum, oddbyte;
oddbyte =
> This is not happening for the maddr stuff.
> I suspect this would do better:
>
> if (portsize > 0)
> isa_set_portsize(dev, portsize);
> if (dvp->id_iobase >= 0)
> isa_set_port(dev,
> Hi,
>
> I ave found one more thing that seems to be broken. I have used the
> irq "autodetect" feature of the ed(4) for a long time, but it seems
> that the newbus compatability shim is not doing the right thing
> with it. My kernel config file have a line like this:
>
> device ed0 at isa? por
> Hey!
>
> I've add UNICODE support to the Joliet patch.
>
> It contains few charsets now, but to add other charsets is very easy.
> Currently, iso8859-1 and euc-jp is included.
>
> Mixture of Joliet/RockRidge Extension is also available, however untested.
>
Cool! I think NTFS and VFATFS could
Do you have an empty /usr/X11R6/include? The Makefile assumes you have the
header files if the directory /usr/X11R6/include is present and tries to
build the X version of doscmd. This assumption may not be true though. I'll
change the Makefile to check for /usr/X11R6/include/X11/X.h instead. By the
> > Here's async log output from alias enabled ppp, while ftp was retransmitting
> > the PORT command packet:
> >
> > Async: 7e 3d c0 00 00 9d 21 45 00 00 38 13 42 00 00 ff
> > ^^
> > Async: 01 e3 a7 cf ca 49 aa d0 17 db 4e 03 03 a2 f8 00
^^
> trying different configurations i have encountered the following
>
> 1. ftp in passive mode (pftp or ftp with -p options) DOES NOT hang;
> 2. ncftp3 from ports DOES NOT hang;
> 3. netscape communicator 4 DOES NOT hang.
>
> so it seems that the problem is in native FreeBSD's ftp or a library
> (
> The kernel-configfile and dmesg-output is available from:
> http://www.attic.ch/fuchur_kernel.html
>
> panic at: generic_bcopy+0x1arepe movsl (%esi), %es:(%edi)
>
> db> trace
> generic_bcopy(c02cc380,c7bb9b1f,0,a,0) at generic_bcopy+0x1a
> sccnputc(cff,1,c7bb9b80,c016c066) at sccnputc+0x18
For threaded applications to work correctly, we need a thread-safe version of
libgcc. It is straight forward to build: define _PTHREADS in CFLAGS. We can
have both versions just like libc and libc_r, and use the thread-safe version
when linking threaded applications. If no one objects, I will add i
There're a couple of places in swtch.s where code looks like this,
#ifdef VM86
btrl%esi, _private_tss
je 3f
...
3:
#endif
The conditional jump statement doesn't seem right, according to manual,
btrl instruction modifies CF flag but not Z, so the jump should be jae
There're a couple places in swtch.s with code like,
#ifdef VM86
btrl%esi, _private_tss
je 3f
...
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> The question is whether there is a way to do the autogrow function if
> the map lock is already held.
>
Allow lock recurse?
-lq
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> Luoqi Chen said:
> > >
> > Do you still have that piece of code? Does it handle the case involves more
> > than one process? For example, process 1 mmaps file B and reads file A into
> > the mmapped region, while process 2 mmaps file A and reads file B, this
> Luoqi Chen said:
> > >
> > This seems to be the good old vnode deadlock during vm_fault() that has been
> > reported a couple of times, and there's still no satisfactory solution to
> > it:
> > fgrep does something like this: (don't ask me w
> On Mon, 22 Feb 1999, Alexander N. Kabaev wrote:
>
> > The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE
> > as of today) to lookup. Shortly after this script is started, all disk
> > activity
> >
> > stops and any attempt to create new process causes system to freese. Wh
> I've gone through these patches and I can see that they are really needed
> for SMP where address spaces are shared.
>
> There are details I didn't get, such as where is the per-processor
> pde pointed, (i.e. where is the per processor KVM range) and is there a
> single page table for each proce
> who's looked at this.
Tor Egge, he has been very helpful during the development of the code. The
pmap change was a result of discussions with him.
> It looks to me that this is serious stuff
> spliting the pmap out of the vmspace structure is a big change.
> caertainly a logical move but req
> Hi,
> I downloaded Star Office 5 and only THEN realised that the code for doing
> linux thread
> emulation is #ifndef SMP :) Still, after downloading 70 meg over a 56k modem
> and paying
> 19c/meg I was gonna try the sucker regardless.. And well, it works!
>
> The install hung at the end, afte
Initially I though /etc/defaults/rc.conf stored the default settings and then
we could override some of the settings in /etc/rc.conf, but after a close
look at how they are used in /etc/rc*, I am confused:
if [ -f /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
> Hi.
>
> I saw that my 4-CURRENT box from 8 February dropped to ddb
> after my last make world. I rebuilt world today, and the
> same problem is occuring. These problems started occuring
> after Matt Dillon's changes to the VM system.
>
> What is worrying/troubling is that in single user mode,
>
> Luoqi Chen wrote:
> > I spend half night yesterday to sort this mess out. If no one objects,
> > I'll commit my fixes. (anyone volunteers to make the hat?)
>
> I know who gets the hat; please cool it on the fixes until the original
> committer has finished.
>
1 - 100 of 113 matches
Mail list logo
