- 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]
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).
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).
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).
Requested by: joerg, marcel, yongari
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.
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.
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.
MFC after: 1 month
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.
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.
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.
Discussed with: bde
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.
Apporved by: simokawa
Tested by: Michiel Boland <michiel@boland.org>
MFC after: 1 month
in case of IP fast forwarding. Enqueue a taskqueue(9) task instead of
calling xl_rxeof() directly.
Reported & tested by: Slava Alpatov
Reviewed by: wpaul
MFC after: 1 week
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.
Submitted by: pjd
Reviewed by: imp, dfr
Obtained from: Coverity Prevent
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.
prevent anything from making calls to the NIC while it's being shut down.
This is yet another attempt to stop things like mdnsd from trying to
poke at the card while it's not properly initialized and panicking
the system.
Also, remove unneeded debug message from if_ndis.c.
user to interrupt autoboot process at all. Currently, even when
`autoboot_delay' is set to 0, loader(8) still allows autoboot process to be
interrupted by pressing any key on the console when the loader reads kernel
and modules from the disk. In some cases (i.e. untrusted environment) such
behaviour is highly indesirable and user should not be allowed to interfere
with the autoboot process at all.
Sponsored by: PBXpress Inc.
MFC after: 3 days
are used onboard in most of the newer PCI-based sun4u machines
(cosmetic change as they were also already probed as generic OHCI
without this). 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 (mainly those used in Blade 100 and the first
one on AX1105 boards). This fixes attaching affected controllers.
Correcting the intpin value might be better off in the PCI code
via a quirk table but on the other hand gem(4) and hem(4) also
correct it themselves and at least for the USB controller part
the intpin register is truely hardwired to 0 and can't be changed.
This means that we would have to hook up the quirk information
in a lot of places in the PCI code (i.e. whenever the value of the
intpin register is read from or written to the pci_devinfo of the
respective device) in order to do it the right way.
MFC after: 1 month
- Add locking.
- Account for if the MC146818_NO_CENT_ADJUST flag is set we don't need
to check wheter year < POSIX_BASE_YEAR.
- Add some comments about mapping the day of week from the range the
generic clock code uses to the range the chip uses and which I meant
to add in the initial version.
- Minor clean-up, use __func__ instead of hardcoded function names in
error strings.
o in the rtc(4) front-end additionally:
- Don't leak resources in case mc146818_attach() fails.
- Account for ebus(4) defaulting to SYS_RES_MEMORY for the memory
resources since ebus.c rev. 1.22.
- Add support for storing the century in MK48TXX_WDAY_CB on MK48Txx with
extended registers when the MK48TXX_NO_CENT_ADJUST flag is set (and which
is termed somewhat confusing as it actually means don't manually adjust
the century in the driver).
- Add the MI part of interfacing the watchdog functionality of MK48Txx with
extended registers with watchdog(9). This is inspired by the SunOS/Solaris
drivers for the 'eeprom' devices also having watchdog support. I actually
expected this to work out of the box on Sun Exx00 machines with 'eeprom'
devices which have a 'watchdog-enable' property. On terminal count of the
the watchdog timer however only the MK48TXX_FLAGS_WDF bit rises but the
reset signal and the interrupt respectively (depending on whether the
MK48TXX_WDOG_WDS bit of the chip and the MK48TXX_WDOG_ENABLE_WDS flag
of the driver respectively is set) goes nowhere. Apparently passing the
reset signal on to the WDR line of the CPUs has to be enabled somewhere
else but we don't have documentation for the Exx00 specific controllers.
I decided to commit this nevertheless so it can be enabled in the eeprom(4)
front-end later in e.g. 6.0-STABLE without breaking the API. Besides the
Exx00 the watchdog part of the MK48Txx should also work on E250 and E450.
Possibly also without extra fiddling on these machines but I haven't
found someone willing to give it a try on such a machine so far.
- Use uintXX_t instead of u_intXX_t, use __func__ instead of hardcoded
function names in error strings.
eeprom_ebus_attach() and eeprom_sbus_attach() into eeprom_attach()
respectively. Since the introduction of the ofw_bus interface some
time ago and now that ebus(4) also uses SYS_RES_MEMORY for the
memory resources since ebus.c rev. 1.22 there is no longer a
need to have separate front-ends for ebus(4), fhc(4) and sbus(4).
- Fail gracefully instead of panicing when the model can't be
determined.
- Don't leak resources when mk48txx_attach() fails.
- Use FBSDID.
compatibility with ISA devices while in fact all known EBus devices
actually use memory space turned out to be not a good idea as so far
there is only the 'rtc' device known to show up either on an EBus or
ISA bus but not on any of the other busses used on sparc64. However
there are quite a couple of them that show up on either EBus, FireHose
or SBus. In order to save extra code in the respective drivers switch
ebus(4) to actually use SYS_RES_MEMORY for the memory resources of
its children. At least for transition still accept SYS_RES_IOPORT
and silently change it to SYS_RES_MEMORY. [1]
- In ebus_probe() use ofw_bus_get_name() instead of re-implementing it
via ofw_bus_get_node() and OF_getprop().
- Remove some unused variables.
- Use FBSDID.
Discussed with: tmm (some time ago)
the iteration variable as the RID when adding the respective resource
to the child via bus_set_resource(). In case a device has both I/O
and memory resources this generates gaps in the newbus resources of
the child, e.g. its first memory resource might end up as RID 1.
To solve this mimic resource_list_add_next() via resource_list_find()
and bus_set_resource(); we can't just use resource_list_add_next()
here as this would circumvent the limit checks in isa_set_resource()
of the common ISA code.
This however is more or less a theoretical problem so far as all known
ISA devices on sparc64 soley use I/O space.
- Just use bus_generic_rl_release_resource() for isa_release_resource()
instead of re-implementing the former.
- Improve some comments to better reflect reality, minor clean-up and
simplifications, return NULL instead of 0 were appropriate.
front-end and the LSI64854 and NCR53C9x code in case one of these
functions fails. Add detach functions to these parts and make esp(4)
detachable.
- Revert rev. 1.7 of esp_sbus.c, since rev. 1.34 of sbus.c the clockfreq
IVAR defaults to the per-child values.
- Merge ncr53c9x.c rev. 1.111 from NetBSD (partial):
On reset, clear state flags and the msgout queue.
In NetBSD code to notify the upper layer (i.e. CAM in FreeBSD) on reset
was also added with this revision. This is believed to be not necessary
in FreeBSD and was not merged.
This makes ncr53c9x.c to be in sync with NetBSD up to rev. 1.114.
- Conditionalize the LSI64854 support on sbus(4) only instead of sbus(4)
and esp(4) as it's also required for the 'dma', 'espdma' and 'ledma'
busses/devices as well as the 'SUNW,bpp' device (printer port) which
all hang off of sbus(4).
- Add a driver for the 'dma', 'espdma' and 'ledma' (pseudo-)busses/
devices. These busses and devices actually represent the LSI64854 DMA
engines for the ESP SCSI and LANCE Ethernet controllers found on the
SBus of Ultra 1 and SBus add-on cards. With 'espdma' and 'ledma' the
'esp' and 'le' devices hang off of the respective DMA bus instead of
directly from the SBus. The 'dma' devices are either also used in this
manner or on some add-on cards also as a companion device to an 'esp'
device which also hangs off directly from the SBus. With the latter
variant it's a bit tricky to glue the DMA engine to the core logic of
the respective 'esp' device. With rev. 1.35 of sbus.c we are however
guaranteed that such a 'dma' device is probed before the respective
'esp' device which simplifies things a lot. [1]
- In the esp(4) SBus front-end read the part-unique ID code of Fast-SCSI
capable chips the right way. This fixes erroneously detecting some
chips as FAS366 when in fact they are not. Add explicit checks for the
FAS100A, FAS216 and FAS236 variants instead treating all of these as
ESP200. That way we can correctly set the respective Fast-SCSI config
bits instead of driving them out of specs. This includes adding the
FAS100A and FAS236 variants to the NCR53C9x core code. We probably
still subsume some chip variants as ESP200 while in fact they are
another variant which however shouldn't really matter as this will
only happen when these chips are driven at 25MHz or less which implies
not being able to run Fast-SCSI. [3]
- Add a workaround to the NCR53C9x interrupt handler which ignores the
stray interrupt generated by FAS100A when doing path inquiry during
boot and which otherwiese would trigger a panic.
- Add support for the 'esp' devices hanging off of a 'dma' or 'espdma'
busses or which are companions of 'dma' devices to esp(4). In case of
the variants that hang off of a DMA device this is a bit hackish as
esp(4) then directly uses the softc of the respective parent to talk
to the DMA engine. It might make sense to add an interface for this
in order to implement this in a cleaner way however it's not yet clear
how the requirements for the LANCE Ethernet controllers are and the
hack works for now. [2]
This effectively adds support for the onboard SCSI controller in
Ultra 1 as well as most of the ESP-based SBus add-on cards to esp(4).
With this the code for supporting the Performance Technologies SBS430
SBus SCSI add-on cards is also largely in place the remaining bits
were however omitted as it's unclear from the NetBSD how to couple
the DMA engine and the core logic together for these cards.
Obtained from: OpenBSD [1]
Obtained from: NetBSD [2]
Clue from: BSD/OS [3]
Reviewed by: scottl (earlier version)
Tested with: FSBE/S add-on card (FAS236), SSHA add-on card (ESP100A),
Ultra 1 (onboard FAS100A), Ultra 2 (onboard FAS366)
device and which also applies to the children. This is very usefull for
drivers for the various subordinate busses so they don't need to fiddle
with the OFW node of their parent themselves. As SBus busses hang of the
nexus and we don't use the ofw_bus interface for nexus devices, yet, this
would also require special knowledge about this in the drivers for the
SBus children which these shouldn't need to have.
This includes switching to use an unshifted IGN in the sc_ign member of
the sbus(4) softc internally.
- For SBus child devices where there are variants that are actually split
split into two SBus devices (as opposed to the first half of the device
being a SBus device and the second half hanging off of the first one)
like 'auxio' and 'SUNW,fdtwo' or 'dma' and 'esp' probe the SBus device
which is a prerequisite to the driver attaching to the second one with
a lower order. This saves us from dealing with different probe orders
in the respective device drivers which generally is more hackish.
- Remove a stale comment about the 'specials' array above the attaching
of the child devices. This is a remnant of the NetBSD/sparc origin of
this code. There the 'specials' array is also used to probe certain
devices which are prerequisites to others first. Why NetBSD soley
relies on the devices having the expected order in the OFW tree on
sparc64 isn't clear to me, as far as I can tell OFW doesn't guaranteed
such things.
copying, rather than a page at a time. This was creating far
too many single-page mappings, and eventually OFW overflowed
some internal data structure and refused to map any more.
The new algorithm creates far less mappings and fixed a bug
where multiple mappings for the same page would be created.
'Twas known this was a problem, but only became urgent when the
install CD's mfs_root grew large enough to cause the overflow.
works again.
This driver uses NdisScheduleWorkItem(), and we have to take special steps
to insure that its workitems don't collide with any of the other workitems
used by the NDISulator. In particular, if one of the driver's work jobs
blocks, it can prevent NdisMAllocateSharedMemoryAsync() from completing
when expected.
The original hack to fix this was to have NdisMAllocateSharedMemoryAsync()
defer its work to the DPC queue instead of the general task queue. To
fix it now, I decided to add some additional workitem threads. (There's
supposed to be a pool of worker threads in Windows anyway.) Currently,
there are 4. There should be at least 2. One is reserved for the legacy
ExQueueWorkItem() API, while the others are used in round-robin by the
IoQueueWorkItem() API. NdisMAllocateSharedMemoryAsync() uses the latter
API while NdisScheduleWorkItem() uses the former, so the deadlock is
avoided.
Fixed NdisMRegisterDevice()/NdisMDeregisterDevice() to work a little
more sensibly with the new driver_object/device_object framework. It
doesn't really register a working user-mode interface, but the existing
code was completely wrong for the new framework.
Fixed a couple of bugs dealing with the cancellation of events and
DPCs. When cancelling an event that's still on the timer queue (i.e.
hasn't expired yet), reset dh_inserted in its dispatch header to FALSE.
Previously, it was left set to TRUE, which would make a cancelled
timer appear to have not been cancelled. Also, when removing a DPC
from a queue, reset its list pointers, otherwise a cancelled DPC
might mistakenly be treated as still pending.
Lastly, fix the behavior of ntoskrnl_wakeup() when dealing with
objects that have nobody waiting on them: sync event objects get
their signalled state reset to FALSE, but notification objects
should still be set to TRUE.
occur on a filesystem running with soft updates after a crash and
before a background fsck has been run. To prevent discrepancies
from arising in a background fsck that may already be running,
the directory is removed but its inode is not freed and is left
with the residual reference count. When encountered by the
background fsck it will be reclaimed.
