resources. (Note that the correct range is 0x3f7,0x3f0-0x3f5.) Such
devices will be detected as follows:
fdc0: <Enhanced floppy controller (i82077, NE72065 or clone)> port
0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0
To do this, we find the minimum and maximum start addresses for the
resources and use them as the base for the IO and control ports.
Help from: jhb
missing parentheses). Use default handling (trap to debugger) for
udev2dev(x, 1) since it is an error and doesn't happen anywhere in
the sys tree except in bogusly commented out code in coda.
read EOF from STDIN_FILENO, write zero bytes into the pseudo-terminal;
this is interpreted as an EOF by the program being scripted.
I've tested this with two non-interactive scripts:
# echo 5 | script foo sh -c 'read x; sleep $x; echo bar'
# echo bar | xargs script foo echo
and one interactive program:
# script foo more /etc/passwd
and everything seems to work properly...
PR: bin/56166, bin/57414, ports/57415, ports/60534
Approved by: rwatson (mentor)
MFC after: 2 weeks
and given a value, but never used. This has no effect on the
resulting binaries, since gcc optimizes the variable away anyway.
PR: kern/62684
Approved by: rwatson (mentor)
that ext2fs in the kernel supports async mounts. ext2fs used to
effectively force the -async flag on. -async for ext2fs only gives
async (more precisely, delayed) writes for inode updates, so it is
barely worth using even when it is safe.
panic "vm_page_cache: caching a dirty page, ...": Access to the page must
be restricted or removed before calling vm_page_cache(). This race
condition is identical in nature to that which was addressed by
vm_pageout.c's revision 1.251 and vm_page.c's revision 1.275.
Reviewed by: tegge
MFC after: 7 days
The Am1771 driver will sometimes do the following:
- Some thread-> NdisScheduleWorkItem(some work)
- Worker thread -> do some work, KeWaitForSingleObject(some event)
- Some other thread -> NdisScheduleWorkItem(some other work)
When the second call to NdisScheduleWorkItem() occurs, the NDIS worker
thread (in our case ndis taskqueue) is suspended in KeWaitForSingleObject()
and waiting for an event to be signaled. This is different from when
the worker thread is idle and waiting on NdisScheduleWorkItem() to
send it more jobs. However, the ndis_sched() function in kern_ndis.c
always calls kthread_resume() when queueing a new job. Normally this
would be ok, but here this causes KeWaitForSingleObject() to return
prematurely, which is not what we want.
To fix this, the NDIS threads created by kern_ndis.c maintain a state
variable to indicate whether they are running (scanning the job list
and executing jobs) or sleeping (blocked on kthread_suspend() in
ndis_runq()), and ndis_sched() will only call kthread_resume() if
the thread is in the sleeping state.
Note that we can't just check to see if the thread is on the run queue:
in both cases, the thread is sleeping, but it's sleeping for different
reasons.
This stops the Am1771 driver from emitting various "NDIS ERROR" messages
and fixes some cases where it crashes.
data for the file system on which the jail's root vnode is located.
Previous behavior (show data for all mountpoints) can be restored
by setting security.jail.getfsstatroot_only to 0. Note: this also
has the effect of hiding other mounts inside a jail, such as /dev,
/tmp, and /proc, but errs on the side of leaking less information.
called until DEVFS had a chance to initialize. Since DEVFS is mandatory
and things over in that department coincidentally works from without
any initialization now, this is safe.
could result in a panic "vm_page_cache: caching a dirty page, ...":
Access to the page must be restricted or removed before calling
vm_page_cache(). This race condition is identical in nature to that
which was addressed by vm_pageout.c's revision 1.251.
- Simplify the code surrounding the fix to this same race condition
in vm_pageout.c's revision 1.251. There should be no behavioral
change. Reviewed by: tegge
MFC after: 7 days
- don't unlock the vnode after vinvalbuf() only to have to relock it
almost immediately.
- don't refer to devices classified by vn_isdisk() as block devices.
is reserved by the loader, and thus any tunable name with that suffix will
be silently discarded.
Document this in the header and man page so that other developers do not
develop so many bumps on the head after banging it against the wall.
Detective work by: Mark Santcroos, grehan