Re: limit the number of cpus amd64 will attach to the number of cpuinfo slots we have

[David Gwynne]

On Thu, Nov 25, 2010 at 06:04:23PM -0500, Kenneth R Westerback wrote:
> Index: amd64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 cpu.c
> --- amd64/cpu.c   13 Nov 2010 04:16:42 -  1.38
> +++ amd64/cpu.c   25 Nov 2010 23:00:44 -
> @@ -135,8 +135,6 @@ struct cpu_info cpu_info_primary = { 0, 
>  
>  struct cpu_info *cpu_info_list = &cpu_info_primary;
>  
> -u_int32_t cpus_attached = 0;
> -
>  #ifdef MULTIPROCESSOR
>  /*
>   * Array of CPU info structures.  Must be statically-allocated because
> @@ -345,8 +343,6 @@ cpu_attach(struct device *parent, struct
>   panic("unknown processor type??");
>   }
>   cpu_vm_init(ci);
> -
> - cpus_attached |= (1 << ci->ci_cpuid);
>  
>  #if defined(MULTIPROCESSOR)
>   if (mp_verbose) {
> Index: include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/cpu.h,v
> retrieving revision 1.60
> diff -u -p -r1.60 cpu.h
> --- include/cpu.h 22 Nov 2010 21:07:18 -  1.60
> +++ include/cpu.h 25 Nov 2010 23:00:44 -
> @@ -211,8 +211,6 @@ extern struct cpu_info cpu_info_primary;
>  
>  #define aston(p) ((p)->p_md.md_astpending = 1)
>  
> -extern u_int32_t cpus_attached;
> -
>  #define curpcb   curcpu()->ci_curpcb
>  
>  /*

this should follow krws diff above.

information about each cpu is stored in a statically sized array.
if we have more physical cpus than entries in that array, we currently
start storing cpu_info structures in unowned memory after that
array. this leads to Bad Things(tm).

MAXCPUs should be bumped up on amd64, but we should also avoid
panicking on ridiculously overspecced boxes. i am sure i will regret
claiming that a 48core machine is overspecced in the very near
future though.

Index: amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.38
diff -u -p -r1.38 cpu.c
--- amd64/cpu.c 13 Nov 2010 04:16:42 -  1.38
+++ amd64/cpu.c 26 Nov 2010 06:31:53 -
@@ -167,10 +165,24 @@ cpu_match(struct device *parent, void *m
 {
struct cfdata *cf = match;
struct cpu_attach_args *caa = aux;
+   int cpunum;
 
-   if (strcmp(caa->caa_name, cf->cf_driver->cd_name) == 0)
+   /*
+* we cannot attach more cpus than we are set up to store in the
+* cpu_info array, so fail to match if we have more cpus than slots
+* in the array.
+*/
+
+   for (cpunum = 0; cpunum < nitems(cpu_info); cpunum++) {
+   if (cpu_info[cpunum] == NULL)
+   break;
+   }
+
+   if (cpunum < nitems(cpu_info) &&
+   strcmp(caa->caa_name, cf->cf_driver->cd_name) == 0)
return 1;
-   return 0;
+
+   return (0);
 }
 
 static void

Re: limit the number of cpus amd64 will attach to the number of cpuinfo slots we have

[David Gwynne]

On 26/11/2010, at 9:04 AM, Kenneth R Westerback wrote:

