> 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
> 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
> 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
> 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'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
> 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
> 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
> 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
> 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
> 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
> 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
> >
> > 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
> 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
> 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
> 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
> 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
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,
> 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
> > 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
> 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
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
> > 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
> 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
> >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
> 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
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x0
> fault code = supervisor write, page not present
> instruction pointer = 0x8:0xc0680c04
> stack pointer = 0x10:0xc03d3f08
> frame pointer = 0x10:0x2a94
> code segment=
> 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/
> 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
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:
> /etc/rc's shell is a controlling process with control terminal /etc/console,
> so /dev/console is supposed to be revoked when /etc/rc's shell exits.
>
Control terminal is for job control, and we don't need job control during
/etc/rc's execution, so why don't we change init not to acquire a cont
With the latest current, whenever I start amd, I would see a lot of log
messages repeating:
arplookup 127.0.0.1 failed: could not allocate llinfo
arpresolve: can't allocate llinfo for 127.0.0.1rt
If I ifconfig my ether interface down, as expected, the messages would stop.
It's puzz
> no control terminal == no signals == no ^C'ing hung programs during
> startup (for example, when you need to boot a machine without a working
> network and sendmail and other programs stop the boot sequence in its
> tracks trying to do DNS lookups).
>
>
> Well,
>
> I REALLY should search mailing lists before sending useless messages...
>
> There is PR conf/14913 which describes what is going wrong. Will somebody
> commit the fix?
>
I was REALLY surprised that people are so ready to accept this as a
configuration bug. By all means, it is NOT,
> Bug the authors to fix it? daemon(3) is provided for a reason!
>
> Here's my version of a simple daemonizing program Neither
> TIOCNOTTY nor setpgid() is sufficient to detach from a terminal
> session in a POSIX environment; setsid() is required. daemon(3) does
> a nice job of encapsulat
> There is no need to fix kernel if the same result could be achieved by simple
> rc.network file modification. Yes, solution proposed in conf/14913 is
> not complete and only works in network_interfaces="auto" case, but the
> modification to make it work in 100% cases is pretty trivial.
>
I fina
> 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
> >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
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
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
> 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
> 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
> 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.
>
> 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
> > 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
> 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
> >> 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
> 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
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
> #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):
I'm pretty sure this is not softupdates related. It could either be bad RAM
or a bad disk block, there is no way entryoffsetinblock could be 21209,
the block size is only 8192. And you need over 2000 files to fill the
directory to i_offset == 37593, assuming an average file name length of
10 bytes.
The check is correct and should be there, the B_CACHE bit was cleared because
I made a mistake when setting the valid bit in the vm page.
Index: vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.192
dif
> On Thu, Jan 21, 1999 at 12:26:04PM -0800, Steve Kargl wrote:
> > cd /usr/src/secure/lib/libcrypt; /usr/obj/usr/src/tmp/usr/bin/make
> > -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend;
> > /usr/obj/usr/src/tmp/usr/bin/make -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE
> > -DNOSHARED all;
Execute anything from NFS would result in an "Input/output error", but if I do
a hexdump of the executable first, the execution would be successful. If I
reverse the order, i.e., execute first then hexdump, execution would fail and
hexdump would hang at "pgtblk". No problem with FFS.
-lq
To Unsub
> :Execute anything from NFS would result in an "Input/output error", but if I
> do
> :a hexdump of the executable first, the execution would be successful. If I
> :reverse the order, i.e., execute first then hexdump, execution would fail and
> :hexdump would hang at "pgtblk". No problem with FFS.
> having spent almost an hour trying to decode the complexities of the crypt
> making process I admit defeat..
> can SOMEBODY please fix the build in -current and sent branson
> a nice pointy hat..
> I think he committed and went on vacation
>
> (I haven't seen any commits that say they fixed this
> 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.
>
> 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,
>
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 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
> 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
> 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
> 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
> 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
> 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
> 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
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
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
> 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
> 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
> 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
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
> 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
> 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
> (
> > 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
^^
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
> 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
> 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
> 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,
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 =
> 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
> > 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
> 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
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
> 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
> 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
> 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
> 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
1 - 100 of 113 matches
Mail list logo
