by Alan Cox <alc@cs.rice.edu>, and his description of the problem.
The bug was primarily in procfs_mem, but the mistake likely happened
due to the lack of vm system support for the operation. I added
better support for selective marking of page dirty flags so that
vm_map_pageable(wiring) will not cause this problem again.
The code in procfs_mem is now less bogus (but maybe still a little
so.)
loop, test for them separately. The bug report from David Malone showed that
even though we had been reselected (SELDI was true), we sat in the poll for
work loop until the selection timeout timer expired. It may be that the
SSTAT0 register doesn't like to have more than one bit tested at a time.
I've seen stranger things than this on these parts.
selection loop was merged with the poll_for_work loop. We cannot assume
that the SCB for the selection timeout is the current SCB. Instead we
must look at the SCB at the head of the waiting for selection list.
This fixes part of a problem reported by David Malone, but does not explain
why he was getting selection timeouts in the first place.
the directory format (ext2fs, cd9660). For these filesystems, it must use
cookies to find the correct offset to use for subsequent reads. Without it,
linux /bin/ls tends to loop re-reading the same block over and over again.
2.2 candidate.
(see LINT). There is a new low-level console type that is more suitable
for use with gdb-remote.
Fixed setting of speed at probe time for the serial console (if any).
Reviewed by: dfr
I got tired of not seeing my worm stats show up during a burn. :)
[Joerg, I just stapled in 1MB/sec for a bogus xfer rate and left seek = 1,
as suggested - I'm not going to dynamically calculate the xfer rate from
a known device spectable, OK? :-)]
Reviewed by: joerg
implementation #ifdef out. This can be used for now by NFS. As soon
as all the other filesystems' locking is fixed, this can go away.
Print the vnode address in vprint for easier debugging.
Bump the timeout for an "ordered tag" recovery action from 1 to 5 seconds.
Remove the multiple timeout panic. Its very easy to get into a situation
where a timedout command will time out a second time even though the
recovery code is working fine. A good example is:
1) Command times out during recovery
2) reset the timeout for the command
3) Recovery actions complete and all transactions are requeued
4) second timeout fires off which puts us back into recovery bogusly
5) another transaction that timedout once during the first recovery action
times out causing the panic.
In essence, the correct solution to the problem is to put every transaction
back up into the work queue and have their timeout handling done in the same
way that all commands are handled. The CAM layer makes this easy, so it
will have to wait until then.
1. imgp->image_header needs to be cleared for the bp == NULL && `goto
interpret' case, else exec_fail_dealloc would free it twice after
an error.
2. Moved the vp->v_writecount check in exec_check_permissions() to
near the end. This fixes execve("/dev/null", ...) returning the
bogus errno ETXTBSY. ETXTBSY is still returned for attempts to
exec interpreted files that are open for writing. The man page
is very old and wrong here. It says that ETXTBSY is for pure
procedure (shared text) files that are open for writing or reading.
3. Moved the setuid disabling in exec_check_permissions() to the end.
Cosmetic. It's more natural to dispose of all the error cases
first.
...plus a couple of other cosmetic changes.
Submitted by: bde
either by looking it up in the array of pending, per target, untagged
transactions, or by using the tag value passed in during the identify. The
old code only direct indexed for tagged transactions. This makes the
"findSCB" routine only necessary when SCB paging is enabled, so appropriately
conditionalize it. This greatly simplifies the non SCB paging code flow.
if all registers are 0xff.
This allows me to run with flags 0xc0ff on my IBM-DMCA-21440 disk, which
gives 5MB/sec sequential read :-)
If you have a laptop, try adding flag 0x4000 to your disk, and tell me if
it makes any difference for you.
cache lines. Removed the struct ip proto since only a couple of chars
were actually being used in it. Changed the order of compares in the
PCB hash lookup to take advantage of partial cache line fills (on PPro).
Discussed-with: wollman
by bde.
Don't return EPERM in setre[ug]id() just because the caller passes in
the current effective id in the second arg (ie: no change), as suggested
by ache.