> On Thu, Nov 25, 2010 at 02:13:35PM +0100, Mark Kettenis wrote:
>>> From: David Gwynne 
>>> 
>>> without this diff this box panics on boot while attaching the 36th
>>> cpu. its a buffer overrun...
>>> 
>>> analysis done by kettenis.
>>> 
>>> ok?
>> 
>> I think the check should involve MAXCPUS.  Your diff makes clear
>> though that simply bumping MAXCPUS to 64 isn't going to fly.  At the
>> very least cpus_attached needs to be changed into a 64-bit integer.
>> 
>>> Index: cpu.c
>>> ===
>>> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
>>> retrieving revision 1.38
>>> diff -u -p -r1.38 cpu.c
>>> --- cpu.c   13 Nov 2010 04:16:42 -  1.38
>>> +++ cpu.c   24 Nov 2010 13:04:30 -
>>> @@ -168,6 +168,9 @@ cpu_match(struct device *parent, void *m
>>> struct cfdata *cf = match;
>>> struct cpu_attach_args *caa = aux;
>>> 
>>> +   if (~cpus_attached == 0)
>>> +   return 0;
>>> +
>>> if (strcmp(caa->caa_name, cf->cf_driver->cd_name) == 0)
>>> return 1;
>>> return 0;
>> 
> 
> Hmmm. I can't actually find any *use* of cpus_attached. Is it a relic?
> 
> The diff below compiles and runs fine on my 6-proc amd64 box.

make sense to me. ok (for what my ok counts for in this area).

dlg

> 
>  Ken
> 
> Index: amd64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 cpu.c
> --- amd64/cpu.c   13 Nov 2010 04:16:42 -  1.38
> +++ amd64/cpu.c   25 Nov 2010 23:00:44 -
> @@ -135,8 +135,6 @@ struct cpu_info cpu_info_primary = { 0, 
> 
> struct cpu_info *cpu_info_list = &cpu_info_primary;
> 
> -u_int32_t cpus_attached = 0;
> -
> #ifdef MULTIPROCESSOR
> /*
>  * Array of CPU info structures.  Must be statically-allocated because
> @@ -345,8 +343,6 @@ cpu_attach(struct device *parent, struct
>   panic("unknown processor type??");
>   }
>   cpu_vm_init(ci);
> -
> - cpus_attached |= (1 << ci->ci_cpuid);
> 
> #if defined(MULTIPROCESSOR)
>   if (mp_verbose) {
> Index: include/cpu.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/cpu.h,v
> retrieving revision 1.60
> diff -u -p -r1.60 cpu.h
> --- include/cpu.h 22 Nov 2010 21:07:18 -  1.60
> +++ include/cpu.h 25 Nov 2010 23:00:44 -
> @@ -211,8 +211,6 @@ extern struct cpu_info cpu_info_primary;
> 
> #define aston(p)  ((p)->p_md.md_astpending = 1)
> 
> -extern u_int32_t cpus_attached;
> -
> #define curpcbcurcpu()->ci_curpcb
> 
> /*

Re: limit the number of cpus amd64 will attach to the number of cpuinfo slots we have

[Kenneth R Westerback]

On Thu, Nov 25, 2010 at 02:13:35PM +0100, Mark Kettenis wrote:
> > Date: Wed, 24 Nov 2010 23:07:45 +1000
> > From: David Gwynne 
> > X-Scanned-By: MIMEDefang 2.62 on 220.110.80.83
> > List-Owner: 
> > X-Loop: tech@openbsd.org
> > Sender: owner-t...@openbsd.org
> > X-XS4ALL-DNSBL-Checked: mxdrop234.xs4all.nl checked 192.43.244.163 against 
> > DNS blacklists
> > X-CNFS-Analysis: v=1.1 cv=nPak59oIMtOfdVQch4uYmxGPiLR+hhfJMKqCKb05RZs= c=1
> >  sm=0 a=JX5xobAnsNsA:10 a=kj9zAlcOel0A:10 a=A3duGc4wJ8K8BtNzzvyz4A==:17
> >  a=UJL0KVoXsl7s0H4imRkA:9 a=jBQNsEcNSG5iu2jYQfsA:7
> >  a=KW889z4Bgh1uv_EMWkrDp0U9jl4A:4 a=CjuIK1q_8ugA:10 a=NDu43_ybFpjtrQvi:21
> >  a=7GxpAH8eZbexILTH:21 a=A3duGc4wJ8K8BtNzzvyz4A==:117
> > X-Virus-Scanned: by XS4ALL Virus Scanner
> > X-XS4ALL-Spam-Score: 0.0 () none
> > X-XS4ALL-Spam: NO
> > Envelope-To: mark.kette...@xs4all.nl
> > 
> > without this diff this box panics on boot while attaching the 36th
> > cpu. its a buffer overrun...
> > 
> > analysis done by kettenis.
> > 
> > ok?
> 
> I think the check should involve MAXCPUS.  Your diff makes clear
> though that simply bumping MAXCPUS to 64 isn't going to fly.  At the
> very least cpus_attached needs to be changed into a 64-bit integer.
> 
> > Index: cpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> > retrieving revision 1.38
> > diff -u -p -r1.38 cpu.c
> > --- cpu.c   13 Nov 2010 04:16:42 -  1.38
> > +++ cpu.c   24 Nov 2010 13:04:30 -
> > @@ -168,6 +168,9 @@ cpu_match(struct device *parent, void *m
> > struct cfdata *cf = match;
> > struct cpu_attach_args *caa = aux;
> >  
> > +   if (~cpus_attached == 0)
> > +   return 0;
> > +
> > if (strcmp(caa->caa_name, cf->cf_driver->cd_name) == 0)
> > return 1;
> > return 0;
> 

Hmmm. I can't actually find any *use* of cpus_attached. Is it a relic?

The diff below compiles and runs fine on my 6-proc amd64 box.

 Ken

Index: amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.38
diff -u -p -r1.38 cpu.c
--- amd64/cpu.c 13 Nov 2010 04:16:42 -  1.38
+++ amd64/cpu.c 25 Nov 2010 23:00:44 -
@@ -135,8 +135,6 @@ struct cpu_info cpu_info_primary = { 0, 
 
 struct cpu_info *cpu_info_list = &cpu_info_primary;
 
-u_int32_t cpus_attached = 0;
-
 #ifdef MULTIPROCESSOR
 /*
  * Array of CPU info structures.  Must be statically-allocated because
@@ -345,8 +343,6 @@ cpu_attach(struct device *parent, struct
panic("unknown processor type??");
}
cpu_vm_init(ci);
-
-   cpus_attached |= (1 << ci->ci_cpuid);
 
 #if defined(MULTIPROCESSOR)
if (mp_verbose) {
Index: include/cpu.h
===
RCS file: /cvs/src/sys/arch/amd64/include/cpu.h,v
retrieving revision 1.60
diff -u -p -r1.60 cpu.h
--- include/cpu.h   22 Nov 2010 21:07:18 -  1.60
+++ include/cpu.h   25 Nov 2010 23:00:44 -
@@ -211,8 +211,6 @@ extern struct cpu_info cpu_info_primary;
 
 #define aston(p)   ((p)->p_md.md_astpending = 1)
 
-extern u_int32_t cpus_attached;
-
 #define curpcb curcpu()->ci_curpcb
 
 /*

Re: convert netisr to real softinterrupt

[Owain Ainsworth]

On Thu, Nov 25, 2010 at 11:23:42PM +0100, Mark Kettenis wrote:
> > Date: Thu, 25 Nov 2010 12:30:39 +
> > From: Owain Ainsworth 
> > 
> > On Thu, Nov 25, 2010 at 11:50:06AM +0100, Claudio Jeker wrote:
> > > On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> > > > On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > > > > This diff was made by oga@ some time ago -- I just fixed a few 
> > > > > conflicts
> > > > > and I would really like to see this going in.
> > > > > 
> > > > > netisr needs to be made a normal C function and not this madness it
> > > > > currently is. This is necessary to imporve the packet scheduling.
> > > > > 
> > > > > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> > > > 
> > > > hi,
> > > > 
> > > > i like the diff, but why not get rid of netisr_dispatch.h?
> > > 
> > > I planned to this after this diff goes in. I did not want to change
> > > Owain's initial diff too much so I left that out for now.
> > 
> > Miod pointed out to me when I first sent this out that some archs use
> > something slightly different than this generic version.
> > 
> > For example hppa uses a specially aligned netisr variable so it can use
> > the pa-risc real atomic instructions which are quite a bit faster.
> 
> Especially on MP kernels.
> 
> > Similarly x86 uses compare-and-swap instead of test, then clear bits.
> > 
> > I meant to add some MD defines so that this could be kept (falling back
> > to the implementation in this diff)  since miod claims that it is useful
> > and significantly faster (I did not check this). I've cced miod so he
> > can answer with somewhat more authority.
> 
> The hppa and i386/amd64 approach are rather similar.  Both do an
> atomic load and clear, which happens to be the only atomic instruction
> available on hppa, and is easy to implement as an atomic swap with 0
> on i386/amd64.  But implementing this operation on other architectures
> shouldn't be much more difficult, and should work just as well as the
> proposed code that uses atomic_clearbits_int().  The MI code would
> look something like:
> 
> void
> netintr(void *unused)
> {
>   int n;
> 
>   n = atomic_load_and_clear(&netisr);
> #define DONETISR(bit, fn) \
>   do {\
>   if (n & 1 << (bit)) \
>   fn();   \
>   } while ( /* CONSTCOND */ 0)
> #include 
> }

