(mutant) Crystal CSS4236 chip on the Intel PR440FX SMP motherboard.
XXX this uses some rather ugly PnP bootstrap code that is *NOT* compatable
with 'controller pnp0' or *ANY* other PnP devices. If you use some other
PnP devices, enabling css0 will burn your house down. :-] The
"simplified" PnP init sequence directly blats your config(8) settings onto
the chip. I'm pretty sure 'css0' will conflict with 'mss0', this whole
area desperately needs a cleanup.
I have been using the following with some success on the PR440FX:
controller snd0
device css0 at isa? port 0x534 irq 5 drq 1 flags 0x08 vector adintr
device opl0 at isa? port 0x388
device mpu0 at isa? port 0x330 irq 10 vector mpuintr
quite a while, but forgot to do so. For now, this code supports
most daemons running as kernel threads in UP kernels, and as
full processes in SMP. We will soon be able to run them as
threads in SMP, but not yet.
nodes; this also apparantly caused a panic in some circumstances.
Also, since procfs_exit() is getting rid of the nodes when a process
exits, don't bother checking for the process' existance in procfs_inactive().
> Error out if someone tries to mv a mount point. Old behavior was to
> move all files contained in the mounted filesystem to the dest. dir
> which could be quite nasty. Personally, I think rename(2) should
> return EPERM or EINVAL instead of EXDEV.
Obtained from: OpenBSD mv.c rev 1.6 by Todd Miller <millert@openbsd.org>
what is teh root cause -- but, sometimes, a procfs vnode in pfshead is
apparantly corrupt (or a UFS vnode instead). Without this patch, I can
get it to panic by doing (in csh)
while (1)
ps auxwww
end
and it will panic when the PID's wrap. With it, it does not panic.
Yes -- I know that this is NOT the right way to fix it. But I haven't
been able to get it to panic yet (which confuses me). I am going to
be looking into the vgone() code now, as that may be a part of it.
Wrappered and enabled by the define BETTER_CLOCK (on by default in smpyests.h)
apic_vector.s also contains a small change I (smp) made to eliminate
the double level INT problem. It seems stable, but I haven't the tools
in place to prove it fixes the problem.
Reviewed by: smp@csn.net
Submitted by: Tor Egge <Tor.Egge@idi.ntnu.no>
me; unfortunately, also makes it hard ot check for errors); second, I had
managed to forget a change to PIOCSFL (it should be _IOW, not _IOR) I had
in my local copy, and Bruce called me on it.
Submitted by: bde
tagged traffic according to the encapsulated protocol. It needs in
addition modifications to the filter generator which would deal with
checking the ethertype and vlan header as required.
We must call inflate again in case there's any pending output
despite our input buffer being empty. If the output buffer
is in fact already flushed, inflate() returns Z_BUF_ERROR.
There isn't really an error !
since we only store CIS_MAXSTR data, and the users may stick the
'entire' CIS string returned from the card in /etc/pccard.conf and
cause the comparison to (bogusly) fail.
Submitted by: Brad Karp <karp@eecs.harvard.edu>
