Remove the modified tte bit and add a softwrite bit. Mappings are only
writeable if they have been written to, thus in general modify just
duplicates the write bit. The softwrite bit makes it easier to distinguish
mappings which should be writeable but are not yet modified.
Move the exec bit down one, it was being sign extended when used as an
immediate operand.
Use the lock bit to mean tsb page and remove the tsb bit. These are the
only form of locked (tsb) entries we support and we need to conserve bits
where possible.
Implement pmap_copy_page and pmap_is_modified and friends.
Detect mappings that are being being upgraded from read-only to read-write
due to copy-on-write and update the write bit appropriately.
Make trap_mmu_fault do the right thing for protection faults, which is
necessary to implement copy on write correctly. Also handle a bunch
more userland trap types and add ktr traces.
and I still dont know why, this was not failing on the non-kse kernel.
It certainly should have since things were using linker_kernel_file
unconditionally. This has highlighted a different problem though that
means that trying to do a kldload on a non-dynamic kernel will implode.
luns) firmware for the Fibre Channel cards.
We used to assume that if we didn't download firmware, we couldn't know
what the firmware capability with respect to SCCLUNs is- and it's important
because the lun field changes in the request queue entry based upon which
firmware it is.
At any rate, we *do* get back firmware attributes in mailbox register 6
when we do ABOUT FIRMWARE for all 2200/2300 cards- and for 2100 cards
with at least 1.17.0 firmware. So- we now assume non-SCCLUN behaviour
for 2100 cards with firmware < 1.17.0- and we check the firmware attributes
for other cards (loaded firmware or not).
This also allows us to get rid of the crappy test of isp_maxluns > 16-
we simply can check firmware attributes for SCCLUN behaviour.
This required an 'oops' fix to the outgoing mailbox count field for
ABOUT FIRMWARE for FC cards.
Also- while here, hardwire firmware revisions for loaded code for SBus
cards. Apparently the 1.35 or 1.37 f/w we've been loading into isp1000
just doesn't report firmware revisions out to mailbox regs 1, 2 and 3
like everyone else. Grumble. Not that this fix hardly matters for FreeBSD.
MFC after: 4 weeks
A nsp chip does suspend I/O write by 512bytes burst write,
though the chip only has 48 bytes FIFO. The chip assert I/O WAIT
signal to PC-Card bus after the CPU writes more than 48 bytes to
the chip if the SCSI device does not respond immediately in supsend
I/O burst write. If the device does not respond for a while it might
cause PC-Card bus timeout.
The previous work around was to wait the request from SCSI device.
But there are some devices which request bytes for synchronous transfer
immediately. So current work aound is to fill 32bytes FIFO, wait for
FIFO empty and burst write 512-32 bytes for every 512 bytes block.
Submitted-by: Honda-san (the author of the driver)
Obtained-from: NetBSD/pc98
