struct timeval passed to todr_gettime(9) and todr_settime(9).
We no longer have an ancient and volatile struct timeval `time'
global since we have switched to MI timercounter(9) on all port.
XXX1: some of these RTC drivers still assume 32bit time_t
XXX2: some of these should be rewritten to use todr_[gs]ettime_ymdhms()
XXX3: todr(9) man page doesn't mention todr_[gs]ettime_ymdhms()
struct timeval passed to todr_gettime(9) and todr_settime(9).
We no longer have an ancient and volatile struct timeval `time'
global since we have switched to MI timercounter(9) on all port.
XXX1: some of these RTC drivers still assume 32bit time_t
XXX2: some of these should be rewritten to use todr_[gs]ettime_ymdhms()
XXX3: todr(9) man page doesn't mention todr_[gs]ettime_ymdhms()
- An argument of struct timeval *tv passed by todr_gettime(9) is used
for a return value and it doesn't contain valid data. Don't read it.
- Instead, use getmicrotime(9) to get a "reasonable" (i.e. current) time
to see expected year value (which is not kept by this device).
- If current time is not valid, assume this is the first todr_gettime(9)
call from inittodr(9) and use file system time for the "reasonable" year.
Fixes silent hangup after mountroot() on sun2.
XXX: MI todr(9) functions seem to get mangled around year ~22000.
do drain' in many places, whereas fo_drain() was called in order to force
blocking read()/write() etc calls to return to userspace so that a close()
call from a different thread can complete.
In the sockets code comment out the broken code in the inner function,
it was being called from compat code.
compatibility. Both fields are now unsigned.
Add compatibility for the old ioctl size.
Detect and error files which are definitely sparse (va_bytes < va_size).
Part of fix for PR/41873.
illegal. I examined all places where lbolt is referenced to make
sure there were pointer aliases of it passed to tsleep, but put a
KASSERT in m/ltsleep() just to be sure.
PHY address first. Avoid problem with bogus ukphy's attaching on the
internal PHY of the SB1000.
Also, take some quirks for internal, external or either MII PHY from
the OpenBSD driver.
Where possible values have been checked against the pcidatabase and x.org.
In some cases I've only commented on some dubious entries!
Values will be picked up by the next update.
Info from PR/36487
Shuffle some bus_dmamem_ operations around, so they actually clean up
in the correct order.
Do not destroy a callout that might be stopped by if_detach later.
When detaching child devices fails, we have passed the point of no return
already, so complete our own cleanup and return the error in the end.
This happens for example when we have been unable to accomodate all phy
devices at attach time (and this is a separate bug).
this breaks abstraction. Because only lvmtools/lvmlib and device-mapper can
have knowledge about target mapping and libdevmapper only passes requests
from lvmtools to kernel and back. Bump major library and driver version.
Requested by: yamt@
Ported by FUKAUMI Naoki from OpenBSD with many modification.
No particular comments (except from me) on tech-kern@.
There are still many TODO even in MI wscons(4) API to handle this device:
* No detach function for wsdisplay(9).
Unpluging a device causes a panic. (should be trivial?)
* ioctl() for X server support is currently commented out. ("notyet")
OpenBSD allows device depedent ioctl()s and they introduced
UDLIO_DAMAGE ioctl for the damage extension ops of X servers for udl(4).
Before blindly pulling such ioctl(), probably we should discuss
how such specific operations should be handled in MI wscons(4) API.
* Screen text of wsemul tty could be mangled during large scroll ops.
All tty output operations are invoked via ttstart() with the giant
tty_lock mutex held, so we can't call cv_wait(9) to wait resources
for data xfers via usbdi(9).h, then text output is silently discarded
on resource shortage. To handle this without tty_lock reorganization,
we have to change wsdisplay(9) APIs (especially wsdisplaystart()) to
return a number of actually handled characters as OpenBSD does, but
it may require whole API changes around child rasops(9) etc.
* No MI API definition to convert mmap(9) cookie to physical address.
The conversion is required to create a cookie which will be passed to
pmap_phys_address(9) in uvm/uvm_device.c:udv_fault(). Most other
drivers use bus_dmamem_mmap(9) or bus_space_mmap(9), but udl(4) uses
kmem_alloc(9)'ed memory for bitmap data.
Furthermore, pmap(9) man page says about pmap_phys_address(9):
"This function is provided to accommodate systems which have
physical address spaces larger than can be directly addressed
by the platform's paddr_t type. The existence of this function is
highly dubious, and it is expected that this function will be
removed from the pmap API in a future release of NetBSD."
As the man page says we have already had split paddr_t and vaddr_t,
so it's time to remove such old ugly cookie and change all mmap(4)
functions (mostly in MD bus_dma(9) and bus_space(9) APIs) to return
simple physical address in paddr_t?
* We need proper device names for wsdisplay1 (and more devices).
Currently wsdisplay0 uses ttyE0 through ttyE253 (minor 0 to 253)
for screens, ttyEstat (254) for status, and ttyEcfg (255) for config.
The next wsdisplay1 will use 256 through 509 for screens, 510 for stat,
and 511 for config but what names should we use for them? ttyFxxx?
* How to handle multiple sets of wskbd/wsdisplay on a single machine.
rc.d/wscons doesn't provide method to specify wscons control devices.
There is no proper interface to specify which keyboard should be connected
to which wsdisplay, etc.
* And maybe more...
HP Pavillion dv9700 laptop features a fan sensor
in the ACPI Thermal Zone which is beyond of the ACPI
Spec.
envstat shows
[acpitz0]
Processor Thermal Zone: 56.000 95.000 degC
FAN: 2840 RPM
envstat -W shows the limits
[acpitz0]
Processor Thermal Zone: 55.000 degC
FAN: 2570 4500 2000 RPM
Patch presented on tech-kern@.
No comments.
Also,
Change bus_space_subregion() size for each SATA PHY register from 1 to 4,
as we do a bus_space_read_4() within these subregions.
Use PCI_MAPREG_START where appropriate.
works fine and is consistent with the other VIA SATA controllers.
Tested on VT8237R+.
(Somewhat amazing that via_sata_chip_map_0() worked at all for the
second port.)
Add support for the Broadcom BCM5709 and BCM5716 chips. This upgrade
the B06 firmware, and add the B09 firmware required by the BCM5709.
Remplace TX dmamap array with a dynamically-grown list.
Tested with:
bnx0 at pci4 dev 0 function 0: Broadcom NetXtreme II BCM5708 1000Base-T
and
bnx0 at pci0 dev 0 function 0: Broadcom NetXtreme II BCM5709 1000Base-SX
Now igsfb will switch to 16 or 32 bit colour when entering graphics mode,
depending on available video memory and the given mode.
While there re-initialize the colour map etc. when leaving graphics mode.
Drastically reduces the amount of time spent rewriting parity after an
unclean shutdown by keeping better track of which regions might have had
outstanding writes. Enabled by default; can be disabled on a per-set
basis, or tuned, with the new raidctl(8) commands.
Discussed on tech-kern@ to a general air of approval; exhortations to
commit from mrg@, christos@, and others.
Thanks to Google for their sponsorship, oster@ for mentoring the
project, assorted developers for trying very hard to break it, and
probably more I'm forgetting.
for pointing out that these drivers still used com_activate().
Use device_private(). Join some lines.
Remove superfluous activation hooks.
Add child-detachment hooks (not used, yet).
TBD: device_t/softc split.
activation hook, pcmcom_activate().
Add a child-detachment hook and use it.
Use device_private().
Cosmetic: use __arraycount(). Join a couple of lines. Delete a
set of superfluous parentheses.
belonged. Remove com_activate().
Consolidate information about the console on com(4) in a new struct
comcons_info.
Support detachment & re-attachment of a system console on com(4).
Re-attachment is somehow incomplete. Ideally, if some other device
could take over as console, it would, but we're not quite there,
yet.
children will not detach, the instance is not left in an inconsistent
state.
If uhub(4) port is disconnected, forcefully detach the children on
that port.
Simplify detachment hooks. (sc_dying must die!)
Pass along and respect detachment flags, esp. DETACH_FORCE,
throughout.
Don't take a device off of the ppbus(4)'s list of children in the
detach routine, but add a child-detachment hook that does it for
us. As a nice side-effect, we can probably detach ppbus(4) children
with drvctl(8), now.
Compile-tested, only.
XXX Does anybody even use ppbus(4)? It's not even in the ALL
XXX configuration for i386!
on sparc64 with a Sun PGX32 / TechSource Raptor GFX 8P
So far it accelerates block copies, rectangle fills and the cursor, it
supports the usual wsdisplay / vcons stuff.
TODO:
- character drawing by hardware so we don't need to map the framebuffer
- DDC2 support
- mode setting
This driver still relies on the firmware to set up graphics modes etc. so it
won't work on x86 ( or non-OpenFirmware for that matter ) unless you use the
VESA BIOS to set up graphics and pass the right properties ( width, height
etc. ) to the driver. For the same reason it will work only if it's the
OpenFirmware console.
- Addresses the issue described in PR/38828.
- Some simplification in threading and sleepq subsystems.
- Eliminates pmap_collect() and, as a side note, allows pmap optimisations.
- Eliminates XS_CTL_DATA_ONSTACK in scsipi code.
- Avoids few scans on LWP list and thus potentially long holds of proc_lock.
- Cuts ~1.5k lines of code. Reduces amd64 kernel size by ~4k.
- Removes __SWAP_BROKEN cases.
Tested on x86, mips, acorn32 (thanks <mpumford>) and partly tested on
acorn26 (thanks to <bjh21>).
Discussed on <tech-kern>, reviewed by <ad>.
