Re: pf.conf(5) man page set limit BNF fix
On Sun, May 01, 2011 at 08:40:39PM -0400, Lawrence Teo wrote: PF's set limit option allows five memory pools to be specified (states, frags, src-nodes, tables, and table-entries); however, the pf.conf BNF grammar specification on the pf.conf(5) man page only lists three. The following diff fixes this by completing the list of possible values for the limit-item symbol. Does it look ok? Thanks, Lawrence fixed, thanks! jmc Index: pf.conf.5 === RCS file: /cvs/src/share/man/man5/pf.conf.5,v retrieving revision 1.492 diff -u -p -r1.492 pf.conf.5 --- pf.conf.5 6 Apr 2011 13:20:44 - 1.492 +++ pf.conf.5 1 May 2011 19:07:49 - @@ -2799,7 +2799,8 @@ timeout= ( tcp.first | tcp.op adaptive.start | adaptive.end ) number limit-list = limit-item [ [ , ] limit-list ] -limit-item = ( states | frags | src-nodes ) number +limit-item = ( states | frags | src-nodes | tables | + table-entries ) number pooltype = ( bitmask | random | source-hash [ ( hex-key | string-key ) ] |
Re: alc(4) support for Atheros AR815x
On Sun, 2011-05-01 at 18:35 +0100, Edd Barrett wrote: On Thu, Apr 28, 2011 at 07:21:16AM +1000, Jonathan Gray wrote: On Tue, Jan 25, 2011 at 06:24:28PM +0800, Kevin Lo wrote: Hi, The following diff adds support for Atheros AR8151/AR8152 chipsets; mostly from FreeBSD. It also fixes an issue i386/6311. Tested on Acer AOD255E. Is there an updated diff for this? It seems this never made it into the tree. I have acquired a netboot (packard bell dot s), which I think uses this NIC. Is there an updated diff? Hi Edd, A couple of days ago jsg@ asked the same question: http://marc.info/?l=openbsd-techm=130393940030183w=2 I forgot to cc tech@. Sorry, I've lacked alc hardware, I have no updated diff. Kevin
malloc: speedup chunk housekeeping
Hi,
Currently, malloc scans the bits of the chunk bitmap from position
zero, skipping a random number (n) of free slots and then picking the
next free one. This slows things down, especially if the number of
full slots diminishes.
This diff changes the scannning to start at a random position in the
bitmap and then taking the first available free slot, wrapping if the
end of the bitmap is reached. Of course we'll still scan more if the
bitmap becomes more full, but the extra iterations skipping free slots
and then some full slots are avoided.
The random number is derived from a global, which is incremented by a
few bits every time a chunk is needed (with a small optimization if
only one free slot is left).
The shows good speedups, especially if lots of small chunks are
allocated and on e.g. loongson which uses a larger page size than
others, while randomness of chunk allocation is preserved.
Please test review,
-Otto
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.129
diff -u -p -r1.129 malloc.c
--- malloc.c30 Apr 2011 15:46:46 - 1.129
+++ malloc.c2 May 2011 07:27:54 -
@@ -113,6 +113,7 @@ struct dir_info {
struct region_info free_regions[MALLOC_MAXCACHE];
/* delayed free chunk slots */
void *delayed_chunks[MALLOC_DELAYED_CHUNKS + 1];
+ u_short chunk_start;
#ifdef MALLOC_STATS
size_t inserts;
size_t insert_collisions;
@@ -1013,40 +1014,31 @@ malloc_bytes(struct dir_info *d, size_t
if (bp-canary != d-canary1)
wrterror(chunk info corrupted, NULL);
- /* Find first word of bitmap which isn't empty */
- for (lp = bp-bits; !*lp; lp++)
- /* EMPTY */;
-
- /* Find that bit, and tweak it */
- u = 1;
- k = 0;
- while (!(*lp u)) {
- u += u;
- k++;
- }
-
- /* advance a random # of positions */
- if (bp-free 1) {
- i = getrnibble() % bp-free;
- while (i 0) {
- u += u;
- k++;
- if (k = MALLOC_BITS) {
- while (!*++lp)
- /* EMPTY */;
- u = 1;
- k = 0;
- if (lp - bp-bits (bp-total - 1) /
- MALLOC_BITS) {
- wrterror(chunk overflow, NULL);
- errno = EFAULT;
- return (NULL);
- }
- }
- if (*lp u)
- i--;
+
+ i = d-chunk_start;
+ if (bp-free 1)
+ i += getrnibble();
+ if (i = bp-total)
+ i = bp-total - 1;
+ for (;;) {
+ for (;;) {
+ lp = bp-bits[i / MALLOC_BITS];
+ if (!*lp) {
+ i += MALLOC_BITS;
+ i = ~(MALLOC_BITS - 1);
+ if (i = bp-total)
+ i = 0;
+ } else
+ break;
}
+ k = i % MALLOC_BITS;
+ u = 1 k;
+ if (*lp u)
+ break;
+ if (++i = bp-total)
+ i = 0;
}
+ d-chunk_start += i + 1;
*lp ^= u;
Re: malloc: speedup chunk housekeeping
On Mon, May 02, 2011 at 10:09:29AM +0200, Otto Moerbeek wrote:
Hi,
Currently, malloc scans the bits of the chunk bitmap from position
zero, skipping a random number (n) of free slots and then picking the
next free one. This slows things down, especially if the number of
full slots diminishes.
ehh, increases.
This diff changes the scannning to start at a random position in the
bitmap and then taking the first available free slot, wrapping if the
end of the bitmap is reached. Of course we'll still scan more if the
bitmap becomes more full, but the extra iterations skipping free slots
and then some full slots are avoided.
The random number is derived from a global, which is incremented by a
few bits every time a chunk is needed (with a small optimization if
only one free slot is left).
The shows good speedups, especially if lots of small chunks are
allocated and on e.g. loongson which uses a larger page size than
others, while randomness of chunk allocation is preserved.
Please test review,
-Otto
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.129
diff -u -p -r1.129 malloc.c
--- malloc.c 30 Apr 2011 15:46:46 - 1.129
+++ malloc.c 2 May 2011 07:27:54 -
@@ -113,6 +113,7 @@ struct dir_info {
struct region_info free_regions[MALLOC_MAXCACHE];
/* delayed free chunk slots */
void *delayed_chunks[MALLOC_DELAYED_CHUNKS + 1];
+ u_short chunk_start;
#ifdef MALLOC_STATS
size_t inserts;
size_t insert_collisions;
@@ -1013,40 +1014,31 @@ malloc_bytes(struct dir_info *d, size_t
if (bp-canary != d-canary1)
wrterror(chunk info corrupted, NULL);
- /* Find first word of bitmap which isn't empty */
- for (lp = bp-bits; !*lp; lp++)
- /* EMPTY */;
-
- /* Find that bit, and tweak it */
- u = 1;
- k = 0;
- while (!(*lp u)) {
- u += u;
- k++;
- }
-
- /* advance a random # of positions */
- if (bp-free 1) {
- i = getrnibble() % bp-free;
- while (i 0) {
- u += u;
- k++;
- if (k = MALLOC_BITS) {
- while (!*++lp)
- /* EMPTY */;
- u = 1;
- k = 0;
- if (lp - bp-bits (bp-total - 1) /
- MALLOC_BITS) {
- wrterror(chunk overflow, NULL);
- errno = EFAULT;
- return (NULL);
- }
- }
- if (*lp u)
- i--;
+
+ i = d-chunk_start;
+ if (bp-free 1)
+ i += getrnibble();
+ if (i = bp-total)
+ i = bp-total - 1;
+ for (;;) {
+ for (;;) {
+ lp = bp-bits[i / MALLOC_BITS];
+ if (!*lp) {
+ i += MALLOC_BITS;
+ i = ~(MALLOC_BITS - 1);
+ if (i = bp-total)
+ i = 0;
+ } else
+ break;
}
+ k = i % MALLOC_BITS;
+ u = 1 k;
+ if (*lp u)
+ break;
+ if (++i = bp-total)
+ i = 0;
}
+ d-chunk_start += i + 1;
*lp ^= u;
Re: alc(4) support for Atheros AR815x
On 2011/05/02 01:16, Edd Barrett wrote: On Sun, May 01, 2011 at 08:10:56PM +0100, Stuart Henderson wrote: On 2011/05/01 18:35, Edd Barrett wrote: I have acquired a netboot (packard bell dot s), which I think uses this NIC. Is there an updated diff? Yes I just took the 2 minutes it took to apply it and fix the minor conflicts and linewrapping issue with the diff. Untested beyond it builds. Stu's diff seems to work, kevlo's diff really.. although the first time i booted my bsd.rd I was unable to install due to: alc0: watchdog timeout (missed link) I had a report of a system with alc(4) which only works if the cable is connected at boot. Is that what happens for you too? If so, try this, similar to freebsd r214542. Index: if_alc.c === RCS file: /cvs/src/sys/dev/pci/if_alc.c,v retrieving revision 1.11 diff -u -p -r1.11 if_alc.c --- if_alc.c5 Apr 2011 18:01:21 - 1.11 +++ if_alc.c2 May 2011 10:01:12 - @@ -236,8 +236,8 @@ alc_miibus_statchg(struct device *dev) reg = CSR_READ_4(sc, ALC_MAC_CFG); reg |= MAC_CFG_TX_ENB | MAC_CFG_RX_ENB; CSR_WRITE_4(sc, ALC_MAC_CFG, reg); + alc_aspm(sc); } - alc_aspm(sc); } void
Vicentico y Los Fabulosos Cadillacs mas Pendrive de Regalo
Los Fabulosos CadillacsBares y Fondasp Yo Te Aviseacute;!h El Sataacute;nicoDr. CadillacsLos FabulososCadillacs Vol.5Sopa DeCaracolEl LeonVVasosVaciacute;osEn Vivo enBuenos AiressRey Azuacute;caroLos Fabulosos Calaveras20 GrandesExitoso La Marcha del GolazoSolitarioo aHolaa aChaua La Luz del RitmooAkustic LocoDe Fabulosos AmigossVicenticoVicentico 2002p Los rayos!h En vivo en el Luna ParkLLos Pajaros5Solo un momento
Re: Radeon HD3000
On Sun, Apr 03, 2011 at 10:47:15PM +0100, Pedro la Peu wrote:
Indeed, thanks Brad.
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1592
diff -u -p -r1.1592 pcidevs
--- sys/dev/pci/pcidevs 23 Mar 2011 21:55:09 - 1.1592
+++ sys/dev/pci/pcidevs 3 Apr 2011 21:41:11 -
@@ -1359,6 +1359,7 @@ product ATI RADEON_HD3200_1 0x9610 Radeo
product ATI RADEON_HD3100 0x9611 Radeon HD 3100
product ATI RADEON_HD3200_20x9612 Radeon HD 3200
product ATI RADEON_HD3300 0x9614 Radeon HD 3300
+product ATI RADEON_HD3000 0x9616 Radeon HD 3000
product ATI RADEON_HD4200_HDA 0x970f Radeon HD 4200 HD Audio
product ATI RADEON_HD4200 0x9710 Radeon HD 4200
product ATI RADEON_HD4200_M0x9712 Mobility Radeon HD 4200
Index: sys/dev/pci/drm/radeon_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
retrieving revision 1.51
diff -u -p -r1.51 radeon_drv.c
--- sys/dev/pci/drm/radeon_drv.c29 Sep 2010 13:32:22 - 1.51
+++ sys/dev/pci/drm/radeon_drv.c3 Apr 2011 21:41:11 -
@@ -500,6 +500,8 @@ const static struct drm_pcidev radeondrm
CHIP_RV635|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3850,
CHIP_RV670|RADEON_NEW_MEMMAP},
+ {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3000,
+CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3200_1,
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD3200_2,
You even got the flags right.
Commited, thanks Pedro! Sorry it took me so long
-0-
--
WARNING TO ALL PERSONNEL:
Firings will continue until morale improves.
Re: alc(4) support for Atheros AR815x
On Mon, May 02, 2011 at 11:02:41AM +0100, Stuart Henderson wrote: On 2011/05/02 01:16, Edd Barrett wrote: On Sun, May 01, 2011 at 08:10:56PM +0100, Stuart Henderson wrote: On 2011/05/01 18:35, Edd Barrett wrote: I have acquired a netboot (packard bell dot s), which I think uses this NIC. Is there an updated diff? Yes I just took the 2 minutes it took to apply it and fix the minor conflicts and linewrapping issue with the diff. Untested beyond it builds. Stu's diff seems to work, kevlo's diff really.. although the first time i booted my bsd.rd I was unable to install due to: alc0: watchdog timeout (missed link) I had a report of a system with alc(4) which only works if the cable is connected at boot. Is that what happens for you too? If so, try this, similar to freebsd r214542. This change was already included in kevlo's diff. It does seem like it could still be related to the link state. I managed to get another error by: * booting with no cable plugged in. * once the system is up, connect a cable * run dhclient alc0 Then as DHREQUESTs were sent some kernel messages: alc0: watchdog timeout alc0: could not disable RxQ/TxQ (0x0008)! alc0: could not disable RxQ/TxQ MAC(0x0008)! Might give some clues? After those messages, the interface does infact recieve a DHCP address and the interface does work. So I would not let this hold back the commit. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: ksh completion
* Martynas Venckus marty...@venck.us [110410 05:17]:
hi,
(this is a re-post)
make tab completion work for '=', '`', '[', ':', and '$' - pulled from
mksh by Alexander Polakov (also posted to tech recently).
closes pr 6006 too.
comments/ok?
The diff is a workaround and even wrong. Ksh lexical analyzer
itself has the ability to deal with escapes properly (see yylex).
I believe we shouldn't remove backward slashes before passing it
for analysis, this would fix all cases, including:
$ touch aabbcc aa\*cc
$ echo aa\*cctab
aa*cc aabbcc
$ echo aa\*cc
aa*cc
Do you mean something like this or I got it all wrong again and we
have to wait another 15 years for someone to dig into this?
Index: bin/ksh/edit.c
===
RCS file: /cvs/src/bin/ksh/edit.c,v
retrieving revision 1.34
diff -u -r1.34 edit.c
--- bin/ksh/edit.c 20 May 2010 01:13:07 - 1.34
+++ bin/ksh/edit.c 2 May 2011 14:10:47 -
@@ -357,20 +357,6 @@
toglob = add_glob(str, slen);
- /* remove all escaping backward slashes */
- escaping = 0;
- for (i = 0, idx = 0; toglob[i]; i++) {
- if (toglob[i] == '\\' !escaping) {
- escaping = 1;
- continue;
- }
-
- toglob[idx] = toglob[i];
- idx++;
- if (escaping) escaping = 0;
- }
- toglob[idx] = '\0';
-
/*
* Convert foo* (toglob) to an array of strings (words)
*/
@@ -393,6 +379,20 @@
;
if (nwords == 1) {
struct stat statb;
+
+ /* remove all escaping backward slashes (see below) */
+ escaping = 0;
+ for (i = 0, idx = 0; toglob[i]; i++) {
+ if (toglob[i] == '\\' !escaping) {
+ escaping = 1;
+ continue;
+ }
+
+ toglob[idx] = toglob[i];
+ idx++;
+ if (escaping) escaping = 0;
+ }
+ toglob[idx] = '\0';
/* Check if globbing failed (returned glob pattern),
* but be careful (E.g. toglob == ab* when the file
Index: bin/ksh/lex.c
===
RCS file: /cvs/src/bin/ksh/lex.c,v
retrieving revision 1.45
diff -u -r1.45 lex.c
--- bin/ksh/lex.c 9 Mar 2011 09:30:39 - 1.45
+++ bin/ksh/lex.c 2 May 2011 14:10:47 -
@@ -287,24 +287,15 @@
switch (c) {
case '\\':
c = getsc();
- switch (c) {
- case '\\':
- case '$': case '`':
+ if ((c == '' ((cf HEREDOC) == 0)) ||
+ strchr(
\#$'()*;=?[\\]`{|}, c)) {
*wp++ = QCHAR, *wp++ = c;
break;
- case '':
- if ((cf HEREDOC) == 0) {
- *wp++ = QCHAR, *wp++ = c;
- break;
- }
- /* FALLTHROUGH */
- default:
- Xcheck(ws, wp);
- if (c) { /* trailing \ is lost */
- *wp++ = CHAR, *wp++ = '\\';
- *wp++ = CHAR, *wp++ = c;
- }
- break;
+ }
+ Xcheck(ws, wp);
+ if (c) { /* trailing \ is lost */
+ *wp++ = CHAR, *wp++ = '\\';
+ *wp++ = CHAR, *wp++ = c;
}
break;
case '$':
--
Alexander Polakov | plhk.ru
Re: Remove useless sti in x86 interrupt return path
Date: Tue, 19 Apr 2011 15:43:01 +0200 From: Christian Ehrhardt christian_ehrha...@genua.de Hi, On Mon, Apr 18, 2011 at 10:00:02PM -0700, Philip Guenther wrote: The sti was introduced in revision 1.97 of locore.s in March 2006 by mickey@. Commit message: | prevent the faults on iret to run w/ disabled intrs and cause | deadlocks; niklas toby tom ok Maybe mickey or one of the people giving oks back then want to comment? That predates my involvement with OpenBSD, but I think get the gist. iret can fault if, for example, the user corrupts certain members of the sigcontext passed to a signal handler. If that happens the the CPU generates an exception on the iret and you end up in trap() where it peeks at the instruction that triggered the trap and, seeing it was iret, arranges to 'return' to the resume_iret label to generate what looks like a normal fault against the process. The goal of that sti is to keep that 'normal' fault from being processed with interrupts blocked. Point taken, I missed the sigreturn path. However, note that iret can only fault if the values of the segment registers stored on the kernel stack are bogus. In particular iret will not fault on the new EIP address. (The address can page fault but the fault will be on the instruction pointed to by the new CS:EIP and not in iret). With that in mind, the question is: Is it really a problem if the trap handler runs with interrupts disabled? See below. Yes, that will be a problem. IPIs will be blocked. So if that trap requires us to grab the kernel lock, and another process (that holds the kernel lock) tries to do a TLB shootdown, we'll deadlock. Possibility two would be to try to handle this from, uh, inside resume_iret I guess. I'm not 100% sure whether it can be unilateral there though. This seems to be what amd64 does, and since calling uvm_fault() with interrupts disabled is really really bad, I don't think this would be a problem. This would be my preferred solution. In particular, I see two possibilities: * Maybe it is not even a problem is irqs are sometimes disabled during trap. naddy@ is seeing hangs on the i386 ports building machine, and I suspect that is because interrupts are disabled while handling a page fault trap. * It is a problem if trap runs with irqs disabled. In this case, userland can easily trigger this by trapping on one of the pop instructions for ds, es, fs or gs. Those instructions in the interrupt return path run with irqs disabled. Thus moving the sti in the interupt return path down one instruction immediately before the iret does not really help. The proper solution would probably be to add explicit calls to sti in all of the resume paths (or even explicitly before calling trap). So here is a diff that adds the sti to both resume paths. Like I said, amd64 already does this (but only has the one resume path). Now the i386 ports machine is a bad machine to test this on. So it would be nice if somebody with the appropriate hardware (an 8-way i386 machine I presume) could: 1. try to reproduce the problem that naddy@ is seeing 2. and then try to reproduce the problem with this diff applied Cheers, Mark Index: locore.s === RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v retrieving revision 1.134 diff -u -p -r1.134 locore.s --- locore.s27 Apr 2011 11:30:53 - 1.134 +++ locore.s2 May 2011 15:37:06 - @@ -1461,6 +1461,7 @@ IDTVEC(align) * This will cause the process to get a SIGBUS. */ NENTRY(resume_iret) + sti ZTRAP(T_PROTFLT) NENTRY(resume_pop_ds) pushl %es @@ -1476,6 +1477,7 @@ NENTRY(resume_pop_gs) movw%ax,%fs NENTRY(resume_pop_fs) movl$T_PROTFLT,TF_TRAPNO(%esp) + sti jmp calltrap NENTRY(alltraps)
Re: ksh completion
On Mon, May 2, 2011 at 7:19 AM, Alexander Polakov polac...@gmail.com wrote: Do you mean something like this or I got it all wrong again and we have to wait another 15 years for someone to dig into this? I think ksh could really benefit from some regression tests to check that tab completion is behaving sanely. At the moment we have no real assurances that diffs don't break other tab completion scenarios. If anyone has clever ideas (preferably in proof-of-concept code form) on how to automate tab completion testing, that would help get support for this fix.
Re: Remove useless sti in x86 interrupt return path
Date: Mon, 2 May 2011 19:21:40 +0200 From: Christian Ehrhardt christian_ehrha...@genua.de Hello Mark, On Mon, May 02, 2011 at 05:42:10PM +0200, Mark Kettenis wrote: Date: Tue, 19 Apr 2011 15:43:01 +0200 From: Christian Ehrhardt christian_ehrha...@genua.de Hi, On Mon, Apr 18, 2011 at 10:00:02PM -0700, Philip Guenther wrote: The sti was introduced in revision 1.97 of locore.s in March 2006 by mickey@. Commit message: | prevent the faults on iret to run w/ disabled intrs and cause | deadlocks; niklas toby tom ok Maybe mickey or one of the people giving oks back then want to comment? That predates my involvement with OpenBSD, but I think get the gist. iret can fault if, for example, the user corrupts certain members of the sigcontext passed to a signal handler. If that happens the the CPU generates an exception on the iret and you end up in trap() where it peeks at the instruction that triggered the trap and, seeing it was iret, arranges to 'return' to the resume_iret label to generate what looks like a normal fault against the process. The goal of that sti is to keep that 'normal' fault from being processed with interrupts blocked. Point taken, I missed the sigreturn path. However, note that iret can only fault if the values of the segment registers stored on the kernel stack are bogus. In particular iret will not fault on the new EIP address. (The address can page fault but the fault will be on the instruction pointed to by the new CS:EIP and not in iret). With that in mind, the question is: Is it really a problem if the trap handler runs with interrupts disabled? See below. Yes, that will be a problem. IPIs will be blocked. So if that trap requires us to grab the kernel lock, and another process (that holds the kernel lock) tries to do a TLB shootdown, we'll deadlock. Ok, but ... Possibility two would be to try to handle this from, uh, inside resume_iret I guess. I'm not 100% sure whether it can be unilateral there though. This seems to be what amd64 does, and since calling uvm_fault() with interrupts disabled is really really bad, I don't think this would be a problem. This would be my preferred solution. In particular, I see two possibilities: * Maybe it is not even a problem if irqs are sometimes disabled during trap. naddy@ is seeing hangs on the i386 ports building machine, and I suspect that is because interrupts are disabled while handling a page fault trap. ... I really don't believe this, unless there is some path that I still miss. Faulting on iret itself should IMHO be a very rare thing. The one and only path that is see, where this can happen, is sigreturn with bogus segment registers provided by userland. I wouldn't call myself an expert on the i386 architecter. The fact that I confuse page faults and protection faults proves this. Anyway, the resume_xxx paths exist for a reason. So here is a diff that adds the sti to both resume paths. Like I said, amd64 already does this (but only has the one resume path). Now the i386 ports machine is a bad machine to test this on. So it would be nice if somebody with the appropriate hardware (an 8-way i386 machine I presume) could: In fact it might be a good idea to try this patch instead (i.e. unconditionally enable irqs before calling trap): Hmm, the amd64 code does have an sti just after the alltraps entry point, but just before the calltrap label. I don't think there is any reason for i386 to be different here. Dunno if there is a reason for the amd64 code to be like it is. Naively I'd think that the amd64 code can indeed be simplified by moving the sti after the calltrap label and remove the sti instructions just before the jmp calltrap instructions. Index: i386/locore.s === RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v retrieving revision 1.130 diff -u -r1.130 locore.s --- i386/locore.s 3 Jul 2010 04:54:32 - 1.130 +++ i386/locore.s 2 May 2011 16:46:14 - @@ -1511,6 +1511,7 @@ #ifdef DIAGNOSTIC movlCPL,%ebx #endif /* DIAGNOSTIC */ + sti pushl %esp call_C_LABEL(trap) addl$4,%esp regards Christian
Support for OpenGL on r600/r700. Testing required.
The following diff provides the kernel support necessary for OpenGL to
work on R600 and R700 radeon chipsets.
One caveat: the drm doesn't have interrupt support yet (this
involves another firmware (making 3 per chipset for r600+) and a rather
funky ringbuffer for interrupt events (yes, this is strange). Apparently
interrupt support should not be needed.
In practise it should be possible to write interrupt support as well,
but that will take more time and may well get fiddly fast. So, for the
time being, if you pkg_add driconf and change the following two options
then it will work ok:
Method to limit rendering latency - busy waiting for the graphics
hardware
Synchronization with vertical refresh - never.
To test this patch you need the bits I commited just before sending this
message (if your system has libdrm_radeon then you're off to a good
start). then do the following two things:
# cd /usr/xenocara/lib/libGL/dri/r600;
# cd ../../
# make obj
# make build
then:
# cd /usr/src/sys/dev/pci/drm
# patch path_to_patch_from_this_email
and build your kernel as normal.
tested on i386 my matthieu@ on a radeon 3650 and myself on amd64 with a
HD4870. For me at least foobillard, openarena, gears, crack-attack and
glsfcave all worked fine.
Please note that this driver isnt' as amazingly performant as it could
be. the faster stuff is based on the kms code which I still need to find
a large period of time to sit down and write.
And before anyone asks: no I can't update the current in-tree radeon
driver yet. The problem with zaphod mode dual head being utterly hosed
on some ATOMBios cards with the newer driver is still there and having
wasted hours on it I still have no idea. Anyone who needs the newer
driver to get their card to work can mail me privately if they can't
manage to get a newer driver working themselves.
test reports to myself and matthieu please.
Cheers,
-0-
Index: files.drm
===
RCS file: /cvs/src/sys/dev/pci/drm/files.drm,v
retrieving revision 1.20
diff -u -p -r1.20 files.drm
--- files.drm 25 May 2010 17:15:49 - 1.20
+++ files.drm 1 May 2011 19:03:57 -
@@ -26,6 +26,7 @@ file dev/pci/drm/r300_cmdbuf.c radeondrm
file dev/pci/drm/r600_blit.c radeondrm
file dev/pci/drm/r600_blit_shaders.c radeondrm
file dev/pci/drm/radeon_cp.c radeondrm
+file dev/pci/drm/radeon_cs.c radeondrm
file dev/pci/drm/radeon_drv.cradeondrm
file dev/pci/drm/radeon_irq.cradeondrm
file dev/pci/drm/radeon_mem.cradeondrm
Index: r600_blit.c
===
RCS file: /cvs/src/sys/dev/pci/drm/r600_blit.c,v
retrieving revision 1.1
diff -u -p -r1.1 r600_blit.c
--- r600_blit.c 27 Mar 2010 00:09:50 - 1.1
+++ r600_blit.c 1 May 2011 19:03:57 -
@@ -128,7 +128,7 @@ set_shaders(struct drm_device *dev)
{
drm_radeon_private_t *dev_priv = dev-dev_private;
u64 gpu_addr;
- int shader_size, i;
+ int i;
u32 *vs, *ps;
uint32_t sq_pgm_resources;
DRM_DEBUG(\n);
@@ -137,12 +137,10 @@ set_shaders(struct drm_device *dev)
vs = (u32 *) ((char *)dev-agp_buffer_map-handle +
dev_priv-blit_vb-offset);
ps = (u32 *) ((char *)dev-agp_buffer_map-handle +
dev_priv-blit_vb-offset + 256);
- shader_size = r6xx_vs_size;
- for (i = 0; i shader_size; i++)
- vs[i] = r6xx_vs[i];
- shader_size = r6xx_ps_size;
- for (i = 0; i shader_size; i++)
- ps[i] = r6xx_ps[i];
+ for (i = 0; i r6xx_vs_size; i++)
+ vs[i] = cpu_to_le32(r6xx_vs[i]);
+ for (i = 0; i r6xx_ps_size; i++)
+ ps[i] = cpu_to_le32(r6xx_ps[i]);
dev_priv-blit_vb-used = 512;
@@ -194,6 +192,9 @@ set_vtx_resource(drm_radeon_private_t *d
DRM_DEBUG(\n);
sq_vtx_constant_word2 = (((gpu_addr 32) 0xff) | (16 8));
+#ifdef __BIG_ENDIAN
+ sq_vtx_constant_word2 |= (2 30);
+#endif
BEGIN_RING(9);
OUT_RING(CP_PACKET3(R600_IT_SET_RESOURCE, 7));
@@ -290,7 +291,11 @@ draw_auto(drm_radeon_private_t *dev_priv
OUT_RING(DI_PT_RECTLIST);
OUT_RING(CP_PACKET3(R600_IT_INDEX_TYPE, 0));
+#ifdef __BIG_ENDIAN
+ OUT_RING((2 2) | DI_INDEX_SIZE_16_BIT);
+#else
OUT_RING(DI_INDEX_SIZE_16_BIT);
+#endif
OUT_RING(CP_PACKET3(R600_IT_NUM_INSTANCES, 0));
OUT_RING(1);
@@ -306,7 +311,7 @@ draw_auto(drm_radeon_private_t *dev_priv
static inline void
set_default_state(drm_radeon_private_t *dev_priv)
{
- int default_state_dw, i;
+ int i;
u32 sq_config, sq_gpr_resource_mgmt_1, sq_gpr_resource_mgmt_2;
u32 sq_thread_resource_mgmt, sq_stack_resource_mgmt_1,
sq_stack_resource_mgmt_2;
int num_ps_gprs, num_vs_gprs, num_temp_gprs, num_gs_gprs, num_es_gprs;
@@ -458,14 +463,12 @@ set_default_state(drm_radeon_private_t *
pf(4) man page: include missing header in example program
The DIOCNATLOOK example program at the end of the pf(4) man page uses memset(3), but string.h is not included. The following diff fixes this. Any thoughts? Thanks, Lawrence Index: pf.4 === RCS file: /cvs/src/share/man/man4/pf.4,v retrieving revision 1.72 diff -u -p -r1.72 pf.4 --- pf.428 Dec 2010 13:56:11 - 1.72 +++ pf.43 May 2011 02:13:35 - @@ -1003,6 +1003,7 @@ command to find the internal host/port o #include err.h #include stdio.h #include stdlib.h +#include string.h u_int32_t read_address(const char *s)
adb(4)/pm_direct.c cleanup
On macppc, the pm_* methods are always attached to a PMU (or PMU99), so
no need to check for hardware.
Tested here with a powerbook6,5.
Ok?
Index: dev/adb.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/adb.c,v
retrieving revision 1.29
diff -u -p -r1.29 adb.c
--- dev/adb.c 1 Feb 2009 17:04:26 - 1.29
+++ dev/adb.c 3 May 2011 02:27:28 -
@@ -1307,7 +1307,6 @@ adb_setup_hw_type(void)
case ADB_HW_PMU:
adbSoftPower = 1;
- pm_setup_adb();
return;
default:
Index: dev/pm_direct.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/pm_direct.c,v
retrieving revision 1.22
diff -u -p -r1.22 pm_direct.c
--- dev/pm_direct.c 18 Feb 2007 19:33:48 - 1.22
+++ dev/pm_direct.c 3 May 2011 02:27:28 -
@@ -54,10 +54,6 @@
/* hardware dependent values */
#define ADBDelay 100 /* XXX */
-/* define the types of the Power Manager */
-#define PM_HW_UNKNOWN 0x00/* don't know */
-#definePM_HW_PB5XX 0x02/* PowerBook Duo and 5XX series
*/
-
/* useful macros */
#define PM_SR()read_via_reg(VIA1, vSR)
#define PM_VIA_INTR_ENABLE() write_via_reg(VIA1, vIER, 0x90)
@@ -75,11 +71,6 @@
#define PM_IS_OFF (0x00 == (read_via_reg(VIA2, vBufB) 0x08))
#endif
-/*
- * Variables for internal use
- */
-intpmHardware = PM_HW_UNKNOWN;
-
/* these values shows that number of data returned after 'send' cmd is sent */
signed char pm_send_cmd_type[] = {
-1, -1, -1, -1, -1, -1, -1, -1,
@@ -164,12 +155,8 @@ void pm_printerr(char *, int, int, char
intpm_wait_busy(int);
intpm_wait_free(int);
-
-/* these functions are for the PB Duo series and the PB 5XX series */
-intpm_receive_pm2(u_char *);
-intpm_send_pm2(u_char);
-intpm_pmgrop_pm2(PMData *);
-void pm_intr_pm2(void);
+intpm_receive(u_char *);
+intpm_send(u_char);
/* these functions also use the variables of adb_direct.c */
void pm_adb_get_TALK_result(PMData *);
@@ -221,18 +208,6 @@ pm_printerr(ttl, rval, num, data)
}
#endif
-
-
-/*
- * Check the hardware type of the Power Manager
- */
-void
-pm_setup_adb()
-{
- pmHardware = PM_HW_PB5XX; /* XXX */
-}
-
-
/*
* Wait until PM IC is busy
*/
@@ -274,7 +249,7 @@ pm_wait_free(int delay)
* Receive data from PM for the PB Duo series and the PB 5XX series
*/
int
-pm_receive_pm2(u_char *data)
+pm_receive(u_char *data)
{
int i;
int rval;
@@ -313,7 +288,7 @@ pm_receive_pm2(u_char *data)
* Send data to PM for the PB Duo series and the PB 5XX series
*/
int
-pm_send_pm2(data)
+pm_send(data)
u_char data;
{
int rval;
@@ -346,7 +321,7 @@ pm_send_pm2(data)
* My PMgrOp routine for the PB Duo series and the PB 5XX series
*/
int
-pm_pmgrop_pm2(PMData *pmdata)
+pmgrop(PMData *pmdata)
{
int i;
int s;
@@ -376,20 +351,20 @@ pm_pmgrop_pm2(PMData *pmdata)
break; /* timeout */
/* send PM command */
- if ((rval = pm_send_pm2((u_char)(pm_cmd 0xff
+ if ((rval = pm_send((u_char)(pm_cmd 0xff
break; /* timeout */
/* send number of PM data */
num_pm_data = pmdata-num_data;
if (pm_send_cmd_type[pm_cmd] 0) {
- if ((rval = pm_send_pm2((u_char)(num_pm_data 0xff)))
!= 0)
+ if ((rval = pm_send((u_char)(num_pm_data 0xff))) != 0)
break; /* timeout */
pmdata-command = 0;
}
/* send PM data */
pm_buf = (u_char *)pmdata-s_buf;
for (i = 0 ; i num_pm_data; i++)
- if ((rval = pm_send_pm2(pm_buf[i])) != 0)
+ if ((rval = pm_send(pm_buf[i])) != 0)
break; /* timeout */
if (i != num_pm_data)
break; /* timeout */
@@ -407,7 +382,7 @@ pm_pmgrop_pm2(PMData *pmdata)
pm_data = pmdata-command;
pm_num_rx_data--;
if (pm_num_rx_data == 0)
- if ((rval = pm_receive_pm2(pm_data)) != 0) {
+ if ((rval = pm_receive(pm_data)) != 0) {
rval = 0xcd37;
break;
}
@@ -415,7 +390,7 @@ pm_pmgrop_pm2(PMData *pmdata)
/* receive number of PM data */
if (pm_num_rx_data 0) {
- if ((rval = pm_receive_pm2(pm_data)) != 0)
+ if ((rval = pm_receive(pm_data)) != 0)
break;
Re: Support for OpenGL on r600/r700. Testing required.
Thanks for sending this, it works on my Mobility Radeon HD 4250 (1002:9712).
I updated to the most recent snapshot, updated my tree and applied the patch in
your mail.
You need to install the updated headers/includes, just copying radeon_drm.h
to /usr/include/dev/pci/drm/ before make {obj,build} in lib/libdrm works.
I also needed to change the following in libGL/dri/Makefile:
-SUBDIR+= i810 i915 i965 radeon r200 r300
+SUBDIR+= i810 i915 i965 radeon r200 r300 r600
Also, if you're using a new version of xf86-video-radeon add --disable-kms to
the configure command.
Once that's done, you'll need the following ~/.drirc or /etc/drirc:
driconf
device screen=0 driver=r600
application name=all
option name=fthrottle_mode value=0/
option name=vblank_mode value=0/
/application
/device
/driconf
Very cool.
-Bryan.
