"established" state.
Similar to OpenBSD's rev. 1.499 by joel but not breaking ABI.
Obtained from: OpenBSD (with changes)
Reported by: Bruno Afonso
MFC after: 3 days
X-MFC: together with local_flags
POSIX. This also makes the struct correct we ever implement an i386-time64
architecture. Not that we need too.
Reviewed by: imp, brooks
Approved by: njl (acpica), des (no objects, touches procfs)
Tested with: make universe
Specifically, it is required for the I/O that may be performed by
elfN_load_section().
Avoid an obscure deadlock in the a.out, elf, and gzip image
activators. Add a comment describing why the deadlock does not occur
in the common case and how it might occur in less usual circumstances.
Eliminate an unused variable from exec_aout_imgact().
In collaboration with: tegge
by debugger, e.g process is dumping core. Only access p_xthread if
P_STOPPED_TRACE is set, this means thread is ready to exchange signal
with debugger, print a warning if P_STOPPED_TRACE is not set due to
some bugs in other code, if there is.
The patch has been tested by Anish Mistry mistry.7 at osu dot edu, and
is slightly adjusted.
I'm holding off on building on sparc64 and others because I don't know
if this driver has had all the inb/outb removed (I think it has). Nor
do I know if there are byte ordering issues. There are very few word
operations on an NE2000, but I've not had time to audit them all.
Suggested by: Daniel O'Connor
handling code so the stack trace unwinders don't start trying to
go into user-space.
Found by trying to create core dumps with a KTR_COMPILE/KTR_GEOM
kernel, which results in a stack_save() call in the ast() coredump
path - this created a panic, and then calling 'trace' in ddb resulted
in the black screen of death after printing out most of the backtrace.
passing a pointer to an opaque clockframe structure and requiring the
MD code to supply CLKF_FOO() macros to extract needed values out of the
opaque structure, just pass the needed values directly. In practice this
means passing the pair (usermode, pc) to hardclock() and profclock() and
passing the boolean (usermode) to hardclock_cpu() and hardclock_process().
Other details:
- Axe clockframe and CLKF_FOO() macros on all architectures. Basically,
all the archs were taking a trapframe and converting it into a clockframe
one way or another. Now they can just extract the PC and usermode values
directly out of the trapframe and pass it to fooclock().
- Renamed hardclock_process() to hardclock_cpu() as the latter is more
accurate.
- On Alpha, we now run profclock() at hz (profhz == hz) rather than at
the slower stathz.
- On Alpha, for the TurboLaser machines that don't have an 8254
timecounter, call hardclock() directly. This removes an extra
conditional check from every clock interrupt on Alpha on the BSP.
There is probably room for even further pruning here by changing Alpha
to use the simplified timecounter we use on x86 with the lapic timer
since we don't get interrupts from the 8254 on Alpha anyway.
- On x86, clkintr() shouldn't ever be called now unless using_lapic_timer
is false, so add a KASSERT() to that affect and remove a condition
to slightly optimize the non-lapic case.
- Change prototypeof arm_handler_execute() so that it's first arg is a
trapframe pointer rather than a void pointer for clarity.
- Use KCOUNT macro in profclock() to lookup the kernel profiling bucket.
Tested on: alpha, amd64, arm, i386, ia64, sparc64
Reviewed by: bde (mostly)
if we need a valid MAC address (for probing the media for example) before
ether_ifattach() has been called since IF_LLADDR() is NULL then.
Tested by: tisco
except for BGE_CHIPID_BCM5700_B0, which is buggy.
- All bge(4) supported hardware, has a bug that produces incorrect checksums
on Ethernet runts. However, in case of a transmitted packet, the latter can
be padded with zeroes, and the checksum would be correct. (Probably chip
includes the pad data into checksum). In case of receive, we just don't
trust checksum data in received runts.
Obtained from: NetBSD (jonathan) via Mihail Balikov
Previously it always returned 0 which means success regardless of
EEPROM status.
While here, add a check whether EEPROM read is successful.
Submitted by: jkim
- removed unused funtion bge_handle_events().
- removed bus_dmamap_destroy(9) calls for DMA maps created by
bus_dmamem_alloc(9). This should fix panics seen on sparc64
in device detach.
- added check for parent DMA tag creation.
- switched to use __NO_STRICT_ALIGNMENT as bge(4) supports all
architectures.
- added missing bus_dmamap_sync(9) in bge_txeof().
- added missing bus_dmamap_sync(9) in bge_encap().
- corrected memory synchronization operation on status block.
As the driver just read status block that was DMAed by NIC it
should use BUS_DMASYNC_POSTREAD. Likewise the driver does not
need to write status block back, so remove unnecessary
bus_dmamap_sync(9) calls in bge_intr().
- corrected memory synchronization operation on RX return ring.
The driver only read the block so remove unnecessary
bus_dmamap_sync(9) in bge_rxeof().
- force bus_dmamap_sync(9) for only modified descriptors. Blindly
synching all desciptor rings would reduce performance.
- call bus_dmamap_sync(9) for DMA maps that were modified in bge_rxeof().
Reviewed by: jkim(initial version)
Tested by: glebius(i386), jkim(amd64 initial version)
interfaces to bridges, which will then send and receive IP protocol 97 packets.
Packets are Ethernet frames with an EtherIP header prepended.
Obtained from: NetBSD
MFC after: 2 weeks
it and reacquiring it in vrele(). Consequently, there is no reason to
increase the reference count on the vm object caching the file's pages.
Reviewed by: tegge
Eliminate unused parameters to elfN_load_file().
3MB of physical memory for heap instead of range between 1MB and 4MB.
This makes this feature working with PAE and amd64 kernels, which are
loaded at 2MB. Teach i386_copyin() to avoid using range allocated by
heap in such case, so that it won't trash heap in the low memory
conditions.
This should make loading bzip2-compressed kernels/modules/mfs images
generally useable, so that re@ team is welcome to evaluate merits
of using this feature in the installation CDs.
Valuable suggestions by: jhb
