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
+ * under the same license
*/
#include "config.h"
@@ -13,6 +16,7 @@
#include "sh.h"
#include
+#include
#include
#include
#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
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 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 ^[ I looked at that and it is,... challenging I might have another look because there are a couple more things in ksh that irritate me and now that I broke the seal ;-) > > -d
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
-# include
-/*
- * 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 = strchr(c,
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
#include
#include
#include
#include
#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
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
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
# include
-/*
- * 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 */
- (vo
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 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 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
# include
-/*
- * 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
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
# include
-/*
- * 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
- *
- */
-#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 (Flag(FTALKING) == 0)
- return;
+ int
Re: xterm bug
On Wed, Aug 17, 2011 at 04:11:55PM -0500, Marco Peereboom wrote:
> 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.
>
> 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.c 7 Mar 2011 20:41:27 - 1.17
> +++ button.c 17 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);
> }
>
Actually this seems to be a much better patch.
Index: button.c
===
RCS file: /cvs/xenocara/app/xterm/button.c,v
retrieving revision 1.17
diff -u -p -r1.17 button.c
--- button.c7 Mar 2011 20:41:27 - 1.17
+++ button.c18 Aug 2011 14:12:19 -
@@ -2308,7 +2308,7 @@ SelectSet(XtermWidget xw,
if (!isSameCELL(&(screen->startSel), &(screen->endSel))) {
SaltTextAway(xw, &(screen->startSel), &(screen->endSel), params,
num_params);
} else {
- DisownSelection(xw);
+ ScrnDisownSelection(xw);
}
}
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=show&redirect=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: 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 : 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 10:17:31AM +0200, Mark Kettenis wrote:
> > Date: Wed, 17 Aug 2011 16:11:55 -0500
> > From: Marco Peereboom
> >
> > 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);
> > }
xterm bug
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.
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: Reading RAID 1 volumes is slow
On Fri, Jul 08, 2011 at 09:39:26PM +0200, Piotr Durlej wrote: > Reading RAID 1 volumes can be slow because of the way reads are > interleaved: > > # dd if=/dev/rsd0c of=/dev/null bs=1m count=256 > 256+0 records in > 256+0 records out > 268435456 bytes transferred in 1.841 secs (145780529 bytes/sec) > # dd if=/dev/rsd1c of=/dev/null bs=1m count=256 > 256+0 records in > 256+0 records out > 268435456 bytes transferred in 1.774 secs (151248200 bytes/sec) > # dd if=/dev/rsd2c of=/dev/null bs=1m count=256 > 256+0 records in > 256+0 records out > 268435456 bytes transferred in 4.683 secs (57311236 bytes/sec) > # bioctl sd2 > Volume Status Size Device > softraid0 0 Online 491516657664 sd2 RAID1 > 0 Online 491516657664 0:0.0 noencl > 1 Online 491516657664 0:1.0 noencl > # ^D > > As a workaround I have produced this patch: > > http://www.durlej.net/sr1.diff This only helps sequential reads. I think under real load this is a total wash. What if you picked the slow drive? What if you are doing heavy writes at the same time too? > > Implementing split seeks might further improve read performance, > especially as far as concurrent requests are concerned. > > Regards, > Piotr
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
> #include
>
> -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)
> -
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: 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
> >
Re: aucat: suggest using -v100 ?
sane defaults. I agree with stu. On Thu, May 26, 2011 at 12:01:22PM +0200, Alexandre Ratchov wrote: > On Thu, May 26, 2011 at 10:31:33AM +0100, Stuart Henderson wrote: > > On 2011/05/26 09:56, Alexandre Ratchov wrote: > > > This is to suggest using -v100 to avoid volume jumps when more than > > > one stream are played at the same time. > > > > > > OK? > > > > > > Or should we just say ``for normal use: -v100'', assuming nowadays > > > nobody listens to a single stream at the same :) > > > > Would it make sense to make -v100 the default, then people who > > wish to retain full dynamic range can set -v127? > > I'd like to avoid having different defaults for files (-i) and > sub-devices (-s). And making -v100 the default would be unpractical > for playing files or for off-line processing. > > -- Alexandre
Re: Panic in sr_crypto_rw with kern.bufcachepercent >= 75
On Fri, May 20, 2011 at 02:45:04PM +0200, Mike Belopuhov 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.
This is correct. Please commit.
>
> 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();
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 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
> 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 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
> wrote:
> >> >> From: Vadim Zhukov
> >> >> 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: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
I think this is great. I find our current code odd and I agree this is
what one expects.
On Wed, May 11, 2011 at 02:50:36AM +0300, Sviatoslav Chagaev wrote:
> I'm sitting at work, listening to music, debugging a web-application
> with JavaScript alert()s. Each time an alert window pops up, the
> browser plays a sound. For a brief moment, the volume drops twicefold
> then goes back to normal. This is annoying and doesn't make sense.
>
> In real life, if you are surrounded by multiple sound sources, their
> sound volumes will not be divided by the total amount of sound sources.
> Their sounds will add up until they blur and you can't distinguish
> anything anymore. Other operating systems, such as Macrohard Doors, do
> mixing by modeling this real world behaviour.
>
> In this sense, aucat violates the principle of least surprise.
> I'm used to how sound interacts in real world and then aucat steps in
> and introduces it's own laws of physics.
>
> To remedy this, aucat has an option -v, which lets you pre-divide the
> volume of inputs. This results in loss of dynamic range (quiet sounds
> might disappear and the maximum volume that you can set decreases). And
> also, if during usage the count of inputs raises above of what I
> predicted, the volume starts to jump up and down again.
>
> Experimentally, I've found that if you do a saturating addition between
> inputs, it sounds very much how it might have sounded in real world and
> how Macrohard Doors, among others, sounds like when playing
> multiple sounds.
>
>
> So, why is what I'm proposing better than what currently exists:
>
> * Resembles how sound behaves in real world more closely;
> * Doesn't violate the principle of least surprise;
> * No more annoying volume jumps up and down;
> * No need to use the -v option anymore / less stuff to remember / "it
> just works";
> * No more choosing between being annoyed by volume jumps or loosing
> dynamic range.
>
> (This doesn't affect the -v option, it remains fully functional.)
>
> Tested on i386 and amd64 with 16 bits and 24 bits.
>
>
> Index: abuf.h
> ===
> RCS file: /OpenBSD/src/usr.bin/aucat/abuf.h,v
> retrieving revision 1.23
> diff -u -r1.23 abuf.h
> --- abuf.h21 Oct 2010 18:57:42 - 1.23
> +++ abuf.h10 May 2011 22:58:18 -
> @@ -46,7 +46,6 @@
> union {
> struct {
> int weight; /* dynamic range */
> - int maxweight; /* max dynamic range allowed */
> unsigned vol; /* volume within the dynamic range */
> unsigned done; /* frames ready */
> unsigned xrun; /* underrun policy */
> Index: aparams.h
> ===
> RCS file: /OpenBSD/src/usr.bin/aucat/aparams.h,v
> retrieving revision 1.11
> diff -u -r1.11 aparams.h
> --- aparams.h 5 Nov 2010 16:42:17 - 1.11
> +++ aparams.h 10 May 2011 22:58:18 -
> @@ -19,6 +19,8 @@
>
> #include
>
> +#include
> +
> #define NCHAN_MAX16 /* max channel in a stream */
> #define RATE_MIN 4000/* min sample rate */
> #define RATE_MAX 192000 /* max sample rate */
> @@ -64,6 +66,9 @@
>
> typedef short adata_t;
>
> +#define ADATA_MINSHRT_MIN
> +#define ADATA_MAXSHRT_MAX
> +
> #define ADATA_MUL(x,y) (((int)(x) * (int)(y)) >> (ADATA_BITS -
> 1))
> #define ADATA_MULDIV(x,y,z) ((int)(x) * (int)(y) / (int)(z))
>
> @@ -71,6 +76,9 @@
>
> typedef int adata_t;
>
> +#define ADATA_MIN(-0xff / 2)
> +#define ADATA_MAX(0xff / 2)
> +
> #if defined(__i386__) && defined(__GNUC__)
>
> static inline int
> @@ -119,6 +127,28 @@
> #else
> #error "only 16-bit and 24-bit precisions are supported"
> #endif
> +
> +/* saturating addition */
> +static inline adata_t
> +adata_sadd(register adata_t x, register adata_t y)
> +{
> +#if ADATA_BITS <= 16
> + register int sum;
> +#else
> + register long long sum;
> +#endif
> +
> + sum = x;
> + sum += y;
> +
> + if (sum < ADATA_MIN)
> + sum = ADATA_MIN;
> + else if (sum > ADATA_MAX)
> + sum = ADATA_MAX;
> +
> + return (adata_t) sum;
> +}
> +#define ADATA_SADD(x,y) adata_sadd(x,y)
>
> #define MIDI_MAXCTL 127
> #define MIDI_TO_ADATA(m) (aparams_ctltovol[m] << (ADATA_BITS - 16))
> Index: aproc.c
> ===
> RCS file: /OpenBSD/src/usr.bin/aucat/aproc.c,v
> retrieving revision 1.64
> diff -u -r1.64 aproc.c
> --- aproc.c 28 Apr 2011 07:20:03 - 1.64
> +++ aproc.c 10 May 2011 22:58:19 -
> @@ -617,6 +617,7 @@
> unsigned i, j, cc, istart, inext, onext, ostart;
> unsigned scount, icount, ocount;
> int vol;
> + adata_t sample;
>
> #ifdef DEBUG
> if (de
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Tue, May 10, 2011 at 12:33:15PM -0500, Amit Kulkarni wrote: > > system32 <- 64 bit dll + apps > > sysWOW <- 32 bit dll + apps > > > > How's that for backwards compatibility. > > > > That's utterly ridiculous. The guy responsible for such things should > be fired :) It works and the users don't know it did. Why does he have to be fired? Compare that to the Linux model.
Re: Filesystem Hierarchy Standard (FHS) and OpenBSD
On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote: > (Sorry if this isn't the proper list for this discussion. If not, > please point me in the right direction.) > > The Linux Foundation's LSB workgroup has taken over maintenance of > the Filesystem Hierarchy Standard, and is working on a number of > updates needed since its last release in 2004. > > Despite all the "Linux" in the names above, we're wanting to make > sure that the FHS remains independent of any particular UNIX > implementation, and continues to be useful to non-Linux UNIXes. Linux is very compatible with Linux and nothing else. Give it up, call it a day. It doesn't even remotely resemble UNIX. > > My question to you is: do you consider the FHS to be relevant to > current and future development of OpenBSD? If not, is this simply > due to lack of maintenance; would your interest in the FHS be > greater with more consistent updates? > > If you are interested, consider this an invitation to participate. > We've set up a mailing list, Web site, etc., and are reviving the > old bug tracker. More details can be found here: > > http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs
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_ASUS"ASUS010" /* 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 80
> 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
Re: softraid iopoolification
tested with all relevant softraid disciplines. ok
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 wrote: > On 4/2/11, Paul Irofti 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 03:15:59PM +0100, Stuart Henderson wrote: > On 2011/03/31 08:29, Marco Peereboom wrote: > > On Thu, Mar 31, 2011 at 09:13:41AM +, Stuart Henderson wrote: > > > On 2011-03-31, Otto Moerbeek 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. > > Typical fsck times on my large partitions holding e.g. music or video > go down from hours to minutes. This is enough of a win that I really > don't care whether it changes anything at runtime. I think I didn't make my point correctly. The parameters you suggested work great. Pretty much all the other ones do not.
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 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
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: 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 > > > > 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
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: ATAPI 5/cdrom
> removable
> cd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 3
> wd0 at pciide1 channel 1 drive 0:
> 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
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: use bswapq for swap64 on amd64
http://stallman.org/Portrait_-_Denmark_DTU_2007-3-31.jpg On Fri, Mar 11, 2011 at 08:28:06PM +0200, Paul Irofti wrote: > On Fri, Mar 11, 2011 at 09:31:57AM -0800, Matthew Dempsky wrote: > > On Fri, Mar 11, 2011 at 9:26 AM, Paul Irofti wrote: > > > bswap r64 is the way to do it, but I'm not sure what the second line is > > > supposed to do. > > > > It's just the syntax for GCC's "Statements and Declarations in > > Expressions" extension: > > > > http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs > > Then okay pirofti@. > > Boy, gcc is so excrutiatingly ugly.
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 > > > > > > > > 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 > > > > > > > > > > > > > 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; >
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: [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 > > 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 > > >> 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: 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 > > 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_
Re: OpenBSD 4.8 RAID 0+1 or 1+0 or 5
On Tue, Feb 15, 2011 at 06:52:58PM -0500, Steven R. Gerber wrote: > On 2/15/2011 5:52 PM, Marco Peereboom wrote: > > it isn't supported so don't do it. it is in the pipeline to do stacked > > raid sets but it is all talk for now. > > > > On Tue, Feb 15, 2011 at 02:45:13PM -0500, Steven R. Gerber wrote: > >> Sorry for cross posting? > >> I am trying to setup a decent RAID (0+1 or 1+0 or 5) and there SEEMS to > >> be no approved method. (4 disks -- I usually like stripe on top of > >> mirrors.) > >> I believe that I have done my homework. > >> What are my options? > [SNIP] > >> > >> Both ccd and RAIDframe are decprecated (FAQ 14.13): > [SNIP] > >> RAID 5 is experimental (man bioctl): > [SNIP] > >> Thanks, > >> Steven > > Understood. I need/want to use 4 drives. > But, RAID 5 is still experimental, right? > Please, give me some guidance. Should I just fall back to ccd? Should > I try to debug my setup re. softraid RAID 5? ccd != raid. Not even remotely. Don't use it. Causes global warming etc. Raid 1, 0 and crypto are fully supported. Raid 5 is experimental because it doesn't zero parity and doesn't rebuild. I'll need about a week of sitting down with these issues to call it a day. Now getting me to sit down for a week is the hard part... > > Thanks, > Steven
Re: OpenBSD 4.8 RAID 0+1 or 1+0 or 5
it isn't supported so don't do it. it is in the pipeline to do stacked raid sets but it is all talk for now. On Tue, Feb 15, 2011 at 02:45:13PM -0500, Steven R. Gerber wrote: > Sorry for cross posting? > I am trying to setup a decent RAID (0+1 or 1+0 or 5) and there SEEMS to > be no approved method. (4 disks -- I usually like stripe on top of > mirrors.) > I believe that I have done my homework. > What are my options? > > softraid (bioctl) cannot handle stripe on mirrors: > I can easily create 2 mirrors and they survive reboot. > I can create stripe on those mirrors (works -- can create files), but it > does not survive reboot. > Message is device not configured. > > Both ccd and RAIDframe are decprecated (FAQ 14.13): > > Software Options > > OpenBSD supports softraid(4), a framework supporting many kinds of I/O > transformations, including RAID and encryption disciplines. Softraid(4) > is managed using bioctl(8). > > > > OpenBSD also includes RAIDframe (raid(4), requires a custom kernel), > and ccd(4) as historic ways of implementing RAID, but at this point > OpenBSD does not suggest implementing either as a RAID solution for new > installs or reinstalls. > "OpenBSD does not suggest implementing either" > Also, RAIDframe requires a custom kernel and we all know that GENERIC is > preferred. > > RAID 5 is experimental (man bioctl): > > CAVEATS > > Use of the CRYPTO & RAID 4/5 disciplines are currently considered > > experimental. > > > > OpenBSD 4.9December 22, 2010 > OpenBSD 4.9 > > > Also, bioctl would not let me create a RAID 5 set: > # bioctl -iv softraid0 > # bioctl -c 5 -l /dev/sd1a,/dev/sd2a,/dev/sd3a,/dev/sd4a softraid0 > bioctl: BIOCCREATERAID: Invalid argument > # bioctl -iv softraid0 > # dmesg|tail > sd11 at scsibus6 targ 0 lun 0: SCSI2 0/direct > fixed > sd11: 3815436MB, 512 bytes/sec, 7814014721 sec total > sd11 detached > scsibus6 detached > sd10 detached > scsibus5 detached > sd9 detached > scsibus4 detached > softraid0: not part of the same volume > softraid0: can't attach metadata type 0 > > Thanks, > Steven
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) | (1<<31)));
> + for (i = 1000; i; i--) {
^^
really?
> + if (!(I915_READ(I830_HIC) & (1<<31)))
> + 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",
+
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
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
> >
> > 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
Re: New acpi challenges! New Dell XPS blows up in acpivideo!
don't forget to send the amldump
On Wed, Dec 22, 2010 at 04:08:54PM -0500, Kenneth R Westerback wrote:
> Got a new Dell XPS 401 laptop today and booted amd64 -current bsd.mp
> off of a usb stick. It immediately blew up in acpi. bsd.rd did not
> blow up.
>
> There seems to be a minor (i.e. non ddb> causing) issue prior to
> acpivideo:
>
> acpiec0 at acpi0
> acpicpu0 at acpi0acpi0: unable to load \\_PR_.CSDT
> : PSS
> acpicpu1 at acpi0: PSS
>
>
> Hand transcribed:
>
>
> acpivideo at acpi0: GFX0
> 0x801d6788 cnt:01 stk: 00 objref: 0x801c3c08
> index: 0 opcode: Cond Ref
> [\HDOS] 0x801c3c08 cnt: 04 stk: 00 method: 08
> Could not convert 101 to 1
> 6a58 Called: \_SB_.PCI0.GFX0._DOS
> arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
> 6a5c Called: \_SB_.PCI0.GFX0._DOS
> arg0: 0x801d1a08 cnt: 01 stk: 00 integer: 4
> panic: aml_die aml_xconvert:2052
>
> ddb{0}> trace
> _aml_die
> aml_xconvert
> aml_xstore
> aml_xparse
> aml_xeval
> aml_evalnode
> acpivideo_set_policy
> acpivideo_attach
> config_attach
> acpi_foundvideo
> aml_found_node
> aml_found_node
> aml_found_node
> aml_found_node
> aml_found_node
> acpi_attach
> config_attach
> bios_attach
> config_attach
> mainbus_attach
> config_attach
> cpu_configure
> main
>
> Disabling acpivideo via ukc makes bsd.mp boot.
>
> tar of acpidump files attached.
>
> Note that the NVidia 425M is only recognized because I added that
> to pcidevs.
>
> Ken
>
> OpenBSD 4.8-current (GENERIC.MP) #3: Wed Dec 22 12:37:54 EST 2010
> r...@tbay.westerback.ca:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 3151962112 (3005MB)
> avail mem = 3054088192 (2912MB)
> User Kernel Config
> UKC> disable acpivido\^H \^Hep\^H \^Ho
> 351 acpivideo* disabled
> UKC> quit
> Continuing...
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb6d0 (56 entries)
> bios0: vendor Dell Inc. version "A04" date 10/15/2010
> bios0: Dell Inc. XPS L401X
> acpi0 at bios0: rev 3
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC SSDT MCFG SLIC HPET OSFR SSDT
> acpi0: wakeup devices P0P1(S3) P0P2(S3) P0P3(S3) P0P4(S3) P0P5(S3) BR20(S3)
> EUSB(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S4) USB4(S3) USB5(S3)
> USB6(S3) PEX0(S3) PEX1(S3) PEX2(S3) PEX3(S3) PEX4(S3) PEX5(S3) PEX6(S3)
> PEX7(S3) SLPB(S0) LID0(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1862.26 MHz
> cpu0:
> FPU,VME,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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: apic clock running at 132MHz
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu1:
> FPU,VME,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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu2:
> FPU,VME,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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu3:
> FPU,VME,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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu4:
> FPU,VME,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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu5 at mainbus0: apid 3 (application processor)
> cpu5: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu5:
> FPU,VME,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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG
> cpu5: 256KB 64b/line 8-way L2 cache
> cpu6 at mainbus0: apid 5 (application processor)
> cpu6: Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz, 1861.99 MHz
> cpu6:
> FPU,VME,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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LO
Re: softraid(4) disks are of wrong size
I am working on this bug and it is a side effect of wrapping VOP_* calls. krw meanwhile commited a fix for the bug that exposed the panic and should make your test case happy. The underlying bug needs more work though but I am working on it. On Mon, Dec 20, 2010 at 06:59:00PM +0100, Andreas Bartelt wrote: > On 12/20/10 18:26, Kenneth R Westerback wrote: > ... > >Can you provide the details on the exact panic you saw? Just to make sure > >when an issue is reproduced we know we are working on the same problem. > > > > Debugger > panic > sr_crypto_finish_io > sr_crypto_intr > sdstrategy > spec_strategy > VOP_STRATEGY > sr_startwu_callback > > sd.c:572 calls bounds_check_with_label (in kern/subr_disk.c) which > returns '-1' in line 698. My assumption was that this eventually > leads to the panic.
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);
[jor...@cvs.openbsd.org: ACPI new fulltask diff]
As promised.
This needs lots of testing so apply, test and reply to jordan and me please.
- Forwarded message from Jordan Hargrave -
Date: Wed, 15 Dec 2010 19:06:26 -0700 (MST)
From: Jordan Hargrave
To: ma...@openbsd.org
Subject: ACPI new fulltask diff
This is a modified acpitask patch that adds all the power/sleep functionality
to the task queue.
It gets rid of all the unecessary state variables in the acpi softc.
This works on the VAIO box that has the infinite wait in the startup AML
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.221
diff -u -p -b -r1.221 acpi.c
--- acpi.c 31 Oct 2010 21:52:46 - 1.221
+++ acpi.c 2 Dec 2010 00:29:23 -
@@ -86,6 +86,10 @@ struct acpi_q *acpi_maptable(struct acpi
void acpi_init_states(struct acpi_softc *);
+void acpi_gpe_task(void *, int);
+void acpi_sbtn_task(void *, int);
+void acpi_pbtn_task(void *, int);
+
#ifndef SMALL_KERNEL
intacpi_thinkpad_enabled;
@@ -1204,6 +1208,54 @@ acpi_init_states(struct acpi_softc *sc)
}
}
+/* ACPI Workqueue support */
+SIMPLEQ_HEAD(,acpi_taskq) acpi_taskq =
+SIMPLEQ_HEAD_INITIALIZER(acpi_taskq);
+
+void
+acpi_addtask(struct acpi_softc *sc, void (*handler)(void *, int),
+void *arg0, int arg1)
+{
+ struct acpi_taskq *wq;
+ int s;
+
+ wq = malloc(sizeof(*wq), M_DEVBUF, M_ZERO | M_NOWAIT);
+ if (wq == NULL)
+ return;
+ wq->handler = handler;
+ wq->arg0 = arg0;
+ wq->arg1 = arg1;
+
+ s = spltty();
+ SIMPLEQ_INSERT_TAIL(&acpi_taskq, wq, next);
+ splx(s);
+}
+
+int
+acpi_dotask(struct acpi_softc *sc)
+{
+ struct acpi_taskq *wq;
+ int s;
+
+ s = spltty();
+ if (SIMPLEQ_EMPTY(&acpi_taskq)) {
+ splx(s);
+
+ /* we don't have anything to do */
+ return (0);
+ }
+ wq = SIMPLEQ_FIRST(&acpi_taskq);
+ SIMPLEQ_REMOVE_HEAD(&acpi_taskq, next);
+ splx(s);
+
+ wq->handler(wq->arg0, wq->arg1);
+
+ free(wq, M_DEVBUF);
+
+ /* We did something */
+ return (1);
+}
+
#ifndef SMALL_KERNEL
int
is_ata(struct aml_node *node)
@@ -1346,6 +1398,82 @@ acpi_reset(void)
delay(10);
}
+void
+acpi_gpe_task(void *arg0, int gpe)
+{
+ struct acpi_softc *sc = acpi_softc;
+ struct gpe_block *pgpe = &sc->gpe_table[gpe];
+
+ dnprintf(10, "handle gpe: %x\n", gpe);
+ if (pgpe->handler && pgpe->active) {
+ pgpe->active = 0;
+ pgpe->handler(sc, gpe, pgpe->arg);
+ }
+}
+
+void
+acpi_pbtn_task(void *arg0, int dummy)
+{
+ struct acpi_softc *sc = arg0;
+ uint16_t en;
+ int s;
+
+ dnprintf(1,"power button pressed\n");
+
+ /* Reset the latch and re-enable the GPE */
+ s = spltty();
+ en = acpi_read_pmreg(sc, ACPIREG_PM1_EN, 0);
+ acpi_write_pmreg(sc, ACPIREG_PM1_EN, 0,
+ en | ACPI_PM1_PWRBTN_EN);
+ splx(s);
+
+ acpi_addtask(sc, acpi_powerdown_task, sc, 0);
+}
+
+void
+acpi_sbtn_task(void *arg0, int dummy)
+{
+ struct acpi_softc *sc = arg0;
+ uint16_t en;
+ int s;
+
+ dnprintf(1,"sleep button pressed\n");
+ aml_notify_dev(ACPI_DEV_SBD, 0x80);
+
+ /* Reset the latch and re-enable the GPE */
+ s = spltty();
+ en = acpi_read_pmreg(sc, ACPIREG_PM1_EN, 0);
+ acpi_write_pmreg(sc, ACPIREG_PM1_EN, 0,
+ en | ACPI_PM1_SLPBTN_EN);
+ splx(s);
+}
+
+void
+acpi_powerdown_task(void *arg0, int dummy)
+{
+ /* XXX put a knob in front of this */
+ psignal(initproc, SIGUSR2);
+}
+
+void
+acpi_sleep_task(void *arg0, int sleepmode)
+{
+ struct acpi_softc *sc = arg0;
+ struct acpi_ac *ac;
+ struct acpi_bat *bat;
+
+ /* System goes to sleep here.. */
+ acpi_sleep_state(sc, sleepmode);
+
+ /* AC and battery information needs refreshing */
+ SLIST_FOREACH(ac, &sc->sc_ac, aac_link)
+ aml_notify(ac->aac_softc->sc_devnode,
+ 0x80);
+ SLIST_FOREACH(bat, &sc->sc_bat, aba_link)
+ aml_notify(bat->aba_softc->sc_devnode,
+ 0x80);
+}
+
int
acpi_interrupt(void *arg)
{
@@ -1366,6 +1494,8 @@ acpi_interrupt(void *arg)
if (en & sts & (1L << jdx)) {
/* Signal this GPE */
sc->gpe_table[idx+jdx].active = 1;
+ dnprintf(10, "queue gpe: %x\n",
idx+jdx);
+ acpi_addtask(sc, acpi_gpe_task, NULL,
idx+jdx);
/*
* Edge interrupts need their STS bits
@@ -1395,7 +1525,8 @@ acpi_interrupt(void *arg)
acpi_write_pmreg(sc, ACPIREG_PM1_STS, 0,
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 acpit
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 > > > > $ 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: 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
> #include
> #include
> +#include
> #include
> #include
>
> -#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: 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-misc&m=125613898224309&w=2
>
> On Tue, Nov 30, 2010 at 5:16 AM, Marco Peereboom 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: 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: 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
Got tons of great test results but still not an independent RAID 1
rebuild. I really want to commit this but I won't until someone else
besides me tests this.
On Thu, Oct 21, 2010 at 02:17:58PM -0500, Marco Peereboom wrote:
> 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.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(cc
Re: softraid cleanup
Groovy. Still waiting for a rebuild report. On Oct 24, 2010, at 14:20, Tobias Ulmer 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
&
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;
-
Re: acpiec madness (HP laptop people pay attention to this one)
Nothing more than paranoia from when I was farting with this. I am sure
it can be non volatile too. I got a useful report that there are still
some issues with this so I am going to plow ahead with the state machine
version jordan drafted.
On Sun, Oct 03, 2010 at 06:19:50PM +0200, Mark Kettenis wrote:
> > Date: Sun, 3 Oct 2010 11:09:17 -0500
> > From: Marco Peereboom
> >
> > 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;
>
> Why are you making 'stat' volatile?
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) {
-
Re: de-static uvm_swap
Kill em dead
On Sep 24, 2010, at 17:33, Thordur Bjornsson 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 */
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 -static int bios_is_32bit; +intbios_is_32bit; u_int kl_n_shift = 32; intarcbios_init(void);
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
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.
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: 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: 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: patch_bioctl_F.patch (inline)
We want patches done with diff -uNp please.
On Sun, Sep 12, 2010 at 10:56:22PM +0200, Merlyn wrote:
> sending the patch fot bioctl
> I'm quite a newbie, so if you find some problem (and you certainly will),
> could you please explain it for me?
> there is a little change from the previous patch - parameter
> has been renamed to -t and expects the number of retries (0 means infinitely).
>
>
> *** /usr/src/sbin/bioctl/bioctl.c Sun Sep 12 00:15:18 2010
> --- /usr/src/sbin/bioctl/bioctl.c Sun Sep 12 23:41:27 2010
> ***
> *** 71,77
> voidbio_setstate(char *, int, char *);
> voidbio_setblink(char *, char *, int);
> voidbio_blink(char *, int, int);
> ! voidbio_createraid(u_int16_t, char *, char *);
> voidbio_deleteraid(char *);
> voidbio_changepass(char *);
> u_int32_t bio_createflags(char *);
> --- 71,77
> voidbio_setstate(char *, int, char *);
> voidbio_setblink(char *, char *, int);
> voidbio_blink(char *, int, int);
> ! int bio_createraid(u_int16_t, char *, char *);
> voidbio_deleteraid(char *);
> voidbio_changepass(char *);
> u_int32_t bio_createflags(char *);
> ***
> *** 102,112
> int ss_func = 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:vu:")) !=
> -1) {
> switch (ch) {
> case 'a': /* alarm */
> --- 102,115
> 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:t:vu:")) !=
> -1) {
> switch (ch) {
> case 'a': /* alarm */
> ***
> *** 132,137
> --- 135,148
> /* 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,240
> errx(1, "need -l parameter");
> if (!biodev)
> errx(1, "must use bio device");
> ! bio_createraid(cr_level, dev_list, key_disk);
> }
>
> return (0);
> --- 245,264
> errx(1, "need -l parameter");
> if (!biodev)
> errx(1, "must use bio device");
> ! if (more_tries == 1){
> ! if ( retries == 0 ){
> ! do {
> ! success=bio_createraid(cr_level,
> dev_list, key_disk);
> ! } while ( success == -1 );
> ! } else {
> ! do {
> ! success=bio_createraid(cr_level,
> dev_list, key_disk);
> ! } while ( --retries > 0 && success == -1 );
> ! }
> ! } else {
> ! bio_createraid(cr_level, dev_list, key_disk);
> ! }
> !
> }
>
> return (0);
> ***
> *** 685,691
> close(bioh);
> }
>
> ! void
> bio_createraid(u_int16_t level, char *dev_list, char *key_disk)
> {
> struct bioc_createraid create;
> --- 709,715
> close(bioh);
> }
>
> ! int
> bio_createraid(u_int16_t level, char *dev_list, char *key_disk)
> {
> struct bioc_createraid create;
> ***
> *** 798,805
> memset(&kdfinfo, 0, sizeof(kdfinfo));
> memset(&create, 0, sizeof(create));
> if (rv == -1) {
> ! if (errno == EPERM)
> ! errx(1, "Incorrect passphrase");
> err(1, "BIOCCREATERAID");
> }
>
> --- 822,831
> memset(&kdfinfo, 0, sizeof(kdfinfo));
> memset(&create, 0, sizeof(create));
> if (rv == -1) {
> ! if (errno == EPERM) {
Re: bioctl.c and /etc/rc patches
Thib is right. I for one can't be bothered to look at patches I need to do special stuff to. mutt or pine work just fine when using a real text editor. On Sun, Sep 12, 2010 at 07:04:01PM +, Thordur I Bjornsson wrote: > On Sun, Sep 12, 2010 at 11:44:12AM +0200, merlyn wrote: > > I found out (thanks Stuart Henderson), that kmail replaces tabs with > > spaces, so patch is not appliable, so I've uploaded the patches here: > This is the complication. > > When looking at diffs, people want them _in the message body_ not because > they are lazy and don't want to jump through hoops to see the diffs (well > people are lazy and will not jump through the hoops so...) but because it > makes talking about the diffs easier, e.g. inline comments. > > If you can't be bothered to spend some time to fix your mailer or switch > a mailer that doesn't fuck up your outgoing mails, why should people and > specially developers bother jumping through hoops trying to read your diffs ? > > I'm not throwing dirt, but fix your mailer and don't demand an exception > to a process that has been in use for years. Diffs go inline into the body > of your mail. > > From the looks of the name of the diffs, this could be neat, but I'm lazy. > > Nice to see people taking an interest in bioctl though! :) > > Ciao, thib. > > > http://merlyn.cz/patch_bioctl_F.patch > > http://merlyn.cz/patch_rc.patch > > And example softraid.conf > > http://merlyn.cz/softraid.conf > > > > Sorry for complications > > > > > > -- > > merlyn > > OpenBSD ufo.merlyn.cz 4.8 GENERIC#1 i386
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: cut swap over to bufq
> > +/* Abuse bufq_fifo, for swapping to regular files. */
> > +struct bufq_swapreg {
> > + SIMPLEQ_ENTRY(buf) bqf_entries;
> > + struct workq_task bqf_wqtask;
> > +
> > +};
>
> BIKESHED: Perhaps this should be:
>
> struct bufq_swapreg {
> struct bufq_fifobfs_fifo;
> struct workq_task bqs_wqtask;
ugh, no.
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: Backout mclgeti for vr(4).
My vr on my firewall hangs for a while until the watchdog kicks it in the pants every time I push a little traffic through it. I'd love to see thibs thing go in. On Mon, Aug 30, 2010 at 11:46:20PM +, Thordur I Bjornsson wrote: > On Mon, Aug 30, 2010 at 06:46:53PM -0400, Brynet wrote: > > Evening, > > > > I have two machines with vr(4) interfaces running 4.7, and I can't seem > > to find any problem running ping -f against them. > > > > vr0 at pci0 dev 12 function 0 "VIA VT6105 RhineIII" rev 0x86: apic 2 int > > 19 (irq 10), address 00:19:5b:82:a1:e0 > > vr0 at pci0 dev 16 function 0 "VIA Rhine/RhineII" rev 0x06: irq 9, > > address 00:50:ba:bd:89:4d > > > > Is it possible that this bug only effects a few models? > Possible. I can't remember what model I had (as I no longer have access > to the machines) but it was a soekris. > > It was pretty easy for me to crash the machine, ~8 ping -f's (from > two different hosts on a 1G lan).
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
> 7f
> 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 De
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.
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
#include
+#include
#include
#include
@@ -32,6 +33,8 @@
#include
+#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",
+ DEVNAME(sc), scratch);
+
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
};
softraid using workq for VOP_STRATEGY take 2
kettenis@ pointed out a misuse of workq_add_task. This diff fixes that.
Please test. And I mean every arch and every raid level!
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 30 Jul 2010 12:19:50 -
@@ -128,6 +128,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
@@ -571,16 +572,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 +1634,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 +1659,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 +1672,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 +1681,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 +1691,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 +1721,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 +1749,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 +1768,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 +1782,7 @@ sr_wu_put(struct sr_workunit *wu)
wu->swu_fake = 0;
wu->swu_flags = 0;
+ mtx_en
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);
Re: acpivideo: don't try to attach to non-existent devices
On Mon, Jul 26, 2010 at 03:20:42PM +0300, Paul Irofti wrote: > On Sun, Jul 25, 2010 at 10:45:04PM +0200, Mark Kettenis wrote: > > > Date: Sat, 24 Jul 2010 22:50:39 +0200 > > > From: Mike Belopuhov > > > > > > Hi, > > > > > > the following diff fixes a hang on boot when acpivideo(4) tries to > > > evaluate _DOD method for nonexistent video device. > > > > > > Long story short, there are crappy laptops out there (like Samsung Q45) > > > that have modifications with advanced video cards (nVidia) and regular > > > Intel ones. To save costs [or for whatever other reasons] manufacturer > > > uses the same ACPI config for both modifications. > > > > > > In this case there are two acpivideo devices: NVID and GFX0 with ADRs > > > Zero and 0x0002 respectively, so it seems natural to knock out NVID > > > by checking its ADR. FWIW, Linux also checks for device presence in a > > > similar manner. > > > > I don't think this will work. A fair number of machines have a video > > card at dev 0 function 0, which would translate into _ADR being zero. > > > > Below is a diff that I have had in my tree for a while to fix a > > similar issue on my Dell laptop. It checks whether the bus on which > > the card supposedly sits really exists. > > Didn't I okay this diff during c2k10? I think I did too but this ties into the pci->dev stuff jordan is working on.
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;
IO sorting
New drives have much more sophisticated IO queueing algorithms and posses much more information about the physical limitations of drive platters (or lack thereof) than an OS can ever hope to have. So switch SCSI (and SATA) drives to use the shiny new bufq that does not sort IOs. Essentially this keeps IOs closer to the drive. The impact I have seen is negligible noise in sequential IO however random IO seems to get a 20 - 25 % performance benefit. I'd like to commit this soon so speak now or forever hold your piece. Index: sd.c === RCS file: /cvs/src/sys/scsi/sd.c,v retrieving revision 1.198 diff -u -p -r1.198 sd.c --- sd.c28 Jun 2010 08:35:46 - 1.198 +++ sd.c30 Jun 2010 18:38:20 - @@ -182,7 +182,11 @@ sdattach(struct device *parent, struct d */ sc->sc_dk.dk_driver = &sddkdriver; sc->sc_dk.dk_name = sc->sc_dev.dv_xname; - sc->sc_bufq = bufq_init(BUFQ_DEFAULT); + + if (SCSISPC(sc_link->inqdata.version) >= 2) + sc->sc_bufq = bufq_init(BUFQ_FIFO); + else + sc->sc_bufq = bufq_init(BUFQ_DEFAULT); if ((sc_link->flags & SDEV_ATAPI) && (sc_link->flags & SDEV_REMOVABLE)) sc_link->quirks |= SDEV_NOSYNCCACHE;
Re: Patch for bogus pointer arithmetic in adw(4)
Except that bcopy always works and memcpy doesn't. Sure it is historic. History is riddled with mistakes. BTW I grew up on memcpy and I always found it a stupid API, same is true for str* functions and original intel assembly. They all got it backwards. On Tue, Jun 22, 2010 at 06:00:33PM -0700, Marco S Hyman wrote: > > 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~%!^% > > Bullshit. If you're going to rail against something at least > get the history correct. > > System III Unix in 1982 had neither > memcpy came with System V in about 1983 > bcopy came with 4.2 bsd in about 1983 > > If you grew up with BSD then bcopy was your friend. > If you grew up with System V then memcpy was your friend. > > It is as simple as that. Whichever one you learned first > tend to be the "natural" order, with the other somehow unnatural. > Until SVR4 and 4.4 BSD there wasn't much choice... you used > the one that came with your release. > > /\/\arc
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 functi
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"
