and I suspect, 68LC040 and 68040V machines. Method used:
1. do NOT use the frames effective address at all
2. do NOT use the frames next instruction address, but
3. restore the "this instruction" pc into the pc field of the frame at the
beginning of the emulation, if we got a frame format 4.
TODO:
A. find the bug in the usage of the frame EA, and revert to using it.
B. find the bug in the usage of the frames next instruction address, and
consider whether it's worthwhile to use it.
C. make the emulation complete.... FEXP FETOM1, and the trigonometric functions
are missing.
This is the kernel part (userland to follow soon) of the latest (and
very probably last) release (version 0.96) of ISDN4BSD. ISDN4BSD has a
homepage at http://www.freebsd-support.de/i4b/.
It gives the user various ways to use the isdn connection: raw data (via
the i4brbch "raw b-channel" device), ppp (via the isp "isdn PPP" device),
voice/answering machine (the i4btel "telephone" device) and ip over isdn
(the ipr device, "IP over raw ISDN").
Supported are a bunch of common and older cards, more to be added soon
after some cleanup. Currently only the european E-DSS1 variant of the
ISDN D channel protocol is supported.
* Since probeget() isn't geared up to deal with _arbitrary_ memory fault
types (and doesn't work at all when called from an interrupt context),
add explicit sanity checks on a stack frame's contents before use
(XXX - needs revisiting).
at tcds in files.alpha for now, and add a new `xasc at tcds' to files.pmax.
after pmax has moved fully to MI scsi (and `asc' is MI scsi), we should move
the device asc, etc., lines to files.tc.
tlbflush() when that's what we mean (currently everywhere, except
in the one place in MI code where it is called).
The whole pmap_update() thing needs to be reexamined, but this helps
to clarify things a little with the currently-defined semantics of
that function.
noticing trap frames, and printing that information as well. For example
Stack traceback :
0x87ba2bc4: _arithflt+0x1a7(0x87ba2cac)
0x87ba2c50: trap type=0x8c code=0x8 pc=0x800008ef psl=0xc00000
0x87ba2c1c: _copystr+0x23(0x8095f378,0xa539f,0x86c0bd20)
> PCMCIAVERBOSE (commented out)
> isapnp at isa (commented out)
> midi at pcppi
> ep at isapnp (commented out)
> ix at isa (commented out)
> iy at isa (commented out)
> wdc at isapnp (commented out)
> wss at isapnp (commented out)
>
> The isapnp stuff is commented out because it may crash due to unimplemented
> alloc methods on some machines with some devices. This should really get
> fixed.
PCMCIAVERBOSE (commented out)
isapnp at isa (commented out)
midi at pcppi
ep at isapnp (commented out)
ix at isa (commented out)
iy at isa (commented out)
wdc at isapnp (commented out)
wss at isapnp (commented out)
The isapnp stuff is commented out because it may crash due to unimplemented
alloc methods on some machines with some devices. This should really get
fixed.
if it is 64k. TCL and TCM will be set properly if we just leave it alone.
Not only that, the ncr53c9x driver issues TRPAD or TRANS based on this
value. We do not want TRPAD in this case!
an ugly bit where we record the value of a2 while handling a "nofault" bus
error in locore.s in order to know how far the transaction got before a
disconnect (see esp.c comments for more details on this).
Also get rid of a loop (and delay()!) in the interrupt routine--hinted at
and researched by Chas Williams <chas@cmf.nrl.navy.mil>.
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
- Make data_abort_address() return the whole affected range, rather than
just one end.
- Don't rely on pmap_confess(). Instead, for LDM/STM, behave as if two faults
had occurred, one at each end of the range.
- Separate out fault handling into do_fault(), and call it from
data_abort_handler() (twice) and prefetch_abort_handler().
1: Cleanup of syscall() -- treat the arguments as an array of register_t
throughout. This saves a few casts, and generally makes seeing what's
going on easier.
2: Be a little more careful in the handling of data aborts on kernel
addresses: don't use the kernel's map unless the access was actually from
a kernel mode. This is how the arm32 data abort handler behaves.
- Use UVMHIST for debugging messages, rather than printf
- Rely on the caller of pmap_enter to tell us how to manipulate referenced/
modified bits in the kernel pmap.
[ Suggested by chs -- may need work on the rest of the kernel. ]
- Split third-stage initialisation out of pmap_create() into pmap_init2().
- Bug fix: when relocating pv_table, fix up all references to it as well.
- Bug fix: in pv_release(), if pulling up a pv_entry to the head of the
list, correct the reference from its pmap.
to CONFIG_HOOK_SET.
- merge CONFIG_HOOK_GET and CONFIG_HOOK_GETPOWER to CONFIG_HOOK_GET.
- merge CONFIG_HOOK_EVENT and CONFIG_HOOK_BUTTONEVENT to CONFIG_HOOK_ENENT.
- new CONFIG_HOOK_EVENT and CONFIG_HOOK_GET and CONFIG_HOOK_SET always have
msg argument as pointer.
- new CONFIG_HOOK_EVENT and CONFIG_HOOK_GET and CONFIG_HOOK_SET use
same event ids.
- CONFIG_HOOK_POWERCONTROL and CONFIG_HOOK_BUTTONEVENT still exist.
i shall rewite codes by using new CONFIG_HOOK_SET and CONFIG_HOOK_EVENT.
just get pmap_fault to shove them back in. Crude, but effective. Fix inspired
by Chuck Silvers.
This breaks pmap_confess, but it probably deserves to die.
XXX if you have libc after citrus locale import, please recompile libc,
and your applications that use mbstate_t (rather rare). really sorry
for the mess.
martin