gallatin [Mon, 21 May 2001 16:09:29 +0000 (16:09 +0000)]
Change pmap_emulate_reference() so that it only touches the vm_page
flags if it is safe to do so, otherwise it will just alter the pmap state
(eg, clear the appropriate PG_FOx bits).
This gets alpha booting in the face of the vm_mtx introduction.
nyan [Mon, 21 May 2001 12:51:44 +0000 (12:51 +0000)]
Update pc98 memory probe functions.
- pc98_getmemsize() function returns available memory size under 16MB.
- getmemsize() function is merged from PC-AT's one.
Submitted by: chi@bd.mbn.or.jp (Chiharu Shibata) and
NOKUBI Hirotaka <nokubi@ff.iij4u.or.jp>
Bug in i4btel driver read routine corrected. The conditions in the
while() clause caused the receive queue to be referenced before checking
if a channel is connected, leading to kernel panic (do a 'dd
if=/dev/i4btel0 of=/dev/null' on an unconnected tel device, panic will
follow). Correction was to reorder the while clause conditions to check
for connectedness first.
imp [Mon, 21 May 2001 05:49:15 +0000 (05:49 +0000)]
Move setting of Vcc bit to before the vcc switch statement. The
datasheets I have seem to indicate that generally this bit is viewed
as a toggle. Correct comments to match code.
imp [Mon, 21 May 2001 04:44:14 +0000 (04:44 +0000)]
Next step on the road to pci: power taming.
Work through the various power commands and convert them from a "is
this a foo controller or a foo' controller or a foo''' controller" to
a cabability based scheme. We have bits in the softc that tell us
what kind of power control scheme the controller uses, rather than
relying on being able to enumerate them all. Cardbus bridges are
numerous, but nearly all implement the i82365sl-DF scheme (well, a few
implement cirrus CL-PD67xx, but those were made by Cirrus Logic!).
Add a pointer back to the softc in each pcic_slot so we can access
these flags.
Add comments that talk about the issues here. Also note in passing
that there are two differ Vpp schemes in use and that we may need to
adjust the code to deal with both of them. Note why it usually works
now.
We have 5 power management modes right now: KING, AB, DF, PD and VG.
AB is for the i82365 stpes A, B and C. DF is for step DF. PD is the
cirrus logic extensions for 3.3V while VG is the VADEM extensions for
3.3V. KING is for the IBM KING controller found on some old cards.
# I'm looking for one of those old cards or a laptop that has the KING
# bridge in it.
We have to still cheat and treat the AB parts like the DF parts
because pci isn't here yet. As far as I can tell, this is harmless
for actual old parts and necessary to work with 3.3V cards in some
laptops.
This almost eliminates all tests for controller in the code. There
are still a few unrelated to power that need taming as well.
imp [Mon, 21 May 2001 03:22:52 +0000 (03:22 +0000)]
Next step towards pcic_pci: the ability to allocate mapped memory in attach.
o Introduce flags word to the softc. This will be used to control various
aspects of the driver. Right now there are two bits defined, PCIC_IO_MAPPED
and PCIC_MEM_MAPPED. One for ISA cards that are I/O mapped, the other is
for PCI cards that are memory mapped. Only the ISA side is implemented
with this commit.
o Introduce a pcic_dealloc which will cleanly dealloc resources used. Right
now it is only supported when called from probe/attach.
o Keep track of resources allocated in the pcic_softc.
o move pcictimeout_ch to the softc so we can support multiple devices
in polling mode.
o In ISA probe, set PCIC_IO_MAPPED.
o Introduce and compute the slot mask. This will be used later when
we expand the number of slots on ISA from 2 to 4. In such a case, we
appear to have to use polling mode otherwise we get two different cards
trying to drive the same interrupt line. I don't have hardware to
test this configuration, so I'll stop here.
imp [Mon, 21 May 2001 00:55:44 +0000 (00:55 +0000)]
Two comments and one bug fix:
o Add defines for the VS[12]# bits in register 0x16.
o Add comment about what we're doing reading register 0x16 (PCIC_CDGC)
in the DF case.
o Check bit VS1# rather than a random bit I was checking due to a bogus
transcrition on my part from nakagawa-san's article.
o Add note about IBM KING and 3.3V operation from information larned from
wildboard.
jasone [Sun, 20 May 2001 23:08:33 +0000 (23:08 +0000)]
Instead of using a join queue for each thread, use a single pointer to
keep track of a joiner. POSIX only supports a single joiner, so this
simplification is acceptable.
At the same time, make sure to mark a joined thread as detached so that
its resources can be freed.
bde [Sun, 20 May 2001 20:04:40 +0000 (20:04 +0000)]
Throw away the complications in npxsave() and their infrastructure.
npxsave() went to great lengths to excecute fnsave with interrupts
enabled in case executing it froze the CPU. This case can't happen,
at least for Intel CPU/NPX's. Spurious IRQ13's don't imply spurious
freezes. Anyway, the complications were usually no-ops because IRQ13
is not used on i486's and newer CPUs, and because SMPng broke them in
rev.1.84. Forcible enabling of interrupts was changed to
write_eflags(old_eflags), but since SMPng usually calls npxsave() from
cpu_switch() with interrupts disabled, write_eflags() usually just
kept interrupts disabled.
bde [Sun, 20 May 2001 18:05:44 +0000 (18:05 +0000)]
Use a critical region to protect almost everything in npxinit().
npxinit() didn't have the usual race because it doesn't save to curpcb,
but it may have had a worse form of it since it uses the npx when it
doesn't "own" it. I'm not sure if locking prevented this. npxinit()
is normally caled with the proc lock but not sched_lock.
Use a critical region to protect pushing of curproc's npx state to
curpcb in npxexit(). Not doing so was harmless since it at worst
saved a wrong state to a dieing pcb.
bde [Sun, 20 May 2001 17:01:20 +0000 (17:01 +0000)]
Use a critical region to protect pushing of curproc's npx state to
curpcb in vm86_bioscall(). I don't know if the state is ever in the
npx at that point.
bde [Sun, 20 May 2001 16:51:08 +0000 (16:51 +0000)]
Use a critical region to protect saving of the npx state in savectx().
Not doing this was fairly harmless because savectx() is only called
for panic dumps and the bug could at worse reset the state.
savectx() is still missing saving of (volatile) debug registers, and
still isn't called for core dumps.
kris [Sat, 19 May 2001 23:24:17 +0000 (23:24 +0000)]
(Previous commit was made prematurely before I could finish composing
the log message)
Bring in the WARNS directive from NetBSD, localized in a new bsd.sys.mk
to avoid polluting sys.mk. This directive controls the addition of
compiler warning flags to CFLAGS in a relatively compiler-neutral manner.
The idea is that WARNS can be set in Makefile.inc or in individual
Makefiles as they become clean, to prevent the introduction of new
warnings in the code (-Werror is added by default when WARNS > 0).
This behaviour can be overridden with the following two knobs:
NO_WARNS disables the checking of WARNS completely
NO_WERROR disables the addition of -Werror to the flags.
Additionally, setting WFORMAT to 1 (in makefiles) and/or defining
FORMAT_AUDIT (by the user) will enable increased checking of format
string arguments.
kris [Sat, 19 May 2001 23:18:21 +0000 (23:18 +0000)]
Bring in the WARNS directive from NetBSD, localized in a new bsd.sys.mk
to avoid polluting sys.mk. This directive controls the addition of
compiler warning flags to CFLAGS in a relatively compiler-neutral manner.
The idea is that WARNS can be set in Makefile.inc or in individual
Makefiles as they become clean, to prevent the introduction of new
warnings in the code. -Werror is added by default
jdp [Sat, 19 May 2001 19:36:32 +0000 (19:36 +0000)]
Fix a range checking bug in ng_int32_parse which affected 64-bit
machines. The code formerly read:
long val;
if (val < (long)-0x80000000 || ...)
return EINVAL;
The constant 0x80000000 has type unsigned int. The unary `-'
operator does not change the type (or the value, in this case).
Therefore the promotion to long is done by 0-extension, giving
0x0000000080000000 instead of the desired 0xffffffff80000000. I
got rid of the `-' and changed the cast to (int32_t) to give proper
sign-extension on all architectures and to better reflect the fact
that we are range-checking a 32-bit value.
This commit also makes the analogous changes to ng_int{8,16}_parse
for consistency.
mckusick [Sat, 19 May 2001 19:24:26 +0000 (19:24 +0000)]
Must ensure that all the entries on the pd_pendinghd list have been
committed to disk before clearing them. More specifically, when
free_newdirblk is called, we know that the inode claims the new
directory block. However, if the associated pagedep is still linked
onto the directory buffer dependency chain, then some of the entries
on the pd_pendinghd list may not be committed to disk yet. In this
case, we will simply note that the inode claims the block and let
the pd_pendinghd list be processed when the pagedep is next written.
If the pagedep is no longer on the buffer dependency chain, then
all the entries on the pd_pending list are committed to disk and
we can free them in free_newdirblk. This corrects a window of
vulnerability introduced in the code added in version 1.95.
imp [Sat, 19 May 2001 06:36:09 +0000 (06:36 +0000)]
Add back the plain i82365 to the list of bridges that do special
things to get 3.3V. It appears that some cardbus chipsets have id
registers that say they are C step parts, but they really support the
DF step 3.3V functionality.
# Need to verify that IBM KING is handled properly since the MISC1
# register is really a cirrus logic only register.
obrien [Sat, 19 May 2001 05:54:11 +0000 (05:54 +0000)]
Remove these libs that are the same .so version as the ones in
5-CURRENT. These libs will not be used [sitting in /usr/lib/compat] as
the -current ones in /usr/lib will be found first by ld-elf.so.1.
obrien [Sat, 19 May 2001 05:53:50 +0000 (05:53 +0000)]
Remove these libs that are the samed .so version as the ones in
5-CURRENT. These libs will not be used [sitting in /usr/lib/compat] as
the -current ones in /usr/lib will be found first by ld-elf.so.1.
imp [Sat, 19 May 2001 05:50:42 +0000 (05:50 +0000)]
Now that we've moved the mecia support out of pcic.c to its own
driver, we no longer need to go through the cinfo.XXXX indirections.
restore the direct calls that were replaced earlier.
imp [Sat, 19 May 2001 05:21:23 +0000 (05:21 +0000)]
Move ISA specific code into pcic_isa. This is the probe routine, the
get/setb1 routines. Also expose clrb and setb as pcic_{clrb,setb} so
we can use it from the probe. pcic_probe is no longer needed.
imp [Sat, 19 May 2001 04:53:20 +0000 (04:53 +0000)]
It turns out that Intel's i82365sl-DF step has the same ID as the VLSI
82C146. The Intel i82365SL-DF supports 3.3V cards. The Step A/B/C
parts do not appear to support this. This is hard to know for sure
since it was deduced from "compatible" parts' data sheets and the
article mentioned below.
Rework the VLSI detection to be a little nicer and not depend on
scanning cards twice. This would allow bad VLSI cards to coexist with
a good intel card, for example. We now detect i82365SL-DF cards where
before we'd detect a VLSI. For the most part, this is good, but we
run a small chance of detecting a single slot 82C146 as a i82365SL-DF.
Since I can't find a datasheet for the 82c146, I don't know if this is
a problem or not.
This work is based on an excellent article, in Japanese, by NAKAGAWA,
Yoshihisa-san that appeared in FreeBSD Press Number 4. He provided a
patch against PAO3 in his article. Since the pcic.c code has changed
some since then, I've gone ahead and cleaned up his patch somewhat and
changed how the code detects the buggy '146 cards.
I also removed the comment asking if there were other cards that
matched the 82C146 since we found one and additional information isn't
necessary.
iedowse [Fri, 18 May 2001 19:43:18 +0000 (19:43 +0000)]
The function clnt_dg_call(), which is used for UDP RPC calls, could
accidentally clobber the server address if a stray packet arrived
at the client port. This would result in any further retransmits
going to the wrong address.
For now, fix this by not saving the source address of the reply; this
matches the pre-tirpc behaviour.
gshapiro [Fri, 18 May 2001 18:35:34 +0000 (18:35 +0000)]
String operations could silently truncate long strings, leaving the output
corrupted. Mark's patch fixes this be removing the MAXTOK limitation on
substring operations and allowing the putback buffer size to be the limiting
factor. If the putback buffer size if reached, m4 gives an error instead of
silently truncating the string.
PR: bin/26619
Submitted by: Mark Peek <mark-ml@whistle.com>
MFC after: 5 days