The only other thing to note is that you may need to define a type (or
whatever) since iirc the hppa one needs a specific alignment (cacheline
to itself).

Otherwise I like this approach, it is cleaner than what I was thinking
(not knowing exactly what hppa was doing other than it was faster didn't
help ;).

-0-
-- 
Sometimes I worry about being a success in a mediocre world.
-- Lily Tomlin

small comment typo in lib/libc/stdlib/bsearch.c

[Carlos Alberto Pereira Gomes]

Hi,

I know a one-character typo in a comment is not important, but here is
the diff anyway:


Index: lib/libc/stdlib/bsearch.c
===
RCS file: /home/carlos/cvs/src/lib/libc/stdlib/bsearch.c,v
retrieving revision 1.6
diff -u -r1.6 bsearch.c
--- lib/libc/stdlib/bsearch.c   8 Aug 2005 08:05:36 -   1.6
+++ lib/libc/stdlib/bsearch.c   25 Nov 2010 22:15:49 -
@@ -37,7 +37,7 @@
  * is odd, moving left simply involves halving lim: e.g., when lim
  * is 5 we look at item 2, so we change lim to 2 so that we will
  * look at items 0 & 1.  If lim is even, the same applies.  If lim
- * is odd, moving right again involes halving lim, this time moving
+ * is odd, moving right again involves halving lim, this time moving
  * the base up one item past p: e.g., when lim is 5 we change base
  * to item 3 and make lim 2 so that we will look at items 3 and 4.
  * If lim is even, however, we have to shrink it by one before
 



-- 
Carlos


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: convert netisr to real softinterrupt

[Mark Kettenis]

> Date: Thu, 25 Nov 2010 12:30:39 +
> From: Owain Ainsworth 
> 
> On Thu, Nov 25, 2010 at 11:50:06AM +0100, Claudio Jeker wrote:
> > On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> > > On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > > > This diff was made by oga@ some time ago -- I just fixed a few conflicts
> > > > and I would really like to see this going in.
> > > > 
> > > > netisr needs to be made a normal C function and not this madness it
> > > > currently is. This is necessary to imporve the packet scheduling.
> > > > 
> > > > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> > > 
> > > hi,
> > > 
> > > i like the diff, but why not get rid of netisr_dispatch.h?
> > 
> > I planned to this after this diff goes in. I did not want to change
> > Owain's initial diff too much so I left that out for now.
> 
> Miod pointed out to me when I first sent this out that some archs use
> something slightly different than this generic version.
> 
> For example hppa uses a specially aligned netisr variable so it can use
> the pa-risc real atomic instructions which are quite a bit faster.

Especially on MP kernels.

> Similarly x86 uses compare-and-swap instead of test, then clear bits.
> 
> I meant to add some MD defines so that this could be kept (falling back
> to the implementation in this diff)  since miod claims that it is useful
> and significantly faster (I did not check this). I've cced miod so he
> can answer with somewhat more authority.

The hppa and i386/amd64 approach are rather similar.  Both do an
atomic load and clear, which happens to be the only atomic instruction
available on hppa, and is easy to implement as an atomic swap with 0
on i386/amd64.  But implementing this operation on other architectures
shouldn't be much more difficult, and should work just as well as the
proposed code that uses atomic_clearbits_int().  The MI code would
look something like:

void
netintr(void *unused)
{
int n;

n = atomic_load_and_clear(&netisr);
#define DONETISR(bit, fn)   \
do {\
if (n & 1 << (bit)) \
fn();   \
} while ( /* CONSTCOND */ 0)
#include 
}

Re: mandoc ZN support

[Ingo Schwarze]

Hi Joerg & Ted,

Joerg Sonnenberger wrote on Thu, Nov 25, 2010 at 02:49:32AM +0100:
> On Wed, Nov 24, 2010 at 08:17:16PM -0500, Ted Unangst wrote:

>> patch below adds "support" for ZN.  i think.  i'm not totally sure
>> what it does, but it makes the words after .ZN show up when i view
>> the page, so it's a big win in my book.

> Ingo is working on proper .de support, so please no more adhoc
> special cases like this.

Actually, i'm planning to commit proper .de support tonight,
including parameter handling, quoting and quote escaping.
Sorry for not getting on with this during the last few weeks.

I'm including the cumulative patch below, it will probably be committed
in two or three steps and may still get minor polishing; main testing
was completed yesterday.

Yours,
  Ingo


