We need to use 'applyset' command for devfs, 'apply hide' is not enough,
because new devfs entries can show up later and one can access such entires
from inside named chroot.
In rc.d scripts we can use devfs_domount() function with devfsrules_hide_all
policy and unhide 'null' and 'random' manually.
Hartmut Brandt [Mon, 23 May 2005 11:24:39 +0000 (11:24 +0000)]
The ticks delivered by the SNMP daemon are now 64-bit, so make our
local tick variable which is used to reduce the number of updates from
kernel structures and to ensure intra-PDU consistency also 64 bit.
Pyun YongHyeon [Mon, 23 May 2005 06:27:07 +0000 (06:27 +0000)]
Make snd_maestro3(4) mpsafe
- Let m3_pchan_trigger()/m3_rchan_trigger() acquire lock and call
m3_pchan_trigger_locked()/m3_rchan_trigger_locked() respectivly.
- Mark interrupt handler INTR_MPSAFE.
- Add locks in sound/channel interface.
Pyun YongHyeon [Mon, 23 May 2005 05:45:36 +0000 (05:45 +0000)]
According to STP2002QFP User's Guide, it seems that driver should
program RXMAC to discard frames with SA field matching the stations's
MAC address. Experimentation shows that HME receives its own frames
when it operates at 10Mbps half-duplex. With this change HME runs at
10Mbps half-duplx should work with IPv6.
(No more "DAD detected duplicate IPv6 address".)
Reported by: jacques brierre <jbrierre AT bellsouth DOT net>
Reviewed by: marius
If we need to hide fsid, kern_statfs()/kern_fstatfs() will do it for us,
so do not duplicate the code in cvtstatfs().
Note, that we now need to clear fsid in freebsd4_getfsstat().
This moves all security related checks from functions like cvtstatfs()
and will allow to add more security related stuff (like statfs(2), etc.
protection for jails) a bit easier.
Damien Bergamini [Sun, 22 May 2005 18:55:32 +0000 (18:55 +0000)]
o Clear device-specific PCI register 0x41 (Retry Timeout) during attach
and on resume (reported to fix issues with ACPI)
o Add monitor mode support
o Add WPA (802.11i) support (not tested extensively though!)
o Add a device specific sysctl to control the tx antenna (default to
antenna diversity)
o Fix sensitivity setting
o Fix setting of the capinfo field when associating
o Temporarly disable 802.11a channels scanning that was causing firmware
panics with 2915ABG adapters until I find a better fix. This breaks
802.11a support.
o Temporarly switch back to software WEP until I implement hardware
encryption for AES and TKIP too.
- Autogenerate device listings for sound(4) aka pcm(4)
- Rename the Audio Devices section into Sound Devices, this is more
in line with out sound and snd_* drivers
Marius Strobl [Sat, 21 May 2005 20:50:45 +0000 (20:50 +0000)]
- Hook up machfb(4) to the sparc64 build, not enabled in GENERIC
by default, yet.
- Replace "graphics cards" with "framebuffers" in the description
of creator(4) in order to make it uniform with the description of
machfb(4) and the latter occur both on-board and as add-on cards.
Marius Strobl [Sat, 21 May 2005 20:47:38 +0000 (20:47 +0000)]
Add machfb(4), a driver for ATI Mach64 graphics chips intended for
use with syscons(4) on sparc64. It's based on the respective NetBSD
driver with some additional info (initialisation/hardware cursor)
obtained from the Xorg 'ati' driver and some ideas taken from
creator(4). ATI Mach64 chips ("ATI Rage") are quite common as low-
end graphics chips in PCI-based sun4u machines and are used on-board
in e.g. Blade 100 and a couple of OEM products. Most if not all of
the Sun PGX add-on cards family (descriptions of the PGX32 are
conflicting but most say it's a Rage Pro) are also based on these
chips. Depending on the version of the OBP Mach64 cards destined for
use in i386 machines also work in sun4u machines.
The driver uses pixel mode with hardware acceleration as far as
syscons(4) currently permits on sparc64 so text mode is already
quite fast. The hardware cursor is used for the mouse pointer;
for one because this is a "restriction" induced in syscons(4) on
sparc64 by creator(4) and also because of issues with mapping
the aperture when used as a low-level early during boot. Due to
insufficiencies in the available documentation I didn't manage to
get mode switch work properly (sync problems), yet. So for now
this driver relies on the OBP having initialised a mode (as does
creator(4)). On all of the tested machines is even true when using
a serial console (and also not only when the OBP switched to a
serial console because no keyboard is present). In general however
the states the Mach64 chips are left in by the OBP vary a lot
depending on the version of the OBP. This e.g. includes the aperture
not being mapped in even when used as the console and the OBP just
barfing when asked to map it. The latter is also the reason for the
existence of this native driver in FreeBSD rather than taking an
OFW frambuffer approach.
Xorg is also happy to talk to these chips by mmap'ing them through
this driver. For some hardware configs like on the Blade 100 a fix
for the Xorg sparc64 MD bus code is however needed (added in version
6.8.2_2 of the xorg-server port).
The video driver font loading and saving methods are not implemented,
yet, as syscons(4) needs more work in that area to work viable on
sparc64.
With minor modifications machfb(4) would most likely also work on
powerpc, when #ifdef'ing the OFW and possibly implementing mode
setting probably also on the other archs. The latter is however
not very practible at the moment as it would conflict with vga(4).
Tested/developed with: Rage II+ add-on card on AX1105 and AXi board,
AXe board (on-board Rage Pro)
Additional testing by: marcel (Ultra 5 w/ on-board Rage Pro),
scottl (Naturetech GENIALstation 777S w/ on-board
Rage Mobility M1),
Michiel Boland and Ilmar S. Habibulin (Blade 100
w/ on-board Rage XL)
Marius Strobl [Sat, 21 May 2005 20:38:26 +0000 (20:38 +0000)]
o creator(4):
- Use register macros instead of magic values in the code. [1]
- Check the return values of OF_getprop() and other stuff that actually
can fail.
- Let the unimplemented video driver methods return ENODEV rather
than 0 so other code isn't tricked into thinking a certain operation
was successfull. In case of e.g. the video driver creator_ioctl()
this caused vidcontrol(1) to return random garbage information.
Remove the TODO macros in the unimplemented video driver methods
which did a printf("%s: unimplemented\n", __func__). Under certain
circumstances these managed to invoke a printf() when a low-level
console device wasn't attached, yet, causing a Fast Data Access MMU
Miss. These macros were only really usefull for development anyway.
- Set the struct video_adapter and struct video_info va_flags and
vi_flags etc. as appropriate.
- In creator_configure() don't rely on hitting the node which is the
chosen console device first when searching the OFW tree for adapters
compatible with this driver. Instead just check whether the chosen
console device is a viable target for this driver. Targets that are
not the console (including additional cards in multi-head configs)
will be attached through creator_upa_attach(). I think this how the
code in creator_configure() was actually meant to work.
Honour the VIO_PROBE_ONLY flag and don't initialise and register the
console device twice when creator_configure() is called a second time
during sc_probe_unit().
Let creator_configure() return the number of the found adapters,
i.e. 1 in case probing succeeds, as it's expected. The return values
of video adapter configure functions however currently aren't checked
so this doesn't make a difference at the moment.
- In creator_upa_attach() don't rely on probing and attaching the
adapter which is the console first, in case there are multiple
adpaters and one of them is the console this could lead into using
the video adapter unit 0 twice.
- Make the check for DACs with inverted cursor control a bit more
precise and actually honour that information when turning the cursor
on or off. Add a helper function creator_cursor_enable() for this
in order to keep code duplication low. [1]
- Don't bother with faking a hardware cursor in case a device is the
console. Apparently this was meant to start kernel output right after
where the firmware left. In general this isn't worth the fuzz and
also had no real effect as creator_set_mode() did clear the screen
in any case, not just in case a device was not the console.
- Implement creator_fill_rect() and use it to actually blank the
display in creator_blank_display() when the mode is V_DISPLAY_BLANK,
moving blanking the display out of creator_set_mode(). Use it also
to implement creator_set_border() so the border can be re-drawn
when switching to a VTY from X, exiting X, etc. (which leaves us
with a black border most of the time).
- Implement the video driver creator_ioctl(), moving the implementation
of the IOCTL interface from the fbN CDEV version of creator_ioctl()
into the video driver version and use the latter to implement the
former. Use fb_commonioctl() to handle most of the FBIO IOCTLs.
This gives programs like vidcontrol(1) which use the video driver
creator_ioctl() a chance of working.
Implement turning off the cursor via the FBIOSCURSOR IOCTL, which
Xorg uses to in order to inform the OS that it's taking over the
cursor. In creator_putm() check whether the cursor is enabled and
(re-)install it if necessary, moving installing the cursor out of
creator_init() and into a helper function creator_cursor_install().
This fixes the missing mouse pointer when switching to a VTY from X,
exiting X, etc.
- Some clean-up (remove unused/useless code, etc.).
o sparc64/creator/creator_upa.c / sparc64/sparc64/sc_machdep.c:
- Attach syscons(4) as an own pseudo-device on the nexus rather than
directly in creator_upa_attach(), similiar to attaching syscons(4)
as a pseudo-device on isa(4) on other archs. This makes it a whole
lot easier to do the right thing in multi-head configs, especially
with different types of graphics adapters. [2]
- Set SC_AUTODETECT_KBD by default so USB keyboards work out of the
box. [2]
Based on/obtained from: Xorg 'ffb' driver [1]
Based on/obtained from: FreeBSD/powerpc [2]
Marius Strobl [Sat, 21 May 2005 20:32:27 +0000 (20:32 +0000)]
- Not every architecture defaults to a black background (e.g. sparc64
uses white) so base the color of the border on SC_NORM_ATTR rather
than hardcoding BG_BLACK.
- Use SC_DRIVER_NAME rather than hardcoding 'sc' in message strings
(see also sys/dev/syscons/syscons.h rev. 1.82).
Marius Strobl [Sat, 21 May 2005 20:29:58 +0000 (20:29 +0000)]
On sparc64 use 'syscons' rather than 'sc' for SC_DRIVER_NAME so
syscons(4) and its pseudo-devices don't get confused (including by
other device drivers) with the system controller devices which are
also termed 'sc' in the OFW tree (and which we probably want to
interface with hwpmc(4) one day).
Marius Strobl [Sat, 21 May 2005 20:28:15 +0000 (20:28 +0000)]
Remove superfluous braces and add #ifndef __sparc64__ around the
VTB_FRAMEBUFFER specific code. On sparc64 we don't use a buffer of
type VTB_FRAMEBUFFER (see syscons.c) and excluding the respective
code here allows to compile syscons(4) without isa(4).
Marius Strobl [Sat, 21 May 2005 20:26:30 +0000 (20:26 +0000)]
- Sprinkle some KBD_IS_* and KBD_*_DONE macros in sunkbd_configure() as
a band-aid allowing to call this function savely multiple times, e.g.
during sckbdprobe() and sc_probe_unit(). Otherwise calling it a second
time results in a non-working keyboard. This needs a lot of more work
to actually do the right thing and work like expected.
- Let sunkbd_configure() return the number of the found keyboards, i.e.
1 in case probing succeeds, as it's expected. The return values of the
keyboard configure functions however currently aren't checked so this
doesn't make a difference at the moment.
- Use FBSDID.
Marius Strobl [Sat, 21 May 2005 20:19:27 +0000 (20:19 +0000)]
- MFpowerpc: sys/powerpc/powerpc/nexus.c rev. 1.7 (partial)
Use bus_generic_probe() and add a bus_add_child() interface method to
allow device drivers to use the identify method to add themselves if
need be (e.g. syscons(4)).
- Use FBSDID.
Marius Strobl [Sat, 21 May 2005 20:17:01 +0000 (20:17 +0000)]
- Make sure that the OFW address properties that are going to be decode
consist of the expected number of address and size cells (we can't use
dynamic arrays here because at the point in the boot process when this
code is used malloc() doesn't work, yet). This fixes a Fast Data Access
MMU Miss when uart(4) (erroneously) calls OF_decode_addr() to decode
the address of PS/2 keyboards. PS/2 keyboards use a different and also
undocumented scheme at the first parent node than mapping at 'ranges'
properties. It's however not worth implementing that other scheme and
actually also fits atkbdc(4) better to just start at the first parent
node of PS/2 keyboards which is the 8042 controller (I have atkbdc(4)
working that way).
- Use FBSDID.
Marius Strobl [Sat, 21 May 2005 20:15:14 +0000 (20:15 +0000)]
For sparc64 conditionalize the compilation of the gfb_cursor() variant
which doesn't assume a hardware cursor on __sparc64__ rather than on
DEV_CREATOR. If we want to include more than one framebuffer driver in
e.g. the GENERIC kernel all drivers have to work the same way. Now that
DEV_CREATOR is no longer used remove it from options.sparc64.
Tim Kientzle [Sat, 21 May 2005 19:45:56 +0000 (19:45 +0000)]
Start to address the race issue between restoring a file's contents
and restoring the metadata. In particular, the metadata-restore
functions now all accept a file descriptor and a pathname. If the
file descriptor is set and the platform supports the appropriate
syscall, restore the metadata through the file descriptor. Otherwise,
restore it through the pathname. This is complicated by varying
syscall support (FreeBSD has an fchmod(2) but no fchflags(2), for
example) and because non-file entries don't have an fd to use in
restoring attributes (for example, mknod(2) doesn't return a file
handle).
Peter Grehan [Sat, 21 May 2005 00:22:57 +0000 (00:22 +0000)]
Quick hack-o-rama to allow the Xorg Radeon driver to start up. It
tries to mmap memory outside of the available BARs, so allow the
range checks to be relaxed with a sysctl.
Peter Wemm [Sat, 21 May 2005 00:02:12 +0000 (00:02 +0000)]
For non-profiling kernels, there were two symbols assigned to the same
address. One was alltraps_with_regs_pushed, the other was calltrap.
When the stack tracer walks up, it looks for magic symbol names to
determine how to parse non-standard stack frames, such as a trapframe.
It was looking for "calltrap". Which of the two symbols you got depended
on things like Phase of moon, etc. If you were unlucky, you got a
garbage stack trace for things like 'debug.trace_on_panic', which would
completely hide the actual source of the problem.
Nate Lawson [Fri, 20 May 2005 17:16:24 +0000 (17:16 +0000)]
Fix LINT build, original breakage was rev 1.23. There are 2 definitions
of MCOUNT to have a C version and an asm version with the same name and
not have LOCORE ifdefs to distinguish them. <machine/profile.h> provides
a C version and <machine/asmacros.h> provides an assembler version.
Hartmut Brandt [Fri, 20 May 2005 15:25:04 +0000 (15:25 +0000)]
Add a test to check whether in compat mode make detectes builtins
on the command line and really executes the shell instead of directly
executing the command.
Hartmut Brandt [Fri, 20 May 2005 15:06:27 +0000 (15:06 +0000)]
Add a test to ensure that in compat mode when a line contains no
shell meta characters it is not passed to the shell, but the command
is executed directly (given that the line is not a shell builtin) and
that the line with a meta character is passed to the shell.
Hartmut Brandt [Fri, 20 May 2005 14:50:30 +0000 (14:50 +0000)]
Add a test that test whether we can replace the shell to use by
make with another shell and set all its parameters (meta and builtins
not tested here).
Marius Strobl [Fri, 20 May 2005 12:37:16 +0000 (12:37 +0000)]
Recognize the integrated (though not necessarily enabled) FireWire
controllers of Sun PCIO-2 chips which are used onboard in most of
the newer PCI-based sun4u machines (cosmetic change as they were also
already probed as generic FWOHCI without this). As with gem(4), hme(4)
and ohci(4) detect whether their intpin register is valid and correct
it if necessary, i.e. set the respective IVAR to the right value for
allocating the IRQ resource, as some of them come up having it set
to 0 (in fact in all machines I'm currently aware of the FireWire
part being enabled). This fixes attaching affected controllers.
Gleb Smirnoff [Fri, 20 May 2005 07:16:09 +0000 (07:16 +0000)]
Calling xl_rxeof() at the end of xl_start_locked() leads to recursion
in case of IP fast forwarding. Enqueue a taskqueue(9) task instead of
calling xl_rxeof() directly.
Nate Lawson [Fri, 20 May 2005 05:00:43 +0000 (05:00 +0000)]
If devclass_get_devices() returns success but a count of 0, free the
pointer. If kernel malloc(0) returns a valid pointer, it needs to be
freed. If it returns NULL, it's ok to free this also.
Bill Paul [Fri, 20 May 2005 04:00:50 +0000 (04:00 +0000)]
Deal with a few bootstrap issues:
We can't call KeFlushQueuedDpcs() during bootstrap (cold == 1), since
the flush operation sleeps to wait for completion, and we can't sleep
here (clowns will eat us).
On an i386 SMP system, if we're loaded/probed/attached during bootstrap,
smp_rendezvous() won't run us anywhere except CPU 0 (since the other CPUs
aren't launched until later), which means we won't be able to set up
the GDTs anywhere except CPU 0. To deal with this case, ctxsw_utow()
now checks to see if the TID for the current processor has been properly
initialized and sets up the GTD for the current CPU if not.
Lastly, in if_ndis.c:ndis_shutdown(), do an ndis_stop() to insure we
really halt the NIC and stop interrupts from happening.
Note that loading a driver during bootstrap is, unfortunately, kind of
a hit or miss sort of proposition. In Windows, the expectation is that
by the time a given driver's MiniportInitialize() method is called,
the system is already in 'multiuser' state, i.e. it's up and running
enough to support all the stuff specified in the NDIS API, which includes
the underlying OS-supplied facilities it implicitly depends on, such as
having all CPUs running, having the DPC queues initialized, WorkItem
threads running, etc. But in UNIX, a lot of that stuff won't work during
bootstrap. This causes a problem since we need to call MiniportInitialize()
at least once during ndis_attach() in order to find out what kind of NIC
we have and learn its station address.
What this means is that some cards just plain won't work right if
you try to pre-load the driver along with the kernel: they'll only be
probed/attach correctly if the driver is kldloaded _after_ the system
has reached multiuser. I can't really think of a way around this that
would still preserve the ability to use an NDIS device for diskless
booting.