GitHub PushEvent at 2014-07-21 07:20:42
Repository: unix-history-repo
Actor: dspinellis
Payload: {"shas":[["92b1687a24efcdb8bd0f80e6121127595fb54ab5","33fd0301077bc24fc6513513c71e288fcecc0c66@FreeBSD.org","Merge r203622 from head:\n\n  Add support for a few more Sony-specific ACPI features (default display\n  brightness, wired LAN power and bass gain), and update the description of\n  one previously unknown feature (display contrast).  While here, expand on\n  a comment and remove two defines left over from an old version of the code.\n\n  Also update man page to document the above changes, and correct grammar.\n\nPR:\t\tkern/127581","Gavin Atkinson",false],["cc9d3c9a6e293a2346f34d5c9f6e8cd7805fdc42","3055effa054a24f84cf42cea946db4cdf445cb76@FreeBSD.org","MFC r205027\n\nLet detailed info about CPU features print on Marvell Sheeva CPU as well.\n\nProvide missing entry in the cpu_classes[].\n\nReported by:\tMaks Verver","raj",false],["30625375fe3cdd36a11f406c016252bd679ec6c6","562b1713e4f1f0ecc82c764a4239a707fecefd16@FreeBSD.org","MFC r203834 and r205197: Make ALTQ work for drbr consumers.","Max Laier",false],["6d10725f9cbf7022c0ac53a741c339e8ac6e869c","79c7d24101a3af56696b485dbd1362edab3b7da5@FreeBSD.org","MFC r202821-202822.\n\nr202821:\n  Fix a long standing ASF heartbeat sending bug. The initial\n  implementation of heartbeat interval was 2 but there was typo which\n  caused the heartbeat is sent approximately every 5 seconds. This\n  caused unintended controller reset by firmware because firmware\n  thought OS was crashed.\n\n  Submitted by:\tFloris Bos < info <> je-eigen-domein dot nl >\n  Tested by:\tAndrzej Tobola < ato <> iem dot pw dot edu dot pl >\n\nr202822:\n  Use new handshake command for BCM5750 or new controllers.","Pyun YongHyeon",false],["5afabb1b7f26238ce9c66b7e3a5add9e3831f7f5","79c7d24101a3af56696b485dbd1362edab3b7da5@FreeBSD.org","MFC r203355:\n  Add more bit definitions to PCI express device control and device\n  status register.","Pyun YongHyeon",false],["f4a63e1e341b9f3f702b247d58b4c777b3d53f39","79c7d24101a3af56696b485dbd1362edab3b7da5@FreeBSD.org","MFC r203358,203716:\n\nr203358:\n  PCI express device status register has W1C feature. Writing 0 has\n  no effect. Make sure to clear error bits by writing 1. [1]\n  While I'm here use predefined value instead of hardcodig magic\n  vlaue.\n\n  Submitted by:\tmsaitoh at NetBSD [1]\n\nr203716:\n  Move device specific flag configuration to attach routine.\n  The softc obtained in device probe wouldn't be the same one used in\n  device attach. Drivers should not assume any values stored in softc\n  structure in probe routine will be available for its attach routine.","Pyun YongHyeon",false],["cafe6eb34c5b6f7de76f4c6707046c700fb55c9b","79c7d24101a3af56696b485dbd1362edab3b7da5@FreeBSD.org","MFC r202826-202827,204146\n\nr202826:\n  s/Mhz/MHz/g\n\n  Submitted by:\tN.J. Mann <njm <> njm dot me dot uk >\n\nr202827:\n  Yukon Ultra2 has 125MHz clock.\n\nr204146:\n  Correct inversed programming of ethernet hardware address on\n  big-endian architecture.\n\n  Submitted by:\tC. Jayachandran <c.jayachandran at gmail dot com> (initial version)","Pyun YongHyeon",false],["64c8d77b1c92172cf7d7cd3a3fb241606fedb21c","79c7d24101a3af56696b485dbd1362edab3b7da5@FreeBSD.org","MFC r204149:\n  Add TSO support on VLANs. Intentionally separated IFCAP_VLAN_HWTSO\n  from IFCAP_VLAN_HWTAGGING. I think some hardwares may be able to\n  TSO over VLAN without VLAN hardware tagging.\n  Driver changes and userland support will follow.","Pyun YongHyeon",false],["2fed70a08f62008b62a7f1599fa8f351ef48e00f","79c7d24101a3af56696b485dbd1362edab3b7da5@FreeBSD.org","MFC r204150:\n  Add TSO support on VLAN in fconfig(8).","Pyun YongHyeon",false],["df148c1a02854060045bc88c574d4fb9ef86b7e2","79c7d24101a3af56696b485dbd1362edab3b7da5@FreeBSD.org","MFC r202717:\n  - Added a workaround for NC-SI management firmware that would allow\n    frames to be accepted while the driver is resetting the hardware.\n    This failure is generally observed when broadcast frames are received\n    during driver load and will generate \"Unable to write CTX memory\"\n    errors.\n  - Small changes to driver flags display.\n\nPR:\tkern/135836, kern/140684","Pyun YongHyeon",false],["0e7409fc5c4c9c143cc17e6888aca60311166418","67150a9dcf8948cde92f2ba91d8ada0d3335c521@FreeBSD.org","MFC r204755:\nUpdate the list of the process flags. Note that the lists of pending\nsignals for process and its threads are distinct.","Konstantin Belousov",false],["571117aa27b0af4c05b544d9242aa955eddd5861","67150a9dcf8948cde92f2ba91d8ada0d3335c521@FreeBSD.org","MFC r205224:\nAdd missing headers.","Konstantin Belousov",false],["9d8ffdc3b7353e1b64ed9a2deaca9720f412412c","67150a9dcf8948cde92f2ba91d8ada0d3335c521@FreeBSD.org","MFC r205225:\nAdd missing headers. While there, arrange headers alphabetically.","Konstantin Belousov",false],["3dc1cfa3bf72ffeac22665ef3aad355e587ca7ac","5264e5e33945818d30424b6d1b4931acdeab802c@FreeBSD.org","MFC r204082,204179,204180,204218,204241,204247,204270,204692:\n\nProvide thermal management and monitoring features in smu(4). This allows\nfan control and thermal monitoring on SMU-based Apple G5 machines, as well\nas an led(4) interface to control the sleep LED.","Nathan Whitehorn",false],["8f912977777cc463b5035d5867d2ca157fa8505f","5264e5e33945818d30424b6d1b4931acdeab802c@FreeBSD.org","MFC r204903:\n\nPlace interrupt handling in a critical section and remove double\ncounting in incrementing the interrupt nesting level. This fixes a number\nof bugs in which the interrupt thread could be preempted by an IPI,\nindefinitely delaying acknowledgement of the interrupt to the PIC, causing\ninterrupt starvation and hangs.\n\nReported by:\tlinimon\nReviewed by:\tmarcel, jhb","Nathan Whitehorn",false],["183adb2a999ff47d2eb2787966421710d0a8afb2","5264e5e33945818d30424b6d1b4931acdeab802c@FreeBSD.org","Fix a bug where pages being removed from memory entirely no longer have\nPVOs, and so the modified state of the page can no longer be communicated\nto the VM layer, causing pages not to be flushed to swap when needed, in\nturn causing memory corruption. Also make several correctness adjustments\nto I-Cache synchronization and TLB invalidation for 64-bit Book-S CPUs.\n\nObtained from:\tprojects/ppc64\nDiscussed with:\tgrehan","Nathan Whitehorn",false],["99b5c4bdd766e4dce5958bd919f7bd7e411be3b3","5264e5e33945818d30424b6d1b4931acdeab802c@FreeBSD.org","MFC r204128:\n\nReduce KVA pressure on OEA64 systems running in bridge mode by mapping\nUMA segments at their physical addresses instead of into KVA. This emulates\nthe direct mapping behavior of OEA32 in an ad-hoc way. To make this work\nproperly required sharing the entire kernel PMAP with Open Firmware, so\nofw_pmap is transformed into a stub on 64-bit CPUs.\n\nAlso implement some more tweaks to get more mileage out of our limited\namount of KVA, principally by extending KVA into segment 16 until the\nbeginning of the first OFW mapping.\n\nReported by:\tlinimon","Nathan Whitehorn",false],["e79df4ed494558992092be3f1ac9dcdaadfec032","5264e5e33945818d30424b6d1b4931acdeab802c@FreeBSD.org","MFC r204268:\n\nClose a race involving the OEA64 scratchpage. When the scratch page's\nphysical address is changed, there is a brief window during which its PTE\nis invalid. Since moea64_set_scratchpage_pa() does not and cannot hold\nthe page table lock, it was possible for another CPU to insert a new PTE\ninto the scratch page's PTEG slot during this interval, corrupting both\nmappings.\n\nSolve this by creating a new flag, LPTE_LOCKED, such that\nmoea64_pte_insert will avoid claiming locked PTEG slots even if they\nare invalid. This change also incorporates some additional paranoia\nadded to solve things I thought might be this bug.\n\nReported by:\tlinimon","Nathan Whitehorn",false],["d60e1b9b4080e8a77aeab3c8b3a71845fc2363d4","5264e5e33945818d30424b6d1b4931acdeab802c@FreeBSD.org","MFC r204269:\n\nUse dcbz instead of word stores for page zeroing, providing a factor of\n3-4 speedup.","Nathan Whitehorn",false],["582b856d30e81f878f069fc13ef50858e599c9b8","5264e5e33945818d30424b6d1b4931acdeab802c@FreeBSD.org","MFC r204296:\n\nProvide an implementation of pmap_dev_direct_mapped() on OEA64. This is\nrequired in order to be able to mmap the running kernel, which is turn\nrequired to avoid fstat returning gibberish.","Nathan Whitehorn",false]],"size":1000,"ref":"refs/heads/FreeBSD-releng/8.1","head":"b2e8c8fcd84932cd0c041f7aefc6c49793ddcce2"}