Index: roff.h
===
RCS file: /cvs/src/usr.bin/mandoc/roff.h,v
retrieving revision 1.5
diff -u -p -r1.5 roff.h
--- roff.h  26 Oct 2010 22:28:57 -  1.5
+++ roff.h  25 Nov 2010 18:51:54 -
@@ -20,6 +20,8 @@
 enum   rofferr {
ROFF_CONT, /* continue processing line */
ROFF_RERUN, /* re-run roff interpreter with offset */
+   ROFF_APPEND, /* re-run main parser, appending next line */
+   ROFF_REPARSE, /* re-run main parser on the result */
ROFF_SO, /* include another file */
ROFF_IGN, /* ignore current line */
ROFF_ERR /* badness: puke and stop */
Index: roff.c
===
RCS file: /cvs/src/usr.bin/mandoc/roff.c,v
retrieving revision 1.15
diff -u -p -r1.15 roff.c
--- roff.c  26 Oct 2010 23:34:38 -  1.15
+++ roff.c  25 Nov 2010 18:51:54 -
@@ -7,9 +7,9 @@
  * purpose with or without fee is hereby granted, provided that the above
  * copyright notice and this permission notice appear in all copies.
  *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
@@ -54,6 +54,7 @@ enum  rofft {
ROFF_tr,
ROFF_cblock,
ROFF_ccond, /* FIXME: remove this. */
+   ROFF_USERDEF,
ROFF_MAX
 };
 
@@ -76,7 +77,8 @@ structroff {
enum roffrulerstack[RSTACK_MAX]; /* stack of !`ie' rules */
int  rstackpos; /* position in rstack */
struct regset   *regs; /* read/writable registers */
-   struct roffstr  *first_string;
+   struct roffstr  *first_string; /* user-defined strings & macros */
+   const char  *current_string; /* value of last called user macro */
 };
 
 struct roffnode {
@@ -84,6 +86,7 @@ structroffnode {
struct roffnode *parent; /* up one in stack */
int  line; /* parse line */
int  col; /* parse col */
+   char*name; /* node name, e.g. macro name */
char*end; /* end-rules: custom token */
int  endspan; /* end-rules: next-line or infty */
enum roffrulerule; /* current evaluation rule */
@@ -128,9 +131,9 @@ static  enum rofferr roff_nr(ROFF_ARGS);
 static int  roff_res(struct roff *, 
char **, size_t *, int);
 static void roff_setstr(struct roff *,
-   const char *, const char *);
+   const char *, const char *, int);
 static enum rofferr roff_so(ROFF_ARGS);
-static char*roff_strdup(const char *);
+static enum rofferr roff_userdef(ROFF_ARGS);
 
 /* See roff_hash_find() */
 
@@ -158,16 +161,17 @@ staticstruct roffmac   roffs[ROFF_MAX] =
{ "tr", roff_line, NULL, NULL, 0, NULL },
{ ".", roff_cblock, NULL, NULL, 0, NULL },
{ "\\}", roff_ccond, NULL, NULL, 0, NULL },
+   { NULL, roff_userdef, NULL, NULL, 0, NULL },
 };
 
 static void roff_free1(struct roff *);
-static enum rofft   roff_hash_find(const char *);
+static enum rofft   roff_hash_find(const char *, size_t);
 static void roff_hash_init(void);
 static void roffnode_cleanscope(struct roff *);
-static void roffnode_push(struct roff *, 
-   enum rofft, int, int);
+static void roffnode_push(struct roff *, enum rofft,
+   const char *, int, int);
 static void roffnode_pop(struct roff *);
-static enum rofft   roff_parse(const char *, int *)

Re: convert netisr to real softinterrupt

[Henning Brauer]

* Claudio Jeker  [2010-11-25 17:04]:
> I doubt that there is a measurable performance difference on
> i386/amd64. 

yeah, well, "doubt". pls run a quick test.

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Re: convert netisr to real softinterrupt

[Henning Brauer]

* Owain Ainsworth  [2010-11-25 14:26]:
> I also recall asking you (or someone with the right setup) to please do
> that verification, request still stands :).

the last word on this was that you'd run them with remote access to my
test setup

be assured i had long run it if i had found the time

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Re: convert netisr to real softinterrupt

[Claudio Jeker]

On Thu, Nov 25, 2010 at 12:30:39PM +, Owain Ainsworth wrote:
> On Thu, Nov 25, 2010 at 11:50:06AM +0100, Claudio Jeker wrote:
> > On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> > > On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > > > This diff was made by oga@ some time ago -- I just fixed a few conflicts
> > > > and I would really like to see this going in.
> > > > 
> > > > netisr needs to be made a normal C function and not this madness it
> > > > currently is. This is necessary to imporve the packet scheduling.
> > > > 
> > > > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> > > 
> > > hi,
> > > 
> > > i like the diff, but why not get rid of netisr_dispatch.h?
> > 
> > I planned to this after this diff goes in. I did not want to change
> > Owain's initial diff too much so I left that out for now.
> 
> My diff needed some tweaking anyway.
> 
> Miod pointed out to me when I first sent this out that some archs use
> something slightly different than this generic version.
> 
> For example hppa uses a specially aligned netisr variable so it can use
> the pa-risc real atomic instructions which are quite a bit faster.
> 
> Similarly x86 uses compare-and-swap instead of test, then clear bits.
>
> I meant to add some MD defines so that this could be kept (falling back
> to the implementation in this diff)  since miod claims that it is useful
> and significantly faster (I did not check this). I've cced miod so he
> can answer with somewhat more authority.
> 

This is all nice and so but the main reason for me to get the netisr code
into a pure c form is that we need better netisr scheduling. There are
some rather nasty effects because of the current way netisr works and it
has nothing todo with optimising the netisr bitfield itself. 
Some quick tests showed that netisr is causing a >25% drop in forwarding
performance. So fixing netisr and the protocol queues can have a very huge
impact on performance.

If somebody has a good way to allow netisr.c to have MD defines in a clean
way then go for it. I doubt that there is a measurable performance
difference on i386/amd64.

> > 
> > > also i'm not sure, but maybe netisr.c copyright should be
> > > attributed to berkeley as we're using their code directly?
> > 
> > Are we? The current netisr.c code is a generic implementation of using
> > softinterrupts to run the netisr and in the future it will get even more
> > different.  Owain, what do you think? 
> 
> I think my initial mail possibly mentioned that I was unsure if the
> original was needed. Put the original one in there as well if you are
> unsure. I won't try and claim that I'm positive that it was entirely my
> code (too long ago for a start ;).
> 
> Anyway, thanks for taking over this diff, claudio. I'm far too busy
> right now to sort it out.
> 

OK, I will kill netisr_dispatch.h. Diff follows...

-- 
:wq Claudio

Re: More Canon scanners (usbdevs, uscanner.c)

[Mattieu Baptiste]

On Thu, Nov 25, 2010 at 2:28 PM, Mark Kettenis 
wrote:

>
> Just nuke it.  It'll be sitting in the attick if anybody wants it back.
>

Ok, here is a proposed diff that can also be found at:
http://www.brimbelle.org/mattieu/stuff/uscanner.diff

Compile tested on amd64.


