Re: ksh wish
On Fri, Sep 02, 2011 at 10:41:51AM +1000, Damien Miller wrote:
Hi,
While people are excited about hacking on ksh(1) - let me add my wish:
unrestricted multibyte character binding so I can have ctrl-left_arrow
(^[[1;5D on my terminal) bound to backward-word and so forth.
Last time I checked the code for bind could only handle a couple of
characters after ^[
-d
Here you go...
Index: Makefile
===
RCS file: /cvs/src/bin/ksh/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- Makefile3 Mar 2009 20:01:01 - 1.27
+++ Makefile6 Sep 2011 22:36:26 -
@@ -10,16 +10,9 @@ DEFS=-Wall
CFLAGS+=${DEFS} -I. -I${.CURDIR} -I${.CURDIR}/../../lib/libc/gen
MAN= ksh.1 sh.1
-CLEANFILES+= emacs.out
-
LINKS= ${BINDIR}/ksh ${BINDIR}/rksh
LINKS+=${BINDIR}/ksh ${BINDIR}/sh
MLINKS=ksh.1 rksh.1
-
-.depend emacs.o: emacs.out
-
-emacs.out: emacs.c
- /bin/sh ${.CURDIR}/emacs-gen.sh ${.CURDIR}/emacs.c emacs.out
check test:
/usr/bin/perl ${.CURDIR}/tests/th -s ${.CURDIR}/tests -p ./ksh -C \
Index: alloc.c
===
RCS file: /cvs/src/bin/ksh/alloc.c,v
retrieving revision 1.8
diff -u -p -r1.8 alloc.c
--- alloc.c 21 Jul 2008 17:30:08 - 1.8
+++ alloc.c 6 Sep 2011 22:36:26 -
@@ -62,7 +62,7 @@ alloc(size_t size, Area *ap)
{
struct link *l;
- l = malloc(sizeof(struct link) + size);
+ l = calloc(1, sizeof(struct link) + size);
if (l == NULL)
internal_errorf(1, unable to allocate memory);
l-next = ap-freelist;
Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.44
diff -u -p -r1.44 emacs.c
--- emacs.c 5 Sep 2011 04:50:33 - 1.44
+++ emacs.c 6 Sep 2011 22:36:35 -
@@ -6,6 +6,9 @@
* created by Ron Natalie at BRL
* modified by Doug Kingston, Doug Gwyn, and Lou Salkind
* adapted to PD ksh by Eric Gisin
+ *
+ * partial rewrite by Marco Peereboom ma...@openbsd.org
+ * under the same license
*/
#include config.h
@@ -13,6 +16,7 @@
#include sh.h
#include sys/stat.h
+#include sys/queue.h
#include ctype.h
#include locale.h
#include edit.h
@@ -37,12 +41,6 @@ struct x_ftab {
short xf_flags;
};
-struct x_defbindings {
- u_char xdb_func; /* XFUNC_* */
- unsigned char xdb_tab;
- unsigned char xdb_char;
-};
-
#define XF_ARG 1 /* command takes number prefix */
#defineXF_NOBIND 2 /* not allowed to bind to function */
#defineXF_PREFIX 4 /* function sets prefix */
@@ -51,10 +49,6 @@ struct x_defbindings {
#defineis_cfs(c) (c == ' ' || c == '\t' || c == '' || c == '\'')
#defineis_mfs(c) (!(isalnum(c) || c == '_' || c == '$')) /*
Separator for motion */
-# define CHARMASK 0xFF/* 8-bit character mask */
-# define X_NTABS 3 /* normal, meta1, meta2 */
-#define X_TABSZ(CHARMASK+1)/* size of keydef tables etc */
-
/* Arguments for do_complete()
* 0 = enumerate M-= complete as much as possible and then list
* 1 = complete M-Esc
@@ -66,6 +60,17 @@ typedef enum {
CT_COMPLIST /* complete and then list (if non-exact) */
} Comp_type;
+/* keybindings */
+struct kb_entry {
+ TAILQ_ENTRY(kb_entry) entry;
+ unsigned char *seq;
+ int len;
+ struct x_ftab *ftab;
+ void*args;
+};
+TAILQ_HEAD(kb_list, kb_entry);
+struct kb_list kblist = TAILQ_HEAD_INITIALIZER(kblist);
+
/* { from 4.9 edit.h */
/*
* The following are used for my horizontal scrolling stuff
@@ -91,20 +96,18 @@ static int x_arg_defaulted;/* x_arg not
static int xlp_valid;
/* end from 4.9 edit.h } */
+static int x_tty; /* are we on a tty? */
+static int x_bind_quiet; /* be quiet when binding keys */
+static int (*x_last_command)(int);
-static int x_prefix1 = CTRL('['), x_prefix2 = CTRL('X');
static char **x_histp; /* history position */
static int x_nextcmd; /* for newline-and-next */
static char*xmp; /* mark pointer */
-static u_char x_last_command;
-static u_char (*x_tab)[X_TABSZ]; /* key definition */
-static char*(*x_atab)[X_TABSZ];/* macro definitions */
-static unsigned char x_bound[(X_TABSZ * X_NTABS + 7) / 8];
#defineKILLSIZE20
static char*killstack[KILLSIZE];
static int killsp, killtp;
-static int x_curprefix;
-static char*macroptr;
+static int x_literal_set;
+static int x_arg_set;
static int prompt_skip;
static int prompt_redraw;
@@ -123,9 +126,6 @@ static int x_search(char *, int, in
static int
ksh hang
While working on djm's wishlist I ran across a hang.
To reproduce the hang go like: ^[16000l which would insert 16000
letter l'. As far as I know going over the line limit makes no sense so
limit it's repetition and prevent the hang in the process.
ok?
Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.43
diff -u -p -u -p -r1.43 emacs.c
--- emacs.c 14 Mar 2011 21:20:01 - 1.43
+++ emacs.c 4 Sep 2011 20:40:25 -
@@ -1787,8 +1787,13 @@ x_set_arg(int c)
int first = 1;
c = CHARMASK; /* strip command prefix */
- for (; c = 0 isdigit(c); c = x_e_getc(), first = 0)
+ for (; c = 0 isdigit(c); c = x_e_getc(), first = 0) {
n = n * 10 + (c - '0');
+ if (n 0 || n LINE) {
+ c = -1;
+ break;
+ }
+ }
if (c 0 || first) {
x_e_putc(BEL);
x_arg = 1;
Re: ksh history corruption
todd had his panties in a wad about backwards compatibility so I lifted
the ksh history load code out of ksh to dump it in a text file. Compile
like:
cc kshconv.c -o kshconv
then run it like:
./kshconv -i ~/.hist -o texthist
Conversion code:
=== 8 ===
#include stdio.h
#include stdlib.h
#include err.h
#include sys/types.h
#include sys/mman.h
#define HMAGIC1 0xab
#define HMAGIC2 0xcd
#define COMMAND 0xff
extern char *__progname;
typedef enum state {
shdr, /* expecting a header */
sline, /* looking for a null byte to end the line */
sn1,/* bytes 1 to 4 of a line no */
sn2, sn3, sn4
} State;
void
histload(FILE *f, unsigned char *base, int bytes)
{
State state;
int lno = 0;
unsigned char *line = NULL;
for (state = shdr; bytes-- 0; base++) {
switch (state) {
case shdr:
if (*base == COMMAND)
state = sn1;
break;
case sn1:
lno = (((*base)0xff)24);
state = sn2;
break;
case sn2:
lno |= (((*base)0xff)16);
state = sn3;
break;
case sn3:
lno |= (((*base)0xff)8);
state = sn4;
break;
case sn4:
lno |= (*base)0xff;
line = base+1;
state = sline;
break;
case sline:
if (*base == '\0') {
fprintf(f, %s\n, line);
state = shdr;
}
}
}
}
int
main(int argc, char *argv[])
{
int c;
char*in;
char*out;
FILE*fin;
FILE*fout;
off_t hsize;
unsigned char *base;
while ((c = getopt(argc, argv, i:o:)) != -1) {
switch (c) {
case 'i':
in = optarg;
break;
case 'o':
out = optarg;
break;
default:
errx(1, %s -i file -o file, __progname);
}
}
if (in == NULL || out == NULL)
errx(1, %s -i file -o file, __progname);
if ((fin = fopen(in, r)) == NULL)
err(1, %s, in);
if ((fout = fopen(out, w+)) == NULL)
err(1, %s, out);
hsize = lseek(fileno(fin), 0L, SEEK_END);
if (hsize == 0)
errx(1, nothing to do);
else if (hsize 0) {
/*
* we have some data
*/
base = (unsigned char *)mmap(0, hsize, PROT_READ,
MAP_FILE|MAP_PRIVATE, fileno(fin), 0);
/*
* check on its validity
*/
if (base == MAP_FAILED || *base != HMAGIC1 || base[1] !=
HMAGIC2) {
if (base != MAP_FAILED)
munmap((caddr_t)base, hsize);
goto done;
}
histload(fout, base+2, hsize-2);
munmap((caddr_t)base, hsize);
}
done:
fclose(fin);
fclose(fout);
}
=== 8 ===
V5 of diff with millert's suggestion to remove mmap.h.
Index: alloc.c
===
RCS file: /cvs/src/bin/ksh/alloc.c,v
retrieving revision 1.8
diff -u -p -r1.8 alloc.c
--- alloc.c 21 Jul 2008 17:30:08 - 1.8
+++ alloc.c 30 Aug 2011 18:05:47 -
@@ -62,7 +62,7 @@ alloc(size_t size, Area *ap)
{
struct link *l;
- l = malloc(sizeof(struct link) + size);
+ l = calloc(1, sizeof(struct link) + size);
if (l == NULL)
internal_errorf(1, unable to allocate memory);
l-next = ap-freelist;
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.39
diff -u -p -r1.39 history.c
--- history.c 19 May 2010 17:36:08 - 1.39
+++ history.c 1 Sep 2011 13:49:13 -
@@ -11,8 +11,7 @@
* a) the original in-memory history mechanism
* b) a more complicated mechanism done by p...@hillside.co.uk
* that more closely follows the real ksh way of doing
- * things. You need to have the mmap system call for this
- * to work on your system
Re: ksh history corruption
Alright this diff keeps the file open and appends lines to HISTFILE. It
only rewrites HISTFILE at 125% of HISTSIZE. Does fancy locking and
deals with signals too. So unless someone finds some bugs I'll consider
this version final.
Yes, no on moving ksh history to text?
Other comments?
Index: alloc.c
===
RCS file: /cvs/src/bin/ksh/alloc.c,v
retrieving revision 1.8
diff -u -p -r1.8 alloc.c
--- alloc.c 21 Jul 2008 17:30:08 - 1.8
+++ alloc.c 30 Aug 2011 18:05:47 -
@@ -62,7 +62,7 @@ alloc(size_t size, Area *ap)
{
struct link *l;
- l = malloc(sizeof(struct link) + size);
+ l = calloc(1, sizeof(struct link) + size);
if (l == NULL)
internal_errorf(1, unable to allocate memory);
l-next = ap-freelist;
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.39
diff -u -p -r1.39 history.c
--- history.c 19 May 2010 17:36:08 - 1.39
+++ history.c 1 Sep 2011 20:14:44 -
@@ -11,8 +11,7 @@
* a) the original in-memory history mechanism
* b) a more complicated mechanism done by p...@hillside.co.uk
* that more closely follows the real ksh way of doing
- * things. You need to have the mmap system call for this
- * to work on your system
+ * things.
*/
#include sh.h
@@ -20,21 +19,11 @@
#ifdef HISTORY
# include sys/file.h
-# include sys/mman.h
-/*
- * variables for handling the data file
- */
-static int histfd;
-static int hsize;
-
-static int hist_count_lines(unsigned char *, int);
-static int hist_shrink(unsigned char *, int);
-static unsigned char *hist_skip_back(unsigned char *,int *,int);
-static void histload(Source *, unsigned char *, int);
-static void histinsert(Source *, int, unsigned char *);
-static void writehistfile(int, char *);
-static int sprinkle(int);
+static voidwritehistfile(void);
+static FILE*history_open(void);
+static int history_load(Source *);
+static voidhistory_close(void);
static int hist_execute(char *);
static int hist_replace(char **, const char *, const char *, int);
@@ -42,11 +31,14 @@ static char **hist_get(const char *, i
static char **hist_get_oldest(void);
static voidhistbackup(void);
+static FILE*histfd;
static char **current; /* current position in history[] */
static char*hname; /* current name of history file */
static int hstarted; /* set after hist_init() called */
-static Source *hist_source;
+static Source *hist_source;
+static uint32_tline_co;
+static struct stat last_sb;
int
c_fc(char **wp)
@@ -529,15 +521,10 @@ sethistfile(const char *name)
/* if the name is the same as the name we have */
if (hname strcmp(hname, name) == 0)
return;
-
/*
* its a new name - possibly
*/
- if (histfd) {
- /* yes the file is open */
- (void) close(histfd);
- histfd = 0;
- hsize = 0;
+ if (hname) {
afree(hname, APERM);
hname = NULL;
/* let's reset the history */
@@ -545,6 +532,9 @@ sethistfile(const char *name)
hist_source-line = 0;
}
+ if (histfd)
+ history_close();
+
hist_init(hist_source);
}
@@ -561,6 +551,27 @@ init_histvec(void)
}
}
+static void
+history_lock(void)
+{
+ while (flock(fileno(histfd), LOCK_EX) != 0) {
+ if (errno == EINTR || errno == EAGAIN)
+ continue;
+ else
+ break;
+ }
+}
+
+static void
+history_unlock(void)
+{
+ while (flock(fileno(histfd), LOCK_UN) != 0) {
+ if (errno == EINTR || errno == EAGAIN)
+ continue;
+ else
+ break;
+ }
+}
/*
* Routines added by Peter Collinson BSDI(Europe)/Hillside Systems to
@@ -577,18 +588,29 @@ init_histvec(void)
void
histsave(int lno, const char *cmd, int dowrite)
{
- char **hp;
- char *c, *cp;
+ char**hp;
+ char*c, *cp;
+ struct stat sb;
+
+ if (dowrite histfd) {
+ history_lock();
+ if (fstat(fileno(histfd), sb) != -1) {
+ if (timespeccmp(sb.st_mtim, last_sb.st_mtim, ==))
+ ; /* file is unchanged */
+ else {
+ /* reset history */
+ histptr = history - 1;
+ hist_source-line = 0;
+ history_load(hist_source);
+ }
+ }
+ }
c = str_save(cmd, APERM);
if ((cp =
Re: ksh history corruption
On Wed, Aug 31, 2011 at 11:59:29AM +0200, LEVAI Daniel wrote: On Tue, Aug 30, 2011 at 13:55:57 -0500, Marco Peereboom wrote: On Tue, Aug 30, 2011 at 11:11:46AM -0500, Marco Peereboom wrote: I have had enough of corrupt ksh history so I had a look at the code to try to fix it. The magical code was very magical so I basically deleted most of it and made ksh history into a flat text file. It handles multiple ksh instances writing to the same text file with locks just like the current ksh does. I haven't noticed any differences in behavior running this. If one had set HISTFILE='', the old behaviour was to not write a history file, but the in memory history was still working. With this patch, if I set HISTFILE='' then there will be no command history at all. This is the same with current ksh. I did forget to mention to move your history file out of the way before testing this. Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: ksh history corruption
On Wed, Aug 31, 2011 at 02:13:19PM +0200, LEVAI Daniel wrote: On Wed, Aug 31, 2011 at 06:57:34 -0500, Marco Peereboom wrote: On Wed, Aug 31, 2011 at 11:59:29AM +0200, LEVAI Daniel wrote: On Tue, Aug 30, 2011 at 13:55:57 -0500, Marco Peereboom wrote: On Tue, Aug 30, 2011 at 11:11:46AM -0500, Marco Peereboom wrote: I have had enough of corrupt ksh history so I had a look at the code to try to fix it. The magical code was very magical so I basically deleted most of it and made ksh history into a flat text file. It handles multiple ksh instances writing to the same text file with locks just like the current ksh does. I haven't noticed any differences in behavior running this. If one had set HISTFILE='', the old behaviour was to not write a history file, but the in memory history was still working. With this patch, if I set HISTFILE='' then there will be no command history at all. This is the same with current ksh. Not for me. Currently if I set HISTFILE to '' then in-memory history works but it doesn't write to history file (which was my intention when I've set HISTFILE=''). Hmmm, I tried again and now I see it. I blame it on not enough coffee. Thanks I'll go figure it out. Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: ksh history corruption
On Wed, Aug 31, 2011 at 07:20:42AM -0500, Marco Peereboom wrote:
On Wed, Aug 31, 2011 at 02:13:19PM +0200, LEVAI Daniel wrote:
On Wed, Aug 31, 2011 at 06:57:34 -0500, Marco Peereboom wrote:
On Wed, Aug 31, 2011 at 11:59:29AM +0200, LEVAI Daniel wrote:
On Tue, Aug 30, 2011 at 13:55:57 -0500, Marco Peereboom wrote:
On Tue, Aug 30, 2011 at 11:11:46AM -0500, Marco Peereboom wrote:
I have had enough of corrupt ksh history so I had a look at the
code to
try to fix it. The magical code was very magical so I basically
deleted
most of it and made ksh history into a flat text file. It handles
multiple ksh instances writing to the same text file with locks just
like the current ksh does. I haven't noticed any differences in
behavior running this.
If one had set HISTFILE='', the old behaviour was to not write a history
file, but the in memory history was still working.
With this patch, if I set HISTFILE='' then there will be no command
history at all.
This is the same with current ksh.
Not for me. Currently if I set HISTFILE to '' then in-memory history
works but it doesn't write to history file (which was my intention when
I've set HISTFILE='').
Hmmm, I tried again and now I see it. I blame it on not enough coffee.
Thanks I'll go figure it out.
Version 4 fixes all reported bugs.
Some folks have expressed doubt about the simplistic way of updating the
history file. Specifically the rewriting of all entries. I am
sensitive to that and know a couple of optimizations that can easily be
applied. However before I go there I'd like to get a thumbs up or down
on this approach. It trashes the binary history file format and
replaces it with flat text. Is this something we want?
Index: alloc.c
===
RCS file: /cvs/src/bin/ksh/alloc.c,v
retrieving revision 1.8
diff -u -p -r1.8 alloc.c
--- alloc.c 21 Jul 2008 17:30:08 - 1.8
+++ alloc.c 30 Aug 2011 18:05:47 -
@@ -62,7 +62,7 @@ alloc(size_t size, Area *ap)
{
struct link *l;
- l = malloc(sizeof(struct link) + size);
+ l = calloc(1, sizeof(struct link) + size);
if (l == NULL)
internal_errorf(1, unable to allocate memory);
l-next = ap-freelist;
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.39
diff -u -p -r1.39 history.c
--- history.c 19 May 2010 17:36:08 - 1.39
+++ history.c 31 Aug 2011 19:33:24 -
@@ -11,8 +11,7 @@
* a) the original in-memory history mechanism
* b) a more complicated mechanism done by p...@hillside.co.uk
* that more closely follows the real ksh way of doing
- * things. You need to have the mmap system call for this
- * to work on your system
+ * things.
*/
#include sh.h
@@ -22,19 +21,10 @@
# include sys/file.h
# include sys/mman.h
-/*
- * variables for handling the data file
- */
-static int histfd;
-static int hsize;
-
-static int hist_count_lines(unsigned char *, int);
-static int hist_shrink(unsigned char *, int);
-static unsigned char *hist_skip_back(unsigned char *,int *,int);
-static void histload(Source *, unsigned char *, int);
-static void histinsert(Source *, int, unsigned char *);
-static void writehistfile(int, char *);
-static int sprinkle(int);
+static voidwritehistfile(FILE *);
+static FILE*history_open(int *);
+static int history_load(FILE *, Source *);
+static voidhistory_close(FILE *);
static int hist_execute(char *);
static int hist_replace(char **, const char *, const char *, int);
@@ -45,8 +35,8 @@ static void histbackup(void);
static char **current; /* current position in history[] */
static char*hname; /* current name of history file */
static int hstarted; /* set after hist_init() called */
-static Source *hist_source;
-
+static Source *hist_source;
+static struct stat last_sb;
int
c_fc(char **wp)
@@ -529,15 +519,10 @@ sethistfile(const char *name)
/* if the name is the same as the name we have */
if (hname strcmp(hname, name) == 0)
return;
-
/*
* its a new name - possibly
*/
- if (histfd) {
- /* yes the file is open */
- (void) close(histfd);
- histfd = 0;
- hsize = 0;
+ if (hname) {
afree(hname, APERM);
hname = NULL;
/* let's reset the history */
@@ -577,18 +562,26 @@ init_histvec(void)
void
histsave(int lno, const char *cmd, int dowrite)
{
- char **hp;
- char *c, *cp;
+ char**hp;
+ char*c, *cp;
+ int changed;
+ FILE*f = NULL;
+
+ if (dowrite
Re: ksh history corruption
On Wed, Aug 31, 2011 at 04:41:07PM -0400, Geoff Steckel wrote: On 08/31/2011 03:42 PM, Marco Peereboom wrote: Version 4 fixes all reported bugs. Some folks have expressed doubt about the simplistic way of updating the history file. Specifically the rewriting of all entries. I am sensitive to that and know a couple of optimizations that can easily be applied. However before I go there I'd like to get a thumbs up or down on this approach. It trashes the binary history file format and replaces it with flat text. Is this something we want? IMnsHO, external non-text files have serious maintenance problems including version dependency. Does the external binary file have any significant advantages over flat text? If not, my experience is that flat text is 99+% a better choice for maintainability, interchangeability, and general obviousness. If an internal binary format has significant advantages, is the cost of conversion significant (coding time and execution time?) If not, go with an external text format for the above reasons. It has one benefit in the ksh case. It retains the line number; the flat text file obviously can't do that without introducing side effects. Now I don't know why having persistent line numbers is useful but that aside. Oh, and it gets corrupted from time to time and one does not have a chance of (without writing some code) of recovering some or any of it. I tend to lose a history file every month or so. Pure appends have a stylistic appeal as well. Anecdotally, almost no-one has been able to show me real-world efficiency gains from binary files for applications where a text file works, especially for ones read once and/or written once per program invocation. geoff steckel gwes at oat mumble com
ksh history corruption
I have had enough of corrupt ksh history so I had a look at the code to
try to fix it. The magical code was very magical so I basically deleted
most of it and made ksh history into a flat text file. It handles
multiple ksh instances writing to the same text file with locks just
like the current ksh does. I haven't noticed any differences in
behavior running this.
Code is much simpler and it shaves ~4k of the binary too.
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.39
diff -u -p -r1.39 history.c
--- history.c 19 May 2010 17:36:08 - 1.39
+++ history.c 30 Aug 2011 15:25:23 -
@@ -11,8 +11,7 @@
* a) the original in-memory history mechanism
* b) a more complicated mechanism done by p...@hillside.co.uk
* that more closely follows the real ksh way of doing
- * things. You need to have the mmap system call for this
- * to work on your system
+ * things.
*/
#include sh.h
@@ -22,19 +21,10 @@
# include sys/file.h
# include sys/mman.h
-/*
- * variables for handling the data file
- */
-static int histfd;
-static int hsize;
-
-static int hist_count_lines(unsigned char *, int);
-static int hist_shrink(unsigned char *, int);
-static unsigned char *hist_skip_back(unsigned char *,int *,int);
-static void histload(Source *, unsigned char *, int);
-static void histinsert(Source *, int, unsigned char *);
-static void writehistfile(int, char *);
-static int sprinkle(int);
+static voidwritehistfile(FILE *);
+static FILE*history_open(int *);
+static int history_load(FILE *, Source *);
+static voidhistory_close(FILE *);
static int hist_execute(char *);
static int hist_replace(char **, const char *, const char *, int);
@@ -45,8 +35,8 @@ static void histbackup(void);
static char **current; /* current position in history[] */
static char*hname; /* current name of history file */
static int hstarted; /* set after hist_init() called */
-static Source *hist_source;
-
+static Source *hist_source;
+static struct stat last_sb;
int
c_fc(char **wp)
@@ -529,15 +519,10 @@ sethistfile(const char *name)
/* if the name is the same as the name we have */
if (hname strcmp(hname, name) == 0)
return;
-
/*
* its a new name - possibly
*/
- if (histfd) {
- /* yes the file is open */
- (void) close(histfd);
- histfd = 0;
- hsize = 0;
+ if (hname) {
afree(hname, APERM);
hname = NULL;
/* let's reset the history */
@@ -577,18 +562,29 @@ init_histvec(void)
void
histsave(int lno, const char *cmd, int dowrite)
{
- char **hp;
- char *c, *cp;
+ char**hp;
+ char*c, *cp;
+ int changed;
+ FILE*f = NULL;
+
+ if (dowrite) {
+ f = history_open(changed);
+ if (f == NULL)
+ return;
+ if (changed) {
+ /* reset history */
+ histptr = history - 1;
+ hist_source-line = 0;
+ history_load(f, hist_source);
+ }
+
+ }
c = str_save(cmd, APERM);
if ((cp = strchr(c, '\n')) != NULL)
*cp = '\0';
- if (histfd dowrite)
- writehistfile(lno, c);
-
hp = histptr;
-
if (++hp = history + histsize) { /* remove oldest command */
afree((void*)*history, APERM);
for (hp = history; hp history + histsize - 1; hp++)
@@ -596,371 +592,123 @@ histsave(int lno, const char *cmd, int d
}
*hp = c;
histptr = hp;
-}
-
-/*
- * Write history data to a file nominated by HISTFILE
- * if HISTFILE is unset then history still happens, but
- * the data is not written to a file
- * All copies of ksh looking at the file will maintain the
- * same history. This is ksh behaviour.
- *
- * This stuff uses mmap()
- * if your system ain't got it - then you'll have to undef HISTORYFILE
- */
-/*
- * Open a history file
- * Format is:
- * Bytes 1, 2: HMAGIC - just to check that we are dealing with
- * the correct object
- * Then follows a number of stored commands
- * Each command is
- * command bytecommand number(4 bytes)bytesnull
- */
-#define HMAGIC10xab
-#define HMAGIC20xcd
-#define COMMAND0xff
+ if (dowrite) {
+ writehistfile(f);
+ history_close(f);
+ }
+}
-void
-hist_init(Source *s)
+static FILE *
+history_open(int *changed)
{
- unsigned char *base;
- int lines;
- int fd;
-
- if
Re: ksh history corruption
On Tue, Aug 30, 2011 at 11:11:46AM -0500, Marco Peereboom wrote:
I have had enough of corrupt ksh history so I had a look at the code to
try to fix it. The magical code was very magical so I basically deleted
most of it and made ksh history into a flat text file. It handles
multiple ksh instances writing to the same text file with locks just
like the current ksh does. I haven't noticed any differences in
behavior running this.
Code is much simpler and it shaves ~4k of the binary too.
Better diff attached.
Index: alloc.c
===
RCS file: /cvs/src/bin/ksh/alloc.c,v
retrieving revision 1.8
diff -u -p -r1.8 alloc.c
--- alloc.c 21 Jul 2008 17:30:08 - 1.8
+++ alloc.c 30 Aug 2011 18:05:47 -
@@ -62,7 +62,7 @@ alloc(size_t size, Area *ap)
{
struct link *l;
- l = malloc(sizeof(struct link) + size);
+ l = calloc(1, sizeof(struct link) + size);
if (l == NULL)
internal_errorf(1, unable to allocate memory);
l-next = ap-freelist;
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.39
diff -u -p -r1.39 history.c
--- history.c 19 May 2010 17:36:08 - 1.39
+++ history.c 30 Aug 2011 18:45:14 -
@@ -11,8 +11,7 @@
* a) the original in-memory history mechanism
* b) a more complicated mechanism done by p...@hillside.co.uk
* that more closely follows the real ksh way of doing
- * things. You need to have the mmap system call for this
- * to work on your system
+ * things.
*/
#include sh.h
@@ -22,19 +21,10 @@
# include sys/file.h
# include sys/mman.h
-/*
- * variables for handling the data file
- */
-static int histfd;
-static int hsize;
-
-static int hist_count_lines(unsigned char *, int);
-static int hist_shrink(unsigned char *, int);
-static unsigned char *hist_skip_back(unsigned char *,int *,int);
-static void histload(Source *, unsigned char *, int);
-static void histinsert(Source *, int, unsigned char *);
-static void writehistfile(int, char *);
-static int sprinkle(int);
+static voidwritehistfile(FILE *);
+static FILE*history_open(int *);
+static int history_load(FILE *, Source *);
+static voidhistory_close(FILE *);
static int hist_execute(char *);
static int hist_replace(char **, const char *, const char *, int);
@@ -45,8 +35,8 @@ static void histbackup(void);
static char **current; /* current position in history[] */
static char*hname; /* current name of history file */
static int hstarted; /* set after hist_init() called */
-static Source *hist_source;
-
+static Source *hist_source;
+static struct stat last_sb;
int
c_fc(char **wp)
@@ -529,15 +519,10 @@ sethistfile(const char *name)
/* if the name is the same as the name we have */
if (hname strcmp(hname, name) == 0)
return;
-
/*
* its a new name - possibly
*/
- if (histfd) {
- /* yes the file is open */
- (void) close(histfd);
- histfd = 0;
- hsize = 0;
+ if (hname) {
afree(hname, APERM);
hname = NULL;
/* let's reset the history */
@@ -577,18 +562,29 @@ init_histvec(void)
void
histsave(int lno, const char *cmd, int dowrite)
{
- char **hp;
- char *c, *cp;
+ char**hp;
+ char*c, *cp;
+ int changed;
+ FILE*f = NULL;
+
+ if (dowrite) {
+ f = history_open(changed);
+ if (f == NULL)
+ return;
+ if (changed) {
+ /* reset history */
+ histptr = history - 1;
+ hist_source-line = 0;
+ history_load(f, hist_source);
+ }
+
+ }
c = str_save(cmd, APERM);
if ((cp = strchr(c, '\n')) != NULL)
*cp = '\0';
- if (histfd dowrite)
- writehistfile(lno, c);
-
hp = histptr;
-
if (++hp = history + histsize) { /* remove oldest command */
afree((void*)*history, APERM);
for (hp = history; hp history + histsize - 1; hp++)
@@ -596,371 +592,124 @@ histsave(int lno, const char *cmd, int d
}
*hp = c;
histptr = hp;
-}
-
-/*
- * Write history data to a file nominated by HISTFILE
- * if HISTFILE is unset then history still happens, but
- * the data is not written to a file
- * All copies of ksh looking at the file will maintain the
- * same history. This is ksh behaviour.
- *
- * This stuff uses mmap()
- * if your system ain't got it - then you'll have to undef HISTORYFILE
- */
-/*
- * Open a history
Re: xterm bug
On Thu, Aug 18, 2011 at 10:17:31AM +0200, Mark Kettenis wrote:
Date: Wed, 17 Aug 2011 16:11:55 -0500
From: Marco Peereboom ma...@peereboom.us
After the long debate yesterday about clipboards sucking major eggs and
stuff I started looking into the problem. One of the problems is that
xterm doesn't honor the Keep Selection flag. The code is a little
tangly but if I read it correctly it looks like a simple test was
missed. This brings xterm in line with all other applications
(including gtk ones) where, by default, if a selection is cleared on the
screen it ISN'T cleared from PRIMARY. People who desire the clearing of
PRIMARY should use the XTerm*keepSelection: false setting as described
in the manual.
This is just step one. The rest of the issues seem to be hidden in gtk.
Makes no sense. The keepSelection check is already done in
ScrnDisownSelection(). The only place where DisownSelection() is
called directly is SelectSet(), and that should only happen if you
explicitly shrink your selection to nothing.
It goes down another code path. This through me for a loop but the
trace shows this.
As far as I know, xterm keeps the selection just fine. If I select
some text in one xterm, then click at some random place in that same
xterm such that the text is no longer highlighted, I can paste it just
fine into another xterm using the middle mouse button.
But not in any application that doesn't use CUT_BUFFER0. Which these
days is about everything minus xterm. This diff brings xterm in line
with everything else and as far as I can see with the man page.
Index: button.c
===
RCS file: /cvs/xenocara/app/xterm/button.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 button.c
--- button.c7 Mar 2011 20:41:27 - 1.17
+++ button.c17 Aug 2011 21:01:24 -
@@ -3890,7 +3890,7 @@ DisownSelection(XtermWidget xw)
for (i = 0; i count; i++) {
int cutbuffer = CutBuffer(atoms[i]);
- if (cutbuffer 0) {
+ if (!screen-keepSelection cutbuffer 0) {
XtDisownSelection((Widget) xw, atoms[i],
screen-selection_time);
}
Re: xterm bug
On Thu, Aug 18, 2011 at 11:21:28AM +0200, Pascal Stumpf wrote: On Thu, Aug 18, 2011 at 10:17:31AM +0200, Mark Kettenis wrote: Makes no sense. The keepSelection check is already done in ScrnDisownSelection(). The only place where DisownSelection() is called directly is SelectSet(), and that should only happen if you explicitly shrink your selection to nothing. As far as I know, xterm keeps the selection just fine. If I select some text in one xterm, then click at some random place in that same xterm such that the text is no longer highlighted, I can paste it just fine into another xterm using the middle mouse button. Having done some simple tests, the situation seems to be like this: If you highlight some text in an xterm, it's copied to PRIMARY just fine and kept there if keepSelection is true. However, PRIMARY cannot be accessed by gtk apps, which use the CLIPBOARD. So most people do something like xterm*VT100.translations: #override Btn1Up: select-end(PRIMARY, CLIPBOARD, CUT _BUFFER0) in their .Xdefaults. And here's the problem: If you select text, it gets copied to both PRIMARY and CLIPBOARD. If you then click somewhere else in the same xterm, it is kept in PRIMARY, but *not* in CLIPBOARD (so it's lost for gtk apps). This is the behavior that should happen with xterm*keepSelection: false Hope this helps. It doesn't because this isn't what the man page states for keep selection. It only works with Scrn* functions and does not get tested when DisownSelection is called, which is called from some other spots directly as well instead of going through Scrn*.
Re: xterm bug
On Thu, Aug 18, 2011 at 02:45:37PM +0200, Pascal Stumpf wrote: On Thu, Aug 18, 2011 at 06:46:12AM -0500, Marco Peereboom wrote: It doesn't because this isn't what the man page states for keep selection. It only works with Scrn* functions and does not get tested when DisownSelection is called, which is called from some other spots directly as well instead of going through Scrn*. No. It does what the manpage says: Keep the selection (= PRIMARY). Copying that to CLIPBOARD is a customisation that has nothing to do with keepSelection. That isn't what the diff does. Anyway, more on the PRIMARY vs. CLIPBOARD problem: http://www.freedesktop.org/wiki/Specifications/ClipboardsWiki?action=showredirect=Standards%2FClipboardsWiki I am well aware of this document and the spec. So xterm cannot (by default) even copy stuff into CLIPBOARD by mere selection without violating the ICCCM. Imho, the correct way to solve this would be to implement explicit cut/copy/paste commands; and that way, it would truly handle both buffers like all other applications. In any case, something like this should probably go upstream. Here is my script to test: $ cat /home/marco/bin/showclip.sh #!/bin/sh for c in clipboard primary secondary do echo == $c xclip -o -selection $c echo done echo == cut_buffer0 xprop -root -len 1024 CUT_BUFFER0 The Keep Selection option _doesn't_ do anything at all. Go through this use case to see it in action: 1 select something in xterm 2 run showclip.sh note how primary and cut_buffer0 have the same content 3 click on the same xterm ans watch the highlighting dissapear 4 run showclip.sh note how primary is cleared and cut_buffer0 still has the previous content Now we can argue if that is intended or not but what I read in the man page and ctlseqs.txt is that this option is a toggle for that. Let me quote ctlseqs.txt Ps = 1 0 4 0 - Keep selection even if not highlighted. (This enables the keepSelection resource).. Additionally, cut buffers have been deprecated. This means that all modern applications that no longer look at them can no longer effectively copy between xterm and said modern application (like gtk apps). Now lets go one further, if you set the selectToClipboard resource to true, the same behavior occurs. This violates clipboard behavior and the principle of least astonishment. Lastly, and this a slightly weaker argument however, here goes. All the other applications do NOT clear primary when text is unhighlighted. xterm is the odd one out doing it's own thing. I have not run across any other app that exhibits this behavior. The diff makes keepSelection work the way the man page and the ctlseqs.txt document (at least the way I read it) AND the user gets to pick which behavior he/she prefers.
Re: 4096 byte sector devices (a.k.a. disks 3TB)
On Mon, Jun 20, 2011 at 08:30:40PM -0400, Kenneth R Westerback wrote: I committed a fix to fdisk(8) today to un-break the -i and -e options on 4096-byte devices. To make a long story short, it had been working accidentally until I committed a 4.9 change to fdisk(8) to make it pay attention to the errors returned from MBR_read(). However this has raised once more concerns about what is going to happen when 4096-byte sector devices become common, then the norm, and then the smallest disks available. There has been a lot of work done in the last few years to de-couple the internal kernel view of a disk (a series of 512 byte blocks) and the 'real world' view of potentially different sector size devices. With seemless translation being done behind the scenes. However, as today has shown, there may well be further unreconstructed code making invalid assumptions or currently silently working accidentally and waiting for the day when it can blow up your machine. So if you have such a device (disks 3TB are your best bet) I would be very interested in hearing how hard you have to work to break something. Of course the clever can also create vnd's with such large sectors but actual hardware is more convincing. Various filesystems (supported ones only please!), utilities such as fdisk, disklabel, newfs, fsck, dump, restore, etc. Anything which may do any serious disk i/o or is suspected of attempting raw, low level i/o. It just occurred to me that softraid crypto would benefit quite a bit from 4096 byte sectors. And... we can use softraid to force 4096 byte sectors pretty trivially so it can be used a test harness as well in lieu of 3096 byte sector disks. Ken
Re: softraid crypto: preallocate crypops and dma buffers.
I am liking this diff quite a bit but it needs more testers. So if you
are using softraid crypto please try this diff.
On Fri, Jun 17, 2011 at 07:53:05PM +0100, Owain Ainsworth wrote:
So here's the problem: ENOMEM on io in a hba driver is bad juju.
In more detail:
When preparing for each io softraid crypto does a
sr_crypto_getcryptop(). This operation does a few things:
- allocate a uio and iovec from a pool.
- if this is a read then allocate a dma buffer with dma_alloc (up to
MAXPHYS, i.e. 64k)
- allocate a cryptop to be used with the crypto(9) framework.
- initialise the above for use in the io.
So if you are getting very low on memory, one of these operations
(probably the dma alloc) will fail. when this happens softraid returns
XS_DRIVER_STUFFUP to scsi land. This returns an EIO back to callers.
Now it is fairly common to use softdep in these situations, synchronous
filesystems are slw. softdep has certain assumptions about how
things will work. if a queued dependancy fails that invalidates these
assumptions. softraid panics in this case. I used to hit this repeatedly
(several times a day) before I bought more memory.
in general, most disk controllers prealloc everything they need (that
isn't passed down to them) so that this won't be a problem.
This diff does the same for softraid crypto. It'll eat just over 1meg of
kva, but it is hardly the only driver to need to do that.
The only slightly scary thing here is the cryptodesc list manipulations
(the comments explain why they are necesary).
I'm typing from a machine that runs this. todd@ is also testing it and
marco kindly did some horrible io torture on a machine running this too
and it runs quite nicely.
A side benefit is that due to missing out allocations in every disk io
this is actually slightly faster in io too.
More testing would be appreciated. Cheers,
-0-
diff --git dev/softraid_crypto.c dev/softraid_crypto.c
index 3259121..a60824e 100644
--- dev/softraid_crypto.c
+++ dev/softraid_crypto.c
@@ -56,9 +56,26 @@
#include dev/softraidvar.h
#include dev/rndvar.h
-struct cryptop *sr_crypto_getcryptop(struct sr_workunit *, int);
+/*
+ * the per-io data that we need to preallocate. We can't afford to allow io
+ * to start failing when memory pressure kicks in.
+ * We can store this in the WU because we assert that only one
+ * ccb per WU will ever be active.
+ */
+struct sr_crypto_wu {
+ TAILQ_ENTRY(sr_crypto_wu)cr_link;
+ struct uio cr_uio;
+ struct iovec cr_iov;
+ struct cryptop *cr_crp;
+ struct cryptodesc *cr_descs;
+ struct sr_workunit *cr_wu;
+ void*cr_dmabuf;
+};
+
+
+struct sr_crypto_wu *sr_crypto_wu_get(struct sr_workunit *, int);
+void sr_crypto_wu_put(struct sr_crypto_wu *);
int sr_crypto_create_keys(struct sr_discipline *);
-void *sr_crypto_putcryptop(struct cryptop *);
int sr_crypto_get_kdf(struct bioc_createraid *,
struct sr_discipline *);
int sr_crypto_decrypt(u_char *, u_char *, u_char *, size_t, int);
@@ -78,7 +95,7 @@ int sr_crypto_meta_opt_load(struct sr_discipline *,
struct sr_meta_opt *);
int sr_crypto_write(struct cryptop *);
int sr_crypto_rw(struct sr_workunit *);
-int sr_crypto_rw2(struct sr_workunit *, struct cryptop *);
+int sr_crypto_rw2(struct sr_workunit *, struct sr_crypto_wu *);
void sr_crypto_intr(struct buf *);
int sr_crypto_read(struct cryptop *);
void sr_crypto_finish_io(struct sr_workunit *);
@@ -230,40 +247,35 @@ done:
return (rv);
}
-struct cryptop *
-sr_crypto_getcryptop(struct sr_workunit *wu, int encrypt)
+
+struct sr_crypto_wu *
+sr_crypto_wu_get(struct sr_workunit *wu, int encrypt)
{
struct scsi_xfer*xs = wu-swu_xs;
struct sr_discipline*sd = wu-swu_dis;
- struct cryptop *crp = NULL;
+ struct sr_crypto_wu *crwu;
struct cryptodesc *crd;
- struct uio *uio = NULL;
- int flags, i, n, s;
+ int flags, i, n;
daddr64_t blk = 0;
u_int keyndx;
- DNPRINTF(SR_D_DIS, %s: sr_crypto_getcryptop wu: %p encrypt: %d\n,
+ DNPRINTF(SR_D_DIS, %s: sr_crypto_wu_get wu: %p encrypt: %d\n,
DEVNAME(sd-sd_sc), wu, encrypt);
- s = splbio();
- uio = pool_get(sd-mds.mdd_crypto.sr_uiopl, PR_ZERO | PR_NOWAIT);
- if (uio == NULL)
- goto poolunwind;
- uio-uio_iov = pool_get(sd-mds.mdd_crypto.sr_iovpl,
- PR_ZERO | PR_NOWAIT);
- if (uio-uio_iov == NULL)
- goto poolunwind;
- splx(s);
+ mtx_enter(sd-mds.mdd_crypto.scr_mutex);
+ if ((crwu =
Re: Toshiba M30 ACPI support
What Paul said!
I have been looking at the diff but don't have the gear to test with.
So please test this and report back.
On Thu, Jun 16, 2011 at 10:58:56AM +0300, Paul Irofti wrote:
People with Toshiba's should test now so that they don't cry later.
Or is there nobody using toshiba nowadays?! Come on people!
On Wed, Jun 15, 2011 at 09:35:24PM +0200, Javier Vazquez wrote:
Hello,
Sending toshiba patch file with the new changes.
Thanks,
Javier.
On Wed, Jun 15, 2011 at 11:03:49AM +0300, Paul Irofti wrote:
On Tue, Jun 14, 2011 at 10:07:54PM +0200, Javier Vazquez wrote:
Hello again,
Sending toshiba acpi patch as Paul has suggested.
Cool!
[--snip--]
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.224
diff -u -p -r1.224 acpi.c
--- dev/acpi/acpi.c 27 Apr 2011 20:55:42 - 1.224
+++ dev/acpi/acpi.c 14 Jun 2011 20:02:44 -
@@ -93,6 +93,7 @@ void acpi_pbtn_task(void *, int);
#ifndef SMALL_KERNEL
intacpi_thinkpad_enabled;
+intacpi_toshiba_enabled;
intacpi_saved_spl;
intacpi_enabled;
@@ -781,8 +782,8 @@ acpi_attach(struct device *parent, struc
/* check if we're running on a sony */
aml_find_node(aml_root, GBRT, acpi_foundsony, sc);
- /* attach video only if this is not a stinkpad */
- if (!acpi_thinkpad_enabled)
+ /* attach video only if this is not a stinkpad or toshiba */
+ if (!acpi_thinkpad_enabled || !acpi_toshiba_enabled)
aml_find_node(aml_root, _DOS, acpi_foundvideo, sc);
You forgot to fix this into:
+ if (!acpi_thinkpad_enabled !acpi_toshiba_enabled)
? toshiba_acpi.patch
Index: arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.319
diff -u -p -r1.319 GENERIC
--- arch/amd64/conf/GENERIC 30 May 2011 22:03:47 - 1.319
+++ arch/amd64/conf/GENERIC 15 Jun 2011 19:35:23 -
@@ -52,6 +52,7 @@ acpimcfg* at acpi?
acpiasus* at acpi?
acpisony* at acpi?
acpithinkpad* at acpi?
+acpitoshiba* at acpi?
acpivideo* at acpi?
acpivout* at acpivideo?
acpipwrres*at acpi?
Index: arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.716
diff -u -p -r1.716 GENERIC
--- arch/i386/conf/GENERIC 30 May 2011 22:03:47 - 1.716
+++ arch/i386/conf/GENERIC 15 Jun 2011 19:35:24 -
@@ -62,6 +62,7 @@ acpitz* at acpi?
acpiasus* at acpi?
acpisony* at acpi?
acpithinkpad* at acpi?
+acpitoshiba* at acpi?
acpivideo* at acpi?
acpivout* at acpivideo?
acpipwrres*at acpi?
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.224
diff -u -p -r1.224 acpi.c
--- dev/acpi/acpi.c 27 Apr 2011 20:55:42 - 1.224
+++ dev/acpi/acpi.c 15 Jun 2011 19:35:27 -
@@ -93,6 +93,7 @@ void acpi_pbtn_task(void *, int);
#ifndef SMALL_KERNEL
intacpi_thinkpad_enabled;
+intacpi_toshiba_enabled;
intacpi_saved_spl;
intacpi_enabled;
@@ -781,8 +782,8 @@ acpi_attach(struct device *parent, struc
/* check if we're running on a sony */
aml_find_node(aml_root, GBRT, acpi_foundsony, sc);
- /* attach video only if this is not a stinkpad */
- if (!acpi_thinkpad_enabled)
+ /* attach video only if this is not a stinkpad or toshiba */
+ if (!acpi_thinkpad_enabled !acpi_toshiba_enabled)
aml_find_node(aml_root, _DOS, acpi_foundvideo, sc);
/* create list of devices we want to query when APM come in */
@@ -2334,6 +2335,13 @@ acpi_foundhid(struct aml_node *node, voi
acpi_thinkpad_enabled = 1;
} else if (!strcmp(dev, ACPI_DEV_ASUSAIBOOSTER))
aaa.aaa_name = aibs;
+ else if (!strcmp(dev, ACPI_DEV_TOSHIBA_LIBRETTO) ||
+ !strcmp(dev, ACPI_DEV_TOSHIBA_DYNABOOK) ||
+ !strcmp(dev, ACPI_DEV_TOSHIBA_SPA40)) {
+ aaa.aaa_name = acpitoshiba;
+ acpi_toshiba_enabled = 1;
+ }
+
if (aaa.aaa_name)
config_found(self, aaa, acpi_print);
Index: dev/acpi/acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.25
diff -u -p -r1.25 acpireg.h
--- dev/acpi/acpireg.h 27 Apr 2011 20:55:42 - 1.25
+++ dev/acpi/acpireg.h 15 Jun 2011 19:35:27 -
@@ -716,5 +716,8 @@ struct acpi_ivrs {
#define ACPI_DEV_IBM IBM0068
Re: Panic in sr_crypto_rw with kern.bufcachepercent = 75
Can I get the orignal diff one more time?
On Fri, May 20, 2011 at 04:51:02PM +0200, David Coppa wrote:
On Fri, May 20, 2011 at 2:45 PM, Mike Belopuhov m...@crypt.org.ru wrote:
On Fri, May 20, 2011 at 06:24 -0600, David Coppa wrote:
Hi all,
OpenBSD-current snapshot dated 16-May-2011:
I get an always-reproducible panic with softraid crypto and
kern.bufcachepercent = 75, when untarring a tarball of the
complete source tree.
The disk layout is the following, with softraid crypto for
all but /:
/dev/sd0a on / type ffs (local)
/dev/sd2f on /home type ffs (local, nodev, nosuid)
/dev/sd2e on /usr type ffs (local, nodev)
/dev/sd2d on /var type ffs (local, nodev, nosuid)
/dev/sd3i on /mnt type msdos (local)
Here's the trace:
panic: sr_crypto_rw: no crypto op
hi,
although i'm not sure that this is a best solution, i can't
see why we should panic here. ?sr_scsi_cmd seems to cope with
stuffups just fine.
Index: dev/softraid_crypto.c
===
RCS file: /home/cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.65
diff -u -p -r1.65 softraid_crypto.c
--- dev/softraid_crypto.c ? ? ? 6 Apr 2011 03:14:51 - ? ? ? 1.65
+++ dev/softraid_crypto.c ? ? ? 20 May 2011 12:42:12 -
@@ -1115,7 +1115,7 @@ sr_crypto_rw(struct sr_workunit *wu)
? ? ? ?if (wu-swu_xs-flags SCSI_DATA_OUT) {
? ? ? ? ? ? ? ?crp = sr_crypto_getcryptop(wu, 1);
? ? ? ? ? ? ? ?if (crp == NULL)
- ? ? ? ? ? ? ? ? ? ? ? panic(sr_crypto_rw: no crypto op);
+ ? ? ? ? ? ? ? ? ? ? ? return (1);
? ? ? ? ? ? ? ?crp-crp_callback = sr_crypto_write;
? ? ? ? ? ? ? ?crp-crp_opaque = wu;
? ? ? ? ? ? ? ?s = splvm();
It now survives to several untarrings of src.tar with kern.bufcachepercent=90.
cheers,
David
Re: vmmap and emacs-22
On Wed, May 18, 2011 at 09:00:25PM -0500, Brad DeMorrow wrote:
On Wed, May 18, 2011 at 8:49 PM, Ariane van der Steldt ari...@stack.nl
wrote:
On Thu, May 19, 2011 at 03:32:10AM +0200, Ariane van der Steldt wrote:
Hi,
I would respond in-thread, but I can't find the thread that had the
original report that emacs-22 doesn't work under vmmap. Perhaps it was
only on icb...
Anyways, emacs-22.3p8 doesn't work under vmmap on i386. And the lovely
thing is, it's not my bug. :)
Emacs, by way of elf commands, insists on having the data area
(ep_daddr) start at address 0x81bd000 (approx 136MB). This means that,
starting at that address, a huge amount of memory (BRKSIZ + MAXDSIZ =
3GB) is unavailable to load libraries.
Normally, this is not a problem (try this on sparc and it just works,
for example). But i386 is special in the way it handles W^X requiring
approx 512MB to load libraries (this presentation explains it all:
http://www.openbsd.org/papers/ven05-deraadt/index.html ).
Short story long, emacs fails to load its libraries into the area it
reserved for brk() and our ld.so, noticing it is asked to work miracles
here, rightfully objects.
Possible way to fix this: teach emacs to be happy with the default
ep_daddr instead of being special or get PXE working (hint hint!).
s/PXE/PAE/ (hint hint!)
--
Ariane
Or we could all just use vi{m} as god intended.
/me ducks
amen brother
Re: Typo in biovar.h?
On Fri, May 13, 2011 at 11:57:37AM +0200, Mike Belopuhov wrote:
On Fri, May 13, 2011 at 11:50 AM, Otto Moerbeek o...@drijf.net wrote:
On Fri, May 13, 2011 at 11:39:01AM +0200, Mike Belopuhov wrote:
On Fri, May 13, 2011 at 11:26 AM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
From: Vadim Zhukov persg...@gmail.com
Date: Fri, 13 May 2011 13:10:10 +0400
Hello all.
Looks like there is a typo in ioctl number...
What makes you think this is a typo?
there are two ioctls with the same command number:
#define BIOCDISCIPLINE _IOWR('B', 40, struct bioc_discipline)
#define BIOCINSTALLBOOT _IOWR('B', 40, struct bioc_installboot)
Only if the two structs happen to have the same size they will clash.
indeed. but was it intentional to have them both set to 40
in the first place?
I'll venture and guess this was unintended. We should make it unique
and I am ok with the original diff that makes it 41.
-Otto
Re: Fan mode management in acpithinkpad(4)
On Thu, May 12, 2011 at 03:32:56PM +0200, Christopher Zimmermann wrote: On 05/12/11 14:37, Vadim Zhukov wrote: Hello all. Here is a patch that allows for me to work on other things. :) Basically, it makes OS choose fan mode instead of firmware. Main feature here is enabling of disengadged mode when temperature goes critical, picking 80C as a red line. Now I can fully load CPU on my X201i - say, make -j 4 - and it still works instead of being powering off by acpitz(4). All information was taken from Linux's thinkpad_acpi.c: http://lxr.free-electrons.com/source/drivers/platform/x86/thinkpad_acpi.c (look at 2f register). I also fixed a few style nits here and there. That's a nice approach you are taking here. Switching to disengaged only when cpu gets too hot and letting firmware handle fan autoregulation otherwise. When I find the time I, maybe I will finish my patch to allow fan regulation from userspace, but then certeinly keep your approach as failsafe. User space will not be allowed to play. I don't have a stinkpad so I can't test this but I do encourage people to play with this diff and report to the list. Christopher
Re: attach acpithinkpad on newer lenovo thinkpads
sure
On Wed, Apr 27, 2011 at 03:36:44PM -0500, joshua stein wrote:
this attaches acpithinkpad to newer lenovo thinkpads like the x120e.
hw.sensors.acpithinkpad0.temp0=57.00 degC
hw.sensors.acpithinkpad0.temp1=0.00 degC
hw.sensors.acpithinkpad0.temp2=57.00 degC
hw.sensors.acpithinkpad0.temp3=0.00 degC
hw.sensors.acpithinkpad0.temp4=0.00 degC
hw.sensors.acpithinkpad0.temp5=0.00 degC
hw.sensors.acpithinkpad0.temp6=27.00 degC
hw.sensors.acpithinkpad0.temp7=0.00 degC
hw.sensors.acpithinkpad0.fan0=335 RPM
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.223
diff -u -p -u -p -r1.223 acpi.c
--- acpi.c22 Apr 2011 18:22:01 - 1.223
+++ acpi.c27 Apr 2011 20:32:46 -
@@ -2328,7 +2328,8 @@ acpi_foundhid(struct aml_node *node, voi
aaa.aaa_name = acpibtn;
else if (!strcmp(dev, ACPI_DEV_ASUS))
aaa.aaa_name = acpiasus;
- else if (!strcmp(dev, ACPI_DEV_THINKPAD)) {
+ else if (!strcmp(dev, ACPI_DEV_IBM) ||
+ !strcmp(dev, ACPI_DEV_LENOVO)) {
aaa.aaa_name = acpithinkpad;
acpi_thinkpad_enabled = 1;
} else if (!strcmp(dev, ACPI_DEV_ASUSAIBOOSTER))
Index: acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 acpireg.h
--- acpireg.h 4 Jan 2011 21:17:49 - 1.24
+++ acpireg.h 27 Apr 2011 20:32:47 -
@@ -713,7 +713,8 @@ struct acpi_ivrs {
#define ACPI_DEV_THZ THERMALZONE /* Thermal Zone */
#define ACPI_DEV_FFB FIXEDBUTTON /* Fixed Feature Button */
#define ACPI_DEV_ASUSASUS010 /* ASUS Hotkeys */
-#define ACPI_DEV_THINKPAD IBM0068 /* ThinkPad support */
+#define ACPI_DEV_IBM IBM0068 /* IBM ThinkPad support */
+#define ACPI_DEV_LENOVO LEN0068 /* Lenovo ThinkPad support */
#define ACPI_DEV_ASUSAIBOOSTER ATK0110 /* ASUSTeK AI Booster */
#endif /* !_DEV_ACPI_ACPIREG_H_ */
Index: acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 acpithinkpad.c
--- acpithinkpad.c2 Jan 2011 04:56:57 - 1.25
+++ acpithinkpad.c27 Apr 2011 20:32:47 -
@@ -114,7 +114,9 @@ struct cfdriver acpithinkpad_cd = {
NULL, acpithinkpad, DV_DULL
};
-const char *acpithinkpad_hids[] = { ACPI_DEV_THINKPAD, 0 };
+const char *acpithinkpad_hids[] = {
+ ACPI_DEV_IBM, ACPI_DEV_LENOVO, 0
+};
int
thinkpad_match(struct device *parent, void *match, void *aux)
OpenBSD 4.9-current (GENERIC.MP) #6: Thu Dec 31 18:16:11 CST 2009
j...@re.superblock.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80clock_battery
real mem = 3867213824 (3688MB)
avail mem = 3750223872 (3576MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf9ba0 (60 entries)
bios0: vendor LENOVO version 8FET27WW (1.11 ) date 03/24/2011
bios0: LENOVO 05962RU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC HPET APIC MCFG UEFI UEFI SSDT SSDT UEFI
acpi0: wakeup devices PB4_(S4) PB5_(S4) PB6_(S4) PB7_(S4) OHC1(S3) EHC1(S3)
OHC2(S3) EHC2(S3) OHC3(S3) EHC3(S3) OHC4(S3) SBAZ(S4) GEC_(S4) P2P_(S5)
SPB0(S4) SPB1(S4) SPB2(S4) SPB3(S4) LID_(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD E-350 Processor, 1597.52 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD E-350 Processor, 1596.60 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,LONG
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpimcfg0 at acpi0 addr 0xf800, bus 0-31
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB4_)
acpiprt2 at acpi0: bus -1 (PB5_)
acpiprt3 at acpi0: bus 1 (PB6_)
acpiprt4 at acpi0: bus -1 (PB7_)
acpiprt5 at acpi0: bus 2 (P2P_)
acpiprt6 at acpi0: bus 3 (SPB0)
acpiprt7 at acpi0: bus 4 (SPB1)
acpiprt8 at acpi0: bus -1 (SPB2)
acpiprt9 at acpi0: bus -1 (SPB3)
acpiec0 at
Re: relax gcc -Wsentinel checking
yes please! the casting of a NULL pointer is a pain in the butt and ugly. On Sat, Apr 02, 2011 at 11:13:05AM +, Miod Vallat wrote: The -Wsentinel warning is supposed to complain when the last argument in a call to a function which has __attribute__((sentinel)) is not a NULL pointer. However, the current implementation of the check in gcc 3 and gcc 4 will warn if the last argument is not explicitely declared as a pointer type, i.e. execl(foo, bar, (const char *)NULL) will not warn, but execl(foo, bar, NULL) will cause a false warning, because NULL is defined as 0L for non-C++ code. The following diff relaxes the check to let it accept either a pointer or an integer type of the same width as a pointer (i.e. on a 64 bit platform, using 0L will compile silently, but using 0 will). Ok? (note that this has only been tested on gcc 4, the gcc 3 version is similar but has not even been checked to compile yet) Index: gnu/gcc/gcc/c-common.c === RCS file: /cvs/src/gnu/gcc/gcc/c-common.c,v retrieving revision 1.3 diff -u -p -r1.3 c-common.c --- gnu/gcc/gcc/c-common.c12 May 2010 13:35:20 - 1.3 +++ gnu/gcc/gcc/c-common.c2 Apr 2011 11:04:49 - @@ -5498,15 +5498,17 @@ check_function_sentinel (tree attrs, tre } /* Validate the sentinel. */ - if ((!POINTER_TYPE_P (TREE_TYPE (TREE_VALUE (sentinel))) -|| !integer_zerop (TREE_VALUE (sentinel))) + sentinel = TREE_VALUE (sentinel); + if ((!(POINTER_TYPE_P (TREE_TYPE (sentinel)) + || (TREE_CODE (sentinel) == INTEGER_CST + TYPE_PRECISION (TREE_TYPE (sentinel)) == POINTER_SIZE)) +|| !integer_zerop (sentinel)) /* Although __null (in C++) is only an integer we allow it nevertheless, as we are guaranteed that it's exactly as wide as a pointer, and we don't want to force users to cast the NULL they have written there. We warn with -Wstrict-null-sentinel, though. */ -(warn_strict_null_sentinel - || null_node != TREE_VALUE (sentinel))) +(warn_strict_null_sentinel || null_node != sentinel)) warning (OPT_Wformat, missing sentinel in function call); } } Index: gnu/usr.bin/gcc/gcc/c-common.c === RCS file: /cvs/src/gnu/usr.bin/gcc/gcc/c-common.c,v retrieving revision 1.6 diff -u -p -r1.6 c-common.c --- gnu/usr.bin/gcc/gcc/c-common.c16 Oct 2009 12:22:07 - 1.6 +++ gnu/usr.bin/gcc/gcc/c-common.c2 Apr 2011 11:04:50 - @@ -6502,8 +6502,11 @@ check_function_sentinel (attrs, params) } /* Validate the sentinel. */ - if (!POINTER_TYPE_P (TREE_TYPE (TREE_VALUE (sentinel))) - || !integer_zerop (TREE_VALUE (sentinel))) + sentinel = TREE_VALUE (sentinel); + if (!(POINTER_TYPE_P (TREE_TYPE (sentinel)) + || (TREE_CODE (sentinel) == INTEGER_CST + TYPE_PRECISION (TREE_TYPE (sentinel)) == POINTER_SIZE)) +|| !integer_zerop (sentinel)) warning (missing sentinel in function call); } }
Re: acpivideo: do not trust _DOD for brightness
I agree. In fact attaching those devices on the 620 makes no sense. On Apr 1, 2011, at 17:20, Martynas Venckus marty...@venck.us wrote: On 4/2/11, Paul Irofti p...@irofti.net wrote: What about devices that should support _DOS and don't support brightness? I've tested this on a D620 (which has the methods but does brightness through the BIOS) and the relevant dmesg diff is: -acpivout0 at acpivideo1: TV__ -acpivout1 at acpivideo1: CRT_ -acpivout2 at acpivideo1: LCD_ -acpivout3 at acpivideo1: DVI_ This makes sense I guess because they're useless on this model, but I'm not sure about other laptops. The first revision of the diff I've posted to you (offlist) handles this, i.e. attaches to all _DOD, and then additionally to all devices having the brightness methods. But I don't see a need for complexity in this case--if device doesn't have the relevant methods, acpivoutX would attach doing nothing (like in your case). This way is both simpler and more reliable.
Re: horribly slow fsck_ffs pass1 performance
On Thu, Mar 31, 2011 at 09:13:41AM +, Stuart Henderson wrote: On 2011-03-31, Otto Moerbeek o...@drijf.net wrote: On Wed, Mar 30, 2011 at 03:45:02PM -0500, Amit Kulkarni wrote: In fsck_ffs's pass1.c it just takes forever for large sized partitions and also if you have very high number of files stored on that partition (used inodes count goes high). If you really have a lot of used inodes, skipping the unused ones isn't going to help :-) You could always build your large-sized filesystems with a larger value of bytes-per-inode. newfs -i 32768 or 65536 is good for common filesystem use patterns with larger partitions (for specialist uses e.g. storing backups as huge single files it might be appropriate to go even higher). So this helps a lot to reduce fsck however if you play a lot with the tuning parameters the only thing you tune is less speed. I played quite a bit with the parameters and the results were always worse than the defaults. Of course this does involve dump/restore if you need to do this for an existing filesystem. It is interesting because it really speeds up fsck_ffs for filesystems with few used inodes. There's also a dangerous part: it assumes the cylinder group summary info is ok when softdeps has been used. I suppose that's the reason why it was never included into OpenBSD. I'll ponder if I want to work on this. A safer alternative to this optimization might be for the installer (or newfs) to consider the fs size when deciding on a default inode density.
Re: NFS writes lock up system with -o tcp,-w32768
use udp instead of tcp. On Tue, Mar 29, 2011 at 12:58:09PM +0200, Walter Haidinger wrote: Hi! OpenBSD-current locks upon writes to a NFS share with the options -o tcp,-w=32768 That is, the following locks up: # mount -o tcp,-w=32768 server:/foo /mnt # cp /bsd /mnt No lockup with default mount_nfs options, i.e. udp, or when reading. However, writes immediately lock up the machine, but not completely as it still responds to icmp echo requests, though. Shell (console) or any other userspace is dead, AFAICT. OpenBSD-current is the NFS client, the NFS server runs Linux (openSUSE 11.3 with vanilla 2.6.38.1). Please note that stable OpenBSD-4.8 has no problems writing to this NFS server with -o tcp,-w=32768. Reproducible with OpenBSD-current, tested both in a Linux KVM virtual machine and on bare metal (it's dmesg appended below). If you need any other information, just let me know. Walter PS: Please add a CC: to my address too when replying. Thanks. OpenBSD 4.9-current (GENERIC) #1: Tue Mar 29 08:33:57 CEST 2011 root@current.private:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD Athlon(tm) XP 2500+ (AuthenticAMD 686-class, 512KB L2 cache) 1.84 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real mem = 2146988032 (2047MB) avail mem = 2101719040 (2004MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 10/01/04, BIOS32 rev. 0 @ 0xfb2c0, SMBIOS rev. 2.3 @ 0xf0100 (38 entries) bios0: vendor Award Software International, Inc. version F5 date 10/01/2004 bios0: Gigabyte Technology Co., Ltd. 7VT600-P-RZ apm0 at bios0: Power Management spec V1.2 (slowidle) apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0xd9f4 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd900/240 (13 entries) pcibios0: PCI Exclusive IRQs: 5 10 11 pcibios0: PCI Interrupt Router at 000:17:0 (VIA VT82C596A ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x8800 0xcc000/0x8000! 0xd4000/0x2000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 VIA VT8377 PCI rev 0x80 viaagp0 at pchb0: v3 agp0 at viaagp0: aperture at 0xd000, size 0x1000 ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 Matrox MGA G400/G450 AGP rev 0x85 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) skc0 at pci0 dev 13 function 0 Marvell Yukon (Belkin F5D5005) rev 0x12, Yukon (0x1): irq 5 sk0 at skc0 port A: address 00:30:bd:b2:6f:96 eephy0 at sk0 phy 0: 88E1011 Gigabit PHY, rev. 3 pciide0 at pci0 dev 15 function 0 VIA VT6420 SATA rev 0x80: DMA pciide0: using irq 10 for native-PCI interrupt pciide1 at pci0 dev 15 function 1 VIA VT82C571 IDE rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide1 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: LITE-ON, COMBO SOHC-5232K, NK0A ATAPI 5/cdrom removable cd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 3 wd0 at pciide1 channel 1 drive 0: SAMSUNG SP2514N wd0: 16-sector PIO, LBA48, 238474MB, 488395055 sectors wd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 6 uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x81: irq 11 uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81: irq 11 uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81: irq 5 uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81: irq 5 ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86: irq 10 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 VIA EHCI root hub rev 2.00/1.00 addr 1 viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 iic0 at viapm0 spdmem0 at iic0 addr 0x50: 1GB DDR SDRAM non-parity PC3200CL3.0 spdmem1 at iic0 addr 0x51: 1GB DDR SDRAM non-parity PC3200CL3.0 auvia0 at pci0 dev 17 function 5 VIA VT8233 AC97 rev 0x60: irq 10 ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0) audio0 at auvia0 vr0 at pci0 dev 18 function 0 VIA RhineII-2 rev 0x78: irq 11, address 00:0f:ea:bf:9b:0e ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 10: OUI 0x004063, model 0x0032 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 VIA UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 VIA UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 VIA UHCI root hub rev 1.00/1.00 addr 1 isa0 at mainbus0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using
Re: NFS writes lock up system with -o tcp,-w32768
On Tue, Mar 29, 2011 at 03:30:57PM +0200, Mark Kettenis wrote: Date: Tue, 29 Mar 2011 08:16:34 -0500 From: Marco Peereboom sl...@peereboom.us use udp instead of tcp. While that is indeed the way $DEITY intended NFS to be run, tcp used to work in 4.8. Something got broken in the TCP stack, anf we should fix it. My bet would be on the window autoscaling that went in between 4.8 and 4.9. I do not recall being able to make tcp nfs ever work with linux. Under any load it would hang.
Re: NFS writes lock up system with -o tcp,-w32768
I am eagerly awaiting the diff from you. On Tue, Mar 29, 2011 at 05:36:36PM +0200, Walter Haidinger wrote: Am 29.03.2011 17:24, schrieb Michael: Hi, I already filed a PR for that on 17.12.20110 - kernel/6525. There also were some mails on misc@ about it. But noone really seemed to care. Yes, it's status is still open (=no work has been done on it yet) and we're on month before release. This will break existing installations after upgrade. Walter
Re: PATCH: Fix boolean value for ACPI logical comparisons
This is the right thing to do. ok On Fri, Mar 18, 2011 at 04:48:13PM -0600, Jordan Hargrave wrote: This patch changes the values of boolean comparisons from 0:1 to 0:-1 (from ACPI Spec) in order to fix an AML issue on some Asus machines. Please test on other machines as well to verify that hardware sensors/acpi/boot work properly. Index: dsdt.c === RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v retrieving revision 1.181 diff -u -p -b -r1.181 dsdt.c --- dsdt.c2 Jan 2011 04:56:57 - 1.181 +++ dsdt.c18 Mar 2011 21:55:16 - @@ -1167,31 +1167,31 @@ aml_evalexpr(int64_t lhs, int64_t rhs, i /* Logical/Comparison */ case AMLOP_LAND: - res = (lhs rhs); + res = -(lhs rhs); break; case AMLOP_LOR: - res = (lhs || rhs); + res = -(lhs || rhs); break; case AMLOP_LNOT: - res = (!lhs); + res = -(!lhs); break; case AMLOP_LNOTEQUAL: - res = (lhs != rhs); + res = -(lhs != rhs); break; case AMLOP_LLESSEQUAL: - res = (lhs = rhs); + res = -(lhs = rhs); break; case AMLOP_LGREATEREQUAL: - res = (lhs = rhs); + res = -(lhs = rhs); break; case AMLOP_LEQUAL: - res = (lhs == rhs); + res = -(lhs == rhs); break; case AMLOP_LGREATER: - res = (lhs rhs); + res = -(lhs rhs); break; case AMLOP_LLESS: - res = (lhs rhs); + res = -(lhs rhs); break; }
Re: OpenBSD crash on an IBM x3550 M3
That is a huge penalty because it is read over the pci bus. The trick
with 0x should work just fine per the doco and other os' drivers
(on top of my head). The question I have is does Linux only have one
device per interrupt?
I am going to reference the doco one more time on this.
On Thu, Mar 03, 2011 at 10:35:59PM -0500, Kenneth R Westerback wrote:
On Thu, Mar 03, 2011 at 07:11:52PM +0100, Mike Belopuhov wrote:
On Fri, Feb 04, 2011 at 14:53 +, emeric boit wrote:
Hello,
After doing a clean install of OpenBSD 4.8 (AMD64) on an IBM x3550 M3,
I find
the
system randomly panics after a period of use.
uvm_fault(0x80cc8360, 0x8000149b7000, 0, 1) - e
kernel: page
fault trap, code=0
Stopped at mpi_reply+0x102:movq
0(%r13),%rax
ddb{0}
ddb{0} trace
mpi_reply() at mpi_reply+0x102
mpi_intr()
at mpi_intr+0x20
Xintr_ioapic_level18() at Xintr_ioapic_level18+0xec
---
interrupt ---
Bad frame pointer: 0x8000194e1920
end trace frame:
0x8000194e1920, count: -3
Xspllower+0xe:
ddb{0}
We've tried different things, but after this hint i realised
that what might be happening is that bnx and mpi interrupts
are chained (it's bnx0 actually, my initial guess about bnx1
was wrong) and mpi_intr is called first. Currently neither
mpi(4) nor mpii(4) don't check the interrupt status register
but look directly into the reply post queue. Although,
there's not supposed to be any race between host cpu reading
from the memory and ioc writing to it, in practice it turns
out that in some particular hardware configurations this rule
is violated and we read a garbled reply from the controller.
If my memory serves, I've considered this for the mpii_intr
but never got into the situation where it was needed and
thus omitted it. I guess I have to bring it back too.
Emeric tortured the machine with this diff and reported that
it solves the issue for him. OK to commit?
On Wed, Mar 02, 2011 at 17:20 +, emeric boit wrote:
hi,
This change doesn't solve the issue.
I have remarked that the server crash when I use the network.
I copy a small file several times without problem.
On the IBM I do :
scp USER@IP:/tmp/mpi.c .
And when I copy a larger file the server crash :
scp USER@IP:/bsd .
And when I copy th same file (bsd) from an usb key I don't have problem.
Emeric.
that sounds like an interrupt sharing bug of some sort.
is it bnx1 that you're using to reproduce a crash?
try the following diff please (on a clean checkout):
Index: mpi.c
===
RCS file: /home/cvs/src/sys/dev/ic/mpi.c,v
retrieving revision 1.166
diff -u -p -r1.166 mpi.c
--- mpi.c 1 Mar 2011 23:48:33 - 1.166
+++ mpi.c 2 Mar 2011 17:40:13 -
@@ -887,6 +887,9 @@ mpi_intr(void *arg)
u_int32_t reg;
int rv = 0;
+ if ((mpi_read_intr(sc) MPI_INTR_STATUS_REPLY) == 0)
+ return (rv);
+
while ((reg = mpi_pop_reply(sc)) != 0x) {
mpi_reply(sc, reg);
rv = 1;
ok krw@.
Ken
Re: Dell R310 - H200 Raid performance problem
I really think this heuristic belongs in the kernel. I think there is a desire to make the policy a knob (the old, I prefer slow and safe over fast and dangerous; well use a ups! they don't! debate). So instead of bioctl I think we need a sysctl, for example hw.diskcache, that by default is enabled which is the drive manufacturers suggested setting. Then if so desired one can turn it off. Or do people think this would be too large a hammer and would like to have a more granular control? On Wed, Mar 02, 2011 at 05:54:23AM -0500, Okan Demirmen wrote: On Sun 2011.02.20 at 10:30 -0500, Okan Demirmen wrote: On Sun 2011.02.20 at 13:28 +0100, Mark Kettenis wrote: Date: Sun, 20 Feb 2011 07:03:25 -0500 From: Kenneth R Westerback kwesterb...@rogers.com On Sun, Feb 20, 2011 at 12:39:06PM +0100, Mark Kettenis wrote: Date: Sun, 20 Feb 2011 19:54:21 +1000 From: David Gwynne l...@animata.net how to manipulate write cache policy? the lsi firmwares dont implement handling of the mod page changes unfortunately. you could call the ioctl this implements yourself though from userland. David, while I think that implementing the cache manipulation ioctls for mpii(4) is a good idea, there is a problem here. We don't have a tool in base that actually issues those ioctls. And unless I'm misreading the diff, this still leaves the cache disabled on the stupid Dell. DIOCSCACHE is called in sdattach() to enable write cache for all disks that DIOCGCACHE reports as having write cache disabled. Or are you concerned that we have no way to manipulate it from userland if/when the default needs to be modified? Ah, that's the bit I was missing. A userland tool to display and manipulate the cache settings would still be good though. Functionality should probably be added to bioctl(8). A bit unfortunate that both the -c and -C options are already taken. Ah, I had a diff for bioctl (enable/disable WCE/RCD) based on dlg's sample, but I think marco wanted more of a policy of when to do WCE/RCD rather than a switch - I'll send it along when I get home later this week. I'm not certain this is wanted, but I said I would forward along this very simplisitc patch, so here it is. If something like this is wanted, it can be re-worked to take multiple args to -e and such, but again, only if this is deemed necessary in a userland tool outside of scsi(8). Index: bioctl.8 === RCS file: /cvs/src/sbin/bioctl/bioctl.8,v retrieving revision 1.84 diff -u -p -r1.84 bioctl.8 --- bioctl.8 22 Dec 2010 16:25:32 - 1.84 +++ bioctl.8 2 Mar 2011 10:44:23 - @@ -35,6 +35,7 @@ .Op Fl hiqv .Op Fl a Ar alarm-function .Op Fl b Ar channel:target[.lun] +.Op Fl e Ar flag .Op Fl H Ar channel:target[.lun] .Op Fl R Ar device \*(Ba channel:target[.lun] .Op Fl u Ar channel:target[.lun] @@ -128,6 +129,24 @@ digits to four or less. .It Fl i Enumerate the selected RAID devices. This is the default if no other option is given. +.It Fl e Ar flag +Pass +.Ar flag +to +.Nm . +May be one of: +.Bl -tag -width disable -compact +.It Ar q +Query the read/write cache status. +.It Ar R +Enable the read cache. +.It Ar r +Disable the read cache. +.It Ar W +Enable the write cache. +.It Ar w +Disable the write cache. +.El .It Fl q Show vendor, product, revision, and serial number for the given disk. .It Fl R Ar device \*(Ba channel:target[.lun] Index: bioctl.c === RCS file: /cvs/src/sbin/bioctl/bioctl.c,v retrieving revision 1.98 diff -u -p -r1.98 bioctl.c --- bioctl.c 1 Dec 2010 19:40:18 - 1.98 +++ bioctl.c 2 Mar 2011 10:44:23 - @@ -77,6 +77,7 @@ voidbio_changepass(char *); u_int32_tbio_createflags(char *); char *bio_vis(char *); void bio_diskinq(char *); +void bio_cache(char *, char *); int devh = -1; int human; @@ -97,17 +98,17 @@ main(int argc, char *argv[]) char*devicename = NULL; char*realname = NULL, *al_arg = NULL; char*bl_arg = NULL, *dev_list = NULL; - char*key_disk = NULL; + char*key_disk = NULL, *ca_arg = NULL; const char *errstr; int ch, rv, blink = 0, changepass = 0, diskinq = 0; - int ss_func = 0; + int ss_func = 0, diskcache = 0; u_int16_t cr_level = 0; int biodev = 0; if (argc 2) usage(); - while ((ch = getopt(argc, argv, a:b:C:c:dH:hik:l:Pp:qr:R:svu:)) != + while ((ch =
Re: [patch] -H flag for grep.
You made your point; no need repeating it. On Tue, Feb 22, 2011 at 08:26:31PM +0100, Pascal Stumpf wrote: On Tue, Feb 22, 2011 at 04:13:34PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 2:21 PM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Tue, Feb 22, 2011 at 12:52:24PM -0300, Iruatc Souza wrote: On Tue, Feb 22, 2011 at 6:08 AM, patrick keshishian sids...@boxsoft.com wrote: my that's awkward. if you can't combine unix tools, you should be looking at perl. iru I bet everyone here knows one can achieve the same results with awk, perl, C, python, ruby, tcl, Haskell, java and goat sacrifices at fullmoon. That doesn't mean any of those is the easiest or most convenient tool for the job. Using a fully-blown programming language just to output a filename and a line matching a regex is plain overkill. are you sure adding a flag is the right tool? maybe you should take a look at the reference i mentioned earlier. iru grep(1) is the right tool. Adding a flag just makes it more usable for specific tasks.
Re: [patch] -H flag for grep.
On Tue, Feb 22, 2011 at 08:41:07PM -0500, Nick Holland wrote:
On 02/22/11 16:47, Stuart Henderson wrote:
On 2011/02/22 01:08, patrick keshishian wrote:
find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
my that's awkward.
^^^
*groan*
d'oh. I missed that. And I thought I was good at the bad pun.
Nick.
http://www.thebestpageintheuniverse.net/c.cgi?u=puns
Re: Dell R310 - H200 Raid performance problem
bah! On Sun, Feb 20, 2011 at 07:20:19PM +, Stuart Henderson wrote: On 2011/02/20 11:59, Ted Unangst wrote: On Sun, Feb 20, 2011 at 7:28 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Ah, that's the bit I was missing. A userland tool to display and manipulate the cache settings would still be good though. Functionality should probably be added to bioctl(8). A bit unfortunate that both the -c and -C options are already taken. -w or -W wouldn't be too bad an alternative (_w_rite cache). We also have a scsi(8) tool that seems more analogous to atactl (which can manipulate cache behavior). scsi(8) can manipulate write cache on some drives too. But in this case we're talking about a setting for the volume rather than for drives, so bioctl(8) wouldn't be a bad choice. (I don't know about mpii, but for mpi the vendor management tool in some OS allows you to set this, and bioctl is the closest analogue to this).
Re: Dell R310 - H200 Raid performance problem
On Thu, Feb 17, 2011 at 04:22:54PM +0100, Mike Belopuhov wrote:
On Thu, Feb 10, 2011 at 14:25 +0100, Lukasz Czarniecki wrote:
Hi
I've bought a Dell R310 with H200 raid controller reported in dmesg as:
Symbios Logic SAS2008. It uses mpii driver and has two hard drives
configured in RAID 1.
Now it seems to work fine but i still have a problem with its
performance. Raid is fully initialized.
How can I help to resolve this problem?
I'm doing simple benchmark:
wget ftp.spline.de/pub/OpenBSD/4.8/sys.tar.gz
time tar xzf ./sys.tar.gz
On the same hardware Linux unpacks it in less then two seconds.
Numbers for OpenBSD:
4.8 amd64 sp: 3m40.95s real 0m0.65s user 0m0.71s system
4.8 amd64 mp-stable: 3m43.36s real 0m0.48s user 0m0.98s system
4.9 amd64 sp: 3m47.72s real 0m0.51s user 0m0.69s system
4.9 i386 rd : 3m45.11s real 0m1.03s user 0m1.19s system
Lukasz and me have figured out that disk write cache gets turned
off by the Dell firmware when you create a volume (it doesn't get
disabled if you use single drives):
http://support.dell.com/support/edocs/storage/storlink/h200/en/ug/html/features.htm#wp1062398
H200 doesn't have and there's no possibility to install an onboard
memory and the battery, so the device becomes pretty much useless
unless the operating system takes care of it. Apparently Linux
does. Should OpenBSD do the same? In my opinion yes.
Linux does this and we should too. All SATA manufacturers recommend
(read recommend very very strongly and call you names when you don't
listen) enabling write cache.
Lukasz has tested the patch below and it works fine for him. I don't
have the hardware myself, so I'm not going to push it for the release,
but if someone thinks it's worth it, please speak up.
I am ok with this making release and think it should. I did not realize
WB was being disabled.
Index: mpii.c
===
RCS file: /home/cvs/src/sys/dev/pci/mpii.c,v
retrieving revision 1.37
diff -u -p -r1.37 mpii.c
--- mpii.c29 Dec 2010 03:55:09 - 1.37
+++ mpii.c17 Feb 2011 15:15:25 -
@@ -981,6 +981,52 @@ struct mpii_msg_sas_oper_reply {
u_int32_t ioc_loginfo;
} __packed;
+struct mpii_msg_raid_action_request {
+ u_int8_taction;
+#define MPII_RAID_ACTION_CHANGE_VOL_WRITE_CACHE (0x17)
+ u_int8_treserved1;
+ u_int8_tchain_offset;
+ u_int8_tfunction;
+
+ u_int16_t vol_dev_handle;
+ u_int8_tphys_disk_num;
+ u_int8_tmsg_flags;
+
+ u_int8_tvp_id;
+ u_int8_tvf_if;
+ u_int16_t reserved2;
+
+ u_int32_t reserved3;
+
+ u_int32_t action_data;
+#define MPII_RAID_VOL_WRITE_CACHE_DISABLE(0x01)
+#define MPII_RAID_VOL_WRITE_CACHE_ENABLE (0x02)
+
+ struct mpii_sge action_sge;
+} __packed;
+
+struct mpii_msg_raid_action_reply {
+ u_int8_taction;
+ u_int8_treserved1;
+ u_int8_tchain_offset;
+ u_int8_tfunction;
+
+ u_int16_t vol_dev_handle;
+ u_int8_tphys_disk_num;
+ u_int8_tmsg_flags;
+
+ u_int8_tvp_id;
+ u_int8_tvf_if;
+ u_int16_t reserved2;
+
+ u_int16_t reserved3;
+ u_int16_t ioc_status;
+
+ u_int32_t action_data[5];
+
+ struct mpii_sge action_sge;
+} __packed;
+
struct mpii_cfg_hdr {
u_int8_tpage_version;
u_int8_tpage_length;
@@ -1972,6 +2018,8 @@ int mpii_req_cfg_page(struct mpii_softc
int mpii_get_ioc_pg8(struct mpii_softc *);
+void mpii_cache_enable(struct mpii_softc *);
+
#if NBIO 0
int mpii_ioctl(struct device *, u_long, caddr_t);
int mpii_ioctl_inq(struct mpii_softc *, struct bioc_inq *);
@@ -2175,6 +2223,9 @@ mpii_attach(struct device *parent, struc
goto free_dev;
}
+ /* enable write cache */
+ mpii_cache_enable(sc);
+
/* we should be good to go now, attach scsibus */
sc-sc_link.adapter = mpii_switch;
sc-sc_link.adapter_softc = sc;
@@ -3206,6 +3257,45 @@ mpii_cfg_coalescing(struct mpii_softc *s
}
return (0);
+}
+
+void
+mpii_cache_enable(struct mpii_softc *sc)
+{
+ struct mpii_msg_raid_action_request *req;
+ struct mpii_device *dev;
+ struct mpii_ccb *ccb;
+ int i;
+
+ ccb = scsi_io_get(sc-sc_iopool, 0);
+ if (ccb == NULL)
+ return;
+
+ for (i = 0; i sc-sc_max_devices; i++) {
+ if (sc-sc_devs[i] == NULL ||
+ !ISSET(sc-sc_devs[i]-flags, MPII_DF_VOLUME))
+ continue;
+
+ dev = sc-sc_devs[i];
+
+
Re: AML PARSE ERROR
On Tue, Feb 01, 2011 at 02:57:18PM +0530, k3.karthic wrote: So, you're running GENERIC.MP, but locally compiled. What about that INTERLDRM_GEM option you added, you wonder? That option has had *NO EFFECT* for over 8 months! If you don't understand why you're building and running a custom kernel, then you shouldn't be. Just use GENERIC.MP from the snapshots and save your own time and that of the developers. I was not aware that inteldrm_gem has no effect for 8 months, in my case x11 will freeze up if i try to run glxgears or even use mplayer without inteldrm_gem option. This was fixed but I don't remember when. As for the error itself: acpiec0 at acpi0### AML PARSE ERROR (0x105b8): Undefined name: \\_PR_.CPU0._PPC error evaluating: \\_SB_.PCI0.LPCB.EC0_._REG acpiec _REG failed, broken BIOS So, OpenBSD thinks the BIOS is broken. Has HP released a BIOS update for that machine? Philip Guenther No HP has not released any BIOS update, i used to run Fedora 13 on my laptop and it gave the same complaint. However, a kernel upgrade cleared the error. This error has not caused any problems while working on the laptop i just wanted to know if this is a hardware fault or not. Bad BIOS. See other email I sent you. This is my first time reporting a problem to OpenBSD mailing lists, next time onwards i will send all reports while running a generic kernel. I am really sorry if i offended anyone. Thanks for replying, Karthic
Re: intel driver fix (PR6517)
On Sat, Jan 29, 2011 at 12:45:25PM +0100, Matthieu Herrb wrote:
Hi,
More last minute X patches...
mpf@ reported in PR6517 a problem with his 965GM chipset.
He did some debugging and found that a patch to the kernel i915 drm
driver from one of the X.Org maintaines (Chris Wilson) fixes his
issues. I don't understand the patch (the X.Org bug report is about
i855 cache coherency problems, not about 965GM) but since it helps
both mpf and mcbride@ machines, I would like to see this committed.
But wider testing is needed. Please apply the patch below to any
machine you have running X with an intel chipset. Report success or
failure to me please, with a dmesg and /var/log/Xorg.0.log.
Thanks in advance.
Original bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=27187
and patch :
https://bugs.freedesktop.org//attachment.cgi?id=41531
Index: i915_drv.c
===
RCS file: /cvs/OpenBSD/src/sys/dev/pci/drm/i915_drv.c,v
retrieving revision 1.101
diff -u -r1.101 i915_drv.c
--- i915_drv.c21 Sep 2010 23:05:41 - 1.101
+++ i915_drv.c29 Jan 2011 08:32:29 -
@@ -995,16 +995,17 @@
bus_space_write_4(dev_priv-ifp.i9xx.bst,
dev_priv-ifp.i9xx.bsh, 0, 1);
} else {
- /*
- * I8XX don't have a flush page mechanism, but do have the
- * cache. Do it the bruteforce way. we write 1024 byes into
- * the cache, then clflush them out so they'll kick the stuff
- * we care about out of the chipset cache.
- */
- if (dev_priv-ifp.i8xx.kva != NULL) {
- memset(dev_priv-ifp.i8xx.kva, 0, 1024);
- agp_flush_cache_range((vaddr_t)dev_priv-ifp.i8xx.kva,
- 1024);
+ int i;
+
+ wbinvd();
That is a very large hammer. How often is this code called?
+
+#define I830_HIC 0x70
+
+ I915_WRITE(I830_HIC, (I915_READ(I830_HIC) | (131)));
+ for (i = 1000; i; i--) {
^^
really?
+ if (!(I915_READ(I830_HIC) (131)))
+ break;
+ delay(100);
}
}
}
--
Matthieu Herrb
Re: softraid: factor out block I/O code
I know you guys aren't testing this patch because it doesn't apply.
I attached the correct one so get to work!
Joel's patch:
You'll probably need this as well if you're testing on USB devices.
Factor out the block level I/O code. Also teach it how to handle writes that
are larger than MAXPHYS. This obviously needs some thorough testing since
it has the potential to eat metadata.
Index: softraidvar.h
===
RCS file: /cvs/src/sys/dev/softraidvar.h,v
retrieving revision 1.96
diff -u -p -r1.96 softraidvar.h
--- softraidvar.h 6 Nov 2010 23:01:56 - 1.96
+++ softraidvar.h 6 Jan 2011 12:41:26 -
@@ -624,6 +624,8 @@ int sr_check_io_collision(struct sr_wo
void sr_scsi_done(struct sr_discipline *,
struct scsi_xfer *);
intsr_chunk_in_use(struct sr_softc *, dev_t);
+intsr_rw(struct sr_softc *, dev_t, char *, size_t,
+ daddr64_t, long);
/* discipline functions */
intsr_raid_inquiry(struct sr_workunit *);
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.217
diff -u -p -r1.217 softraid.c
--- softraid.c 20 Dec 2010 17:47:48 - 1.217
+++ softraid.c 6 Jan 2011 12:41:26 -
@@ -387,57 +387,93 @@ sr_meta_getdevname(struct sr_softc *sc,
}
int
-sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t sz,
-daddr64_t ofs, long flags)
+sr_rw(struct sr_softc *sc, dev_t dev, char *buf, size_t size, daddr64_t offset,
+long flags)
{
- struct sr_softc *sc = sd-sd_sc;
+ struct vnode*vp;
struct buf b;
+ size_t bufsize;
int rv = 1;
- DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
- DEVNAME(sc), dev, md, sz, ofs, flags);
-
- bzero(b, sizeof(b));
+ DNPRINTF(SR_D_MISC, %s: sr_rw(0x%x, %p, %d, %llu 0x%x)\n,
+ DEVNAME(sc), dev, buf, size, offset, flags);
- if (md == NULL) {
- printf(%s: read invalid metadata pointer\n, DEVNAME(sc));
+ if (bdevvp(dev, vp)) {
+ printf(%s: sr_rw: failed to allocate vnode\n, DEVNAME(sc));
goto done;
}
- b.b_flags = flags | B_PHYS;
- b.b_blkno = ofs;
- b.b_bcount = sz;
- b.b_bufsize = sz;
- b.b_resid = sz;
- b.b_data = md;
- b.b_error = 0;
- b.b_proc = curproc;
- b.b_dev = dev;
- b.b_iodone = NULL;
- if (bdevvp(dev, b.b_vp)) {
- printf(%s: sr_meta_rw: can't allocate vnode\n, DEVNAME(sc));
- goto done;
- }
- if ((b.b_flags B_READ) == 0)
- b.b_vp-v_numoutput++;
-
- LIST_INIT(b.b_dep);
- VOP_STRATEGY(b);
- biowait(b);
-
- if (b.b_flags B_ERROR) {
- printf(%s: 0x%x i/o error on block %llu while reading
- metadata %d\n, DEVNAME(sc), dev, b.b_blkno, b.b_error);
- goto done;
+
+ while (size 0) {
+
+ DNPRINTF(SR_D_MISC, %s: buf %p, size %d, offset %llu)\n,
+ DEVNAME(sc), buf, size, offset);
+
+ bufsize = (size MAXPHYS) ? MAXPHYS : size;
+
+ bzero(b, sizeof(b));
+
+ b.b_flags = flags | B_PHYS;
+ b.b_proc = curproc;
+ b.b_dev = dev;
+ b.b_iodone = NULL;
+ b.b_error = 0;
+ b.b_blkno = offset;
+ b.b_data = buf;
+ b.b_bcount = bufsize;
+ b.b_bufsize = bufsize;
+ b.b_resid = bufsize;
+ b.b_vp = vp;
+
+ if ((b.b_flags B_READ) == 0)
+ vp-v_numoutput++;
+
+ LIST_INIT(b.b_dep);
+ VOP_STRATEGY(b);
+ biowait(b);
+
+ if (b.b_flags B_ERROR) {
+ printf(%s: I/O error %d on dev 0x%x at block %llu\n,
+ DEVNAME(sc), b.b_error, dev, b.b_blkno);
+ goto done;
+ }
+
+ size -= bufsize;
+ buf += bufsize;
+ offset += howmany(bufsize, DEV_BSIZE);
+
}
+
rv = 0;
+
done:
- if (b.b_vp)
- vput(b.b_vp);
+ if (vp)
+ vput(vp);
return (rv);
}
int
+sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t size,
+daddr64_t offset, long flags)
+{
+ int rv = 1;
+
+ DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
+ DEVNAME(sd-sd_sc), dev, md, size, offset, flags);
+
+ if (md == NULL) {
+ printf(%s: sr_meta_rw: invalid metadata pointer\n,
+ DEVNAME(sd-sd_sc));
+
Re: softraid: factor out block I/O code
This one needs lots of testing folks. Please oblige.
On Sat, Jan 15, 2011 at 01:22:24AM +1100, Joel Sing wrote:
The following diff factors out the block I/O code that is used within
softraid(4) and also allows it to handle I/Os that exceeds MAXPHYS in
size. This is necessary for some upcoming work.
This diff needs extensive testing since the main purpose is to read and
write the softraid metadata. Bugs in this area will eat softraid metadata
and therefore destroy softraid volumes. If you are testing please ensure
that you have backed up your data or that the volume does not have
critical information. Please report test successes/failures directly to me.
Index: softraidvar.h
===
RCS file: /cvs/src/sys/dev/softraidvar.h,v
retrieving revision 1.96
diff -u -p -r1.96 softraidvar.h
--- softraidvar.h 6 Nov 2010 23:01:56 - 1.96
+++ softraidvar.h 6 Jan 2011 12:41:26 -
@@ -624,6 +624,8 @@ int sr_check_io_collision(struct
sr_wo
void sr_scsi_done(struct sr_discipline *,
struct scsi_xfer *);
int sr_chunk_in_use(struct sr_softc *, dev_t);
+int sr_rw(struct sr_softc *, dev_t, char *, size_t,
+ daddr64_t, long);
/* discipline functions */
int sr_raid_inquiry(struct sr_workunit *);
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.217
diff -u -p -r1.217 softraid.c
--- softraid.c20 Dec 2010 17:47:48 - 1.217
+++ softraid.c6 Jan 2011 12:41:26 -
@@ -387,57 +387,93 @@ sr_meta_getdevname(struct sr_softc *sc,
}
int
-sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t sz,
-daddr64_t ofs, long flags)
+sr_rw(struct sr_softc *sc, dev_t dev, char *buf, size_t size, daddr64_t
offset,
+long flags)
{
- struct sr_softc *sc = sd-sd_sc;
+ struct vnode*vp;
struct buf b;
+ size_t bufsize;
int rv = 1;
- DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
- DEVNAME(sc), dev, md, sz, ofs, flags);
-
- bzero(b, sizeof(b));
+ DNPRINTF(SR_D_MISC, %s: sr_rw(0x%x, %p, %d, %llu 0x%x)\n,
+ DEVNAME(sc), dev, buf, size, offset, flags);
- if (md == NULL) {
- printf(%s: read invalid metadata pointer\n, DEVNAME(sc));
+ if (bdevvp(dev, vp)) {
+ printf(%s: sr_rw: failed to allocate vnode\n, DEVNAME(sc));
goto done;
}
- b.b_flags = flags | B_PHYS;
- b.b_blkno = ofs;
- b.b_bcount = sz;
- b.b_bufsize = sz;
- b.b_resid = sz;
- b.b_data = md;
- b.b_error = 0;
- b.b_proc = curproc;
- b.b_dev = dev;
- b.b_iodone = NULL;
- if (bdevvp(dev, b.b_vp)) {
- printf(%s: sr_meta_rw: can't allocate vnode\n, DEVNAME(sc));
- goto done;
- }
- if ((b.b_flags B_READ) == 0)
- b.b_vp-v_numoutput++;
-
- LIST_INIT(b.b_dep);
- VOP_STRATEGY(b);
- biowait(b);
-
- if (b.b_flags B_ERROR) {
- printf(%s: 0x%x i/o error on block %llu while reading
- metadata %d\n, DEVNAME(sc), dev, b.b_blkno, b.b_error);
- goto done;
+
+ while (size 0) {
+
+ DNPRINTF(SR_D_MISC, %s: buf %p, size %d, offset %llu)\n,
+ DEVNAME(sc), buf, size, offset);
+
+ bufsize = (size MAXPHYS) ? MAXPHYS : size;
+
+ bzero(b, sizeof(b));
+
+ b.b_flags = flags | B_PHYS;
+ b.b_proc = curproc;
+ b.b_dev = dev;
+ b.b_iodone = NULL;
+ b.b_error = 0;
+ b.b_blkno = offset;
+ b.b_data = buf;
+ b.b_bcount = bufsize;
+ b.b_bufsize = bufsize;
+ b.b_resid = bufsize;
+ b.b_vp = vp;
+
+ if ((b.b_flags B_READ) == 0)
+ vp-v_numoutput++;
+
+ LIST_INIT(b.b_dep);
+ VOP_STRATEGY(b);
+ biowait(b);
+
+ if (b.b_flags B_ERROR) {
+ printf(%s: I/O error %d on dev 0x%x at block %llu\n,
+ DEVNAME(sc), b.b_error, dev, b.b_blkno);
+ goto done;
+ }
+
+ size -= bufsize;
+ buf += bufsize;
+ offset += howmany(bufsize, DEV_BSIZE);
+
}
+
rv = 0;
+
done:
- if (b.b_vp)
- vput(b.b_vp);
+ if (vp)
+ vput(vp);
return (rv);
}
int
+sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t size,
+daddr64_t offset, long flags)
+{
+ int rv = 1;
+
Re: bioctl should retry passphrase
sure
On Thu, Jan 13, 2011 at 06:51:18PM -0500, Ted Unangst wrote:
If I type the wrong password into bioctl at boot, disks don't exist,
filesystems don't get mounted, and generally lots of things go wrong. All
I need is a second chance to remind me to type the right password.
Index: bioctl.c
===
RCS file: /home/tedu/cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.98
diff -u -r1.98 bioctl.c
--- bioctl.c 1 Dec 2010 19:40:18 - 1.98
+++ bioctl.c 13 Jan 2011 23:47:24 -
@@ -699,6 +699,7 @@
int rv, no_dev, fd;
dev_t *dt;
u_int16_t min_disks = 0;
+ int retry = 0;
if (!dev_list)
errx(1, no devices specified);
@@ -738,6 +739,7 @@
if (level == 'C' no_dev != min_disks)
errx(1, not exactly one partition);
+again:
memset(create, 0, sizeof(create));
create.bc_cookie = bl.bl_cookie;
create.bc_level = level;
@@ -802,8 +804,14 @@
memset(kdfinfo, 0, sizeof(kdfinfo));
memset(create, 0, sizeof(create));
if (rv == -1) {
- if (errno == EPERM)
+ if (errno == EPERM) {
+ if (!retry) {
+ warnx(Incorrect passphrase. Try again.);
+ retry = 1;
+ goto again;
+ }
errx(1, Incorrect passphrase);
+ }
err(1, BIOCCREATERAID);
}
Re: add back tcp sysctls
My cable modem works just like bad satellite so I'd love to see this go
in as well.
On Sat, Dec 25, 2010 at 12:03:27PM +0100, Mark Kettenis wrote:
Date: Fri, 24 Dec 2010 22:50:22 -0500 (EST)
From: Ted Unangst ted.unan...@gmail.com
As I mentioned previously, the auto recv space scaling algorithm isn't
optimized for all links. At list in my case, with the proverbial
satellite link (high bandwidth, high latency), the window never appears to
grow.
I can believe that a satellite link has high latency, but high bandwidth?
Manually setting the default recv space allows me to download at high
speed again. This diff brings back the two relevant sysctls.
Anyway, it'd be nice if the algorithm could be improved such that it
works for a broader range of links. For example, you probably want to
scale more aggressively if the RTT is large.
That said, my experience with Linux, which supposedly has had window
auto-tuning for quite some time, tells me that there will always be
corner cases where some manual tuning is necessary. So this diff
makes sense to me. Make sure you get an ok from claudio though.
Index: tcp_var.h
===
RCS file: /home/tedu/cvs/src/sys/netinet/tcp_var.h,v
retrieving revision 1.97
diff -u -r1.97 tcp_var.h
--- tcp_var.h 21 Oct 2010 11:38:27 - 1.97
+++ tcp_var.h 24 Dec 2010 23:08:33 -
@@ -481,8 +481,8 @@
{ keepintvl, CTLTYPE_INT }, \
{ slowhz, CTLTYPE_INT }, \
{ baddynamic, CTLTYPE_STRUCT }, \
- { NULL, 0 }, \
- { NULL, 0 }, \
+ { recvspace, CTLTYPE_INT }, \
+ { sendspace, CTLTYPE_INT }, \
{ ident, CTLTYPE_STRUCT }, \
{ sack, CTLTYPE_INT }, \
{ mssdflt,CTLTYPE_INT }, \
@@ -506,8 +506,8 @@
tcp_keepintvl, \
NULL, \
NULL, \
- NULL, \
- NULL, \
+ tcp_recvspace, \
+ tcp_sendspace, \
NULL, \
NULL, \
tcp_mssdflt, \
Re: timeout io on mpii(4)
This is great but the real question is why does the IO get jammed?
On Fri, Dec 24, 2010 at 04:09:23PM +1000, David Gwynne wrote:
i can reliably produce a situation where an io on a disk attached
to mpii(4) never completes. this implements timeouts on scsi io so
we can recover from this situation.
ok?
Index: mpii.c
===
RCS file: /cvs/src/sys/dev/pci/mpii.c,v
retrieving revision 1.35
diff -u -p -r1.35 mpii.c
--- mpii.c23 Aug 2010 00:53:36 - 1.35
+++ mpii.c24 Dec 2010 06:04:38 -
@@ -1757,7 +1757,8 @@ struct mpii_ccb {
volatile enum {
MPII_CCB_FREE,
MPII_CCB_READY,
- MPII_CCB_QUEUED
+ MPII_CCB_QUEUED,
+ MPII_CCB_TIMEOUT
} ccb_state;
void(*ccb_done)(struct mpii_ccb *);
@@ -1822,6 +1823,15 @@ struct mpii_softc {
struct mpii_ccb_listsc_ccb_free;
struct mutexsc_ccb_free_mtx;
+ struct mutexsc_ccb_mtx;
+ /*
+ * this protects the ccb state and list entry
+ * between mpii_scsi_cmd and scsidone.
+ */
+
+ struct mpii_ccb_listsc_ccb_tmos;
+ struct scsi_iohandler sc_ccb_tmo_handler;
+
struct scsi_iopool sc_iopool;
struct mpii_dmamem *sc_requests;
@@ -1894,6 +1904,10 @@ intmpii_alloc_queues(struct mpii_softc
void mpii_push_reply(struct mpii_softc *, struct mpii_rcb *);
void mpii_push_replies(struct mpii_softc *);
+void mpii_scsi_cmd_tmo(void *);
+void mpii_scsi_cmd_tmo_handler(void *, void *);
+void mpii_scsi_cmd_tmo_done(struct mpii_ccb *);
+
int mpii_alloc_dev(struct mpii_softc *);
int mpii_insert_dev(struct mpii_softc *, struct mpii_device *);
int mpii_remove_dev(struct mpii_softc *, struct mpii_device *);
@@ -4035,7 +4049,11 @@ mpii_alloc_ccbs(struct mpii_softc *sc)
int i;
SLIST_INIT(sc-sc_ccb_free);
+ SLIST_INIT(sc-sc_ccb_tmos);
mtx_init(sc-sc_ccb_free_mtx, IPL_BIO);
+ mtx_init(sc-sc_ccb_mtx, IPL_BIO);
+ scsi_ioh_set(sc-sc_ccb_tmo_handler, sc-sc_iopool,
+ mpii_scsi_cmd_tmo_handler, sc);
sc-sc_ccbs = malloc(sizeof(*ccb) * (sc-sc_request_depth-1),
M_DEVBUF, M_NOWAIT | M_ZERO);
@@ -4448,6 +4466,7 @@ mpii_scsi_cmd(struct scsi_xfer *xs)
DNPRINTF(MPII_D_CMD, %s: Offset0: 0x%02x\n, DEVNAME(sc),
io-sgl_offset0);
+ timeout_set(xs-stimeout, mpii_scsi_cmd_tmo, ccb);
if (xs-flags SCSI_POLL) {
if (mpii_poll(sc, ccb) != 0) {
xs-error = XS_DRIVER_STUFFUP;
@@ -4459,10 +4478,66 @@ mpii_scsi_cmd(struct scsi_xfer *xs)
DNPRINTF(MPII_D_CMD, %s:mpii_scsi_cmd(): opcode: %02x
datalen: %d\n, DEVNAME(sc), xs-cmd-opcode, xs-datalen);
+ timeout_add_msec(xs-stimeout, xs-timeout);
mpii_start(sc, ccb);
}
void
+mpii_scsi_cmd_tmo(void *xccb)
+{
+ struct mpii_ccb *ccb = xccb;
+ struct mpii_softc *sc = ccb-ccb_sc;
+
+ printf(%s: mpii_scsi_cmd_tmo\n, DEVNAME(sc));
+
+ mtx_enter(sc-sc_ccb_mtx);
+ if (ccb-ccb_state == MPII_CCB_QUEUED) {
+ ccb-ccb_state = MPII_CCB_TIMEOUT;
+ SLIST_INSERT_HEAD(sc-sc_ccb_tmos, ccb, ccb_link);
+ }
+ mtx_leave(sc-sc_ccb_mtx);
+
+ scsi_ioh_add(sc-sc_ccb_tmo_handler);
+}
+
+void
+mpii_scsi_cmd_tmo_handler(void *cookie, void *io)
+{
+ struct mpii_softc *sc = cookie;
+ struct mpii_ccb *tccb = io;
+ struct mpii_ccb *ccb;
+ struct mpii_msg_scsi_task_request *stq;
+
+ mtx_enter(sc-sc_ccb_mtx);
+ ccb = SLIST_FIRST(sc-sc_ccb_tmos);
+ if (ccb != NULL) {
+ SLIST_REMOVE_HEAD(sc-sc_ccb_tmos, ccb_link);
+ ccb-ccb_state = MPII_CCB_QUEUED;
+ }
+ /* should remove any other ccbs for the same dev handle */
+ mtx_leave(sc-sc_ccb_mtx);
+
+ if (ccb == NULL) {
+ scsi_io_put(sc-sc_iopool, tccb);
+ return;
+ }
+
+ stq = tccb-ccb_cmd;
+ stq-function = MPII_FUNCTION_SCSI_TASK_MGMT;
+ stq-task_type = MPII_SCSI_TASK_TARGET_RESET;
+ stq-dev_handle = htole16(ccb-ccb_dev_handle);
+
+ tccb-ccb_done = mpii_scsi_cmd_tmo_done;
+ mpii_start(sc, tccb);
+}
+
+void
+mpii_scsi_cmd_tmo_done(struct mpii_ccb *tccb)
+{
+ mpii_scsi_cmd_tmo_handler(tccb-ccb_sc, tccb);
+}
+
+void
mpii_scsi_cmd_done(struct mpii_ccb *ccb)
{
struct mpii_msg_scsi_io_error *sie;
@@ -4470,6 +4545,14 @@ mpii_scsi_cmd_done(struct mpii_ccb *ccb)
struct scsi_xfer*xs = ccb-ccb_cookie;
struct
Re: acpi and sysctl
On Sun, Dec 19, 2010 at 04:12:02PM +0100, Christopher Zimmermann wrote:
Hi,
I've finally found some time to work on the fan control support for my
thinkpad.
But I'm having problems calling to acpiec_write() from sysctl or
timeout_set(9) context. (Assertion failure in acpiec_gpehandler()).
According to dev/acpi/acpiec.c:229 this function is meant to be called
only from acpi thread context.
Now how am I supposed to talk to the acpi controller?
You are not supposed to talk directly to the ec device.
Jordan has a diff floating around for acpi tasklets. This really should
be the way to get this done. I'll forward the diff to tech with the
caveat that it isn't finalized yet.
I would prefer for this fan stuff to be automatic instead of by hand
based on the apm heuristics.
One solution would be to use the aml_register_notify(..., ACPIDEV_POLL)
callback mechanism already in use by the acpithinkpad(4) driver to
somehow get into acpi thread context. The problem is that this callback
mechanism is hardcoded to 10s intervals. But I need intervals 1s to
implement a workaround described on
http://www.thinkwiki.org/wiki/How_to_control_fan_speed#Disengaged_.28full-speed.29_mode
any help is appreciated. I'm stuck here.
Christopher
this is what I've got so far:
Index: arch/i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.485
diff -u -p -r1.485 machdep.c
--- arch/i386/i386/machdep.c 2 Oct 2010 23:31:34 - 1.485
+++ arch/i386/i386/machdep.c 19 Dec 2010 15:11:09 -
@@ -243,6 +243,7 @@ void via_update_sensor(void *args);
#endif
int kbd_reset;
int lid_suspend;
+int fan_control;
/*
* safepri is a safe priority for sleep to set for a spin-wait
@@ -3416,6 +3417,8 @@ cpu_sysctl(int *name, u_int namelen, voi
return (sysctl_rdint(oldp, oldlenp, newp, i386_has_xcrypt));
case CPU_LIDSUSPEND:
return (sysctl_int(oldp, oldlenp, newp, newlen, lid_suspend));
+ case CPU_FANCONTROL:
+ return (sysctl_int(oldp, oldlenp, newp, newlen, fan_control));
default:
return (EOPNOTSUPP);
}
Index: arch/i386/include/cpu.h
===
RCS file: /cvs/src/sys/arch/i386/include/cpu.h,v
retrieving revision 1.117
diff -u -p -r1.117 cpu.h
--- arch/i386/include/cpu.h 2 Oct 2010 23:13:28 - 1.117
+++ arch/i386/include/cpu.h 19 Dec 2010 15:11:09 -
@@ -461,7 +461,8 @@ void vm86_gpfault(struct proc *, int);
#define CPU_SSE2 15 /* supports SSE2 */
#define CPU_XCRYPT 16 /* supports VIA xcrypt in userland */
#define CPU_LIDSUSPEND 17 /* lid close causes a suspend */
-#define CPU_MAXID18 /* number of valid machdep ids */
+#define CPU_FANCONTROL 18 /* lid close causes a suspend */
+#define CPU_MAXID19 /* number of valid machdep ids */
#define CTL_MACHDEP_NAMES { \
{ 0, 0 }, \
@@ -482,6 +483,7 @@ void vm86_gpfault(struct proc *, int);
{ sse2, CTLTYPE_INT }, \
{ xcrypt, CTLTYPE_INT }, \
{ lidsuspend, CTLTYPE_INT }, \
+ { fancontrol, CTLTYPE_INT }, \
}
/*
Index: dev/acpi/acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.24
diff -u -p -r1.24 acpithinkpad.c
--- dev/acpi/acpithinkpad.c 7 Aug 2010 16:21:20 - 1.24
+++ dev/acpi/acpithinkpad.c 19 Dec 2010 15:11:17 -
@@ -77,6 +77,16 @@
#define THINKPAD_ECOFFSET_FANLO 0x84
#define THINKPAD_ECOFFSET_FANHI 0x85
+#define THINKPAD_ECOFFSET_FANCTL 0x2f
+#define THINKPAD_FAN_REGVAL 0xff
+/* Most thinkpads only support only speed steps 1-7 */
+#define THINKPAD_FAN_MANUAL 0x3f
+#define THINKPAD_FAN_DISENGAGE 0x40
+#define THINKPAD_FAN_AUTO0x80
+/* AntiPulse */
+#define THINKPAD_FAN_AP 0x100
+#define THINKPAD_FAN_AP_DISENGAGE0x200
+
struct acpithinkpad_softc {
struct devicesc_dev;
@@ -86,8 +96,13 @@ struct acpithinkpad_softc {
struct ksensor sc_sens[THINKPAD_NSENSORS];
struct ksensordevsc_sensdev;
+
+ /* Fan control */
+ struct timeout sc_fan_timeout;
};
+extern int fan_control;
+
extern void acpiec_read(struct acpiec_softc *, u_int8_t, int, u_int8_t *);
int thinkpad_match(struct device *, void *, void *);
@@ -103,8 +118,9 @@ int thinkpad_volume_mute(struct acpithin
int thinkpad_brightness_up(struct acpithinkpad_softc *);
int thinkpad_brightness_down(struct acpithinkpad_softc *);
-voidthinkpad_sensor_attach(struct acpithinkpad_softc *sc);
+voidthinkpad_sensor_attach(struct
Re: softraid(4) disks are of wrong size
I could swear we had the sizes right but I'll have another look at this.
What raid type did you test this with?
On Sun, Dec 19, 2010 at 02:17:46PM +0100, Andreas Bartelt wrote:
Hello,
I've noticed that the size of softraid(4) disks is one sector too large.
In the following description, the native disk is sd4c (which is of type
RAID), and the corresponding virtual softraid(4) disk will be sd5. I
will assume that sd5 is of discipline CRYPTO, but the problem should be
the same for all disciplines.
The size for sd5 gets eventually stored in struct sr_metadata as
sd_meta-ssdi.ssd_size in function sr_crypto_create
(dev/softraid_crypto.c). Its value gets initially calculated in function
sr_meta_native_probe (dev/softraid.c):
size = DL_GETPSIZE(label.d_partitions[part]) - SR_DATA_OFFSET;
where SR_DATA_OFFSET = 528
If the size (as shown via disklabel(8)) of the underlying disk sd4c is
'n', the variable 'size' will be calculated as 'n - 528'. However,
according to disklabel(8), the resulting softraid(4) disk sd5c will be
of size 'n - 528 + 1'. I think this is because function scsi_size in
scsi/scsi_base.c returns 'max_addr + 1' where max_addr corresponds to
sd_meta-ssdi.ssd_size.
For example, newfs(8) on /dev/rsd5c tries to write to the last sector of
sd5 (first wtfs call in mkfs.c) which is one sector beyond the native
disk size of sd4. This gives an error if label sd4c was used as the
native device. It results in a kernel panic in case another label of sd4
was used as the underlying native device (i.e., sd4a).
The attached diff fixes the problem for all newly created softraid volumes.
TODO: fixing the problem for existing softraid(4) volumes would require
to update sd_meta-ssdi.ssd_size to the correct size (and probably some
other metadata for consistency).
Best regards
Andreas
Index: softraid.c
===
RCS file: /usr/cvsync/cvs/src/sys/dev/softraid.c,v
retrieving revision 1.216
diff -u -r1.216 softraid.c
--- softraid.c6 Nov 2010 23:01:56 - 1.216
+++ softraid.c19 Dec 2010 13:01:14 -
@@ -1386,7 +1386,7 @@
goto unwind;
}
- size = DL_GETPSIZE(label.d_partitions[part]) - SR_DATA_OFFSET;
+ size = DL_GETPSIZE(label.d_partitions[part]) - SR_DATA_OFFSET - 1;
if (size = 0) {
DNPRINTF(SR_D_META, %s: %s partition too small\n, DEVNAME(sc),
devname);
Re: ld.so fix for empty LD_PRELOAD
I kind of disagree with you mark and I think that the diff makes sense. On Fri, Dec 17, 2010 at 11:48:06AM +0100, Mark Kettenis wrote: Date: Thu, 16 Dec 2010 22:43:04 +0100 From: Stefan Sperling s...@openbsd.org $ export LD_PRELOAD='' $ sed sed: can't load library '' $ env env: can't load library '' $ vim /usr/local/bin/vim: can't load library '' $ Is this the right way to fix it? I'd say it works just fine without your fix. If you really don't want to preload stuff, make sure LD_PRELOAD isn't set at all. Index: loader.c === RCS file: /cvs/src/libexec/ld.so/loader.c,v retrieving revision 1.120 diff -u -p -r1.120 loader.c --- loader.c25 Oct 2010 20:34:44 - 1.120 +++ loader.c16 Dec 2010 21:40:07 - @@ -493,7 +493,7 @@ _dl_boot(const char **argv, char **envp, TAILQ_INSERT_TAIL(_dlopened_child_list, n, next_sib); exe_obj-opencount++; - if (_dl_preload != NULL) + if (_dl_preload != NULL _dl_preload[0] != '\0') _dl_dopreload(_dl_preload); _dl_load_dep_libs(exe_obj, exe_obj-obj_flags, 1);
Re: allow bioctl to read passphrase from stdin
I like this.
On Mon, Nov 29, 2010 at 02:22:35PM -0800, Chris Kuethe wrote:
Currently bioctl invokes readpassphrase(3) with RPP_REQUIRE_TTY, which
means that there must be a controlling tty to read the password from.
This diff adds an option (-s) to force bioctl to read the passphrase
from stdin. Without this option existing behavior is maintained.
Index: bioctl.8
===
RCS file: /cvs/src/sbin/bioctl/bioctl.8,v
retrieving revision 1.82
diff -u -p -r1.82 bioctl.8
--- bioctl.8 20 Nov 2010 17:46:24 - 1.82
+++ bioctl.8 29 Nov 2010 22:17:03 -
@@ -43,7 +43,7 @@
.Pp
.Nm bioctl
.Bk -words
-.Op Fl dhiPqv
+.Op Fl dhiPqsv
.Op Fl C Ar flag[,flag,...]
.Op Fl c Ar raidlevel
.Op Fl k Ar keydisk
@@ -235,6 +235,11 @@ the PBKDF2 algorithm used to convert a p
Higher iteration counts take more time, but offer more resistance to key
guessing attacks.
The minimum is 1000 rounds and the default is 8192.
+.It Fl s
+Read the passphrase for the selected crypto volume from
+.Pa /dev/stdin
+rather than
+.Pa /dev/tty .
.El
.Sh EXAMPLES
The following command, executed from the command line, would configure
Index: bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.97
diff -u -p -r1.97 bioctl.c
--- bioctl.c 10 Jul 2010 02:56:16 - 1.97
+++ bioctl.c 29 Nov 2010 22:17:03 -
@@ -86,6 +86,7 @@ int rflag = 8192;
char *password;
struct bio_locatebl;
+int rpp_flag = RPP_REQUIRE_TTY;
int
main(int argc, char *argv[])
@@ -106,7 +107,7 @@ main(int argc, char *argv[])
if (argc 2)
usage();
- while ((ch = getopt(argc, argv, a:b:C:c:dH:hik:l:Pp:qr:R:vu:)) !=
+ while ((ch = getopt(argc, argv, a:b:C:c:dH:hik:l:Pp:qr:R:svu:)) !=
-1) {
switch (ch) {
case 'a': /* alarm */
@@ -174,6 +175,9 @@ main(int argc, char *argv[])
ss_func = BIOC_SSREBUILD;
al_arg = optarg;
break;
+ case 's':
+ rpp_flag = RPP_STDIN;
+ break;
case 'v':
verbose = 1;
break;
@@ -252,12 +256,12 @@ usage(void)
[-R device | channel:target[.lun]\n
\t[-u channel:target[.lun]]
device\n
- %s [-dhiPqv]
-[-C flag[,flag,...]] [-c raidlevel] [-k keydisk]\n
-\t[-l special[,special,...]] [-p passfile]\n
-\t[-R device | channel:target[.lun] [-r rounds]
+%s [-dhiPqsv]
+ [-C flag[,flag,...]] [-c raidlevel] [-k keydisk]\n
+ \t[-l special[,special,...]] [-p passfile]\n
+ \t[-R device | channel:target[.lun] [-r rounds]
device\n, __progname, __progname);
-
+
exit(1);
}
@@ -1070,14 +1074,14 @@ derive_key_pkcs(int rounds, u_int8_t *ke
fclose(f);
} else {
if (readpassphrase(prompt, passphrase, sizeof(passphrase),
- RPP_REQUIRE_TTY) == NULL)
+ rpp_flag) == NULL)
errx(1, unable to read passphrase);
}
if (verify) {
/* request user to re-type it */
if (readpassphrase(Re-type passphrase: , verifybuf,
- sizeof(verifybuf), RPP_REQUIRE_TTY) == NULL) {
+ sizeof(verifybuf), rpp_flag) == NULL) {
memset(passphrase, 0, sizeof(passphrase));
errx(1, unable to read passphrase);
}
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: allow bioctl to read passphrase from stdin
I changed my mind. I did talk with jsing and deraadt about the bioctl
follow on but haven't gotten to it yet.
On Tue, Nov 30, 2010 at 11:20:53AM -0500, Ted Unangst wrote:
err, the last time this came up you said you would do it right... :)
http://marc.info/?l=openbsd-miscm=125613898224309w=2
On Tue, Nov 30, 2010 at 5:16 AM, Marco Peereboom sl...@peereboom.us wrote:
I like this.
On Mon, Nov 29, 2010 at 02:22:35PM -0800, Chris Kuethe wrote:
Currently bioctl invokes readpassphrase(3) with RPP_REQUIRE_TTY, which
means that there must be a controlling tty to read the password from.
This diff adds an option (-s) to force bioctl to read the passphrase
from stdin. Without this option existing behavior is maintained.
Index: bioctl.8
===
RCS file: /cvs/src/sbin/bioctl/bioctl.8,v
retrieving revision 1.82
diff -u -p -r1.82 bioctl.8
--- bioctl.8 20 Nov 2010 17:46:24 - 1.82
+++ bioctl.8 29 Nov 2010 22:17:03 -
@@ -43,7 +43,7 @@
.Pp
.Nm bioctl
.Bk -words
-.Op Fl dhiPqv
+.Op Fl dhiPqsv
.Op Fl C Ar flag[,flag,...]
.Op Fl c Ar raidlevel
.Op Fl k Ar keydisk
@@ -235,6 +235,11 @@ the PBKDF2 algorithm used to convert a p
Higher iteration counts take more time, but offer more resistance to key
guessing attacks.
The minimum is 1000 rounds and the default is 8192.
+.It Fl s
+Read the passphrase for the selected crypto volume from
+.Pa /dev/stdin
+rather than
+.Pa /dev/tty .
.El
.Sh EXAMPLES
The following command, executed from the command line, would configure
Index: bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.97
diff -u -p -r1.97 bioctl.c
--- bioctl.c 10 Jul 2010 02:56:16 - 1.97
+++ bioctl.c 29 Nov 2010 22:17:03 -
@@ -86,6 +86,7 @@ int rflag = 8192;
char *password;
struct bio_locatebl;
+int rpp_flag = RPP_REQUIRE_TTY;
int
main(int argc, char *argv[])
@@ -106,7 +107,7 @@ main(int argc, char *argv[])
if (argc 2)
usage();
- while ((ch = getopt(argc, argv, a:b:C:c:dH:hik:l:Pp:qr:R:vu:)) !=
+ while ((ch = getopt(argc, argv, a:b:C:c:dH:hik:l:Pp:qr:R:svu:)) !=
-1) {
switch (ch) {
case 'a': /* alarm */
@@ -174,6 +175,9 @@ main(int argc, char *argv[])
ss_func = BIOC_SSREBUILD;
al_arg = optarg;
break;
+ case 's':
+ rpp_flag = RPP_STDIN;
+ break;
case 'v':
verbose = 1;
break;
@@ -252,12 +256,12 @@ usage(void)
[-R device | channel:target[.lun]\n
\t[-u channel:target[.lun]]
device\n
- %s [-dhiPqv]
-[-C flag[,flag,...]] [-c raidlevel] [-k keydisk]\n
-\t[-l special[,special,...]] [-p passfile]\n
-\t[-R device | channel:target[.lun] [-r rounds]
+%s [-dhiPqsv]
+ [-C flag[,flag,...]] [-c raidlevel] [-k keydisk]\n
+ \t[-l special[,special,...]] [-p passfile]\n
+ \t[-R device | channel:target[.lun] [-r rounds]
device\n, __progname, __progname);
-
+
exit(1);
}
@@ -1070,14 +1074,14 @@ derive_key_pkcs(int rounds, u_int8_t *ke
fclose(f);
} else {
if (readpassphrase(prompt, passphrase, sizeof(passphrase),
- RPP_REQUIRE_TTY) == NULL)
+ rpp_flag) == NULL)
errx(1, unable to read passphrase);
}
if (verify) {
/* request user to re-type it */
if (readpassphrase(Re-type passphrase: , verifybuf,
- sizeof(verifybuf), RPP_REQUIRE_TTY) == NULL) {
+ sizeof(verifybuf), rpp_flag) == NULL) {
memset(passphrase, 0, sizeof(passphrase));
errx(1, unable to read passphrase);
}
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: more hotplug events
yes please. I see all kinds of overruns when resuming currently.
On Tue, Nov 30, 2010 at 07:37:06PM -0500, Ted Unangst wrote:
there are a lot of usb devices that attach more than 16 things at once,
notably the endless stream of nonsense uhid type gadgetry. increase the
limit.
this will use more kernel memory of course (only a tiny bit really, but
whatever) so it's allocated at first open. if you don't use hotplug, you
don't waste memory on it. we could in theory make the buffer quite a bit
larger even now.
Index: hotplug.c
===
RCS file: /home/tedu/cvs/src/sys/dev/hotplug.c,v
retrieving revision 1.9
diff -u -r1.9 hotplug.c
--- hotplug.c 9 Nov 2009 17:53:39 - 1.9
+++ hotplug.c 30 Nov 2010 21:44:43 -
@@ -26,13 +26,14 @@
#include sys/fcntl.h
#include sys/hotplug.h
#include sys/ioctl.h
+#include sys/malloc.h
#include sys/poll.h
#include sys/vnode.h
-#define HOTPLUG_MAXEVENTS16
+#define HOTPLUG_MAXEVENTS64
static int opened;
-static struct hotplug_event evqueue[HOTPLUG_MAXEVENTS];
+static struct hotplug_event *evqueue;
static int evqueue_head, evqueue_tail, evqueue_count;
static struct selinfo hotplug_sel;
@@ -88,6 +89,8 @@
printf(hotplug: event lost, queue full\n);
return (1);
}
+ if (!evqueue)
+ return (1);
evqueue[evqueue_head] = *he;
evqueue_head = EVQUEUE_NEXT(evqueue_head);
@@ -119,12 +122,22 @@
int
hotplugopen(dev_t dev, int flag, int mode, struct proc *p)
{
+ struct hotplug_event *q;
+
if (minor(dev) != 0)
return (ENXIO);
if ((flag FWRITE))
return (EPERM);
if (opened)
return (EBUSY);
+ if (!evqueue) {
+ q = malloc(sizeof(*q) * HOTPLUG_MAXEVENTS, M_DEVBUF, M_WAITOK);
+ if (opened) {
+ free(q, M_DEVBUF);
+ return (EBUSY);
+ }
+ evqueue = q;
+ }
opened = 1;
return (0);
}
@@ -155,7 +168,7 @@
if (flags IO_NDELAY)
return (EAGAIN);
- error = tsleep(evqueue, PRIBIO | PCATCH, htplev, 0);
+ error = tsleep(evqueue, PRIBIO | PCATCH, htplev, 0);
if (error)
return (error);
goto again;
Re: acpithinkpad(4) fan control
This needs to be all handled in the kernel. User space can only get status. We'd love to see this code. On Mon, Nov 29, 2010 at 03:23:58PM +0100, Christopher Zimmermann wrote: Hi! I'd like to implement fan speed control for Thinkpads. It is documented at http://www.thinkwiki.org/wiki/How_to_control_fan_speed#Hardware_specs and linux also implements this (but with special case for TP 570, 600e/x, 770e, 770x - anyone here with access to one of these?) Implementing a driver for this will be a piece of cake, but I need help with communication to userspace to get started. I guess the way to go is sysctl (?) In acpithinkpad only read only sensor variables are created. How do I create r/w variables - where can I find code examples? And where in the sysctl tree should I put them? When I have this working I want to implement a PID controler for it. Since I'd like to see this get committed, where would be the preferred place to put the PID-controller? Kernel or userland? Christopher
Re: softraid cleanup
Groovy. Still waiting for a rebuild report. On Oct 24, 2010, at 14:20, Tobias Ulmer tobi...@tmux.org wrote: On Wed, Oct 20, 2010 at 08:47:00PM -0500, Marco Peereboom wrote: On Thu, Sep 30, 2010 at 03:35:33AM +0200, Tobias Ulmer wrote: I got this after a while: panic: softraid0: sr_crypto_finish_io No serial, so there's no more info. You know where to find me new diff that should fix all them issues. No issues.
Re: softraid cleanup
anyone?
On Wed, Oct 20, 2010 at 08:47:00PM -0500, Marco Peereboom wrote:
On Thu, Sep 30, 2010 at 03:35:33AM +0200, Tobias Ulmer wrote:
I got this after a while:
panic: softraid0: sr_crypto_finish_io
No serial, so there's no more info. You know where to find me
new diff that should fix all them issues.
please test, especially raid 1 including rebuild and stuff.
Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.215
diff -u -p -r1.215 softraid.c
--- dev/softraid.c12 Oct 2010 00:53:32 - 1.215
+++ dev/softraid.c21 Oct 2010 01:36:32 -
@@ -126,6 +126,7 @@ void sr_rebuild(void *);
void sr_rebuild_thread(void *);
void sr_roam_chunks(struct sr_discipline *);
int sr_chunk_in_use(struct sr_softc *, dev_t);
+void sr_startwu_callback(void *, void *);
/* don't include these on RAMDISK */
#ifndef SMALL_KERNEL
@@ -1806,6 +1807,8 @@ sr_wu_put(struct sr_workunit *wu)
wu-swu_fake = 0;
wu-swu_flags = 0;
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_wu_put, DEVNAME(sd-sd_sc));
while ((ccb = TAILQ_FIRST(wu-swu_ccb)) != NULL) {
TAILQ_REMOVE(wu-swu_ccb, ccb, ccb_link);
sr_ccb_put(ccb);
@@ -2563,6 +2566,9 @@ sr_hotspare_rebuild(struct sr_discipline
busy = 0;
s = splbio();
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_hotspare_rebuild,
+ DEVNAME(sd-sd_sc));
TAILQ_FOREACH(wu, sd-sd_wu_pendq, swu_link) {
TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
if (ccb-ccb_target == chunk_no)
@@ -2816,6 +2822,11 @@ sr_ioctl_createraid(struct sr_softc *sc,
sd = malloc(sizeof(struct sr_discipline), M_DEVBUF, M_WAITOK | M_ZERO);
sd-sd_sc = sc;
SLIST_INIT(sd-sd_meta_opt);
+ sd-sd_workq = workq_create(srdis, 1, IPL_BIO);
+ if (sd-sd_workq == NULL) {
+ printf(%s: could not create workq\n);
+ goto unwind;
+ }
if (sr_discipline_init(sd, bc-bc_level)) {
printf(%s: could not initialize discipline\n, DEVNAME(sc));
goto unwind;
@@ -3407,6 +3418,9 @@ sr_discipline_shutdown(struct sr_discipl
sr_chunks_unwind(sc, sd-sd_vol.sv_chunk_list);
+ if (sd-sd_workq)
+ workq_destroy(sd-sd_workq);
+
if (sd)
sr_discipline_free(sd);
@@ -3625,10 +3639,29 @@ sr_raid_sync(struct sr_workunit *wu)
}
void
+sr_startwu_callback(void *arg1, void *arg2)
+{
+ struct sr_discipline*sd = arg1;
+ struct sr_workunit *wu = arg2;
+ struct sr_ccb *ccb;
+ int s;
+
+ s = splbio();
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_startwu_callback, DEVNAME(sd-sd_sc));
+ wu-swu_cb_active = 1;
+
+ TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link)
+ VOP_STRATEGY(ccb-ccb_buf);
+
+ wu-swu_cb_active = 0;
+ splx(s);
+}
+
+void
sr_raid_startwu(struct sr_workunit *wu)
{
struct sr_discipline*sd = wu-swu_dis;
- struct sr_ccb *ccb;
splassert(IPL_BIO);
@@ -3643,9 +3676,8 @@ sr_raid_startwu(struct sr_workunit *wu)
TAILQ_INSERT_TAIL(sd-sd_wu_pendq, wu, swu_link);
/* start all individual ios */
- TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
- VOP_STRATEGY(ccb-ccb_buf);
- }
+ workq_queue_task(sd-sd_workq, wu-swu_wqt, 0, sr_startwu_callback,
+ sd, wu);
}
void
Index: dev/softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.57
diff -u -p -r1.57 softraid_crypto.c
--- dev/softraid_crypto.c 27 Sep 2010 19:49:43 - 1.57
+++ dev/softraid_crypto.c 5 Oct 2010 20:49:24 -
@@ -164,11 +164,11 @@ sr_crypto_create(struct sr_discipline *s
} else if (sr_crypto_get_kdf(bc, sd))
goto done;
-
+
/* Passphrase volumes cannot be automatically assembled. */
if (!(bc-bc_flags BIOC_SCNOAUTOASSEMBLE) bc-bc_key_disk == NODEV)
goto done;
-
+
strlcpy(sd-sd_name, CRYPTO, sizeof(sd-sd_name));
sd-sd_meta-ssdi.ssd_size = coerced_size;
@@ -194,15 +194,12 @@ sr_crypto_assemble(struct sr_discipline
goto done;
if (bc-bc_key_disk != NODEV) {
-
/* Read the mask key from the key disk. */
sd-mds.mdd_crypto.key_disk =
sr_crypto_read_key_disk(sd, bc-bc_key_disk);
if (sd-mds.mdd_crypto.key_disk == NULL)
goto done
Re: softraid cleanup
On Thu, Sep 30, 2010 at 03:35:33AM +0200, Tobias Ulmer wrote:
I got this after a while:
panic: softraid0: sr_crypto_finish_io
No serial, so there's no more info. You know where to find me
new diff that should fix all them issues.
please test, especially raid 1 including rebuild and stuff.
Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.215
diff -u -p -r1.215 softraid.c
--- dev/softraid.c 12 Oct 2010 00:53:32 - 1.215
+++ dev/softraid.c 21 Oct 2010 01:36:32 -
@@ -126,6 +126,7 @@ voidsr_rebuild(void *);
void sr_rebuild_thread(void *);
void sr_roam_chunks(struct sr_discipline *);
intsr_chunk_in_use(struct sr_softc *, dev_t);
+void sr_startwu_callback(void *, void *);
/* don't include these on RAMDISK */
#ifndef SMALL_KERNEL
@@ -1806,6 +1807,8 @@ sr_wu_put(struct sr_workunit *wu)
wu-swu_fake = 0;
wu-swu_flags = 0;
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_wu_put, DEVNAME(sd-sd_sc));
while ((ccb = TAILQ_FIRST(wu-swu_ccb)) != NULL) {
TAILQ_REMOVE(wu-swu_ccb, ccb, ccb_link);
sr_ccb_put(ccb);
@@ -2563,6 +2566,9 @@ sr_hotspare_rebuild(struct sr_discipline
busy = 0;
s = splbio();
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_hotspare_rebuild,
+ DEVNAME(sd-sd_sc));
TAILQ_FOREACH(wu, sd-sd_wu_pendq, swu_link) {
TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
if (ccb-ccb_target == chunk_no)
@@ -2816,6 +2822,11 @@ sr_ioctl_createraid(struct sr_softc *sc,
sd = malloc(sizeof(struct sr_discipline), M_DEVBUF, M_WAITOK | M_ZERO);
sd-sd_sc = sc;
SLIST_INIT(sd-sd_meta_opt);
+ sd-sd_workq = workq_create(srdis, 1, IPL_BIO);
+ if (sd-sd_workq == NULL) {
+ printf(%s: could not create workq\n);
+ goto unwind;
+ }
if (sr_discipline_init(sd, bc-bc_level)) {
printf(%s: could not initialize discipline\n, DEVNAME(sc));
goto unwind;
@@ -3407,6 +3418,9 @@ sr_discipline_shutdown(struct sr_discipl
sr_chunks_unwind(sc, sd-sd_vol.sv_chunk_list);
+ if (sd-sd_workq)
+ workq_destroy(sd-sd_workq);
+
if (sd)
sr_discipline_free(sd);
@@ -3625,10 +3639,29 @@ sr_raid_sync(struct sr_workunit *wu)
}
void
+sr_startwu_callback(void *arg1, void *arg2)
+{
+ struct sr_discipline*sd = arg1;
+ struct sr_workunit *wu = arg2;
+ struct sr_ccb *ccb;
+ int s;
+
+ s = splbio();
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_startwu_callback, DEVNAME(sd-sd_sc));
+ wu-swu_cb_active = 1;
+
+ TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link)
+ VOP_STRATEGY(ccb-ccb_buf);
+
+ wu-swu_cb_active = 0;
+ splx(s);
+}
+
+void
sr_raid_startwu(struct sr_workunit *wu)
{
struct sr_discipline*sd = wu-swu_dis;
- struct sr_ccb *ccb;
splassert(IPL_BIO);
@@ -3643,9 +3676,8 @@ sr_raid_startwu(struct sr_workunit *wu)
TAILQ_INSERT_TAIL(sd-sd_wu_pendq, wu, swu_link);
/* start all individual ios */
- TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
- VOP_STRATEGY(ccb-ccb_buf);
- }
+ workq_queue_task(sd-sd_workq, wu-swu_wqt, 0, sr_startwu_callback,
+ sd, wu);
}
void
Index: dev/softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.57
diff -u -p -r1.57 softraid_crypto.c
--- dev/softraid_crypto.c 27 Sep 2010 19:49:43 - 1.57
+++ dev/softraid_crypto.c 5 Oct 2010 20:49:24 -
@@ -164,11 +164,11 @@ sr_crypto_create(struct sr_discipline *s
} else if (sr_crypto_get_kdf(bc, sd))
goto done;
-
+
/* Passphrase volumes cannot be automatically assembled. */
if (!(bc-bc_flags BIOC_SCNOAUTOASSEMBLE) bc-bc_key_disk == NODEV)
goto done;
-
+
strlcpy(sd-sd_name, CRYPTO, sizeof(sd-sd_name));
sd-sd_meta-ssdi.ssd_size = coerced_size;
@@ -194,15 +194,12 @@ sr_crypto_assemble(struct sr_discipline
goto done;
if (bc-bc_key_disk != NODEV) {
-
/* Read the mask key from the key disk. */
sd-mds.mdd_crypto.key_disk =
sr_crypto_read_key_disk(sd, bc-bc_key_disk);
if (sd-mds.mdd_crypto.key_disk == NULL)
goto done;
-
} else if (bc-bc_opaque_flags BIOC_SOOUT) {
-
/*
acpiec madness (HP laptop people pay attention to this one)
On the HP8350w (and others with acpitz issues etc) IBF or OBF are set
well before the data is actually ready to read or write. By adding some
delays on the way out we seem to work around this problem and the
machine goes from flaky (hung keyboard and hung graphics etc) to rock
solid. It suspends/resumes, the works.
Looking at the linux driver it seems that they don't run into this issue
because it takes a while between getting IBF/OBF to reading/writing the
data. Their driver waits before it starts handling a command, while
handling a command and on the way out. So this seems like a safe
workaround for now.
Jordan has a state machine based acpiec diff in the works that does a
bit more checking. Contact me off list if you want to play with that.
Do send me failure reports with this diff.
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.43
diff -u -p -r1.43 acpiec.c
--- acpiec.c8 Aug 2010 17:25:41 - 1.43
+++ acpiec.c29 Sep 2010 04:24:13 -
@@ -92,7 +92,7 @@ void
acpiec_wait(struct acpiec_softc *sc, u_int8_t mask, u_int8_t val)
{
static int acpiecnowait;
- u_int8_tstat;
+ volatile u_int8_t stat;
dnprintf(40, %s: EC wait_ns for: %b == %02x\n,
DEVNAME(sc), (int)mask,
@@ -104,8 +104,14 @@ acpiec_wait(struct acpiec_softc *sc, u_i
if (cold || (stat EC_STAT_BURST))
delay(1);
else
- tsleep(acpiecnowait, PWAIT, acpiec, 1);
+ tsleep(acpiecnowait, PWAIT, ecstat, 1);
}
+
+ /* delay to make sure the data is actually ready */
+ if (cold)
+ delay(10);
+ else
+ tsleep(acpiecnowait, PWAIT, ecout, 1);
dnprintf(40, %s: EC wait_ns, stat: %b\n, DEVNAME(sc), (int)stat,
\20\x8IGN\x7SMI\x6SCI\05BURST\04CMD\03IGN\02IBF\01OBF);
Re: softraid cleanup
hrmpf, not supposed to happen panic. Thanks!
Back to the drawing board.
On Wed, Sep 29, 2010 at 11:58:51PM -0400, Dan Harnett wrote:
On Thu, Sep 30, 2010 at 03:35:33AM +0200, Tobias Ulmer wrote:
I got this after a while:
panic: softraid0: sr_crypto_finish_io
I see the same panic in the latest amd64 snapshot.
panic: softraid0: sr_crypto_finish_io
Stopped atDebugger+0x5: leave
ddb{0} trace
Debugger() at Debugger+0x5
panic() at panic+0xe4
sr_crypto_finish_io() at sr_crypto_finish_io+0xc7
sr_crypto_intr() at sr_crypto_intr+0x15d
sd_buf_done() at sd_buf_done+0x76
ahci_port_intr() at ahci_port_intr+0x183
ahci_intr() at ahci_intr+0x5c
Xintr_ioapic_level10() at Xintr_ioapic_level10+0xec
--- interrupt ---
Bad frame pointer: 0x800025c16df8
end trace frame: 0x800025c16df8, count: -8
spllower+0x35:
ddb{0}
softraid cleanup
I have been running with this for months and would like to revive the
idea. This adds a workq for all IO handling in softraid crypto and raid
1. This fixes the violation of VOP_STRATEGY being called from interrupt
context.
I plan on doing something more sophisticated at a later point that would
handle rebuild/scrub/md IO through the same path but I think it is worth
it to get the workq stuff in and then cut the individual pieces in one
at at a time.
I am looking for test reports and oks. If I don't get any I am going to
move forward with it and everyone gets to test it.
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.214
diff -u -p -r1.214 softraid.c
--- softraid.c 23 Sep 2010 18:49:39 - 1.214
+++ softraid.c 27 Sep 2010 22:13:55 -
@@ -126,6 +126,7 @@ voidsr_rebuild(void *);
void sr_rebuild_thread(void *);
void sr_roam_chunks(struct sr_discipline *);
intsr_chunk_in_use(struct sr_softc *, dev_t);
+void sr_startwu_callback(void *, void *);
/* don't include these on RAMDISK */
#ifndef SMALL_KERNEL
@@ -1806,6 +1807,8 @@ sr_wu_put(struct sr_workunit *wu)
wu-swu_fake = 0;
wu-swu_flags = 0;
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_wu_put, DEVNAME(sd-sd_sc));
while ((ccb = TAILQ_FIRST(wu-swu_ccb)) != NULL) {
TAILQ_REMOVE(wu-swu_ccb, ccb, ccb_link);
sr_ccb_put(ccb);
@@ -2563,6 +2566,9 @@ sr_hotspare_rebuild(struct sr_discipline
busy = 0;
s = splbio();
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_hotspare_rebuild,
+ DEVNAME(sd-sd_sc));
TAILQ_FOREACH(wu, sd-sd_wu_pendq, swu_link) {
TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
if (ccb-ccb_target == chunk_no)
@@ -2816,6 +2822,11 @@ sr_ioctl_createraid(struct sr_softc *sc,
sd = malloc(sizeof(struct sr_discipline), M_DEVBUF, M_WAITOK | M_ZERO);
sd-sd_sc = sc;
SLIST_INIT(sd-sd_meta_opt);
+ sd-sd_workq = workq_create(srdis, 1, IPL_BIO);
+ if (sd-sd_workq == NULL) {
+ printf(%s: could not create workq\n);
+ goto unwind;
+ }
if (sr_discipline_init(sd, bc-bc_level)) {
printf(%s: could not initialize discipline\n, DEVNAME(sc));
goto unwind;
@@ -3407,6 +3418,9 @@ sr_discipline_shutdown(struct sr_discipl
sr_chunks_unwind(sc, sd-sd_vol.sv_chunk_list);
+ if (sd-sd_workq)
+ workq_destroy(sd-sd_workq);
+
if (sd)
sr_discipline_free(sd);
@@ -3624,10 +3638,26 @@ sr_raid_sync(struct sr_workunit *wu)
}
void
+sr_startwu_callback(void *arg1, void *arg2)
+{
+ struct sr_discipline*sd = arg1;
+ struct sr_workunit *wu = arg2;
+ struct sr_ccb *ccb;
+
+ if (wu-swu_cb_active == 1)
+ panic(%s: sr_startwu_callback, DEVNAME(sd-sd_sc));
+ wu-swu_cb_active = 1;
+
+ TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link)
+ VOP_STRATEGY(ccb-ccb_buf);
+
+ wu-swu_cb_active = 0;
+}
+
+void
sr_raid_startwu(struct sr_workunit *wu)
{
struct sr_discipline*sd = wu-swu_dis;
- struct sr_ccb *ccb;
splassert(IPL_BIO);
@@ -3641,10 +3671,9 @@ sr_raid_startwu(struct sr_workunit *wu)
/* move wu to pending queue */
TAILQ_INSERT_TAIL(sd-sd_wu_pendq, wu, swu_link);
- /* start all individual ios */
- TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
- VOP_STRATEGY(ccb-ccb_buf);
- }
+ /* start all individual ios */
+ workq_queue_task(sd-sd_workq, wu-swu_wqt, 0, sr_startwu_callback,
+ sd, wu);
}
void
Index: softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.57
diff -u -p -r1.57 softraid_crypto.c
--- softraid_crypto.c 27 Sep 2010 19:49:43 - 1.57
+++ softraid_crypto.c 27 Sep 2010 22:13:55 -
@@ -164,11 +164,11 @@ sr_crypto_create(struct sr_discipline *s
} else if (sr_crypto_get_kdf(bc, sd))
goto done;
-
+
/* Passphrase volumes cannot be automatically assembled. */
if (!(bc-bc_flags BIOC_SCNOAUTOASSEMBLE) bc-bc_key_disk == NODEV)
goto done;
-
+
strlcpy(sd-sd_name, CRYPTO, sizeof(sd-sd_name));
sd-sd_meta-ssdi.ssd_size = coerced_size;
@@ -194,15 +194,12 @@ sr_crypto_assemble(struct sr_discipline
goto done;
if (bc-bc_key_disk != NODEV) {
-
/* Read the mask key from the key disk. */
Re: de-static uvm_swap
Kill em dead
On Sep 24, 2010, at 17:33, Thordur Bjornsson t...@openbsd.org wrote:
and I'd like to kill these to:
Index: uvm_pdaemon.c
===
RCS file: /cvs/src/sys/uvm/uvm_pdaemon.c,v
retrieving revision 1.55
diff -u -p -r1.55 uvm_pdaemon.c
--- uvm_pdaemon.c14 Oct 2009 17:53:30 -1.55
+++ uvm_pdaemon.c24 Sep 2010 22:31:47 -
@@ -96,9 +96,9 @@
* local prototypes
*/
-static voiduvmpd_scan(void);
-static boolean_tuvmpd_scan_inactive(struct pglist *);
-static voiduvmpd_tune(void);
+voiduvmpd_scan(void);
+boolean_tuvmpd_scan_inactive(struct pglist *);
+voiduvmpd_tune(void);
/*
* uvm_wait: wait (sleep) for the page daemon to free some pages
@@ -155,7 +155,7 @@ uvm_wait(const char *wmsg)
* = caller must call with page queues locked
*/
-static void
+void
uvmpd_tune(void)
{
UVMHIST_FUNC(uvmpd_tune); UVMHIST_CALLED(pdhist);
@@ -329,7 +329,7 @@ uvm_aiodone_daemon(void *arg)
* = we return TRUE if we are exiting because we met our target
*/
-static boolean_t
+boolean_t
uvmpd_scan_inactive(struct pglist *pglst)
{
boolean_t retval = FALSE;/* assume we haven't hit target */
Re: raise the openings on mpi(4)
Meh. Code has changed a lot since then and we should just raise them all and see if this is still an issue. On Mon, Sep 13, 2010 at 05:52:31PM +1000, David Gwynne wrote: last time i tried this i caused weird issues on people using the SPI variants of mpi(4). this restricts the large number of openings to the SAS or FC mpi(4) variants, both of which i have succesffully tested myself. ok? Index: mpi.c === RCS file: /cvs/src/sys/dev/ic/mpi.c,v retrieving revision 1.161 diff -u -p -r1.161 mpi.c --- mpi.c 13 Sep 2010 07:48:12 - 1.161 +++ mpi.c 13 Sep 2010 07:49:52 - @@ -339,7 +340,10 @@ mpi_attach(struct mpi_softc *sc) sc-sc_link.adapter_softc = sc; sc-sc_link.adapter_target = sc-sc_target; sc-sc_link.adapter_buswidth = sc-sc_buswidth; - sc-sc_link.openings = sc-sc_maxcmds / sc-sc_buswidth; + if (sc-sc_porttype == MPI_PORTFACTS_PORTTYPE_SCSI) + sc-sc_link.openings = sc-sc_maxcmds / sc-sc_buswidth; + else + sc-sc_link.openings = sc-sc_maxcmds; sc-sc_link.pool = sc-sc_iopool; bzero(saa, sizeof(saa));
Re: Minor clarifications for bioctl.8 and softraid.4
I don't like detach. bioctl is a generic tool and the intent of that command is to delete a logical disk of a controller. The fact that softraid detaches the disk is a side-effect. On mfi, for example, that is a pretty destructive command. On Mon, Sep 13, 2010 at 03:10:12PM +0100, Jason McIntyre wrote: On Sun, Sep 12, 2010 at 11:00:47PM -0700, Chris Palmer wrote: Jason McIntyre writes: ok, my diff below tries to collect the various bits of feedback. stuff i haven't taken: Thanks for doing this. - delete - detach, for reasons given by marco I'd still like to reconsider this. if marco indicates he's alright with it, i'll add it. - `` - ; i don't think it's worth changing But it looks silly with the other style of quotes right next to it in the page: ``Unused'', promote it to being a ``Hot Spare''. -h Where necessary, produce human-readable output. Use unit suffix- ok, i will make this change. i'll hold off from commit to see about the delete/detach thing... jmc
Re: Minor clarifications for bioctl.8 and softraid.4
sure. On Mon, Sep 13, 2010 at 03:29:19PM +0100, Jason McIntyre wrote: On Mon, Sep 13, 2010 at 09:18:10AM -0500, Marco Peereboom wrote: I don't like detach. bioctl is a generic tool and the intent of that command is to delete a logical disk of a controller. The fact that softraid detaches the disk is a side-effect. On mfi, for example, that is a pretty destructive command. ok. alright with the rest of the diff? jmc Index: bioctl.8 === RCS file: /cvs/src/sbin/bioctl/bioctl.8,v retrieving revision 1.80 diff -u -r1.80 bioctl.8 --- bioctl.8 31 Dec 2009 14:00:45 - 1.80 +++ bioctl.8 13 Sep 2010 14:29:28 - @@ -119,7 +119,9 @@ promote it to being a .Dq Hot Spare . .It Fl h -Where necessary, produce human-readable output. +Where necessary, produce +.Dq human-readable +output. Use unit suffixes: Byte, Kilobyte, Megabyte, Gigabyte, Terabyte, Petabyte, Exabyte in order to reduce the number of digits to four or less. @@ -223,7 +225,7 @@ It cannot be used during the initial creation of the crypto volume. .It Fl r Ar rounds When creating an encrypted volume, specifies the number of iterations of -the algorithm used to convert a passphrase into a key. +the PBKDF2 algorithm used to convert a passphrase into a key. Higher iteration counts take more time, but offer more resistance to key guessing attacks. The minimum is 1000 rounds and the default is 8192. @@ -245,7 +247,7 @@ .Ed .Pp .Nm -will ask for a passphrase, that will be needed to unlock the encrypted +will ask for a passphrase, which will be needed to unlock the encrypted disk. After creating a newly encrypted disk, the first megabyte of it should be zeroed, so tools like @@ -267,6 +269,11 @@ .Xr bio 4 , .Xr scsi 4 , .Xr softraid 4 +.Rs +.%R RFC 2898 +.%T PKCS #5: Password-Based Cryptography Specification Version 2.0 +.%D 2000 +.Re .Sh HISTORY The .Nm @@ -278,4 +285,4 @@ interface was written by .An Marco Peereboom Aq ma...@openbsd.org . .Sh CAVEATS -Use of the crypto RAID 4/5 disciplines are currently considered experimental. +Use of the CRYPTO RAID 4/5 disciplines are currently considered experimental.
fix some warnings on sgi
This quiets the compiler quite a bit. ok? Index: Makefile.inc === RCS file: /cvs/src/sys/arch/sgi/stand/Makefile.inc,v retrieving revision 1.5 diff -u -p -r1.5 Makefile.inc --- Makefile.inc14 May 2009 18:57:41 - 1.5 +++ Makefile.inc14 Sep 2010 01:43:53 - @@ -14,6 +14,7 @@ CPPFLAGS+=-I. CFLAGS+= -fno-stack-protector -Wall CFLAGS+= -fno-builtin-vprintf -fno-builtin-printf -fno-builtin-putchar +CFLAGS+= -fno-builtin-exit SAABI?=-mips3 -mno-abicalls -G 0 -fno-pic -fno-common AS?= as LD?= ld
fix gcc4 compiler error on sgi
This is just like the mips64 code. Index: arcbios.c === RCS file: /cvs/src/sys/arch/sgi/stand/boot/arcbios.c,v retrieving revision 1.12 diff -u -p -r1.12 arcbios.c --- arcbios.c 22 Jul 2009 20:23:44 - 1.12 +++ arcbios.c 14 Sep 2010 02:23:45 - @@ -36,7 +36,7 @@ #include stand.h -static int bios_is_32bit; +intbios_is_32bit; u_int kl_n_shift = 32; intarcbios_init(void);
Re: Minor clarifications for bioctl.8 and softraid.4
On Sun, Sep 12, 2010 at 09:21:31PM +0100, Jason McIntyre wrote: On Sun, Sep 12, 2010 at 12:22:25PM -0700, Chris Palmer wrote: I recently set up a CRYPTO volume with softraid(4) and enjoyed it. Thanks! Here are some hopefully-clarifying diffs to the man pages. feedback from softraid people please... Inline where I don't agree. --- bioctl.8.orig Sat Sep 11 19:55:27 2010 +++ bioctl.8Sun Sep 12 12:17:30 2010 @@ -119,7 +119,7 @@ promote it to being a .Dq Hot Spare . .It Fl h -Where necessary, produce human-readable output. +Where necessary, produce ``human-readable'' output. er, ... Use unit suffixes: Byte, Kilobyte, Megabyte, Gigabyte, Terabyte, Petabyte, Exabyte in order to reduce the number of digits to four or less. @@ -202,7 +202,7 @@ RAID 4 and RAID 5 require at least three devices, and the CRYPTO discipline requires exactly one. .It Fl d -Delete volume specified by device. +Detach volume specified by device. softraid people? Nope; technically it is a delete. Detaching is a side-effect. .It Fl k Ar keydisk Use special device .Ar keydisk @@ -224,6 +224,7 @@ .It Fl r Ar rounds When creating an encrypted volume, specifies the number of iterations of the algorithm used to convert a passphrase into a key. +(The algorithm is PBKDF2.) if correct, we can probably say: ...the algorithm used (PBKDF2) to convert... but someone confirm, please. Higher iteration counts take more time, but offer more resistance to key guessing attacks. The minimum is 1000 rounds and the default is 8192. @@ -245,20 +246,19 @@ .Ed .Pp .Nm -will ask for a passphrase, that will be needed to unlock the encrypted -disk. +will ask for the passphrase needed to unlock the encrypted disk. After creating a newly encrypted disk, the first megabyte of it should be zeroed, so tools like .Xr fdisk 8 or .Xr disklabel 8 don't get confused by the random data that appears on the new disk. -This can be done with the following command (assuming the new disk is sd3): +This can be done with the following command (assuming the new disk is sd2): .Bd -literal -offset 3n -# dd if=/dev/zero of=/dev/rsd3c bs=1m count=1 +# dd if=/dev/zero of=/dev/rsd2c bs=1m count=1 er, ... .Ed .Pp -Deleting a softraid volume requires the exact volume name. +Detaching a softraid volume requires the exact volume name. softraid people, please. Same as previous. For example: .Bd -literal -offset 3n # bioctl -d sd2 @@ -267,6 +267,8 @@ .Xr bio 4 , .Xr scsi 4 , .Xr softraid 4 +.Pp +RFC 2898 describes PBKDF2. we can probably expand this. .Sh HISTORY The .Nm @@ -278,4 +280,4 @@ interface was written by .An Marco Peereboom Aq ma...@openbsd.org . .Sh CAVEATS -Use of the crypto RAID 4/5 disciplines are currently considered experimental. +Use of the CRYPTO and RAID 4/5 disciplines are currently considered experimental. --- softraid.4.orig Sun Sep 12 12:13:10 2010 +++ softraid.4 Sun Sep 12 12:14:50 2010 @@ -119,6 +119,9 @@ # printf a\en\en\en\enRAID\enw\enq\en\en | disklabel -E wd3 .Ed .Pp +(Note that RAID is also the correct partition type when using the CRYPTO +discipline.) +.Pp this page already states: A chunk is a partition or storage area of fstype ``RAID''. disklabel(8) is used to alter the fstype. this is pretty clear, no? jmc
Re: bioctl patch (inline) diff -uNp
I am not a fan of this. Why wouldn't you do this in the wrapping
script?
I added some style nits too for future reference
On Sun, Sep 12, 2010 at 11:42:26PM +0200, Merlyn wrote:
Index: bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.97
diff -u -p -r1.97 bioctl.c
--- bioctl.c 10 Jul 2010 02:56:16 - 1.97
+++ bioctl.c 12 Sep 2010 21:40:23 -
@@ -71,7 +71,7 @@ int bio_getvolbyname(char *);
void bio_setstate(char *, int, char *);
void bio_setblink(char *, char *, int);
void bio_blink(char *, int, int);
-void bio_createraid(u_int16_t, char *, char *);
+int bio_createraid(u_int16_t, char *, char *);
void bio_deleteraid(char *);
void bio_changepass(char *);
u_int32_tbio_createflags(char *);
@@ -102,11 +102,14 @@ main(int argc, char *argv[])
int ss_func = 0;
u_int16_t cr_level = 0;
int biodev = 0;
+ int success = 0;
+ int more_tries = 0;
+ int retries = 0;
if (argc 2)
usage();
- while ((ch = getopt(argc, argv, a:b:C:c:dH:hik:l:Pp:qr:R:vu:)) !=
+ while ((ch = getopt(argc, argv, a:b:C:c:dH:hik:l:Pp:qr:R:t:vu:)) !=
-1) {
switch (ch) {
case 'a': /* alarm */
@@ -132,6 +135,14 @@ main(int argc, char *argv[])
/* delete volume */
func |= BIOC_DELETERAID;
break;
+ case 't':
+ /* ask for password retries-times */
+ more_tries = 1;
+ retries = strtonum(optarg, 0, 1000, errstr);
+ if (errstr != NULL)
+ errx(1, Number of retries is %s: %s,
+ errstr, optarg);
+ break;
case 'u': /* unblink */
func |= BIOC_BLINK;
blink = BIOC_SBUNBLINK;
@@ -234,7 +245,17 @@ main(int argc, char *argv[])
errx(1, need -l parameter);
if (!biodev)
errx(1, must use bio device);
- bio_createraid(cr_level, dev_list, key_disk);
+ if (more_tries == 1)
+ if ( retries == 0 )
+ do
+ success=bio_createraid(cr_level,
dev_list, key_disk);
+ while ( success == -1 );
^ no space^
+ else
+ do
+ success=bio_createraid(cr_level,
dev_list, key_disk);
+ while ( --retries 0 success == -1 );
^ no space there ^
+ else
+ bio_createraid(cr_level, dev_list, key_disk);
}
return (0);
@@ -255,7 +276,8 @@ usage(void)
%s [-dhiPqv]
[-C flag[,flag,...]] [-c raidlevel] [-k keydisk]\n
\t[-l special[,special,...]] [-p passfile]\n
-\t[-R device | channel:target[.lun] [-r rounds]
+\t[-R device | channel:target[.lun] [-r rounds]\n
+ \t[-t retries]
device\n, __progname, __progname);
exit(1);
@@ -685,7 +707,7 @@ bio_blink(char *enclosure, int target, i
close(bioh);
}
-void
+int
bio_createraid(u_int16_t level, char *dev_list, char *key_disk)
{
struct bioc_createraid create;
@@ -798,8 +820,10 @@ bio_createraid(u_int16_t level, char *de
memset(kdfinfo, 0, sizeof(kdfinfo));
memset(create, 0, sizeof(create));
if (rv == -1) {
- if (errno == EPERM)
- errx(1, Incorrect passphrase);
+ if (errno == EPERM) {
+ fprintf(stderr,Incorrect passphrase\n);
+ return -1;
+ }
err(1, BIOCCREATERAID);
}
Re: ACPI systems without legacy mode
Now that release is done I am not opposed to this. On Tue, Aug 31, 2010 at 03:58:43PM +0200, Niklas Hallqvist wrote: On 08/08/10 12:18, Mark Kettenis wrote: Date: Sun, 8 Aug 2010 17:57:20 +0800 Is there someone who would be willing to test this diff on a physical machine that currently reports ACPI control unavailable in dmesg, e.g. acpi0 at bios0: rev 2, ACPI control unavailable I'm pretty sure such hardware does not exist, at least not in the i386/amd64 world. To me, that doesn't matter. There exist the concept of ACPI systems without SMM in the specs, and at least one VMM implements their ACPI without any SMM. I see no reason to not support running OpenBSD in in it, i.e. Xen. The diff removes the need for UKC workaounds when running HVM OpenBSD guests in Citrix Xenserver. As such it is very useful as is, and it is, in my opinion, correct. I have spent quite a few hours debugging some PCI IRQ routing problems in the Xen guest world which finally boiled down to ioapic enabling, without the ACPI tables available to set it up correctly. acpiprt made it work immedately as soon as acpi was allowed to attach. With this diff, OpenBSD does not need any UKC magic to boot (xenserver still needs some hacks to the qemu-dm-wrapper, in order to emulate em instead of rl, which seems to be a known broken emulation). Furthermore, since USB can be enabled, the much better trick of using a USB tablet for mouse emulation, GUIs become usable as well. Not that I need it, but the side effect to having to disable USB in order to boot OpenBSD, makes mouse emulation really bad. I find it funny that Nathanael only wanted this for halt -p, that would be the least of the good stuff it brings :-) Still, Citrix XenServer breaks SMP, that will be my next thing to fix I guess. I sort of hoped acpimadt would do it :-) So as far as I am concerned Nathanaels diff should be considered seriously. I am already using it in my baseline tree I build all our clients' systems from. Niklas [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: HP ProBook 4510s ACPI test. apm -a and -b works. apm -z does nothing. audio/video skips
Were you running apmd? On Fri, Aug 06, 2010 at 03:20:48PM -0700, Tim Howe wrote: This is on a HP ProBook 4510s. apm -a and apm -b seem to give me correct info. apm -z does nothing as far as I can tell. Also, when ACPI is enabled (which must be done in order for SMP to work) audio and video skips a lot. I have no idea why, but when ACPI (and therefor SMP) is disabled everything is nice and smooth. Still, this is an improvement. with 4.7 this laptop would not boot unless ACPI was disabled. OpenBSD 4.8-beta (GENERIC.MP) #304: Wed Aug 4 20:26:11 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP RTC BIOS diagnostic error 7fROM_cksum,config_unit,memory_size,fixed_disk,invalid_time cpu0: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (GenuineIntel 686-class) 2.10 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE real mem = 2072080384 (1976MB) avail mem = 2028208128 (1934MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 09/15/09, SMBIOS rev. 2.4 @ 0x7bac3000 (21 entries) bios0: vendor Hewlett-Packard version 68PZI Ver. F.0F date 10/20/2009 bios0: Hewlett-Packard HP ProBook 4510s acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG ASF! SSDT SLIC SSDT SSDT SSDT acpi0: wakeup devices LANC(S5) HDEF(S4) RP02(S5) WNIC(S5) RP03(S5) ECF0(S5) RP05(S5) ECF0(S5) RP06(S5) NIC_(S5) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) U6RM(S3) EHC1(S3) EHC2(S3) PCIB(S5) HST1(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (GenuineIntel 686-class) 2.10 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpiprt0 at acpi0: bus -1 (PEGP) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus 68 (RP05) acpiprt5 at acpi0: bus 133 (RP06) acpiprt6 at acpi0: bus 134 (PCIB) acpiprt7 at acpi0: bus 0 (PCI0) acpiec0 at acpi0 acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpipwrres0 at acpi0: APPR acpipwrres1 at acpi0: COMP acpipwrres2 at acpi0: LPP_ acpipwrres3 at acpi0: PFN6 acpipwrres4 at acpi0: PFN7 acpipwrres5 at acpi0: PFN8 acpipwrres6 at acpi0: PFN9 acpipwrres7 at acpi0: PFNA acpipwrres8 at acpi0: PFNB acpipwrres9 at acpi0: PGF0 acpitz0 at acpi0: critical temperature 108 degC acpipwrres10 at acpi0: PFN0 acpipwrres11 at acpi0: PFN1 acpipwrres12 at acpi0: PFN2 acpipwrres13 at acpi0: PFN3 acpipwrres14 at acpi0: PFN4 acpipwrres15 at acpi0: PFN5 acpitz1 at acpi0: critical temperature 105 degC acpitz2 at acpi0: critical temperature 108 degC acpitz3 at acpi0: critical temperature 105 degC acpitz4 at acpi0: critical temperature 108 degC acpitz5 at acpi0: critical temperature 110 degC acpibat0 at acpi0: BAT0 model Primary serial 02691 2009/06/24 type LIon oem Hewlett-Packard acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID_ acpivideo0 at acpi0: DGFX acpivideo1 at acpi0: GFX0 acpivout0 at acpivideo1: DD02 bios0: ROM list: 0xc/0xfe00! 0xd/0x1000 0xd1000/0x1000 cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2101, 2100, 1600, 1200 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel GM45 Host rev 0x07 vga1 at pci0 dev 2 function 0 Intel GM45 Video rev 0x07 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0x8000, size 0x1000 inteldrm0 at vga1: apic 1 int 16 (irq 10) drm0 at inteldrm0 Intel GM45 Video rev 0x07 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x03: apic 1 int 16 (irq 10) uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x03: apic 1 int 17 (irq 11) uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x03: apic 1 int 18 (irq 10) ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x03: apic 1 int 19 (irq 10) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801I HD Audio rev 0x03: apic 1 int 17 (irq 11) azalia0: codecs: Analog Devices AD1984A, Intel/0x2802, using Analog Devices AD1984A audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801I
macbook
Has anyone tried suspend/resume on macbook? If you have one of these things please send me the aml by doing: acpidump -o macbook_screensize pcidump -vv pcidump dmesg dmesg then tarring the files and mailing them to me.
acpi on newer laptops
This fixes the HP G62 laptops interrupt pegging issues and doesn't break
the Dell E6500.
Please test this on all acpi machines you have. I only want to know
about breakage and diffs between dmesg with and without this diff.
Test if you want this to make release!
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.176
diff -u -p -r1.176 dsdt.c
--- dsdt.c 28 Jul 2010 16:00:29 - 1.176
+++ dsdt.c 31 Jul 2010 21:38:02 -
@@ -1498,6 +1498,7 @@ char *aml_valid_osi[] = {
Windows 2001 SP3,
Windows 2001 SP4,
Windows 2006,
+ Windows 2009,
NULL
};
msi hardware
If you have an msi laptop/desktop with failing acpi please test this
diff. Only amd64 at this time.
I know, I know it is as ugly as ugly gets I just want to validate the
idea first.
Index: arch/amd64/include/smbiosvar.h
===
RCS file: /cvs/src/sys/arch/amd64/include/smbiosvar.h,v
retrieving revision 1.7
diff -u -p -r1.7 smbiosvar.h
--- arch/amd64/include/smbiosvar.h 15 Nov 2007 17:14:00 - 1.7
+++ arch/amd64/include/smbiosvar.h 31 Jul 2010 17:14:59 -
@@ -176,6 +176,28 @@ struct smbios_board {
u_int8_tnoc;/* number of contained objects */
} __packed;
+struct smbios_enclosure {
+ u_int8_tvendor; /* string */
+ u_int8_ttype;
+ u_int8_tversion;/* string */
+ u_int8_tserial; /* string */
+ u_int8_tasset_tag; /* string */
+ /* 2.1+ */
+ u_int8_tboot_state;
+ u_int8_tpsu_state;
+ u_int8_tthermal_state;
+ u_int8_tsecurity_status;
+ /* 2.3+ */
+ u_int16_t oem_defined;
+ u_int8_theight;
+ u_int8_tno_power_cords;
+ u_int8_tno_contained_element;
+ u_int8_treclen_contained_element;
+ u_int8_tcontained_elements;
+ /* 2.7+ */
+ u_int8_tsku;/* string */
+} __packed;
+
/*
* SMBIOS Structure Type 4 processor Information
* DMTF Specification DSP0134 v2.5 Section 3.3.5 p.g. 24
Index: dev/acpi/acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.40
diff -u -p -r1.40 acpiec.c
--- dev/acpi/acpiec.c 29 Jul 2010 18:32:26 - 1.40
+++ dev/acpi/acpiec.c 31 Jul 2010 21:49:14 -
@@ -23,6 +23,7 @@
#include sys/malloc.h
#include machine/bus.h
+#include machine/smbiosvar.h
#include dev/acpi/acpireg.h
#include dev/acpi/acpivar.h
@@ -32,6 +33,8 @@
#include sys/sensors.h
+#include bios.h
+
intacpiec_match(struct device *, void *, void *);
void acpiec_attach(struct device *, struct device *, void *);
@@ -91,7 +94,7 @@ const char *acpiec_hids[] = { ACPI_DEV_E
void
acpiec_wait(struct acpiec_softc *sc, u_int8_t mask, u_int8_t val)
{
- static int acpiecnowait;
+ static int acpiecnowait;
u_int8_tstat;
dnprintf(40, %s: EC wait_ns for: %b == %02x\n,
@@ -101,7 +104,10 @@ acpiec_wait(struct acpiec_softc *sc, u_i
while (((stat = acpiec_status(sc)) mask) != val) {
if (stat EC_STAT_SCI_EVT)
sc-sc_gotsci = 1;
- if (cold || (stat EC_STAT_BURST))
+
+ if (sc-sc_msi)
+ delay(550);
+ else if (cold || (stat EC_STAT_BURST))
delay(1);
else
tsleep(acpiecnowait, PWAIT, acpiec, 1);
@@ -263,6 +269,54 @@ acpiec_attach(struct device *parent, str
{
struct acpiec_softc *sc = (struct acpiec_softc *)self;
struct acpi_attach_args *aa = aux;
+
+#if NBIOS 0
+ charscratch[64];
+ struct smbtable tbl;
+ struct smbios_struct_bios *sb;
+ struct smbios_sys *sys;
+ struct smbios_enclosure *enc;
+ /* XXX move this into tables */
+
+ bzero(tbl, sizeof tbl);
+ if (smbios_find_table(SMBIOS_TYPE_BIOS, tbl)) {
+ sb = tbl.tblhdr;
+ if ((smbios_get_string(tbl, sb-vendor, scratch,
+ sizeof(scratch))) != NULL) {
+ if (!strcmp(scratch, Micro-Star)) {
+ sc-sc_msi = 1;
+ dnprintf(1, %s: quirked BIOS vendor %s,
+ DEVNAME(sc), scratch);
+ }
+ }
+ }
+
+ bzero(tbl, sizeof tbl);
+ if (smbios_find_table(SMBIOS_TYPE_SYSTEM, tbl)) {
+ sys = tbl.tblhdr;
+ if ((smbios_get_string(tbl, sys-vendor, scratch,
+ sizeof(scratch))) != NULL) {
+ if (!strcmp(scratch, Micro-Star)) {
+ sc-sc_msi = 1;
+ dnprintf(1, %s: quirked SYSTEM vendor %s,
+ DEVNAME(sc), scratch);
+ }
+ }
+ }
+
+ bzero(tbl, sizeof tbl);
+ if (smbios_find_table(SMBIOS_TYPE_ENCLOSURE, tbl)) {
+ enc = tbl.tblhdr;
+ if ((smbios_get_string(tbl, enc-vendor, scratch,
+ sizeof(scratch))) != NULL) {
+ if (!strcmp(scratch, MICRO-Star)) {
+ sc-sc_msi = 1;
+ dnprintf(1, %s: quirked ENCLOSURE vendor %s,
+
softraid using workq for VOP_STRATEGY
This converts softraid from scheduling IO in interrupt context to a
workq. It also kills most spl dances since we needed to protect the
queues with a mutex anyway.
I am testing this with RAID 0, 1, 5 6 + crypto but I really could use
some eyes on this and lots and lots of testing.
The failure paths for RAID 1, 4, 5 6 are especially suspect at this
point.
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.210
diff -u -p -r1.210 softraid.c
--- softraid.c 3 Jul 2010 03:04:55 - 1.210
+++ softraid.c 29 Jul 2010 20:37:32 -
@@ -571,16 +571,12 @@ void
sr_meta_save_callback(void *arg1, void *arg2)
{
struct sr_discipline*sd = arg1;
- int s;
-
- s = splbio();
if (sr_meta_save(arg1, SR_META_DIRTY))
printf(%s: save metadata failed\n,
DEVNAME(sd-sd_sc));
sd-sd_must_flush = 0;
- splx(s);
}
int
@@ -1637,12 +1633,14 @@ sr_ccb_alloc(struct sr_discipline *sd)
sd-sd_ccb = malloc(sizeof(struct sr_ccb) *
sd-sd_max_wu * sd-sd_max_ccb_per_wu, M_DEVBUF, M_WAITOK | M_ZERO);
+ mtx_enter(sd-sd_mtx); /* need this for sr_ccb_put */
TAILQ_INIT(sd-sd_ccb_freeq);
for (i = 0; i sd-sd_max_wu * sd-sd_max_ccb_per_wu; i++) {
ccb = sd-sd_ccb[i];
ccb-ccb_dis = sd;
sr_ccb_put(ccb);
}
+ mtx_leave(sd-sd_mtx);
DNPRINTF(SR_D_CCB, %s: sr_ccb_alloc ccb: %d\n,
DEVNAME(sd-sd_sc), sd-sd_max_wu * sd-sd_max_ccb_per_wu);
@@ -1660,8 +1658,10 @@ sr_ccb_free(struct sr_discipline *sd)
DNPRINTF(SR_D_CCB, %s: sr_ccb_free %p\n, DEVNAME(sd-sd_sc), sd);
+ mtx_enter(sd-sd_mtx);
while ((ccb = TAILQ_FIRST(sd-sd_ccb_freeq)) != NULL)
TAILQ_REMOVE(sd-sd_ccb_freeq, ccb, ccb_link);
+ mtx_leave(sd-sd_mtx);
if (sd-sd_ccb)
free(sd-sd_ccb, M_DEVBUF);
@@ -1671,9 +1671,8 @@ struct sr_ccb *
sr_ccb_get(struct sr_discipline *sd)
{
struct sr_ccb *ccb;
- int s;
- s = splbio();
+ MUTEX_ASSERT_LOCKED(sd-sd_mtx);
ccb = TAILQ_FIRST(sd-sd_ccb_freeq);
if (ccb) {
@@ -1681,8 +1680,6 @@ sr_ccb_get(struct sr_discipline *sd)
ccb-ccb_state = SR_CCB_INPROGRESS;
}
- splx(s);
-
DNPRINTF(SR_D_CCB, %s: sr_ccb_get: %p\n, DEVNAME(sd-sd_sc),
ccb);
@@ -1693,21 +1690,18 @@ void
sr_ccb_put(struct sr_ccb *ccb)
{
struct sr_discipline*sd = ccb-ccb_dis;
- int s;
+
+ MUTEX_ASSERT_LOCKED(sd-sd_mtx);
DNPRINTF(SR_D_CCB, %s: sr_ccb_put: %p\n, DEVNAME(sd-sd_sc),
ccb);
- s = splbio();
-
ccb-ccb_wu = NULL;
ccb-ccb_state = SR_CCB_FREE;
ccb-ccb_target = -1;
ccb-ccb_opaque = NULL;
TAILQ_INSERT_TAIL(sd-sd_ccb_freeq, ccb, ccb_link);
-
- splx(s);
}
int
@@ -1726,13 +1720,15 @@ sr_wu_alloc(struct sr_discipline *sd)
return (1);
no_wu = sd-sd_max_wu;
- sd-sd_wu_pending = no_wu;
sd-sd_wu = malloc(sizeof(struct sr_workunit) * no_wu,
M_DEVBUF, M_WAITOK | M_ZERO);
+ mtx_enter(sd-sd_mtx);
+ sd-sd_wu_pending = no_wu;
TAILQ_INIT(sd-sd_wu_freeq);
TAILQ_INIT(sd-sd_wu_pendq);
TAILQ_INIT(sd-sd_wu_defq);
+ mtx_leave(sd-sd_mtx);
for (i = 0; i no_wu; i++) {
wu = sd-sd_wu[i];
wu-swu_dis = sd;
@@ -1752,12 +1748,14 @@ sr_wu_free(struct sr_discipline *sd)
DNPRINTF(SR_D_WU, %s: sr_wu_free %p\n, DEVNAME(sd-sd_sc), sd);
+ mtx_enter(sd-sd_mtx);
while ((wu = TAILQ_FIRST(sd-sd_wu_freeq)) != NULL)
TAILQ_REMOVE(sd-sd_wu_freeq, wu, swu_link);
while ((wu = TAILQ_FIRST(sd-sd_wu_pendq)) != NULL)
TAILQ_REMOVE(sd-sd_wu_pendq, wu, swu_link);
while ((wu = TAILQ_FIRST(sd-sd_wu_defq)) != NULL)
TAILQ_REMOVE(sd-sd_wu_defq, wu, swu_link);
+ mtx_leave(sd-sd_mtx);
if (sd-sd_wu)
free(sd-sd_wu, M_DEVBUF);
@@ -1769,12 +1767,8 @@ sr_wu_put(struct sr_workunit *wu)
struct sr_discipline*sd = wu-swu_dis;
struct sr_ccb *ccb;
- int s;
-
DNPRINTF(SR_D_WU, %s: sr_wu_put: %p\n, DEVNAME(sd-sd_sc), wu);
- s = splbio();
-
wu-swu_xs = NULL;
wu-swu_state = SR_WU_FREE;
wu-swu_ios_complete = 0;
@@ -1787,6 +1781,7 @@ sr_wu_put(struct sr_workunit *wu)
wu-swu_fake = 0;
wu-swu_flags = 0;
+ mtx_enter(sd-sd_mtx);
while ((ccb = TAILQ_FIRST(wu-swu_ccb)) != NULL) {
TAILQ_REMOVE(wu-swu_ccb, ccb, ccb_link);
sr_ccb_put(ccb);
@@ -1804,17 +1799,15 @@ sr_wu_put(struct sr_workunit *wu)
if
Re: [heads up] xserver 1.8 in snapshots
This helps but the mouse isn't as responsive as it used to be.
On Sun, Jul 25, 2010 at 10:11:11PM +, Miod Vallat wrote:
This is due to revision 1.3 of sys/dev/pckbc/pms_intelli.c,
reverting it back to 1.2 fixes the problem.
Does the following diff help?
Miod
Index: pms_intelli.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms_intelli.c,v
retrieving revision 1.3
diff -u -p -r1.3 pms_intelli.c
--- pms_intelli.c 24 Jul 2010 10:35:34 - 1.3
+++ pms_intelli.c 25 Jul 2010 22:10:33 -
@@ -77,27 +77,31 @@ const struct wsmouse_accessops pmsi_acce
pmsi_disable,
};
-static int pmsi_setintellimode(pckbc_tag_t, pckbc_slot_t);
+int pmsi_setintellimode(pckbc_tag_t, pckbc_slot_t, int);
-static int
-pmsi_setintellimode(tag, slot)
- pckbc_tag_t tag;
- pckbc_slot_t slot;
+int
+pmsi_setintellimode(pckbc_tag_t tag, pckbc_slot_t slot, int poll)
{
u_char cmd[2], resp[1];
int i, res;
- static u_char rates[] = {200, 100, 80};
+ static const u_char rates[] = {200, 100, 80};
cmd[0] = PMS_SET_SAMPLE;
for (i = 0; i 3; i++) {
cmd[1] = rates[i];
- res = pckbc_poll_cmd(tag, slot, cmd, 2, 0, NULL, 0);
+ if (poll)
+ res = pckbc_poll_cmd(tag, slot, cmd, 2, 0, NULL, 0);
+ else
+ res = pckbc_enqueue_cmd(tag, slot, cmd, 2, 0, 0, NULL);
if (res)
return (res);
}
cmd[0] = PMS_SEND_DEV_ID;
- res = pckbc_poll_cmd(tag, slot, cmd, 1, 1, resp, 0);
+ if (poll)
+ res = pckbc_poll_cmd(tag, slot, cmd, 1, 1, resp, 0);
+ else
+ res = pckbc_enqueue_cmd(tag, slot, cmd, 1, 1, 0, resp);
if (res)
return (res);
if (resp[0] != 3)
@@ -144,7 +148,7 @@ pmsiprobe(parent, match, aux)
return (0);
}
- if ((res = pmsi_setintellimode(pa-pa_tag, pa-pa_slot))) {
+ if ((res = pmsi_setintellimode(pa-pa_tag, pa-pa_slot, 1))) {
#ifdef DEBUG
printf(pmsiprobe: intellimode - %d\n, res);
#endif
@@ -182,7 +186,7 @@ pmsiattach(parent, self, aux)
return;
}
#endif
- res = pmsi_setintellimode(pa-pa_tag, pa-pa_slot);
+ res = pmsi_setintellimode(pa-pa_tag, pa-pa_slot, 1);
#ifdef DEBUG
if (res) {
printf(pmsiattach: error setting intelli mode\n);
@@ -257,14 +261,14 @@ pmsi_change_state(struct pmsi_softc *sc,
cmd, 1, 2, resp, 1);
#ifdef DEBUG
if (res || resp[0] != PMS_RSTDONE || resp[1] != 0) {
- printf(pmsiattach: reset error\n);
+ printf(pmsi_change_state: reset error\n);
return;
}
#endif
- res = pmsi_setintellimode(sc-sc_kbctag, sc-sc_kbcslot);
+ res = pmsi_setintellimode(sc-sc_kbctag, sc-sc_kbcslot, 0);
#ifdef DEBUG
if (res) {
- printf(pmsiattach: error setting intelli mode\n);
+ printf(pmsi_change_state: error setting intelli
mode\n);
return;
}
#endif
@@ -273,18 +277,17 @@ pmsi_change_state(struct pmsi_softc *sc,
res = pckbc_enqueue_cmd(sc-sc_kbctag, sc-sc_kbcslot,
cmd, 1, 0, 1, 0);
if (res)
- printf(pmsi_enable: command error\n);
+ printf(pmsi_change_state: command error\n);
sc-sc_state = newstate;
break;
case PMSI_STATE_DISABLED:
-
/* FALLTHROUGH */
case PMSI_STATE_SUSPENDED:
cmd[0] = PMS_DEV_DISABLE;
res = pckbc_enqueue_cmd(sc-sc_kbctag, sc-sc_kbcslot,
cmd, 1, 0, 1, 0);
if (res)
- printf(pmsi_disable: command error\n);
+ printf(pmsi_change_state: command error\n);
pckbc_slot_enable(sc-sc_kbctag, sc-sc_kbcslot, 0);
sc-sc_state = newstate;
break;
Re: Patch for bogus pointer arithmetic in adw(4)
On Wed, Jun 23, 2010 at 12:20:09AM +0200, Marc Espie wrote: On Tue, Jun 22, 2010 at 06:53:12PM +, Miod Vallat wrote: Is there any reson you use bcopy() not memcpy()? If not considder using memcpy() please. :) We couldn't care what you believe, unless you have diffs of your own to submit. I think the guy there asked if there is any difference, it was just that. I also don't know bcopy() and would like to know just out of curiosity (I'm really don't know, isn't not an irony): there's some difference between bcopy() and memcpy()? Yes, the order of the arguments. bcopy is intuitive: since you copy FROM somewhere TO somewhere, the arguments are FROM, TO, LENGTH. memcpy has FROM and TO exchanged, which is stupid. Some people argue this is because it is similar to an assignment, where you write DEST = SRC. But function calls are hardly assignments in my book. Err. shame on strcpy on being dest, src ? Totally. Why don't you compaign to have miodstrlcpy( ) ? I'll switch tomorrow! miod is 100% right. memcpy is another committee hit job on practicality. OMG bcopy wasn't invented here lets flip around the parameters foar moar bettarone!!!```~!~!Y~%!^%
Re: Try this patch.. HP Laptop Panic
Did it work? On Sat, Jun 19, 2010 at 02:41:10PM +0200, Jan Johansson wrote: jor...@peereboom.us wrote: This patch is for an issue seen with ACPI on a HP Laptop but wanted to get some additional testing done. Some debugging prints in for now. Had some problem with the last hunk but applied it manually cvs diff is at the bottom for verification. For more info on the machine see PR 6379 or send me a note. OpenBSD 4.7-current (GENERIC.MP) #0: Sat Jun 19 11:33:25 CEST 2010 j...@tuvok.wenf.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM real mem = 1047818240 (999MB) avail mem = 1005146112 (958MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/04/08, BIOS32 rev. 0 @ 0xf, SMBIOS rev. 2.4 @ 0xf3253 (27 entries) bios0: vendor Hewlett-Packard version 68MCU Ver. F.17 date 11/04/2008 bios0: Hewlett-Packard HP Compaq 6910p acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SLIC HPET APIC MCFG TCPA ASF! SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices C0B0(S5) C108(S3) C10F(S3) C110(S3) C111(S3) C119(S3) C11A(S3) C11B(S3) C131(S5) C2A7(S5) C132(S5) C2A8(S5) C134(S5) C2A8(S5) C137(S0) C23D(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz (GenuineIntel 686-class) 2 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 copy objref: 5b12 \\_OSI MULTI: \\_SB_.C3C3.C3CD.C3CE acpiprt0 at acpi0: bus 2 (C0B0) acpiprt1 at acpi0: bus 8 (C11D) acpiprt2 at acpi0: bus 16 (C131) acpiprt3 at acpi0: bus 40 (C134) acpiprt4 at acpi0: bus 0 (C003) acpiec0 at acpi0 acpicpu0 at acpi0MULTI: \\_PR_.CPU0._OSC.UID0 MULTI: \\_PR_.CPU0._OSC.UID0 : C3, C2, C1, PSS acpicpu1 at acpi0MULTI: \\_PR_.CPU1._OSC.UID1 MULTI: \\_PR_.CPU1._OSC.UID1 : C3, C2, C1, PSS acpipwrres0 at acpi0: C272 acpipwrres1 at acpi0: C27A acpipwrres2 at acpi0: C281 acpipwrres3 at acpi0: C29D acpipwrres4 at acpi0: C1C5 acpipwrres5 at acpi0: C3B9 acpipwrres6 at acpi0: C3BA acpipwrres7 at acpi0: C3BB acpipwrres8 at acpi0: C3BC acpipwrres9 at acpi0: C3BD acpitz0 at acpi0: critical temperature 105 degC acpitz1 at acpi0: critical temperature 105 degC acpitz2 at acpi0: critical temperature 110 degC acpitz3 at acpi0: critical temperature 256 degC acpitz4 at acpi0: critical temperature 105 degC acpibat0 at acpi0: C23B model Primary serial 36496 2024/12/16 type LIon oem Hewlett-Packard acpibat1 at acpi0: C23A not present acpiac0 at acpi0: AC unit offline acpibtn0 at acpi0: C2BB acpibtn1 at acpi0: C153 acpivideo0 at acpi0: C098 copy objref: 5b12 \\_SB_.C003.C098.C1AC acpivout0 at acpivideo0: C1AD acpivout1 at acpivideo0: C1B2 acpivout2 at acpivideo0: C1B3 acpivout3 at acpivideo0: C1B4 bios0: ROM list: 0xc/0xee00! cpu0: Enhanced SpeedStep 1996 MHz: speeds: 2001, 2000, 1600, 1200, 800 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel GM965 Host rev 0x0c vga1 at pci0 dev 2 function 0 Intel GM965 Video rev 0x0c wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1: apic 1 int 16 (irq 10) drm0 at inteldrm0 Intel GM965 Video rev 0x0c at pci0 dev 2 function 1 not configured vendor Intel, unknown product 0x2a04 (class communications subclass miscellaneous, rev 0x0c) at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 Intel GM965 PT IDER rev 0x0c: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 (irq 11) for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) Intel GM965 KT rev 0x0c at pci0 dev 3 function 3 not configured em0 at pci0 dev 25 function 0 Intel ICH8 IGP M AMT rev 0x03: apic 1 int 22 (irq 11), address 00:1b:38:95:e7:c6 uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x03: apic 1 int 16 (irq 10) uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x03: apic 1 int 17 (irq 10) ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x03: apic 1 int 18 (irq 11) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev
Re: possible fix to races in ami(4)
And make sure the hotspare kicks in. You HAVE to create the hotspare
under heavy io.
On Tue, Jun 01, 2010 at 11:09:53AM +1000, David Gwynne wrote:
you cant test a variable and then sleep on it without blocking
interrupts, cos a completion could change the variables state between
those two actions.
could anyone test setting a hotspare on ami(4) while doing io?
dlg
Index: ami.c
===
RCS file: /cvs/src/sys/dev/ic/ami.c,v
retrieving revision 1.204
diff -u -p ami.c
--- ami.c 20 May 2010 00:55:17 - 1.204
+++ ami.c 31 May 2010 12:42:47 -
@@ -186,11 +186,8 @@ ami_remove_runq(struct ami_ccb *ccb)
splassert(IPL_BIO);
TAILQ_REMOVE(ccb-ccb_sc-sc_ccb_runq, ccb, ccb_link);
- if (TAILQ_EMPTY(ccb-ccb_sc-sc_ccb_runq)) {
- ccb-ccb_sc-sc_drained = 1;
- if (ccb-ccb_sc-sc_drainio)
- wakeup(ccb-ccb_sc);
- }
+ if (ccb-ccb_sc-sc_drainio TAILQ_EMPTY(ccb-ccb_sc-sc_ccb_runq))
+ wakeup(ccb-ccb_sc);
}
void
@@ -198,7 +195,6 @@ ami_insert_runq(struct ami_ccb *ccb)
{
splassert(IPL_BIO);
- ccb-ccb_sc-sc_drained = 0;
TAILQ_INSERT_TAIL(ccb-ccb_sc-sc_ccb_runq, ccb, ccb_link);
}
@@ -539,7 +535,6 @@ ami_attach(struct ami_softc *sc)
/* error already printed */
goto free_mbox;
}
- sc-sc_drained = 1;
/* hack for hp netraid version encoding */
if ('A' = sc-sc_fwver[2] sc-sc_fwver[2] = 'Z'
@@ -1016,7 +1011,6 @@ ami_runqueue(struct ami_softc *sc)
while ((ccb = TAILQ_FIRST(sc-sc_ccb_preq)) != NULL) {
if (sc-sc_exec(sc, ccb-ccb_cmd) != 0) {
- /* this is now raceable too with other incoming io */
timeout_add(sc-sc_run_tmo, 1);
break;
}
@@ -1895,10 +1889,8 @@ ami_mgmt(struct ami_softc *sc, u_int8_t opcode, u_int8
goto err;
}
ccb-ccb_done = ami_done_ioctl;
- } else {
+ } else
ccb = sc-sc_mgmtccb;
- ccb-ccb_done = ami_done_dummy;
- }
if (size) {
if ((am = ami_allocmem(sc, size)) == NULL) {
@@ -1930,22 +1922,29 @@ ami_mgmt(struct ami_softc *sc, u_int8_t opcode, u_int8
if (opcode != AMI_CHSTATE) {
ami_start(sc, ccb);
+ s = splbio();
while (ccb-ccb_state != AMI_CCB_READY)
tsleep(ccb, PRIBIO,ami_mgmt, 0);
+ splx(s);
} else {
/* change state must be run with id 0xfe and MUST be polled */
+ s = splbio();
sc-sc_drainio = 1;
- while (sc-sc_drained != 1)
+ while (!TAILQ_EMPTY(sc-sc_ccb_runq)) {
if (tsleep(sc, PRIBIO, ami_mgmt_drain, hz * 60) ==
EWOULDBLOCK) {
printf(%s: drain io timeout\n, DEVNAME(sc));
ccb-ccb_flags |= AMI_CCB_F_ERR;
goto restartio;
}
- ami_poll(sc, ccb);
+ }
+
+ error = sc-sc_poll(sc, ccb-ccb_cmd);
+ if (error == -1)
+ ccb-ccb_flags |= AMI_CCB_F_ERR;
+
restartio:
/* restart io */
- s = splbio();
sc-sc_drainio = 0;
ami_runqueue(sc);
splx(s);
@@ -1966,7 +1965,6 @@ memerr:
} else {
ccb-ccb_flags = 0;
ccb-ccb_state = AMI_CCB_FREE;
- ccb-ccb_done = NULL;
}
err:
Index: amivar.h
===
RCS file: /cvs/src/sys/dev/ic/amivar.h,v
retrieving revision 1.54
diff -u -p amivar.h
--- amivar.h 28 Oct 2008 11:43:10 - 1.54
+++ amivar.h 31 May 2010 12:42:47 -
@@ -149,7 +149,6 @@ struct ami_softc {
charsc_plist[AMI_BIG_MAX_PDRIVES];
struct ami_ccb *sc_mgmtccb;
- int sc_drained;
int sc_drainio;
u_int8_tsc_drvinscnt;
};
Re: (another) Intel driver change needs testing.
(==) intel(0): Intel XvMC decoder enabled (II) intel(0): Set up textured video (II) intel(0): [XvMC] xvmc_vld driver initialized. (II) intel(0): direct rendering: DRI2 Enabled groovy,... up to the second amd64 on gcc4. On Mon, May 17, 2010 at 10:16:54PM +0100, Owain Ainsworth wrote: The diff found at http://xenocara.org/xvmc.diff could do with some testing. This is some stuff that I didn't backport back to 2.9.1 when I did the intial intel driver backport pile. This contains a huge cleanup of the XVMC code (and enabled it on 965+ by default, it is still there by an option on lower). Otherwise there are a few small changes, but the vast majority of it is xvmc. With this the intel driver renderer is equal to just after intel 2.11 upstream. Please test and report to myself and matthieu@, good feedback or bad, when i've got this and one more thing out of the way I plan to work on radeon dri2. For those of you new here, or termnally adsent minded, instructions follow: make sure your xenocara tree is up to date. $ cd /usr/xenocara/driver/xf86-video-intel $ patch -E /path/to/xvmc.diff $ make -f Makefile.bsd-wrapper obj $ make -f Makefile.bsd-wrapper build restart X and robert is your mother's brother. Cheers, -0- -- Abstainer, n.: A weak person who yields to the temptation of denying himself a pleasure. -- Ambrose Bierce, The Devil's Dictionary
Re: Source Overview
On Mon, Apr 19, 2010 at 11:48:02AM -0400, Adam M. Dutko wrote: On Mon, Apr 19, 2010 at 10:57 AM, Bret S. Lambert blamb...@openbsd.orgwrote: ... snip ... Hopefully this is useful for somebody. It is, thank you. With regard to the other questions I peppered everyone with... :-) 1) Are there areas that are easier for relative newbies to start in versus other areas? I know this depends on a lot of things, to include experience. Hypothetically, someone that has some C experience, but not a lot of kernel (and subsystem) experience. Is it better to start from the bottom up like bootstrap to init? or is it better to start with memory management? network drivers? What is usually the best area from a learning and future utility perspective? Only you can determine that so pick an area you are interested in and simply start hacking on it. 2) Is there something like an openbsd janitors project where newbies can start contributing small patches? similar to the Linux janitors project? Janitor is actually a very hard task that requires in-depth knowledge of many sub-systems and is therefore not a good n00b starting point. Thanks again.
Re: Completing softraid support (sparc/sparc64 ramdisk)
if we are dropping bioctl then we might as well drop CRYPTO. You really one with the other. On Mon, Apr 19, 2010 at 09:05:43PM +0200, David Coppa wrote: On Mon, Apr 19, 2010 at 8:57 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Mon, 19 Apr 2010 07:05:53 +0200 From: David Coppa dco...@gmail.com Hi, This diff adds missing bits for softraid support into sparc/sparc64 ramdisks. Tested on my Blade 150, bsd.rd didn't overflow. Comments? OKs? For sparc64, I think we shouldn't add bioctl this to ramdisk/list and ramdiskB/list. These are floppy images and space is a bit tight. Besides, you didn't add CRYPTO to RAMDISKU1 and RAMDISKU5, so it wouldn't be terribly useful anyway. I'll remove sbin/bioctl from ramdisk/list and ramdiskB/list And you'll need to test the sparc bits (or drop them). Cannot test since i don't have a sparc machine available: so I'll drop these too. ok?
Re: ahci(4) Intel RAID mode pci ids diff.
RAID ids should not be added at this time until a better decision is made. On Fri, Apr 16, 2010 at 04:50:39PM -0400, Brad wrote: On Wednesday 07 April 2010 20:16:54 Brad wrote: On Wednesday 07 April 2010 05:50:51 Mark Kettenis wrote: Meanwhile, we probably should not add these RAID IDs to the ahci(4) driver (and remove the ones that are already there). That makes sure that there is no risk we accidentally overwrite the Intel-specific metadata on these disks. People simply have to flip the controller back in AHCI mode to access their disks (taking the hopefully conscious decision to destroy any existing RAID volumes). I have no issue which way this goes as long as there is consistency. Either add all of the ids or add none of them. There still has not been any decision made as to which direction this is going in... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: ahci(4) Intel RAID mode pci ids diff.
They should. On Apr 16, 2010, at 4:01 PM, Brad b...@comstyle.com wrote: - Original message - RAID ids should not be added at this time until a better decision is made. and the 3 ids that have been added have not been removed yet. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: ahci(4) Intel RAID mode pci ids diff.
On Wed, Apr 07, 2010 at 11:50:51AM +0200, Mark Kettenis wrote:
Date: Tue, 6 Apr 2010 21:39:48 -0500
From: Marco Peereboom sl...@peereboom.us
Why?
RAID mode is NOT a valid ID for ahci.
Actually, it is. The hardware works exactly the same way if the
controller is in RAID mode or in AHCI. The different PCI ID acts
simply as a flag to indicate that the disks behind the controller
might contain metadata for one of the propriatery Intel software RAID
solutions. I guess it makes sure that Windows loads a different
driver that understands that metadata format instead of loading the
generic AHCI driver that would overwrite the metadata and destroy any
RAID volumes behind it. Oh, and the BIOS probably knows how to boot
from these RAID volumes as well. Note that I say *might* contain
metadata here; only when you actually create a RAID volume (through
the BIOS or other tools) the metadata will be actually there. I don't
know how Windows treats blank disks behind such a controller in RAID
mode.
Now to the question how OpenBSD should treat these controllers in RAID
mode. Ideally softraid would understand the Intel metadata format and
do the right thing. For that to work, these RAID ID's will have to be
added to the ahci(4) driver, otherwise softraid will not have access
to the disks that form the RAID volume and can't do its thing.
Perhaps some infrastructure is needed to communicate the fact that
disks are in RAID mode with softraid, such that softraid doesn't have
to check for a zillion of metadata formats. I can imagine though that
adding support for the Intel metdata format to softraid is not a
terribly high priority. Doing so really only makes sense if you want
to share the volume with Windows, otherwise you're probably much
better off using plain softraid on these disks (assuming booting from
plain softraid works).
Meanwhile, we probably should not add these RAID IDs to the ahci(4)
driver (and remove the ones that are already there). That makes sure
that there is no risk we accidentally overwrite the Intel-specific
metadata on these disks. People simply have to flip the controller
back in AHCI mode to access their disks (taking the hopefully
conscious decision to destroy any existing RAID volumes).
You said it in many more words but this reflects exactly my sentiment.
Until we can ignore disks in RAID mode in ahci we should not add them.
On Tue, Apr 06, 2010 at 09:09:47PM -0400, Brad wrote:
On Mon, Mar 15, 2010 at 10:19:18PM -0400, Brad wrote:
The following diff adds the remaining PCI ids for the Intel AHCI
controllers with a RAID mode to the existing ICH8 / ICH10 PCI ids.
Add the Intel ICH7 (82801GHM / GR), ICH9 (82801I) and ICH10 (82801JD),
6321ESB and PCH (3400) RAID mode PCI ids.
Updated for the latest rev of ahci.c.
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.161
diff -u -p -r1.161 ahci.c
--- ahci.c6 Apr 2010 13:59:37 - 1.161
+++ ahci.c7 Apr 2010 00:40:18 -
@@ -440,11 +440,25 @@ static const struct ahci_device ahci_dev
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_1,
NULL, ahci_ati_sb600_attach },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_1,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_2,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_1,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_2,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GHM_RAID,
+ NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GR_RAID,
NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801H_RAID,
NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_RAID,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JD_RAID,
NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JI_RAID,
NULL, NULL },
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: ahci(4) Intel RAID mode pci ids diff.
Why?
RAID mode is NOT a valid ID for ahci.
On Tue, Apr 06, 2010 at 09:09:47PM -0400, Brad wrote:
On Mon, Mar 15, 2010 at 10:19:18PM -0400, Brad wrote:
The following diff adds the remaining PCI ids for the Intel AHCI
controllers with a RAID mode to the existing ICH8 / ICH10 PCI ids.
Add the Intel ICH7 (82801GHM / GR), ICH9 (82801I) and ICH10 (82801JD),
6321ESB and PCH (3400) RAID mode PCI ids.
Updated for the latest rev of ahci.c.
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.161
diff -u -p -r1.161 ahci.c
--- ahci.c6 Apr 2010 13:59:37 - 1.161
+++ ahci.c7 Apr 2010 00:40:18 -
@@ -440,11 +440,25 @@ static const struct ahci_device ahci_dev
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_1,
NULL, ahci_ati_sb600_attach },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_1,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_2,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_1,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_2,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GHM_RAID,
+ NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GR_RAID,
NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801H_RAID,
NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_RAID,
+ NULL, NULL },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JD_RAID,
NULL, NULL },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JI_RAID,
NULL, NULL },
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: mpii enchancements
This is fine but how will you deal with dynamic disks?
That's the diff I still have in my mail from you...
On Mon, Mar 01, 2010 at 07:52:33PM +0300, Mike Belopuhov wrote:
On Tue, Feb 09, 2010 at 19:48 +0300, Mike Belopuhov wrote:
On Tue, Feb 09, 2010 at 10:41 -0600, Marco Peereboom wrote:
I talked to Jim and he and I had exactly the same comments. We love
this minus the numbers you pull out of an orifice ;-)
To be exact:
- sc-sc_reply_post_qdepth = 128;
- sc-sc_request_depth = 128;
- sc-sc_num_reply_frames = 63;
- sc-sc_reply_free_qdepth = 64;
+ sc-sc_reply_post_qdepth = 8192;
+ sc-sc_request_depth = 1024;
+ sc-sc_num_reply_frames = 1151;
+ sc-sc_reply_free_qdepth = 1152;
Both choices are bad. This needs to come from the firmware and not made
up as we do now. Jim's values are conservative, yours are probably ok
for *your* chip but no telling about others. I think the port facts
pages has these.
I can go ahead and commit the rest. Agree?
of course! calculation code above that should be used/fixed anyway.
Hi,
Calculation code is actually fine. openings was incorrect, resulting
in the dead slow performance.
With this diff i get ~130Mb/s write performace on the RAID1 w/ 15K RPM
SAS drives, which is twice i got with the request value cranked up to
the 1024.
The idea is that openings are treated as an amount of possible
outstanding requests in the scsi subsystem. mpii was using a value
of total maximum number of devices you can actually attach, but
that's far from the reality, which is the number of physical disks
and volumes present.
Cheers,
Mike
Index: mpii.c
===
RCS file: /cvs/src/sys/dev/pci/mpii.c,v
retrieving revision 1.9
diff -N -u -p -u -p mpii.c
--- mpii.c25 Feb 2010 02:05:41 - 1.9
+++ mpii.c1 Mar 2010 16:42:42 -
@@ -1757,8 +1757,7 @@ uint32_t mpii_debug = 0
*/
#define MPII_MAX_SGL (32)
-#define MPII_MAX_REQUEST_CREDIT (500)
-#define MPII_MAX_REPLY_POST_QDEPTH (128)
+#define MPII_MAX_REQUEST_CREDIT (128)
struct mpii_dmamem {
bus_dmamap_tmdm_map;
@@ -2375,7 +2374,8 @@ mpii_attach(struct mpii_softc *sc)
sc-sc_link.adapter_softc = sc;
sc-sc_link.adapter_target = sc-sc_target;
sc-sc_link.adapter_buswidth = sc-sc_max_devices;
- sc-sc_link.openings = sc-sc_request_depth / sc-sc_max_devices;
+ sc-sc_link.openings = sc-sc_request_depth / (sc-sc_pd_count +
+ sc-sc_vd_count);
bzero(saa, sizeof(saa));
saa.saa_sc_link = sc-sc_link;
@@ -3037,23 +3037,11 @@ mpii_iocfacts(struct mpii_softc *sc)
sc-sc_reply_post_qdepth = sc-sc_request_depth +
sc-sc_num_reply_frames + 1;
- if (sc-sc_reply_post_qdepth MPII_MAX_REPLY_POST_QDEPTH)
- sc-sc_reply_post_qdepth = MPII_MAX_REPLY_POST_QDEPTH;
-
if (sc-sc_reply_post_qdepth
ifp.max_reply_descriptor_post_queue_depth)
sc-sc_reply_post_qdepth =
ifp.max_reply_descriptor_post_queue_depth;
- /* XXX JPG temporary override of calculated values.
- * need to think this through as the specs
- * and other existing drivers contradict
- */
- sc-sc_reply_post_qdepth = 128;
- sc-sc_request_depth = 128;
- sc-sc_num_reply_frames = 63;
- sc-sc_reply_free_qdepth = 64;
-
DNPRINTF(MPII_D_MISC, %s: sc_request_depth: %d
sc_num_reply_frames: %d sc_reply_free_qdepth: %d
sc_reply_post_qdepth: %d\n, DEVNAME(sc), sc-sc_request_depth,
Re: mpii enchancements
I talked to Jim and he and I had exactly the same comments. We love
this minus the numbers you pull out of an orifice ;-)
To be exact:
- sc-sc_reply_post_qdepth = 128;
- sc-sc_request_depth = 128;
- sc-sc_num_reply_frames = 63;
- sc-sc_reply_free_qdepth = 64;
+ sc-sc_reply_post_qdepth = 8192;
+ sc-sc_request_depth = 1024;
+ sc-sc_num_reply_frames = 1151;
+ sc-sc_reply_free_qdepth = 1152;
Both choices are bad. This needs to come from the firmware and not made
up as we do now. Jim's values are conservative, yours are probably ok
for *your* chip but no telling about others. I think the port facts
pages has these.
I can go ahead and commit the rest. Agree?
On Mon, Feb 08, 2010 at 07:13:36PM +0300, Mike Belopuhov wrote:
Good day,
the following diff...
- implements bioctl support;
- fixes hot-un-plugging w/ softeps;
- improves performance;
- fixes IPL levels;
- fixes lots of small things;
- does a little bit of cleanup;
- fixes NOWAIT/WAITOK;
- disables useless/unused Driver Persistent Mapping code that prevents
driver to work properly on our board;
- maybe something else.
I thought about splitting it up in several pieces, but then I thought:
What the heck! Lets beat the devil out of it!
Enjoy and be merry.
Index: mpii.c
===
RCS file: /mount/cvsdev/cvs/openbsd/src/sys/dev/pci/mpii.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 mpii.c
--- mpii.c1 Dec 2009 00:09:03 - 1.5
+++ mpii.c8 Feb 2010 15:51:40 -
@@ -30,6 +30,7 @@
#include sys/kernel.h
#include sys/rwlock.h
#include sys/sensors.h
+#include sys/tree.h
#include machine/bus.h
@@ -1019,7 +1020,6 @@ struct mpii_cfg_hdr {
#define MPII_CONFIG_REQ_PAGE_TYPE_MANUFACTURING (0x09)
#define MPII_CONFIG_REQ_PAGE_TYPE_RAID_PD(0x0a)
#define MPII_CONFIG_REQ_PAGE_TYPE_EXTENDED (0x0f)
-#define MPII_CONFIG_REQ_PAGE_TYPE_DRIVER_MAPPING (0x17)
} __packed;
struct mpii_ecfg_hdr {
@@ -1030,6 +1030,9 @@ struct mpii_ecfg_hdr {
u_int16_t ext_page_length;
u_int8_text_page_type;
+#define MPII_CONFIG_REQ_PAGE_TYPE_SAS_DEVICE (0x12)
+#define MPII_CONFIG_REQ_PAGE_TYPE_RAID_CONFIG(0x16)
+#define MPII_CONFIG_REQ_PAGE_TYPE_DRIVER_MAPPING (0x17)
u_int8_treserved2;
} __packed;
@@ -1269,52 +1272,45 @@ struct mpii_cfg_fc_device_pg0 {
u_int8_tcurrent_bus;
} __packed;
+#define MPII_CFG_RAID_VOL_ADDR_HANDLE(128)
+
struct mpii_cfg_raid_vol_pg0 {
struct mpii_cfg_hdr config_header;
- u_int8_tvolume_id;
- u_int8_tvolume_bus;
- u_int8_tvolume_ioc;
+ u_int16_t volume_handle;
+ u_int8_tvolume_state;
+#define MPII_CFG_RAID_VOL_0_STATE_MISSING(0x00)
+#define MPII_CFG_RAID_VOL_0_STATE_FAILED (0x01)
+#define MPII_CFG_RAID_VOL_0_STATE_INITIALIZING (0x02)
+#define MPII_CFG_RAID_VOL_0_STATE_ONLINE (0x03)
+#define MPII_CFG_RAID_VOL_0_STATE_DEGRADED (0x04)
+#define MPII_CFG_RAID_VOL_0_STATE_OPTIMAL(0x05)
u_int8_tvolume_type;
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID0 (0x00)
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID1E (0x01)
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID1 (0x02)
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID10 (0x05)
+#define MPII_CFG_RAID_VOL_0_TYPE_UNKNOWN (0xff)
- u_int8_tvolume_status;
-#define MPII_CFG_RAID_VOL_0_STATUS_ENABLED (10)
-#define MPII_CFG_RAID_VOL_0_STATUS_QUIESCED (11)
-#define MPII_CFG_RAID_VOL_0_STATUS_RESYNCING (12)
-#define MPII_CFG_RAID_VOL_0_STATUS_ACTIVE(13)
-#define MPII_CFG_RAID_VOL_0_STATUS_BADBLOCK_FULL (14)
- u_int8_tvolume_state;
-#define MPII_CFG_RAID_VOL_0_STATE_OPTIMAL(0x00)
-#define MPII_CFG_RAID_VOL_0_STATE_DEGRADED (0x01)
-#define MPII_CFG_RAID_VOL_0_STATE_FAILED (0x02)
-#define MPII_CFG_RAID_VOL_0_STATE_MISSING(0x03)
- u_int16_t reserved1;
+ u_int32_t volume_status;
u_int16_t volume_settings;
-#define MPII_CFG_RAID_VOL_0_SETTINGS_WRITE_CACHE_EN (10)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_OFFLINE_SMART_ERR (11)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_OFFLINE_SMART (12)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_AUTO_SWAP (13)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_HI_PRI_RESYNC (14)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_PROD_SUFFIX (15)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_FAST_SCRUB (16) /*
obsolete */
-#define
Re: mpii enchancements
Oh my. I'll be going over this in a few days.
On Mon, Feb 08, 2010 at 07:13:36PM +0300, Mike Belopuhov wrote:
Good day,
the following diff...
- implements bioctl support;
- fixes hot-un-plugging w/ softeps;
- improves performance;
- fixes IPL levels;
- fixes lots of small things;
- does a little bit of cleanup;
- fixes NOWAIT/WAITOK;
- disables useless/unused Driver Persistent Mapping code that prevents
driver to work properly on our board;
- maybe something else.
I thought about splitting it up in several pieces, but then I thought:
What the heck! Lets beat the devil out of it!
Enjoy and be merry.
Index: mpii.c
===
RCS file: /mount/cvsdev/cvs/openbsd/src/sys/dev/pci/mpii.c,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 mpii.c
--- mpii.c1 Dec 2009 00:09:03 - 1.5
+++ mpii.c8 Feb 2010 15:51:40 -
@@ -30,6 +30,7 @@
#include sys/kernel.h
#include sys/rwlock.h
#include sys/sensors.h
+#include sys/tree.h
#include machine/bus.h
@@ -1019,7 +1020,6 @@ struct mpii_cfg_hdr {
#define MPII_CONFIG_REQ_PAGE_TYPE_MANUFACTURING (0x09)
#define MPII_CONFIG_REQ_PAGE_TYPE_RAID_PD(0x0a)
#define MPII_CONFIG_REQ_PAGE_TYPE_EXTENDED (0x0f)
-#define MPII_CONFIG_REQ_PAGE_TYPE_DRIVER_MAPPING (0x17)
} __packed;
struct mpii_ecfg_hdr {
@@ -1030,6 +1030,9 @@ struct mpii_ecfg_hdr {
u_int16_t ext_page_length;
u_int8_text_page_type;
+#define MPII_CONFIG_REQ_PAGE_TYPE_SAS_DEVICE (0x12)
+#define MPII_CONFIG_REQ_PAGE_TYPE_RAID_CONFIG(0x16)
+#define MPII_CONFIG_REQ_PAGE_TYPE_DRIVER_MAPPING (0x17)
u_int8_treserved2;
} __packed;
@@ -1269,52 +1272,45 @@ struct mpii_cfg_fc_device_pg0 {
u_int8_tcurrent_bus;
} __packed;
+#define MPII_CFG_RAID_VOL_ADDR_HANDLE(128)
+
struct mpii_cfg_raid_vol_pg0 {
struct mpii_cfg_hdr config_header;
- u_int8_tvolume_id;
- u_int8_tvolume_bus;
- u_int8_tvolume_ioc;
+ u_int16_t volume_handle;
+ u_int8_tvolume_state;
+#define MPII_CFG_RAID_VOL_0_STATE_MISSING(0x00)
+#define MPII_CFG_RAID_VOL_0_STATE_FAILED (0x01)
+#define MPII_CFG_RAID_VOL_0_STATE_INITIALIZING (0x02)
+#define MPII_CFG_RAID_VOL_0_STATE_ONLINE (0x03)
+#define MPII_CFG_RAID_VOL_0_STATE_DEGRADED (0x04)
+#define MPII_CFG_RAID_VOL_0_STATE_OPTIMAL(0x05)
u_int8_tvolume_type;
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID0 (0x00)
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID1E (0x01)
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID1 (0x02)
+#define MPII_CFG_RAID_VOL_0_TYPE_RAID10 (0x05)
+#define MPII_CFG_RAID_VOL_0_TYPE_UNKNOWN (0xff)
- u_int8_tvolume_status;
-#define MPII_CFG_RAID_VOL_0_STATUS_ENABLED (10)
-#define MPII_CFG_RAID_VOL_0_STATUS_QUIESCED (11)
-#define MPII_CFG_RAID_VOL_0_STATUS_RESYNCING (12)
-#define MPII_CFG_RAID_VOL_0_STATUS_ACTIVE(13)
-#define MPII_CFG_RAID_VOL_0_STATUS_BADBLOCK_FULL (14)
- u_int8_tvolume_state;
-#define MPII_CFG_RAID_VOL_0_STATE_OPTIMAL(0x00)
-#define MPII_CFG_RAID_VOL_0_STATE_DEGRADED (0x01)
-#define MPII_CFG_RAID_VOL_0_STATE_FAILED (0x02)
-#define MPII_CFG_RAID_VOL_0_STATE_MISSING(0x03)
- u_int16_t reserved1;
+ u_int32_t volume_status;
u_int16_t volume_settings;
-#define MPII_CFG_RAID_VOL_0_SETTINGS_WRITE_CACHE_EN (10)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_OFFLINE_SMART_ERR (11)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_OFFLINE_SMART (12)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_AUTO_SWAP (13)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_HI_PRI_RESYNC (14)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_PROD_SUFFIX (15)
-#define MPII_CFG_RAID_VOL_0_SETTINGS_FAST_SCRUB (16) /*
obsolete */
-#define MPII_CFG_RAID_VOL_0_SETTINGS_DEFAULTS(115)
u_int8_thot_spare_pool;
- u_int8_treserved2;
-
- u_int32_t max_lba;
+ u_int8_treserved1;
- u_int32_t reserved3;
+ u_int64_t max_lba;
u_int32_t stripe_size;
- u_int32_t reserved4;
+ u_int16_t block_size;
+ u_int16_t reserved2;
- u_int32_t reserved5;
+ u_int8_tphys_disk_types;
+ u_int8_tresync_rate;
+ u_int16_t data_scrub_rate;
Re: Christiano Haesbaert wants to keep up with you on Twitter
a twatter? On Thu, Jan 28, 2010 at 03:27:55AM -0200, Christiano F. Haesbaert wrote: I'm sorry for that, I made the account quickly to make a joke with , just pressed next next next and didn't notice tech@openbsd.org was on the friends suggestions. My sincere apologies. I'm such a tool :D. On Thu, Jan 28, 2010 at 04:08:20AM +, Twitter wrote: Twitter connects you with everything you want to know, right now. Short bursts of information are readily available from news organizations, corporate entities, politicians, celebrities, local businesses - even your close friends and family. Also, if you have something to share with the world, Twitter makes it super easy. To join for free, click the link below. http://twitter.com/i/4836cb63db5f5d923b83210a43403cdd71cf465c Thanks, @twitterAbout Twitter, Inc. Founded in 2007, Twitter Inc believes the open exchange of information can have a positive global impact. Every Tweet is limited to 140 characters of text or links which means they are easily written or read on a wide variety of services and devices including any mobile phone, social networks, television, Macs, PCs, and the Web. This message was sent by a Twitter user who entered your email address. If you'd prefer not to receive emails when other people invite you to Twitter, click here: http://twitter.com/i/o?c=%2BEcN9FeOjQ28W7hmwxAHWse%2BRTCW6iAC -- Christiano Farina HAESBAERT Do NOT send me html mail.
Re: rt2661 patch to fix interrupt handling under load
Damien objected off list. It is his driver so his vote counts. I'll send you his comments off list. If he wanted them out in public he would have sent it here. On Tue, Jan 26, 2010 at 04:56:55AM +, Roland Dreier wrote: Marco Peereboom slash at peereboom.us writes: Objections were made. Apparently this patch only works for AP and does funky stuff to the hardware. So back to the drawing board on this one. Who made these objections? I didn't see anything on the mailing list. (And it would be nice if I could be kept cc'ed on this discussion, as the original author of the patch) I honestly can't be bothered to test in STA mode at this point but it's hard for me to see how my patch breaks that -- I don't particularly know much about how this hardware works but it seems to me that all the things about the low-level TX interrupt handling that I'm changing work exactly the same in AP or STA mode. According to Damien this part is broken. And does funky stuff to the hardware?? I don't even know what that means, and I can't see how a patch that does nothing but simplify the code and close races in interrupt handling could be described that way. The current rt2661 code is seriously buggy, and has been buggy ever since the driver was committed. Multiple people find rt2661 essentially unusable because the interface gets stuck with OACTIVE set. I think I understand the root cause of that, and described it when I sent my original patch; if you guys want to leave rt2661 broken because objections were made in some private way that I can't even see, that's fine but I'm afraid it will be someone other than me going back to the drawing board. - Roland
Re: rt2661 patch to fix interrupt handling under load
Then if no one objects I'll commit it tomorrow. On Sun, Jan 17, 2010 at 04:54:09PM -0600, Marco Peereboom wrote: Has this been tested on all variants of the chip? On Sun, Jan 17, 2010 at 07:40:29PM +, Tom Murphy wrote: Hi, I'd like to point out that Roland Dreier's patch as detailed here: http://www.mail-archive.com/m...@openbsd.org/msg83528.html Works great on my little Soekris 5501 with a RT2661. (dmesg attached to end of this email.) I do still get the odd wireless drop for 15-20 seconds, but it no longer brings up the OACTIVE flag on ral0 and it doesn't make the system completely freeze (no way of getting a dump, have to hard reset.) I emailed damien@ on December 1st and got no response. The author of the patch has expressed his frustration at being able to contact a developer to get this committed. I would be more than happy to do testing. Feel free to contact me.. I know it's hard to test all hardware devices when there is a lack of them. Regards, Tom (kernel was compiled by me, with aforementioned patch above, and is GENERIC) OpenBSD 4.6-current (GENERIC) #2: Fri Nov 27 12:20:04 GMT 2009 r...@pertho.net:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 500 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 536440832 (511MB) avail mem = 511152128 (487MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) io address conflict 0x6100/0x100 io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:cb:a6:64 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:cb:a6:65 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:cb:a6:66 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:cb:a6:67 ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 14 function 0 Ralink RT2661 rev 0x00: irq 10, address 00:14:85:d5:39:bb ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR) glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 0, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 1: WDC WD1200BEVS-00VAT0 wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 21 function 0 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 21 function 1 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS gpio1 at nsclpcsio0: 29 pins npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 biomask e1c7 netmask ffe7 ttymask mtrr: K6-family MTRR support (2 registers) vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root root on wd0a swap on wd0b dump on wd0b
Re: kernel hacking
That book is very relevant. Modern really means add more shit. On Thu, Dec 10, 2009 at 09:04:31PM +0100, Joerg Sonnenberger wrote: On Thu, Dec 10, 2009 at 08:54:30PM +0100, Thomas Pfaff wrote: A few books on this topic in general worth mentioning is Modern Operating Systems by Tanenbaum, Operating Systems: Design and Implementation. The latter one details the MINIX system, though. Modern Operating Systems is mostly of historic value -- the modern is relative to the state of the art of the 1970, early 1980. Joerg
Re: How to express memory ordering in OpenBSD kernel?
On Sun, Dec 06, 2009 at 08:50:42AM -0800, Roland Dreier wrote: So a diff like the one below seems like a good idea. However I'm not very experienced with the OpenBSD kernel and I'm wondering what the idiomatic way is to express the fact that we need to make sure that neither the compiler nor an out-of-order CPU reorder the TX descriptor writes either. Or do we just not worry about this? Assuming I understand you question correctly, this can not be guaranteed and in fact it is unlikely to complete in order you expect. All newish DMA engines interleave DMA transfers. A driver for a piece of hardware that got bitten by that (because they assumed in order completion of a DMA) is ami(4). For the full horror story read the interrupt path code which does nothing but ensure that individual pieces are completed before it calls it an overall completion. I don't think there's any such complexity in this case. Maybe a better way of phrasing what is needed is to say that we need to make sure that the correct contents of the rest of the TX descriptor in system memory must be visible to the ral device before the VALID|BUSY bits become visible to the ral device. On x86, because of the strong architectural memory ordering model, simply making sure that the instructions that set those bits come last in order is enough -- so we need a compiler barrier that makes sure the compiler doesn't optimize things and move where the bits get set earlier in the function. On architectures with a weaker memory ordering model, some sort of synchronization instruction is probably required between writing the rest of the TX descriptor and then writing the VALID|BUSY bits. Oh, for that you need: bus_dmamap_sync with one of these ops: BUS_DMASYNC_PREREAD, BUS_DMASYNC_POSTREAD, BUS_DMASYNC_PREWRITE, BUS_DMASYNC_POSTWRITE. In OpenBSD you are supposed to add those to all your drivers regardless of architecture. Those operations are crucial for arches such as hppa and sparc64. The bus_dmamap_sync man page is full of good information but requires to be read several times before it sinks in. A few good drivers for example code is mpi, ami or mfi. Anything (c) dlg really. - R.
Re: ldapd
I have been looking for a good btree implementation. I'll definitively take a look at yours. On Fri, Nov 13, 2009 at 12:41:14PM +0100, Martin Hedenfalk wrote: Hello, I've been writing a small ldap server recently and thought I'd see if there was any interest in such a thing here. It's ISC-licensed with a small and readable code base. Still in a very early stage, but at least usable as a simple address book, although I wouldn't trust it with real data yet. Data is stored in an append-only b-tree database format, supporting lock-free reads (snapshots), hot backups and simpler code. See the ldapcompact(8) man page inside the tarball. I've made available a snapshot here: http://bzero.se/ldapd/ It needs an _ldapd user, and will chroot to the home directory of that user. Feedback much appreciated. -martin
Re: Add IDE / SATA support for AMD SB900 chipset.
Got a dmesg?
On Sun, Sep 20, 2009 at 02:31:27PM -0400, Brad wrote:
The following diffs add support for IDE and SATA with the AMD SB900 chipset.
Index: pciide.c
===
RCS file: /cvs/src/sys/dev/pci/pciide.c,v
retrieving revision 1.298
diff -u -p -r1.298 pciide.c
--- pciide.c 5 Sep 2009 10:24:58 - 1.298
+++ pciide.c 13 Sep 2009 06:49:14 -
@@ -557,6 +557,10 @@ const struct pciide_product_desc pciide_
{ PCI_PRODUCT_AMD_CS5536_IDE,
0,
amd756_chip_map
+ },
+ { PCI_PRODUCT_AMD_SB900_IDE,
+ 0,
+ ixp_chip_map
}
};
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.148
diff -u -p -r1.148 ahci.c
--- ahci.c13 Sep 2009 13:26:39 - 1.148
+++ ahci.c20 Sep 2009 17:55:31 -
@@ -427,8 +427,8 @@ int ahci_nvidia_mcp_attach(struct
ahci
struct pci_attach_args *);
static const struct ahci_device ahci_devices[] = {
- { PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VT8251_SATA,
- ahci_no_match, ahci_vt8251_attach },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_SB900_SATA,
+ NULL, ahci_ati_sb600_attach },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SB600_SATA,
NULL, ahci_ati_sb600_attach },
{ PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_1,
@@ -438,7 +438,9 @@ static const struct ahci_device ahci_dev
{ PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP67_AHCI_1,
NULL, ahci_nvidia_mcp_attach },
{ PCI_VENDOR_NVIDIA,PCI_PRODUCT_NVIDIA_MCP77_AHCI_5,
- NULL, ahci_nvidia_mcp_attach }
+ NULL, ahci_nvidia_mcp_attach },
+ { PCI_VENDOR_VIATECH, PCI_PRODUCT_VIATECH_VT8251_SATA,
+ ahci_no_match, ahci_vt8251_attach }
};
int ahci_pci_match(struct device *, void *, void *);
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: acpi question
Leave it enabled. On Fri, Sep 04, 2009 at 10:13:53PM +0200, frantisek holop wrote: hi there, poking around in my bios i have found the following setting: Power Now!(tm) Technology [Enabled] the help message says: Enable/disable the generation of ACPI _PPC, _PSS, and _PCT objects. if anybody knowledgable reads this, what does this mean and how would flipping this affect openbsd? thanks. -f -- there is only one universal passion: fear.
move softraid to vnode api
To deal with an issue jordan found and to be able to boot softraid the
code needs to start using the vnode api.
Please test. I am particularly interested in rebuilds and hotspares
that initiate a rebuild.
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.169
diff -u -p -r1.169 softraid.c
--- softraid.c 31 Jul 2009 16:05:25 - 1.169
+++ softraid.c 4 Aug 2009 23:12:37 -
@@ -273,7 +273,7 @@ int
sr_meta_probe(struct sr_discipline *sd, dev_t *dt, int no_chunk)
{
struct sr_softc *sc = sd-sd_sc;
- struct bdevsw *bdsw;
+ struct vnode*vn;
struct sr_chunk *ch_entry, *ch_prev = NULL;
struct sr_chunk_head*cl;
chardevname[32];
@@ -305,23 +305,28 @@ sr_meta_probe(struct sr_discipline *sd,
continue;
} else {
sr_meta_getdevname(sc, dev, devname, sizeof(devname));
- bdsw = bdevsw_lookup(dev);
+ if (bdevvp(dev, vn)) {
+ printf(%s:, sr_meta_probe: can't allocate
+ vnode\n);
+ goto unwind;
+ }
/*
* XXX leaving dev open for now; move this to attach
* and figure out the open/close dance for unwind.
*/
- error = bdsw-d_open(dev, FREAD | FWRITE, S_IFBLK,
- curproc);
+ error = VOP_OPEN(vn, FREAD | FWRITE, NOCRED, 0);
if (error) {
DNPRINTF(SR_D_META,%s: sr_meta_probe can't
open %s\n, DEVNAME(sc), devname);
/* dev isn't open but will be closed anyway */
+ vput(vn);
goto unwind;
}
strlcpy(ch_entry-src_devname, devname,
- sizeof(ch_entry-src_devname));
+ sizeof(ch_entry-src_devname));
+ ch_entry-src_vn = vn;
}
/* determine if this is a device we understand */
@@ -385,12 +390,12 @@ sr_meta_rw(struct sr_discipline *sd, dev
DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
DEVNAME(sc), dev, md, sz, ofs, flags);
+ bzero(b, sizeof(b));
+
if (md == NULL) {
printf(%s: read invalid metadata pointer\n, DEVNAME(sc));
goto done;
}
-
- bzero(b, sizeof(b));
b.b_flags = flags | B_PHYS;
b.b_blkno = ofs;
b.b_bcount = sz;
@@ -400,10 +405,16 @@ sr_meta_rw(struct sr_discipline *sd, dev
b.b_error = 0;
b.b_proc = curproc;
b.b_dev = dev;
- b.b_vp = NULL;
b.b_iodone = NULL;
+ if (bdevvp(dev, b.b_vp)) {
+ printf(%s:, sr_meta_native_bootprobe: can't allocate vnode\n);
+ goto done;
+ }
+ if ((b.b_flags B_READ) == 0)
+ b.b_vp-v_numoutput++;
+
LIST_INIT(b.b_dep);
- bdevsw_lookup(b.b_dev)-d_strategy(b);
+ VOP_STRATEGY(b);
biowait(b);
if (b.b_flags B_ERROR) {
@@ -413,6 +424,9 @@ sr_meta_rw(struct sr_discipline *sd, dev
}
rv = 0;
done:
+ if (b.b_vp)
+ vput(b.b_vp);
+
return (rv);
}
@@ -837,7 +851,7 @@ int
sr_meta_native_bootprobe(struct sr_softc *sc, struct device *dv,
struct sr_metadata_list_head *mlh)
{
- struct bdevsw *bdsw;
+ struct vnode*vn;
struct disklabellabel;
struct sr_metadata *md;
struct sr_discipline*fake_sd;
@@ -853,40 +867,38 @@ sr_meta_native_bootprobe(struct sr_softc
if (majdev == -1)
goto done;
dev = MAKEDISKDEV(majdev, dv-dv_unit, RAW_PART);
- bdsw = bdevsw[majdev];
-
- /*
-* The devices are being opened with S_IFCHR instead of
-* S_IFBLK so that the SCSI mid-layer does not whine when
-* media is not inserted in certain devices like zip drives
-* and such.
-*/
+ if (bdevvp(dev, vn)) {
+ printf(%s:, sr_meta_native_bootprobe: can't allocate vnode\n);
+ goto done;
+ }
/* open device */
- error = (*bdsw-d_open)(dev, FREAD, S_IFCHR, curproc);
+ error = VOP_OPEN(vn, FREAD, NOCRED, 0);
if (error) {
DNPRINTF(SR_D_META, %s: sr_meta_native_bootprobe open
failed\n, DEVNAME(sc));
+ vput(vn);
goto done;
}
/* get disklabel */
- error = (*bdsw-d_ioctl)(dev, DIOCGDINFO, (void *)label, FREAD,
-
Re: move softraid to vnode api
better diff with thib comments.
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.169
diff -u -p -r1.169 softraid.c
--- softraid.c 31 Jul 2009 16:05:25 - 1.169
+++ softraid.c 5 Aug 2009 15:40:48 -
@@ -273,7 +273,7 @@ int
sr_meta_probe(struct sr_discipline *sd, dev_t *dt, int no_chunk)
{
struct sr_softc *sc = sd-sd_sc;
- struct bdevsw *bdsw;
+ struct vnode*vn;
struct sr_chunk *ch_entry, *ch_prev = NULL;
struct sr_chunk_head*cl;
chardevname[32];
@@ -305,23 +305,28 @@ sr_meta_probe(struct sr_discipline *sd,
continue;
} else {
sr_meta_getdevname(sc, dev, devname, sizeof(devname));
- bdsw = bdevsw_lookup(dev);
+ if (bdevvp(dev, vn)) {
+ printf(%s:, sr_meta_probe: can't allocate
+ vnode\n, DEVNAME(sc));
+ goto unwind;
+ }
/*
* XXX leaving dev open for now; move this to attach
* and figure out the open/close dance for unwind.
*/
- error = bdsw-d_open(dev, FREAD | FWRITE, S_IFBLK,
- curproc);
+ error = VOP_OPEN(vn, FREAD | FWRITE, NOCRED, 0);
if (error) {
DNPRINTF(SR_D_META,%s: sr_meta_probe can't
open %s\n, DEVNAME(sc), devname);
/* dev isn't open but will be closed anyway */
+ vput(vn);
goto unwind;
}
strlcpy(ch_entry-src_devname, devname,
- sizeof(ch_entry-src_devname));
+ sizeof(ch_entry-src_devname));
+ ch_entry-src_vn = vn;
}
/* determine if this is a device we understand */
@@ -385,12 +390,12 @@ sr_meta_rw(struct sr_discipline *sd, dev
DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
DEVNAME(sc), dev, md, sz, ofs, flags);
+ bzero(b, sizeof(b));
+
if (md == NULL) {
printf(%s: read invalid metadata pointer\n, DEVNAME(sc));
goto done;
}
-
- bzero(b, sizeof(b));
b.b_flags = flags | B_PHYS;
b.b_blkno = ofs;
b.b_bcount = sz;
@@ -400,10 +405,16 @@ sr_meta_rw(struct sr_discipline *sd, dev
b.b_error = 0;
b.b_proc = curproc;
b.b_dev = dev;
- b.b_vp = NULL;
b.b_iodone = NULL;
+ if (bdevvp(dev, b.b_vp)) {
+ printf(%s:, sr_meta_rw: can't allocate vnode\n, DEVNAME(sc));
+ goto done;
+ }
+ if ((b.b_flags B_READ) == 0)
+ b.b_vp-v_numoutput++;
+
LIST_INIT(b.b_dep);
- bdevsw_lookup(b.b_dev)-d_strategy(b);
+ VOP_STRATEGY(b);
biowait(b);
if (b.b_flags B_ERROR) {
@@ -413,6 +424,9 @@ sr_meta_rw(struct sr_discipline *sd, dev
}
rv = 0;
done:
+ if (b.b_vp)
+ vput(b.b_vp);
+
return (rv);
}
@@ -837,7 +851,7 @@ int
sr_meta_native_bootprobe(struct sr_softc *sc, struct device *dv,
struct sr_metadata_list_head *mlh)
{
- struct bdevsw *bdsw;
+ struct vnode*vn;
struct disklabellabel;
struct sr_metadata *md;
struct sr_discipline*fake_sd;
@@ -853,40 +867,39 @@ sr_meta_native_bootprobe(struct sr_softc
if (majdev == -1)
goto done;
dev = MAKEDISKDEV(majdev, dv-dv_unit, RAW_PART);
- bdsw = bdevsw[majdev];
-
- /*
-* The devices are being opened with S_IFCHR instead of
-* S_IFBLK so that the SCSI mid-layer does not whine when
-* media is not inserted in certain devices like zip drives
-* and such.
-*/
+ if (bdevvp(dev, vn)) {
+ printf(%s:, sr_meta_native_bootprobe: can't allocate vnode\n,
+ DEVNAME(sc));
+ goto done;
+ }
/* open device */
- error = (*bdsw-d_open)(dev, FREAD, S_IFCHR, curproc);
+ error = VOP_OPEN(vn, FREAD, NOCRED, 0);
if (error) {
DNPRINTF(SR_D_META, %s: sr_meta_native_bootprobe open
failed\n, DEVNAME(sc));
+ vput(vn);
goto done;
}
/* get disklabel */
- error = (*bdsw-d_ioctl)(dev, DIOCGDINFO, (void *)label, FREAD,
- curproc);
+ error = VOP_IOCTL(vn, DIOCGDINFO, (caddr_t)label, FREAD, NOCRED, 0);
if (error) {
Re: 4.6-beta acpicpu0 panic
Well that sort of tells me that ahci hasn't caught up with all latest chips. I will look at that acpicpu thing though. On Thu, Jul 30, 2009 at 06:20:38PM +0200, frantisek holop wrote: hmm, on Thu, Jul 30, 2009 at 11:05:14AM -0500, Marco Peereboom said that But is that an interrupt issue or does the disk simply suck? the interrupt issues i reported about this machine are gone (atm). interrupts in top showed normal level as far as i can tell. this disk is of course the highest udma breed (actually it is ahci, but last time i checked it wasn't found by the kernel) but if it's doing PIO, doing anything that touches the disk makes everything go slow-mo. just send me any commands you want me to execute and collect the output... -f -- if people listened to themselves more often, they would shut up.
Re: 4.6-beta acpicpu0 panic
Performance ok/better with the fancy pci routing tables enabled? On Thu, Jul 30, 2009 at 03:52:05PM +0200, frantisek holop wrote: hmm, on Wed, Jul 29, 2009 at 08:50:14PM -0500, Marco Peereboom said that did you try disabling acpicpu only? i have tried this and here is the dmesg: (it is also accessible under obiit.org/f/dmesg.bsd.sp.acpi) OpenBSD 4.6-current (GENERIC) #85: Mon Jul 27 19:10:16 MDT 2009 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD Turion(tm) X2 Ultra Dual-Core Mobile ZM-80 (AuthenticAMD 686-class, 1024KB L2 cache) 2.11 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16 real mem = 3217108992 (3068MB) avail mem = 311880 (2972MB) User Kernel Config UKC disable acpicpu 471 acpicpu* disabled UKC quit Continuing... mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/08/08, SMBIOS rev. 2.4 @ 0xbfb51018 (53 entries) bios0: vendor American Megatrends Inc. version E1652NMS VER.106 date 12/26/2008 bios0: Micro-Star International GX-630 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC SSDT MCFG SLIC acpi0: wakeup devices PS2K(S4) PS2M(S4) NSMB(S4) USB0(S4) USB2(S3) USB1(S4) USB4(S3) NMAC(S5) HDAC(S4) POP2(S4) BR12(S4) BR13(S4) BR14(S4) BR16(S4) SLPB(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (BR12) acpiprt2 at acpi0: bus 4 (BR13) acpiprt3 at acpi0: bus 5 (BR14) acpiprt4 at acpi0: bus 8 (BR16) acpiec0 at acpi0 acpicpu at acpi0 not configured acpitz0 at acpi0: critical temperature 100 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model MS-1221 serial type LION oem MSI Corp. acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: CRT_ acpivout1 at acpivideo0: LCD_ acpivout2 at acpivideo0: HDMI bios0: ROM list: 0xc/0xe200 0xce800/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) NVIDIA MCP77 Memory rev 0xa2 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 NVIDIA MCP77 ISA rev 0xa2 nviic0 at pci0 dev 1 function 1 NVIDIA MCP77 SMBus rev 0xa1 iic0 at nviic0 iic1 at nviic0 spdmem0 at iic1 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL5 SO-DIMM spdmem1 at iic1 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-6400CL5 SO-DIMM NVIDIA MCP77 Co-processor rev 0xa2 at pci0 dev 1 function 3 not configured NVIDIA MCP77 Memory rev 0xa1 at pci0 dev 1 function 4 not configured ohci0 at pci0 dev 2 function 0 NVIDIA MCP77 USB rev 0xa1: apic 0 int 7 (irq 7), version 1.0, legacy support ehci0 at pci0 dev 2 function 1 NVIDIA MCP77 USB rev 0xa1: apic 0 int 11 (irq 11) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 ohci1 at pci0 dev 4 function 0 NVIDIA MCP77 USB rev 0xa1: apic 0 int 5 (irq 5), version 1.0, legacy support ehci1 at pci0 dev 4 function 1 NVIDIA MCP77 USB rev 0xa1: apic 0 int 7 (irq 7) usb1 at ehci1: USB revision 2.0 uhub1 at usb1 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 pciide0 at pci0 dev 6 function 0 NVIDIA MCP77 IDE rev 0xa1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 ignored (disabled) pciide0: channel 1 ignored (disabled) azalia0 at pci0 dev 7 function 0 NVIDIA MCP77 HD Audio rev 0xa1: apic 0 int 11 (irq 11) azalia0: codecs: Realtek ALC888, Motorola/0x3055, NVIDIA/0x0006, using Realtek ALC888 audio0 at azalia0 ppb0 at pci0 dev 8 function 0 NVIDIA MCP77 PCI rev 0xa1 pci1 at ppb0 bus 1 pciide1 at pci0 dev 9 function 0 NVIDIA MCP77 AHCI rev 0xa2: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide1: using apic 0 int 10 (irq 10) for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: FUJITSU MHZ2320BH G2 wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors atapiscsi0 at pciide1 channel 0 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: Optiarc, DVD RW AD-7560S, SX01 ATAPI 5/cdrom removable pciide1: channel 1 ignored (not responding; disabled or no drives?) nfe0 at pci0 dev 10 function 0 NVIDIA MCP77 LAN rev 0xa2: apic 0 int 5 (irq 5), address 00:21:85:55:af:d3 eephy0 at nfe0 phy 1: 88E1116 Gigabit PHY, rev. 1 ppb1 at pci0 dev 16 function 0 NVIDIA MCP77 PCIE rev 0xa1: apic 0 int 7 (irq 7) pci2 at ppb1 bus 2 vga1 at pci2 dev 0 function 0 vendor NVIDIA, unknown product 0x0649 rev 0xa1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb2 at pci0 dev 18 function 0 NVIDIA MCP77 PCIE rev 0xa1: apic 0 int 11 (irq 11) pci3 at ppb2 bus 3 ral0 at pci3 dev 0
Re: 4.6-beta acpicpu0 panic
But is that an interrupt issue or does the disk simply suck? On Thu, Jul 30, 2009 at 05:27:25PM +0200, frantisek holop wrote: hmm, on Thu, Jul 30, 2009 at 09:25:49AM -0500, Marco Peereboom said that Performance ok/better with the fancy pci routing tables enabled? hard to say as the disk is pig slow. feels like the 486 times.. pciide1 at pci0 dev 9 function 0 NVIDIA MCP77 AHCI rev 0xa2: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide1: using apic 0 int 10 (irq 10) for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: FUJITSU MHZ2320BH G2 wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors -f On Thu, Jul 30, 2009 at 03:52:05PM +0200, frantisek holop wrote: hmm, on Wed, Jul 29, 2009 at 08:50:14PM -0500, Marco Peereboom said that did you try disabling acpicpu only? i have tried this and here is the dmesg: (it is also accessible under obiit.org/f/dmesg.bsd.sp.acpi) OpenBSD 4.6-current (GENERIC) #85: Mon Jul 27 19:10:16 MDT 2009 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD Turion(tm) X2 Ultra Dual-Core Mobile ZM-80 (AuthenticAMD 686-class, 1024KB L2 cache) 2.11 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16 real mem = 3217108992 (3068MB) avail mem = 311880 (2972MB) User Kernel Config UKC disable acpicpu 471 acpicpu* disabled UKC quit Continuing... mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/08/08, SMBIOS rev. 2.4 @ 0xbfb51018 (53 entries) bios0: vendor American Megatrends Inc. version E1652NMS VER.106 date 12/26/2008 bios0: Micro-Star International GX-630 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC SSDT MCFG SLIC acpi0: wakeup devices PS2K(S4) PS2M(S4) NSMB(S4) USB0(S4) USB2(S3) USB1(S4) USB4(S3) NMAC(S5) HDAC(S4) POP2(S4) BR12(S4) BR13(S4) BR14(S4) BR16(S4) SLPB(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (BR12) acpiprt2 at acpi0: bus 4 (BR13) acpiprt3 at acpi0: bus 5 (BR14) acpiprt4 at acpi0: bus 8 (BR16) acpiec0 at acpi0 acpicpu at acpi0 not configured acpitz0 at acpi0: critical temperature 100 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model MS-1221 serial type LION oem MSI Corp. acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: CRT_ acpivout1 at acpivideo0: LCD_ acpivout2 at acpivideo0: HDMI bios0: ROM list: 0xc/0xe200 0xce800/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) NVIDIA MCP77 Memory rev 0xa2 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 NVIDIA MCP77 ISA rev 0xa2 nviic0 at pci0 dev 1 function 1 NVIDIA MCP77 SMBus rev 0xa1 iic0 at nviic0 iic1 at nviic0 spdmem0 at iic1 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-6400CL5 SO-DIMM spdmem1 at iic1 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-6400CL5 SO-DIMM NVIDIA MCP77 Co-processor rev 0xa2 at pci0 dev 1 function 3 not configured NVIDIA MCP77 Memory rev 0xa1 at pci0 dev 1 function 4 not configured ohci0 at pci0 dev 2 function 0 NVIDIA MCP77 USB rev 0xa1: apic 0 int 7 (irq 7), version 1.0, legacy support ehci0 at pci0 dev 2 function 1 NVIDIA MCP77 USB rev 0xa1: apic 0 int 11 (irq 11) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 ohci1 at pci0 dev 4 function 0 NVIDIA MCP77 USB rev 0xa1: apic 0 int 5 (irq 5), version 1.0, legacy support ehci1 at pci0 dev 4 function 1 NVIDIA MCP77 USB rev 0xa1: apic 0 int 7 (irq 7) usb1 at ehci1: USB revision 2.0 uhub1 at usb1 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 pciide0 at pci0 dev 6 function 0 NVIDIA MCP77 IDE rev 0xa1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 ignored (disabled) pciide0: channel 1 ignored (disabled) azalia0 at pci0 dev 7 function 0 NVIDIA MCP77 HD Audio rev 0xa1: apic 0 int 11 (irq 11) azalia0: codecs: Realtek ALC888, Motorola/0x3055, NVIDIA/0x0006, using Realtek ALC888 audio0 at azalia0 ppb0 at pci0 dev 8 function 0 NVIDIA MCP77 PCI rev 0xa1 pci1 at ppb0 bus 1 pciide1 at pci0 dev 9 function 0 NVIDIA MCP77 AHCI rev 0xa2: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide1: using apic 0 int 10 (irq 10) for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: FUJITSU MHZ2320BH G2 wd0: 16-sector PIO, LBA48, 305245MB, 625142448
Re: ACPI C-States diff
Can we get some tests on this?
On Sun, Jun 07, 2009 at 02:48:24PM -0500, jor...@peereboom.us wrote:
Sending out an initial attempt at implementing C-states for APCI CPUs.
The C-states are used to implement the CPU idle loop per CPU.
Please send dmesgs of booting using this patch.
Index: acpicpu.c
===
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.53
diff -u -p -u -p -b -r1.53 acpicpu.c
--- acpicpu.c 24 Feb 2009 13:20:02 - 1.53
+++ acpicpu.c 7 Jun 2009 19:47:34 -
@@ -41,6 +41,10 @@ intacpicpu_match(struct device *, void
void acpicpu_attach(struct device *, struct device *, void *);
int acpicpu_notify(struct aml_node *, int, void *);
void acpicpu_setperf(int);
+voidacpicpu_idle(void);
+
+#define C2_OVERHEAD 4
+#define C3_OVERHEAD 4
#define ACPI_STATE_C00x00
#define ACPI_STATE_C10x01
@@ -65,14 +69,20 @@ void acpicpu_setperf(int);
/* Make sure throttling bits are valid,a=addr,o=offset,w=width */
#define valid_throttle(o,w,a)(a w (o+w)=31 (o4 ||
(o+w)=4))
+TAILQ_HEAD(acpi_cstatehead, acpi_cstate);
+
struct acpi_cstate
{
int type;
int latency;
int power;
int address;
+ int enter;
+
+ int pthr, dthr;
+ int pcount, dcount;
- SLIST_ENTRY(acpi_cstate) link;
+ TAILQ_ENTRY(acpi_cstate) link;
};
struct acpicpu_softc {
@@ -85,7 +95,9 @@ struct acpicpu_softc {
int sc_pblk_len;
int sc_flags;
- SLIST_HEAD(,acpi_cstate) sc_cstates;
+ int sc_prevsleep;
+ struct acpi_cstate *sc_cx;
+ struct acpi_cstatehead sc_cstates;
bus_space_tag_t sc_iot;
bus_space_handle_t sc_ioh;
@@ -121,6 +133,8 @@ int acpicpu_getpct(struct acpicpu_softc
int acpicpu_getpss(struct acpicpu_softc *);
struct acpi_cstate *acpicpu_add_cstate(struct acpicpu_softc *, int, int,
int,
int);
+u_int acpicpu_ticks(struct acpicpu_softc *, u_int, u_int);
+int acpicpu_get_cstaddr(union acpi_resource *, void *);
#if 0
voidacpicpu_set_throttle(struct acpicpu_softc *, int);
struct acpi_cstate *acpicpu_find_cstate(struct acpicpu_softc *, int);
@@ -163,31 +177,36 @@ acpicpu_find_cstate(struct acpicpu_softc
{
struct acpi_cstate *cx;
- SLIST_FOREACH(cx, sc-sc_cstates, link)
+ TAILQ_FOREACH(cx, sc-sc_cstates, link) {
if (cx-type == type)
return cx;
+ }
return (NULL);
}
#endif
struct acpi_cstate *
-acpicpu_add_cstate(struct acpicpu_softc *sc, int type, int latency, int
power,
+acpicpu_add_cstate(struct acpicpu_softc *sc,
+int type, int latency, int power,
int address)
{
struct acpi_cstate *cx;
+ printf(C%d: latency:%d power:%d addr:%.4x\n,
+ type, latency, power, address);
+
dnprintf(10, C%d: latency:.%4x power:%.4x addr:%.8x\n,
type, latency, power, address);
switch (type) {
case ACPI_STATE_C2:
if (latency ACPI_MAX_C2_LATENCY || !address ||
- (sc-sc_flags FLAGS_NO_C2))
+ sc-sc_flags FLAGS_NO_C2)
goto bad;
break;
case ACPI_STATE_C3:
if (latency ACPI_MAX_C3_LATENCY || !address ||
- (sc-sc_flags FLAGS_NO_C3))
+ sc-sc_flags FLAGS_NO_C3)
goto bad;
break;
}
@@ -199,7 +218,19 @@ acpicpu_add_cstate(struct acpicpu_softc
cx-latency = latency;
cx-address = address;
- SLIST_INSERT_HEAD(sc-sc_cstates, cx, link);
+ if (type == ACPI_STATE_C1)
+ cx-pthr = 10;
+ else if (type == ACPI_STATE_C2) {
+ cx-dthr = 1;
+ cx-pthr = 4;
+ }
+ else if (type == ACPI_STATE_C3)
+ cx-dthr = 1;
+
+ TAILQ_INSERT_TAIL(sc-sc_cstates, cx, link);
+
+ if (sc-sc_cx == NULL)
+ sc-sc_cx = cx;
return (cx);
bad:
@@ -207,21 +238,34 @@ acpicpu_add_cstate(struct acpicpu_softc
return (NULL);
}
+int
+acpicpu_get_cstaddr(union acpi_resource *crs, void *arg)
+{
+ struct acpi_gas *gas = arg;
+
+ if (AML_CRSTYPE(crs) == LR_GENREGISTER)
+ memcpy(gas, crs-pad+3, sizeof(*gas));
+ return 0;
+}
+
/* Found a _CST object, add new cstate for each entry */
void
acpicpu_add_cstatepkg(struct aml_value *val, void *arg)
{
struct acpicpu_softc*sc = arg;
+ struct acpi_gas gas;
-#if defined(ACPI_DEBUG) !defined(SMALL_KERNEL)
- aml_showvalue(val, 0);
-#endif
if (val-type != AML_OBJTYPE_PACKAGE || val-length != 4)
return;
+ memset(gas, 0, sizeof(gas));
+
acpi bay stuff
Jordan wrote this diff to play with modular hotplug bay devices such as
cd players. We need some tests on this to see if the acpi device to pci
device mapping works right. Try removing and reinserting the cd bay
device.
Be warned that this may panic your box.
Please send me and jordan the results.
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.137
diff -u -p -u -p -b -r1.137 acpi.c
--- acpi.c 30 Apr 2009 20:42:14 - 1.137
+++ acpi.c 31 May 2009 18:18:53 -
@@ -339,6 +339,103 @@ acpi_foundprt(struct aml_node *node, voi
return 0;
}
+int acpi_foundide(struct aml_node *node, void *arg);
+int acpiide_notify(struct aml_node *, int, void *);
+
+int ide_installed=1;
+
+#include dev/pci/pciidereg.h
+#include dev/pci/pciidevar.h
+void wdcattach(struct channel_softc *);
+int wdcdetach(struct channel_softc *, int);
+
+struct idechnl
+{
+ struct acpi_softc *sc;
+ int64_t addr;
+ int64_t chnl;
+};
+
+int
+acpiide_notify(struct aml_node *node, int ntype, void *arg)
+{
+ struct idechnl *ide = arg;
+ struct acpi_softc *sc = ide-sc;
+ struct pciide_softc *wsc;
+ struct device *dev;
+ int b,d,f;
+ int64_t sta;
+
+ if (aml_evalinteger(sc, node, _STA, 0, NULL, sta) != 0)
+ return 0;
+
+ printf(IDE notify! %s %d status:%llx\n, aml_nodename(node), ntype,
sta);
+
+ /* Walk device list looking for IDE device match */
+ TAILQ_FOREACH(dev, alldevs, dv_list) {
+ if (strncmp(dev-dv_xname, pciide, 6))
+ continue;
+
+ wsc = (struct pciide_softc *)dev;
+ pci_decompose_tag(NULL, wsc-sc_tag, b, d, f);
+ if (b != ACPI_PCI_BUS(ide-addr) ||
+ d != ACPI_PCI_DEV(ide-addr) ||
+ f != ACPI_PCI_FN(ide-addr))
+ continue;
+ printf(Found pciide: %s %x.%x.%x channel:%llx \%s\\n,
+ dev-dv_xname, b,d,f, ide-chnl,
+ wsc-pciide_channels[ide-chnl].name);
+#if 1
+ if (sta == 0 ide_installed) {
+ ide_installed = 0;
+
wdcdetach(wsc-pciide_channels[ide-chnl].wdc_channel,0);
+ }
+ else if (sta !ide_installed) {
+ ide_installed = 1;
+ wdcattach(wsc-pciide_channels[ide-chnl].wdc_channel);
+ }
+#endif
+ }
+ return 0;
+}
+
+int
+acpi_foundide(struct aml_node *node, void *arg)
+{
+ struct acpi_softc *sc = arg;
+ struct aml_node *pp;
+ struct idechnl *ide;
+ int lvl;
+
+ ide = malloc(sizeof(struct idechnl), M_DEVBUF, M_NOWAIT | M_ZERO);
+ ide-sc = sc;
+
+ /* GTM/GTF can be at 2/3 levels: pciX.ideX.channelX[.driveX] */
+ lvl = 0;
+ for (pp=node-parent; pp; pp=pp-parent) {
+ lvl++;
+ if (aml_searchname(pp, _HID))
+ break;
+ }
+
+ /* Get PCI address and channel */
+ if (lvl == 3) {
+ aml_evalinteger(sc, node-parent, _ADR, 0, NULL,
+ ide-chnl);
+ aml_xgetpci(node-parent, ide-addr);
+ }
+ else if (lvl == 4) {
+ aml_evalinteger(sc, node-parent-parent, _ADR, 0, NULL,
+ ide-chnl);
+ aml_xgetpci(node-parent-parent, ide-addr);
+ }
+ printf(%s %llx channel:%llx\n,
+ aml_nodename(node), ide-addr, ide-chnl);
+
+ aml_register_notify(node-parent, acpiide, acpiide_notify, ide, 0);
+ return 0;
+}
+
int
acpi_match(struct device *parent, void *match, void *aux)
{
@@ -584,6 +681,10 @@ acpi_attach(struct device *parent, struc
/* attach battery, power supply and button devices */
aml_find_node(aml_root, _HID, acpi_foundhid, sc);
+
+ /* Attach IDE bay */
+ aml_find_node(aml_root, _GTF, acpi_foundide, sc);
+ aml_find_node(aml_root, _GTM, acpi_foundide, sc);
/* attach docks */
aml_find_node(aml_root, _DCK, acpi_founddock, sc);
