Re: CVS commit: src/usr.bin/grep
On Thu, Feb 17, 2011 at 12:06:30PM +0900, enami tsugutomo wrote:
I just did `more fastgrep.c' and found following piece of code. The
usage of wflag is an obvious regression from OpenBSD code.
| if (fg-len = 14
| strncmp(pat + (fg-bol ? 1 : 0), [[::]], 7) == 0
| strncmp(pat + (fg-bol ? 1 : 0) + fg-len - 7, [[::]], 7) == 0) {
| fg-len -= 14;
| /* Word boundary is handled separately in util.c */
| wflag = true;
| }
It looks like that might transform:
grep '[[::]]foo.*bar[[::]]'
to
grep -w 'foo.*bar'
which isn't a valid transform.
(I presume something else translated the original '\foo.*bar\' ...)
I've known grep where searches for '\word\' were a lot faster than
using -w. Presumably because -w locates the words (start and end)
rather than just the start!
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/dev/acpi
The so-called wakedev code might be broken for a short while. The reasons are listed below. - Jukka. On Thu, Feb 17, 2011 at 10:49:30AM +, Jukka Ruohonen wrote: Module Name: src Committed By: jruoho Date: Thu Feb 17 10:49:30 UTC 2011 Modified Files: src/sys/dev/acpi: acpi_ec.c acpi_wakedev.c Log Message: ACPICA 20101209: Completed the major overhaul of the GPE support code that was begun in July 2010. Major features include: removal of _PRW execution in ACPICA (host executes _PRWs anyway), cleanup of wake GPE interfaces and processing, changes to existing interfaces, simplification of GPE handler operation, and a handful of new interfaces: AcpiUpdateAllGpes AcpiFinishGpe AcpiSetupGpeForWake AcpiSetGpeWakeMask ACPICA 20100331: Completed a major update for the GPE support in order to improve support for shared GPEs and to simplify both host OS and ACPICA code. Added a reference count mechanism to support shared GPEs that require multiple device drivers. Several external interfaces have changed. One external interface has been removed. One new external interface was added. Most of the GPE external interfaces now use the GPE spinlock instead of the events mutex (and the Flags parameter for many GPE interfaces has been removed.) See the updated ACPICA Programmer Reference for details. Matthew Garrett, Bob Moore, Rafael Wysocki. ACPICA BZ 831. Changed: AcpiEnableGpe, AcpiDisableGpe, AcpiClearGpe, AcpiGetGpeStatus Removed: AcpiSetGpeType New: AcpiSetGpe ACPICA 20100702: Implemented several updates to the recently added GPE reference count support. The model for wake GPEs is changing to give the host OS complete control of these GPEs. Eventually, the ACPICA core will not execute any _PRW methods, since the host already must execute them. Also, additional changes were made to help ensure that the reference counts are kept in proper synchronization with reality. Rafael J. Wysocki. 1) Ensure that GPEs are not enabled twice during initialization. 2) Ensure that GPE enable masks stay in sync with the reference count. 3) Do not inadvertently enable GPEs when writing GPE registers. 4) Remove the internal wake reference counter and add new AcpiGpeWakeup interface. This interface will set or clear individual GPEs for wakeup. 5) Remove GpeType argument from AcpiEnable and AcpiDisable. These interfaces are now used for runtime GPEs only. To generate a diff of this commit: cvs rdiff -u -r1.68 -r1.69 src/sys/dev/acpi/acpi_ec.c cvs rdiff -u -r1.20 -r1.21 src/sys/dev/acpi/acpi_wakedev.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/dev/acpi
On Thu, Feb 17, 2011 at 07:36:49PM +, Jukka Ruohonen wrote: Log Message: As explained in the new ACPICA documentation, as of ACPICA 20101207, the _PRW methods are no longer automatically executed as part of the ACPICA initialization. Refactor and rewrite the wake-device code to account this. Despite of testing before the import, a regression still slipped through. The following change that affects acpiec(4) is the most plausible culprit: Re-introduced the support to enable multi-byte transfers for Embedded Controller (EC) operation regions. A reported problem was found to be a bug in the host OS, not in the multi-byte support. Previously, the maximum data size passed to the EC operation region handler was a single byte. There are often EC Fields larger than one byte that need to be transferred, and it is useful for the EC driver to lock these as a single transaction. This change enables single transfers larger than 8 bits. This effectively changes the access to the EC space from ByteAcc to AnyAcc, and will probably require changes to the host OS Embedded Controller driver to enable 16/32/64/256-bit transfers in addition to 8-bit transfers. Alexey Starikovskiy, Lin Ming. (ACPICA 20100806.) I don't have cycles to debug this any more today, but I will continue tomorrow. In the meanwhile, if someone has an idea about this, please feel free to join. - Jukka.
Re: CVS commit: src/sys/external/bsd/drm/dist/bsd-core
On 18.02.11 00:21, Jonathan A. Kollasch wrote:
Module Name: src
Committed By: jakllsch
Date: Thu Feb 17 23:21:54 UTC 2011
Modified Files:
src/sys/external/bsd/drm/dist/bsd-core: drm_pciids.h
Log Message:
Add the RS880 device IDs to radeondrm(4).
To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/sys/external/bsd/drm/dist/bsd-core/drm_pciids.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/external/bsd/drm/dist/bsd-core/drm_pciids.h
diff -u src/sys/external/bsd/drm/dist/bsd-core/drm_pciids.h:1.5
src/sys/external/bsd/drm/dist/bsd-core/drm_pciids.h:1.6
--- src/sys/external/bsd/drm/dist/bsd-core/drm_pciids.h:1.5 Thu Jan 6
11:07:48 2011
+++ src/sys/external/bsd/drm/dist/bsd-core/drm_pciids.h Thu Feb 17
23:21:53 2011
@@ -393,7 +393,12 @@
{0x1002, 0x9552, CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP, ATI
Mobility Radeon 4300 Series}, \
{0x1002, 0x9553, CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP, ATI
Mobility Radeon 4500 Series}, \
{0x1002, 0x9555, CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP, ATI
Mobility Radeon 4500 Series}, \
- {0x1002, 0x9712,
CHIP_RV620|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility HD 4200}, \
+ {0x1002, 0x9710, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4200}, \
+ {0x1002, 0x9711, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon RS880}, \
+ {0x1002, 0x9712,
CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility HD 4200}, \
+ {0x1002, 0x9713,
CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility RS880}, \
+ {0x1002, 0x9714, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4290}, \
+ {0x1002, 0x9715, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4250}, \
{0, 0, 0, NULL}
Are you sure some of them aren't actually RS780 chips ?
Christoph
#define r128_PCI_IDS \
re: CVS commit: src/sys
Module Name: src Committed By: rmind Date: Thu Feb 17 18:32:29 UTC 2011 Modified Files: src/sys/conf: files src/sys/sys: cpu_data.h lwp.h Added Files: src/sys/kern: subr_pcu.c src/sys/sys: pcu.h Log Message: Add PCU (Per-CPU Unit) - an interface to manage synchronization of any per CPU context tied with an LWP. Main use - lazy FPU handling on SMP. Requested by matt@, will be used on mips64. Note: implementation will be improved to use IPIs before adopting on x86. OK ad@. why is this compiled on every port when no one uses it yet and most of them never will? .mrg.
re: CVS commit: src/sys/external/bsd/drm/dist/bsd-core
- {0x1002, 0x9712,
CHIP_RV620|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility HD 4200}, \
+ {0x1002, 0x9710, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4200}, \
+ {0x1002, 0x9711, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon RS880}, \
+ {0x1002, 0x9712,
CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility HD 4200}, \
+ {0x1002, 0x9713,
CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility RS880}, \
+ {0x1002, 0x9714, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4290}, \
+ {0x1002, 0x9715, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4250}, \
{0, 0, 0, NULL}
Are you sure some of them aren't actually RS780 chips ?
the new code matches the linux drm driver.
.mrg.
Re: CVS commit: src/sys
On Thu, Feb 17, 2011 at 8:27 PM, Matt Thomas m...@netbsd.org wrote: Module Name: src Committed By: matt Date: Thu Feb 17 19:27:13 UTC 2011 Modified Files: src/sys/kern: kern_kthread.c src/sys/uvm: uvm_extern.h uvm_glue.c Log Message: Add support for cpu-specific uarea allocation routines. Allows different allocation for user and system lwps. MIPS will use this to map uareas of system lwp used direct-mapped addresses (to reduce the overhead of switching to kernel threads). ibm4xx could use to map uareas via direct mapped addresses and avoid the problem of having the kernel stack not in the TLB. To generate a diff of this commit: cvs rdiff -u -r1.30 -r1.31 src/sys/kern/kern_kthread.c cvs rdiff -u -r1.170 -r1.171 src/sys/uvm/uvm_extern.h cvs rdiff -u -r1.147 -r1.148 src/sys/uvm/uvm_glue.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Hi, I get the idea of this change but not quite complete. First I got the a compile error on amd64, thats what made me look at it. An ifdef arround the initialization of the uvm_uarea_system_cache is missing. What are the cpu_uarea_alloc functions supposed to do, differently from the PMAP_MAP_POOLPAGE approach, I guess they are able to alloc multiplies of PAGE_SIZE with the correct alignment, if so once they are in place the PMAP_MAP_POOLPAGE is not required any more? I think MIPS currently uses PMAP_MAP_POOLPAGE. And why treat system lwp uareas differently from user ones? Sorry if I miss something here. Greetings, Lars -- Mystische Erklärungen: Die mystischen Erklärungen gelten für tief; die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind. -- Friedrich Nietzsche [ Die Fröhliche Wissenschaft Buch 3, 126 ]
Re: CVS commit: src/sys/external/bsd/drm/dist/bsd-core
On 18.02.11 07:00, matthew green wrote:
- {0x1002, 0x9712,
CHIP_RV620|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility HD 4200}, \
+ {0x1002, 0x9710, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4200}, \
+ {0x1002, 0x9711, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon RS880}, \
+ {0x1002, 0x9712,
CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility HD 4200}, \
+ {0x1002, 0x9713,
CHIP_RS880|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI Radeon
Mobility RS880}, \
+ {0x1002, 0x9714, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4290}, \
+ {0x1002, 0x9715, CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP, ATI
Radeon HD 4250}, \
{0, 0, 0, NULL}
Are you sure some of them aren't actually RS780 chips ?
the new code matches the linux drm driver.
ok. IIRC there is a PR with a patch that adds an entry for HD4250
which can be closed now.
Christoph