Index: sys/dev/usb/uscanner.c
===
RCS file: sys/dev/usb/uscanner.c
diff -N sys/dev/usb/uscanner.c
--- sys/dev/usb/uscanner.c  24 Sep 2010 08:33:59 -  1.43
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,687 +0,0 @@
-/* $OpenBSD: uscanner.c,v 1.43 2010/09/24 08:33:59 yuo Exp $ */
-/* $NetBSD: uscanner.c,v 1.40 2003/01/27 00:32:44 wiz Exp $*/
-
-/*
- * Copyright (c) 2000 The NetBSD Foundation, Inc.
- * All rights reserved.
- *
- * This code is derived from software contributed to The NetBSD Foundation
- * by Lennart Augustsson (lenn...@augustsson.net) at
- * Carlstedt Research & Technology
- * and Nick Hibma (n_hi...@qubesoft.com).
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
- * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR
- * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
- * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-#include 
-
-#ifdef USCANNER_DEBUG
-#define DPRINTF(x) do { if (uscannerdebug) printf x; } while (0)
-#define DPRINTFN(n,x)  do { if (uscannerdebug>(n)) printf x; } while (0)
-intuscannerdebug = 0;
-#else
-#define DPRINTF(x)
-#define DPRINTFN(n,x)
-#endif
-
-struct uscan_info {
-   struct usb_devno devno;
-   u_int flags;
-#define USC_KEEP_OPEN 1
-};
-
-/* Table of scanners that may work with this driver. */
-static const struct uscan_info uscanner_devs[] = {
-  /* Acer Peripherals */
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_320U }, 0 },
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_640U }, 0 },
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_620U }, 0 },
- {{ USB_VENDOR_ACERP, USB_PRODUCT_ACERP_ACERSCAN_C310U }, 0 },
-
-  /* AGFA */
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCAN1236U }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCAN1212U }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCAN1212U2 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANTOUCH }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE40 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE50 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE20 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE25 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE26 }, 0 },
- {{ USB_VENDOR_AGFA, USB_PRODUCT_AGFA_SNAPSCANE52 }, 0 },
-
-  /* Avision */
- {{ USB_VENDOR_AVISION, USB_PRODUCT_AVISION_1200U }, 0 },
-
-  /* Canon */
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N656U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N670U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1220U }, 0 },
- {{ USB_VENDOR_CANON, USB_PRODUCT_CANON_N1240U }, 0 },
-
-  /* Kye */
- {{ USB_VENDOR_KYE, USB_PRODUCT_KYE_VIVIDPRO }, 0 },
-
-  /* HP */
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_2200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_3300C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_3400CSE }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_4100C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_4200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_4300C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_S20 }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_5200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_6200C }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_6300C }, 0 },
-
-  /* Mustek */
- {{ USB_VENDOR_MUSTEK, USB_PRODUCT_MUSTEK_1200CU }, 0 },
- {{ USB_VENDOR_MUSTEK, USB_PRODUCT_MUSTEK_BEARPAW1200F }, 0 },
- {{ USB_VENDOR_MUSTEK, USB_PRODUCT_MUSTEK_600USB }, 0 },
- {{ USB_VENDOR_MUSTEK, USB_

Re: systat and livelocks

[Mark Kettenis]

> Date: Thu, 25 Nov 2010 15:31:38 +0100
> From: Claudio Jeker 
> 
> On Thu, Nov 25, 2010 at 02:57:56PM +0100, Jasper Lievisse Adriaanse wrote:
> > Hi,
> > 
> > Currently the 'mbufs' view of systat only shows the difference of livelocks,
> > this diff also adds the actual total (or sum). This is info most people are
> > actually looking for anyway (as noticed by kettenis and sthen yesterday).
> > 
> 
> Why? The total number of livelocks is just a number it has no
> meaningful value. I also wonder why yet another column needs to be added
> for something that is just printed once. systat mbuf output may actually
> need some rework.

The total number of livelocks tells me how badly my host has been
affected by livelocks in the past.  That is useful to know.  Not sure
whether it is systat's job to report it though.  The sysctl is good
enough for me.

Re: systat and livelocks

[Claudio Jeker]

On Thu, Nov 25, 2010 at 02:57:56PM +0100, Jasper Lievisse Adriaanse wrote:
> Hi,
> 
> Currently the 'mbufs' view of systat only shows the difference of livelocks,
> this diff also adds the actual total (or sum). This is info most people are
> actually looking for anyway (as noticed by kettenis and sthen yesterday).
> 

Why? The total number of livelocks is just a number it has no
meaningful value. I also wonder why yet another column needs to be added
for something that is just printed once. systat mbuf output may actually
need some rework.

> OK?
> 
> -- 
> Cheers,
> Jasper
> 
> "Stay Hungry. Stay Foolish."
> 
> Index: mbufs.c
> ===
> RCS file: /cvs/src/usr.bin/systat/mbufs.c,v
> retrieving revision 1.31
> diff -p -u -r1.31 mbufs.c
> --- mbufs.c   5 Nov 2010 10:07:30 -   1.31
> +++ mbufs.c   25 Nov 2010 13:55:48 -
> @@ -61,7 +61,8 @@ field_def fields_mbuf[] = {
>   {"IFACE", 8, 16, 1, FLD_ALIGN_LEFT, -1, 0, 0, 0},
>   {"RXDELAY", 5, 8, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
>   {"TXDELAY", 5, 8, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
> - {"LIVELOCKS", 5, 10, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
> + {"LIVELOCKS (NOW)", 5, 15, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
> + {"(SUM)", 5, 10, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
>   {"SIZE", 3, 5, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
>   {"ALIVE", 3, 5, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
>   {"LWM", 3, 5, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
> @@ -72,15 +73,16 @@ field_def fields_mbuf[] = {
>  
>  #define FIELD_ADDR(x) (&fields_mbuf[x])
>  
> -#define FLD_MB_IFACE FIELD_ADDR(0)
> -#define FLD_MB_RXDELAY   FIELD_ADDR(1)
> -#define FLD_MB_TXDELAY   FIELD_ADDR(2)
> -#define FLD_MB_LLOCKSFIELD_ADDR(3)
> -#define FLD_MB_MSIZE FIELD_ADDR(4)
> -#define FLD_MB_MALIVEFIELD_ADDR(5)
> -#define FLD_MB_MLWM  FIELD_ADDR(6)
> -#define FLD_MB_MHWM  FIELD_ADDR(7)
> -#define FLD_MB_MCWM  FIELD_ADDR(8)
> +#define FLD_MB_IFACE FIELD_ADDR(0)
> +#define FLD_MB_RXDELAY   FIELD_ADDR(1)
> +#define FLD_MB_TXDELAY   FIELD_ADDR(2)
> +#define FLD_MB_LLOCKS_NOWFIELD_ADDR(3)
> +#define FLD_MB_LLOCKS_SUMFIELD_ADDR(4)
> +#define FLD_MB_MSIZE FIELD_ADDR(5)
> +#define FLD_MB_MALIVEFIELD_ADDR(6)
> +#define FLD_MB_MLWM  FIELD_ADDR(7)
> +#define FLD_MB_MHWM  FIELD_ADDR(8)
> +#define FLD_MB_MCWM  FIELD_ADDR(9)
>  
>  
>  /* Define views */
> @@ -89,7 +91,7 @@ field_def *view_mbuf[] = {
>  #if NOTYET
>   FLD_MB_RXDELAY, FLD_MB_TXDELAY,
>  #endif
> - FLD_MB_LLOCKS, FLD_MB_MSIZE, FLD_MB_MALIVE, FLD_MB_MLWM, FLD_MB_MHWM,
> + FLD_MB_LLOCKS_NOW, FLD_MB_LLOCKS_SUM, FLD_MB_MSIZE, FLD_MB_MALIVE, 
> FLD_MB_MLWM, FLD_MB_MHWM,
>   FLD_MB_MCWM, NULL
>  };
>  
> @@ -353,7 +355,8 @@ showmbuf(struct if_info *ifi, int p, int
>   print_fld_str(FLD_MB_IFACE, ifi->name);
>  
>   if (p == -1 && ifi == interfaces) {
> - print_fld_uint(FLD_MB_LLOCKS, mcllivelocks_diff);
> + print_fld_uint(FLD_MB_LLOCKS_NOW, mcllivelocks_diff);
> + print_fld_uint(FLD_MB_LLOCKS_SUM, mcllivelocks_cur);
>   print_fld_size(FLD_MB_MSIZE, mbpool.pr_size);
>   print_fld_size(FLD_MB_MALIVE, mbpool.pr_nget - mbpool.pr_nput);
>   print_fld_size(FLD_MB_MHWM, mbpool.pr_hiwat);
> 

-- 
:wq Claudio

Re: more usb detach love

[Jacob Meuser]

On Thu, Nov 25, 2010 at 12:45:10PM +, Kevin Chadwick wrote:
> On Wed, 24 Nov 2010 20:59:22 +
> Jacob Meuser  wrote:
> 
> > thoughts?
> 
> Probably not the thoughts your after especially on tech, but some of the
> panics I was seeing a while back (keep meaning to run more recent and
> proper tests with output, but time is short at the mo) would occur just
> after device removal and only with certain usb readers. If I remember
> right, usually after bb_reset messages. This along with other work on
> usb I've seen definately seems to ring bells.
> 
> I'll try to find the time to see if my 4.8 snapshot can be paniced with
> some troublesome readers, though I'm not sure if the ones that were
> troublesome varied on 4.5/4.6? and 4.7. Anyway, If I can, I'll try
> your patch

dlg@ fixed some panics that were caused by removing sd(4) devices not
so long ago, e.g. sys/scsi/sd.c r1.212.  anyway, this patch doesn't
touch umass(4), so it probably isn't a whole lot of help for that
particular case.

for people testing this, I'm more interested that it doesn't break
anything, than that it fixes some particular case, because I already
know that it does fix some particular cases.

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

systat and livelocks

[Jasper Lievisse Adriaanse]

Hi,

Currently the 'mbufs' view of systat only shows the difference of livelocks,
this diff also adds the actual total (or sum). This is info most people are
actually looking for anyway (as noticed by kettenis and sthen yesterday).

OK?

-- 
Cheers,
Jasper

"Stay Hungry. Stay Foolish."

Index: mbufs.c
===
RCS file: /cvs/src/usr.bin/systat/mbufs.c,v
retrieving revision 1.31
diff -p -u -r1.31 mbufs.c
--- mbufs.c 5 Nov 2010 10:07:30 -   1.31
+++ mbufs.c 25 Nov 2010 13:55:48 -
@@ -61,7 +61,8 @@ field_def fields_mbuf[] = {
{"IFACE", 8, 16, 1, FLD_ALIGN_LEFT, -1, 0, 0, 0},
{"RXDELAY", 5, 8, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
{"TXDELAY", 5, 8, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
-   {"LIVELOCKS", 5, 10, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
+   {"LIVELOCKS (NOW)", 5, 15, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
+   {"(SUM)", 5, 10, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
{"SIZE", 3, 5, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
{"ALIVE", 3, 5, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
{"LWM", 3, 5, 1, FLD_ALIGN_RIGHT, -1, 0, 0, 0},
@@ -72,15 +73,16 @@ field_def fields_mbuf[] = {
 
 #define FIELD_ADDR(x) (&fields_mbuf[x])
 
-#define FLD_MB_IFACE   FIELD_ADDR(0)
-#define FLD_MB_RXDELAY FIELD_ADDR(1)
-#define FLD_MB_TXDELAY FIELD_ADDR(2)
-#define FLD_MB_LLOCKS  FIELD_ADDR(3)
-#define FLD_MB_MSIZE   FIELD_ADDR(4)
-#define FLD_MB_MALIVE  FIELD_ADDR(5)
-#define FLD_MB_MLWMFIELD_ADDR(6)
-#define FLD_MB_MHWMFIELD_ADDR(7)
-#define FLD_MB_MCWMFIELD_ADDR(8)
+#define FLD_MB_IFACE   FIELD_ADDR(0)
+#define FLD_MB_RXDELAY FIELD_ADDR(1)
+#define FLD_MB_TXDELAY FIELD_ADDR(2)
+#define FLD_MB_LLOCKS_NOW  FIELD_ADDR(3)
+#define FLD_MB_LLOCKS_SUM  FIELD_ADDR(4)
+#define FLD_MB_MSIZE   FIELD_ADDR(5)
+#define FLD_MB_MALIVE  FIELD_ADDR(6)
+#define FLD_MB_MLWMFIELD_ADDR(7)
+#define FLD_MB_MHWMFIELD_ADDR(8)
+#define FLD_MB_MCWMFIELD_ADDR(9)
 
 
 /* Define views */
@@ -89,7 +91,7 @@ field_def *view_mbuf[] = {
 #if NOTYET
FLD_MB_RXDELAY, FLD_MB_TXDELAY,
 #endif
-   FLD_MB_LLOCKS, FLD_MB_MSIZE, FLD_MB_MALIVE, FLD_MB_MLWM, FLD_MB_MHWM,
+   FLD_MB_LLOCKS_NOW, FLD_MB_LLOCKS_SUM, FLD_MB_MSIZE, FLD_MB_MALIVE, 
FLD_MB_MLWM, FLD_MB_MHWM,
FLD_MB_MCWM, NULL
 };
 
@@ -353,7 +355,8 @@ showmbuf(struct if_info *ifi, int p, int
print_fld_str(FLD_MB_IFACE, ifi->name);
 
if (p == -1 && ifi == interfaces) {
-   print_fld_uint(FLD_MB_LLOCKS, mcllivelocks_diff);
+   print_fld_uint(FLD_MB_LLOCKS_NOW, mcllivelocks_diff);
+   print_fld_uint(FLD_MB_LLOCKS_SUM, mcllivelocks_cur);
print_fld_size(FLD_MB_MSIZE, mbpool.pr_size);
print_fld_size(FLD_MB_MALIVE, mbpool.pr_nget - mbpool.pr_nput);
print_fld_size(FLD_MB_MHWM, mbpool.pr_hiwat);

Re: More Canon scanners (usbdevs, uscanner.c)

[Mark Kettenis]

> Date: Wed, 24 Nov 2010 19:30:22 +
> From: Stuart Henderson 
> 
> On 2010/11/24 19:06, Antoine Jacoutot wrote:
> > On Wed, 24 Nov 2010, Miod Vallat wrote:
> > 
> > > > But is there any reason to keep these devices in uscanner? To my
> > > > knowledge, sane is the only tool to access such devices. Is there
> > > > other software that need uscanner?
> > > > 
> > > > And more generally, is there any reason to keep uscanner?
> > > 
> > > According to the manpage, it was written to provide a linux-compatible
> > > scanner device. If nowadays' scanning applications are perfectly happy
> > > with ugen(4), then I see no point in keeping uscanner(4). Unless I
> > > misunderstood things...
> > 
> > Well, I don't own many scanners. All I can say is that uscanner is 
> > deprecated in linux, they now use libusb. I also do so without issue 
> > but I cannot guess it'll be the same for all scanners around.
> > The expected scenario is that all usb scanners *should* work with libusb 
> > where only some will also work also uscanner.
> > 
> > This calls for testing from people who own such hardware. Personally I'd 
> > be happy to see uscanner move away, I wouldn't have to config(8) my 
> > kernel all the time.
> 
> How about removing uscanner from GENERIC for now, then if nobody
> has a problem with it, remove the code at a later date? (I would
> suggest picking that date in advance so it doesn't sit around for
> ages).

Just nuke it.  It'll be sitting in the attick if anybody wants it back.

Re: convert netisr to real softinterrupt

[Owain Ainsworth]

On Thu, Nov 25, 2010 at 01:41:00PM +0100, Henning Brauer wrote:
> * Owain Ainsworth  [2010-11-25 13:33]:
> > and significantly faster (I did not check this).
> 
> I really want to see a verification that this doesn't slow us down
> before it goes in.
> 
> and no, sorry, "shouldn't be slower" is not good enough.

I was referring to using the MD specific alignment and instructions as
being faster. Not the diff in general (which lacks those tweaks for x86
and hppa).

I also recall asking you (or someone with the right setup) to please do
that verification, request still stands :).

-0-
-- 
Forgetfulness, n.:
A gift of God bestowed upon debtors in compensation for their
destitution of conscience.

Re: limit the number of cpus amd64 will attach to the number of cpuinfo slots we have

[Mark Kettenis]

> Date: Wed, 24 Nov 2010 23:07:45 +1000
> From: David Gwynne 
> X-Scanned-By: MIMEDefang 2.62 on 220.110.80.83
> List-Owner: 
> X-Loop: tech@openbsd.org
> Sender: owner-t...@openbsd.org
> X-XS4ALL-DNSBL-Checked: mxdrop234.xs4all.nl checked 192.43.244.163 against 
> DNS blacklists
> X-CNFS-Analysis: v=1.1 cv=nPak59oIMtOfdVQch4uYmxGPiLR+hhfJMKqCKb05RZs= c=1
>  sm=0 a=JX5xobAnsNsA:10 a=kj9zAlcOel0A:10 a=A3duGc4wJ8K8BtNzzvyz4A==:17
>  a=UJL0KVoXsl7s0H4imRkA:9 a=jBQNsEcNSG5iu2jYQfsA:7
>  a=KW889z4Bgh1uv_EMWkrDp0U9jl4A:4 a=CjuIK1q_8ugA:10 a=NDu43_ybFpjtrQvi:21
>  a=7GxpAH8eZbexILTH:21 a=A3duGc4wJ8K8BtNzzvyz4A==:117
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: 0.0 () none
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kette...@xs4all.nl
> 
> without this diff this box panics on boot while attaching the 36th
> cpu. its a buffer overrun...
> 
> analysis done by kettenis.
> 
> ok?

I think the check should involve MAXCPUS.  Your diff makes clear
though that simply bumping MAXCPUS to 64 isn't going to fly.  At the
very least cpus_attached needs to be changed into a 64-bit integer.

> Index: cpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 cpu.c
> --- cpu.c 13 Nov 2010 04:16:42 -  1.38
> +++ cpu.c 24 Nov 2010 13:04:30 -
> @@ -168,6 +168,9 @@ cpu_match(struct device *parent, void *m
>   struct cfdata *cf = match;
>   struct cpu_attach_args *caa = aux;
>  
> + if (~cpus_attached == 0)
> + return 0;
> +
>   if (strcmp(caa->caa_name, cf->cf_driver->cd_name) == 0)
>   return 1;
>   return 0;

Re: more usb detach love

[Kevin Chadwick]

On Wed, 24 Nov 2010 20:59:22 +
Jacob Meuser  wrote:

> thoughts?

Probably not the thoughts your after especially on tech, but some of the
panics I was seeing a while back (keep meaning to run more recent and
proper tests with output, but time is short at the mo) would occur just
after device removal and only with certain usb readers. If I remember
right, usually after bb_reset messages. This along with other work on
usb I've seen definately seems to ring bells.

I'll try to find the time to see if my 4.8 snapshot can be paniced with
some troublesome readers, though I'm not sure if the ones that were
troublesome varied on 4.5/4.6? and 4.7. Anyway, If I can, I'll try
your patch

Une vidéo intéressante

[info]

Avez-vous pensC) C  une vidC)o pour augmenter votre visibilitC) ?Donnez-vous
une chance d'apparaC.tre en 1C(re page de Google.

Quelques exemples, tous rC)alisC)s C  des budgets de moins de 990 euros* :






EXEMPLE PRC SENTATION D'ENTREPRISES




EXEMPLE PRODUIT / SERVICE...




EXEMPLE ACCUEIL SITE INTERNET




EXEMPLE FORMATION - Aide C  la comprC)hension d'outils ...




EXEMPLE WEB-MAGAZINE - Magazine TV avec interview ...
Vous C*tes intC)ressC) ? Je vous invite C  cliquer sur ce bouton : TrC(s
cordialement.
 CrC)ateur de visibilitC) sur internet
:http://www.web-visite-video.com/catalogue/ --
Delphine Levrat
Directrice commerciale| delph...@web-visite.com| +33(0)4.27.52.91.49 /
+33(0)6.18.25.14.16
| http://www.web-visite-video.com >> DC)mo VidC)o <<
*Pour une durC)e de 1 min

[ Ce mail nbest pas un spam, cbest un message dbinformations, mais
sbil ne vous intC)resse pas ou si vous ne souhaitez plus recevoir de
courriel C  lbavenir, merci de nous envoyer le message B+ non merci B; via
notre formulaire  http://www.web-visite.com/contact-form.php ]

Re: convert netisr to real softinterrupt

[Henning Brauer]

* Owain Ainsworth  [2010-11-25 13:33]:
> and significantly faster (I did not check this).

I really want to see a verification that this doesn't slow us down
before it goes in.

and no, sorry, "shouldn't be slower" is not good enough.

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Re: convert netisr to real softinterrupt

[Owain Ainsworth]

On Thu, Nov 25, 2010 at 11:50:06AM +0100, Claudio Jeker wrote:
> On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> > On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > > This diff was made by oga@ some time ago -- I just fixed a few conflicts
> > > and I would really like to see this going in.
> > > 
> > > netisr needs to be made a normal C function and not this madness it
> > > currently is. This is necessary to imporve the packet scheduling.
> > > 
> > > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> > 
> > hi,
> > 
> > i like the diff, but why not get rid of netisr_dispatch.h?
> 
> I planned to this after this diff goes in. I did not want to change
> Owain's initial diff too much so I left that out for now.

My diff needed some tweaking anyway.

Miod pointed out to me when I first sent this out that some archs use
something slightly different than this generic version.

For example hppa uses a specially aligned netisr variable so it can use
the pa-risc real atomic instructions which are quite a bit faster.

Similarly x86 uses compare-and-swap instead of test, then clear bits.

I meant to add some MD defines so that this could be kept (falling back
to the implementation in this diff)  since miod claims that it is useful
and significantly faster (I did not check this). I've cced miod so he
can answer with somewhat more authority.

> 
> > also i'm not sure, but maybe netisr.c copyright should be
> > attributed to berkeley as we're using their code directly?
> 
> Are we? The current netisr.c code is a generic implementation of using
> softinterrupts to run the netisr and in the future it will get even more
> different.  Owain, what do you think? 

I think my initial mail possibly mentioned that I was unsure if the
original was needed. Put the original one in there as well if you are
unsure. I won't try and claim that I'm positive that it was entirely my
code (too long ago for a start ;).

Anyway, thanks for taking over this diff, claudio. I'm far too busy
right now to sort it out.

Ta,

-0-
-- 
Grelb's Reminder:
Eighty percent of all people consider themselves to be above
average drivers.

Re: convert netisr to real softinterrupt

[Mike Belopuhov]

On Thu, Nov 25, 2010 at 11:50 AM, Claudio Jeker
 wrote:
> On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
>> On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
>> > This diff was made by oga@ some time ago -- I just fixed a few conflicts
>> > and I would really like to see this going in.
>> >
>> > netisr needs to be made a normal C function and not this madness it
>> > currently is. This is necessary to imporve the packet scheduling.
>> >
>> > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
>>
>> hi,
>>
>> i like the diff, but why not get rid of netisr_dispatch.h?
>
> I planned to this after this diff goes in. I did not want to change
> Owain's initial diff too much so I left that out for now.
>

i don't see a reason to wait, but ymmv.

>> also i'm not sure, but maybe netisr.c copyright should be
>> attributed to berkeley as we're using their code directly?
>
> Are we?
>

actually, this is netbsd code in part.  i've traced it to the Eric
Haszlakiewicz's
 commit to sys/arch/sparc/sparc/intr.c [1] and he also introduced
netisr_dispatch.h include.  unfortunately he's not mentioned in any copyrights.
maybe our derived work is a bit different, so we shouldn't bother.

> --
> :wq Claudio

Re: convert netisr to real softinterrupt

[Claudio Jeker]

On Wed, Nov 24, 2010 at 05:42:59PM +0100, Mike Belopuhov wrote:
> On Wed, Nov 24, 2010 at 17:06 +0100, Claudio Jeker wrote:
> > This diff was made by oga@ some time ago -- I just fixed a few conflicts
> > and I would really like to see this going in.
> > 
> > netisr needs to be made a normal C function and not this madness it
> > currently is. This is necessary to imporve the packet scheduling.
> > 
> > Tested myself on i386, amd64, sparc64, sparc, alpha and hppa
> 
> hi,
> 
> i like the diff, but why not get rid of netisr_dispatch.h?

I planned to this after this diff goes in. I did not want to change
Owain's initial diff too much so I left that out for now.

> also i'm not sure, but maybe netisr.c copyright should be
> attributed to berkeley as we're using their code directly?

Are we? The current netisr.c code is a generic implementation of using
softinterrupts to run the netisr and in the future it will get even more
different.  Owain, what do you think? 

-- 
:wq Claudio