Re: km(4) support for AMD Family 14h processors
Hi Brad, Brad wrote on Mon, May 30, 2011 at 07:44:37PM -0400: Index: share/man/man4/km.4 [...] +.\ .%O http://support.amd.com/us/Processor_TechDocs/31116.pdf Why are the URIs commented out? Both mandoc and modern groff handle %U properly. OK for the following diff? Ingo Index: km.4 === RCS file: /cvs/src/share/man/man4/km.4,v retrieving revision 1.6 diff -u -r1.6 km.4 --- km.431 May 2011 00:19:54 - 1.6 +++ km.431 May 2011 08:05:45 - @@ -47,21 +47,21 @@ .%D March 26, 2008 .%R Publication # 31116 .%P pp. 236--237 and pp. 243--244 -.\ .%O http://support.amd.com/us/Processor_TechDocs/31116.pdf +.%U http://support.amd.com/us/Processor_TechDocs/31116.pdf .Re .Rs .%T BIOS and Kernel Developer's Guide for AMD Family 11h Processors .%D July 07, 2008 .%R Publication # 41256 .%P pp. 156--157 and pp. 159--160 -.\ .%O http://support.amd.com/us/Processor_TechDocs/41256.pdf +.%U http://support.amd.com/us/Processor_TechDocs/41256.pdf .Re .Rs .%T BIOS and Kernel Developer's Guide for AMD Family 14h Models 00h-04h Processors .%D May 02, 2011 .%R Publication # 43170 .%P pp. 277--278 and pp. 280--282 -.\ .%O http://support.amd.com/us/Processor_TechDocs/43170.pdf +.%U http://support.amd.com/us/Processor_TechDocs/43170.pdf .Re .Sh HISTORY The
enable msi for ix(4)
similar to other such diffs, this enables msi for ix(4).
OK?
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.51
diff -u -p -r1.51 if_ix.c
--- dev/pci/if_ix.c 15 Apr 2011 15:12:27 - 1.51
+++ dev/pci/if_ix.c 31 May 2011 07:39:46 -
@@ -1297,7 +1321,7 @@ ixgbe_allocate_legacy(struct ix_softc *s
sc-rid[0] = 0;
/* We allocate a single interrupt resource */
- if (pci_intr_map(pa, ih)) {
+ if (pci_intr_map_msi(pa, ih) != 0 pci_intr_map(pa, ih) != 0) {
printf(: couldn't map interrupt\n);
return (ENXIO);
}
--
Lowery's Law:
If it jams -- force it.
If it breaks, it needed replacing anyway.
Re: enable msi for ix(4)
On Tue, May 31, 2011 at 10:21:33AM +0200, Peter Hessler wrote:
similar to other such diffs, this enables msi for ix(4).
OK?
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.51
diff -u -p -r1.51 if_ix.c
--- dev/pci/if_ix.c 15 Apr 2011 15:12:27 - 1.51
+++ dev/pci/if_ix.c 31 May 2011 07:39:46 -
@@ -1297,7 +1321,7 @@ ixgbe_allocate_legacy(struct ix_softc *s
sc-rid[0] = 0;
/* We allocate a single interrupt resource */
- if (pci_intr_map(pa, ih)) {
+ if (pci_intr_map_msi(pa, ih) != 0 pci_intr_map(pa, ih) != 0) {
printf(: couldn't map interrupt\n);
return (ENXIO);
}
--
Lowery's Law:
If it jams -- force it.
If it breaks, it needed replacing anyway.
I had to pull the exact same diff out of ahci.c in order to make
my system boot -current. So I am now interested if such diffs are
the right thing to do and soemthing else is broken in ahci.
Ken
Re: enable msi for ix(4)
On Tue, May 31, 2011 at 08:17:33AM -0400, Kenneth R Westerback wrote:
On Tue, May 31, 2011 at 10:21:33AM +0200, Peter Hessler wrote:
similar to other such diffs, this enables msi for ix(4).
OK?
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.51
diff -u -p -r1.51 if_ix.c
--- dev/pci/if_ix.c 15 Apr 2011 15:12:27 - 1.51
+++ dev/pci/if_ix.c 31 May 2011 07:39:46 -
@@ -1297,7 +1321,7 @@ ixgbe_allocate_legacy(struct ix_softc *s
sc-rid[0] = 0;
/* We allocate a single interrupt resource */
- if (pci_intr_map(pa, ih)) {
+ if (pci_intr_map_msi(pa, ih) != 0 pci_intr_map(pa, ih) != 0) {
printf(: couldn't map interrupt\n);
return (ENXIO);
}
--
Lowery's Law:
If it jams -- force it.
If it breaks, it needed replacing anyway.
I had to pull the exact same diff out of ahci.c in order to make
my system boot -current. So I am now interested if such diffs are
the right thing to do and soemthing else is broken in ahci.
Some drivers need special handling for MSI others should just work if the
underlying HW does correct MSI. IMO it is now the time to try to turn on
as many MSI interrupt handlers as possible to see which MB/chipsets may
need some blacklisting. On the other hand a knob to turn it off in case
MSI fails would be nice.
--
:wq Claudio
Re: bc and editline
On Thu, May 26, 2011 at 05:57:18PM +0200, Otto Moerbeek wrote:
On Thu, May 26, 2011 at 07:02:55AM +0200, Otto Moerbeek wrote:
Hi,
adding editline caused a regrssion in the handling of ^C.
Originally (and I mean the days of ATT) bc used ^C as an abort line.
With editline, while appearing to work, the characters typed so far
remain in the input buffer. Try this: 1+^C2enter
Editline has no signal safe facility to accomodate that. So switch it
off (you can use ^U anyway).
Also, honour the edit off command from .editrc or interactively. In
that case ^C works as before.
Actually, after some more study I concluded that the non-wide chars
code is safe. We don;t support wide chars editline now, and certainly
will not in bc(1). So this should fare better, and have correct ^C
handling both in editline mode and non-editline mode.
Nobody? I have another diff queued and I 'd like to make progress. So
if nobody objects, I'll commit tonight.
-Otto
Index: bc.y
===
RCS file: /cvs/src/usr.bin/bc/bc.y,v
retrieving revision 1.34
diff -u -p -r1.34 bc.y
--- bc.y 7 Mar 2011 08:11:15 - 1.34
+++ bc.y 26 May 2011 15:54:39 -
@@ -1143,7 +1143,7 @@ main(int argc, char *argv[])
history(hist, he, H_SETSIZE, 100);
el_set(el, EL_HIST, history, hist);
el_set(el, EL_EDITOR, emacs);
- el_set(el, EL_SIGNAL, 1);
+ el_set(el, EL_SIGNAL, 0);
el_set(el, EL_PROMPT, dummy_prompt);
el_source(el, NULL);
}
Index: scan.l
===
RCS file: /cvs/src/usr.bin/bc/scan.l,v
retrieving revision 1.24
diff -u -p -r1.24 scan.l
--- scan.l7 Mar 2011 08:11:15 - 1.24
+++ scan.l26 May 2011 15:54:39 -
@@ -38,6 +38,8 @@ History *hist;
static char *strbuf = NULL;
static size_tstrbuf_sz = 1;
static bool dot_seen;
+static int use_el;
+static volatile sig_atomic_t skipchars;
static void init_strbuf(void);
static void add_str(const char *);
@@ -236,12 +238,18 @@ add_str(const char *str)
void
abort_line(int sig)
{
- static const char str[] = [\n]P\n;
+ static const char str1[] = [\n]P\n;
+ static const char str2[] = [^C\n]P\n;
int save_errno;
+ const LineInfo *info;
save_errno = errno;
- YY_FLUSH_BUFFER;/* XXX signal race? */
- write(STDOUT_FILENO, str, sizeof(str) - 1);
+ if (use_el) {
+ write(STDOUT_FILENO, str2, sizeof(str2) - 1);
+ info = el_line(el);
+ skipchars = info-lastchar - info-buffer;
+ } else
+ write(STDOUT_FILENO, str1, sizeof(str1) - 1);
errno = save_errno;
}
@@ -295,17 +303,32 @@ static int
bc_yyinput(char *buf, int maxlen)
{
int num;
- if (yyin == stdin interactive) {
+
+ if (el != NULL)
+ el_get(el, EL_EDITMODE, use_el);
+
+ if (yyin == stdin interactive use_el) {
const char *bp;
+ sigset_t oset, nset;
if ((bp = el_gets(el, num)) == NULL || num == 0)
return (0);
+ sigemptyset(nset);
+ sigaddset(nset, SIGINT);
+ sigprocmask(SIG_BLOCK, nset, oset);
+ if (skipchars num) {
+ bp += skipchars;
+ num -= skipchars;
+ }
+ skipchars = 0;
+ sigprocmask(SIG_SETMASK, oset, NULL);
if (num maxlen) {
el_push(el, (char *)(void *)bp + maxlen);
num = maxlen;
}
memcpy(buf, bp, num);
history(hist, he, H_ENTER, bp);
+ el_get(el, EL_EDITMODE, use_el);
} else {
int c = '*';
for (num = 0; num maxlen
Re: make \user syntax more explicit in forward(5)
Hi Thomas, i don't use .forward(5) and am not sure whether what you say is true or false, but the form is definitely not ok. Thomas de Grivel wrote on Tue, May 31, 2011 at 08:15:28PM +0200: --- forward.5.~1.9.~ Wed May 4 17:24:22 2011 +++ forward.5 Tue May 31 19:53:17 2011 @@ -35,8 +35,8 @@ Multiple entries may be specified on one line, comma separated. Additionally, a copy of all mail may be retained on the local machine using a -.Dq \euser -entry. +.Dq \eUSER +entry where USER names a valid user on the local machine. 1. I guess you want to say that the string user has to be replaced by some other string. Expressing that by all caps is not ok. 2. Probably, user should be marked up as .Ar (argument), which is the macro used for such purposes, like in In place of an e-mail address, .Dq \e Ns Ar user may be used to deliver a copy of the message to the specified .Ar user account on the local machine. .Pp .Pa .forward files must not be group or world writable. @@ -55,7 +55,7 @@ # empty lines are ignored # #@# with whitespace on both sides may be used to start a comment -f...@bar.baz.com, \euser #@# is a comment anywhere +f...@bar.baz.com, \efoo #@# is a comment anywhere | /usr/local/libexec/slocal -user foo .Ed .Sh SEE ALSO Not sure about that one. If i understand correctly what you are trying to say, that explicitly does *not* need to be foo, but might by some other user, right? Besides, i'm not sure this manual is maintained here at all. Isn't it part of the sendmail distribution, that is, shouldn't it be maintained upstream? Even if we do maintain it in tree, there are more serious problems with this manual: - It should say that all this only works if the MTA is configured to look at .forward files, which may not be the case. - What is the name of a private incoming mailer? That is utterly incomprehensible. - What happens if a .forward file is world writeable? I assume it will be ignored? - EXAMPLES should not contain new material, but... well, examples. Comments should be explained in the DESCRIPTION. Pipes should be explained in the DESCRIPTION. To sum up, this manual is in dire need of a rewrite. Yours, Ingo
Re: switch to xkeyboard-config XKB configuration: please test
On Tue, May 31, 2011 at 08:22:09PM +0200, Antoine Jacoutot wrote: On Mon, 30 May 2011, Matthieu Herrb wrote: Hi, Some years ago X.Org decided to switch to a new set of XKB (the X Keyboard extension) data files known as xkeyboard-config. For various reasons (local changes, complexity of the build system for xkeyboard-config, slacking) Xenocara is still using the old and unmaintained xkb-data. The update is needed for libxklavier which is a required library for some Desktop related ports. Keyboard handling in GNOME3 for one will not work at all without this update. KDE4 may require the same at some point and same goes for ports that use xkeyboard-config. With the help of Alexandr Shadchin, Xenocara now ready to switch to xkeyboard-config, but we'd like to have a last round of tests. For this apply the patch below and rebuild xenocara from sources. Please note that this will move the xkb data files from /etc/X11 to /usr/X11R6/share/X11 Report success/failures to shadchin@ and me. Thanks. Works beautifully for me on i386 and amd64. I also tried macppc, it worked but I'm using a regular keyboard, not an apple one, so I'm not sure that counts :) Index: share/mk/bsd.xconf.mk === RCS file: /cvs/OpenBSD/xenocara/share/mk/bsd.xconf.mk,v retrieving revision 1.18 diff -u -p -u -r1.18 bsd.xconf.mk --- share/mk/bsd.xconf.mk 8 Mar 2011 20:48:59 - 1.18 +++ share/mk/bsd.xconf.mk 29 May 2011 17:07:33 - @@ -19,4 +19,4 @@ XENOCARA_BUILD_PIXMAN?=yes .endif # Build xkeyboard-config? -XENOCARA_USE_XKEYBOARD_CONFIG?=no +XENOCARA_USE_XKEYBOARD_CONFIG?=yes -- Antoine Works fine on my i386, amd64 and sparc64 (all with standard keyboards). I should be able to test a Sun Type 6 USB beginning next week. -- Cheers, Jasper Capable, generous men do not create victims, they nurture them.
