headers
Denis Lagno | 1 Apr 2005 11:11
Picon

Re: Melting down your network [Subject changed]

Jonathan Stone scribed:
> Deploying any application designed to pump out wire-speed, non-rate-
> adaptive, non-congestion-responsive, is an evil act.  It may lead to
> your ISP removing service. It may lead to criminal or civil prosecution.

> Just don't do it.  It's not just ignorant or stupid; it's *evil*.

heh:)  Apparantly Jonathan has a strong lobby in IETF:
ftp://ftp.rfc-editor.org/in-notes/rfc4041.txt
Permalink | Reply | 0 comments |
headers
Greg A. Woods | 3 Apr 2005 01:37
X-Face
Favicon

Re: isp(4) with Q-Logic 2340 suffers "stray interrupts" under load

[ On Monday, March 28, 2005 at 20:08:26 (-0800), Jason Thorpe wrote: ]
> Subject: Re: isp(4) with Q-Logic 2340 suffers "stray interrupts" under load
>
> I just checked in the attached (minimally invasive) patch, and will  
> request pullups to the netbsd-2 and netbsd-3 branches.

Thanks.  Could you request a pullup for netbsd-1-6 too?

(I think this may help prevent at least the worst of some other
interrupt related problems I've seen posted to this list, though I can't
say for sure that any of those posters are still running 1.6.x  :-)

>  void
> +alpha_shared_intr_reset_strays(struct alpha_shared_intr *intr,
> +    unsigned int num)
> +{
> +
> +	/*
> +	 * Don't bother blocking interrupts; this doesn't have to be
> +	 * precise, but it does need to be fast.
> +	 */
> +	intr[num].intr_nstrays = 0;
> +}

It needs to be fast because it always gets called for every interrupt,
right?  So maybe it should be a CPP macro?  (Not that I know what the
current cycle count for a function call is on any of the CPU models I
run, let alone any of the many other versions.... :-)

(or alternately an __inline__ definition?)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hubert Feyrer | 3 Apr 2005 13:05
Picon
Favicon

Re: boot message

On Sun, 3 Apr 2005, Marcin Jessa wrote:
> Is there a way one can make a booting kernel be silent and not to spit out all the info of what's going on?
> I wish my soekris build to be quiet and display only boot loader's message and then go straight to the login prompt.

There are two ways to get that done:

1) re-enable console=pc, and make sure you have gettys enabled, esp.
on your serial port (tty00).

2) Really tell the kernel to not print anything at all. I don't know to 
what extent that is supported, some support is available: printf(9) 
documents in the aprint_*() functions that you can set a "boothowto" 
variable to values like AB_QUIET, AB_VERBOSE and AB_SILENT.

I think the variable can be set from the bootprompt, setting a default in 
src/sys/kern/init_main.c would make sense to me. You'll need to change the 
C file for that.

In the bootloader, interrupt the countdown and type "boot -q". 
The result is not too impressive though:

 	> boot -q
 	booting hd0a:netbsd (howto 0x10000)
 	6746364+148460+522576 [376144+337471]=0x7c2458
 	BIOS CFG: Model-SubM-Rev: fc-00-01, 0x4074<EBDA,KBDINT,RTC,IC2,KBDF>
 	Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
 	    The NetBSD Foundation, Inc.  All rights reserved.
 	Copyright (c) 1982, 1986, 1989, 1991, 1993
 	    The Regents of the University of California.  All rights reserved.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Thorpe | 3 Apr 2005 19:29

Re: boot message


On Apr 3, 2005, at 4:05 AM, Hubert Feyrer wrote:

> In the bootloader, interrupt the countdown and type "boot -q". The  
> result is not too impressive though:

That's because the i386 port doesn't use the "aprint" functions  
properly.  That needs to be fixed.

-- thorpej
Permalink | Reply | 0 comments |
headers
J Chapman Flack | 3 Apr 2005 22:36
Picon
Favicon

ffs question

In another thread I happened to find this in fsck_ffs(8):

     The kernel takes care that only a restricted class of innocuous file sys-
     tem inconsistencies can happen unless hardware or software failures
     intervene.  These are limited to the following:

     Unreferenced inodes
     Link counts in inodes too large
     Missing blocks in the free map
     Blocks in the free map also in files
     Counts in the super-block wrong

I noticed that out of the five listed inconsistencies, four of them are
truly innocuous, in that they won't hurt you badly if you operate the
filesystem without fscking it.  But "blocks in the free map also in files"
would hurt,because with further use of the fs you'd wind up with files
sharing blocks. Does the kernel really allow that? Is the problem that nobody
wants to sync-update the bitmap so frequently?

It occurred to me there's an idea that could probably be tweaked to keep the
bitmap updates down: work from a cache of the bitmap, and whenever a region
(of tunable size) of the cache is loaded from disk, sync-write that region
with all bits clear.  In an unclean shutdown, the bitmap'll be wrong, but
only wrong with missing free blocks, which really is innocuous.

Worth considering, or not?

-Chap
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 4 Apr 2005 09:11
Picon

Re: ffs question

On Sun, Apr 03, 2005 at 03:36:03PM -0500, J Chapman Flack wrote:
> I noticed that out of the five listed inconsistencies, four of them are
> truly innocuous, in that they won't hurt you badly if you operate the
> filesystem without fscking it.  But "blocks in the free map also in files"
> would hurt,because with further use of the fs you'd wind up with files
> sharing blocks. Does the kernel really allow that? Is the problem that nobody
> wants to sync-update the bitmap so frequently?

At least with soft updates it is supposed to be "blocks in the free map
marked as used, but not in files". That doesn't hurt badly, it is the same
situation as inode count too large.

Joerg
Permalink | Reply | 0 comments |
headers
Oliver Korpilla | 4 Apr 2005 13:53
Picon
Picon

Hard realtime scheduling

Hello!

I'm new to NetBSD, though I switched to it to maybe participate in some 
kernel work. I did a little porting for Linux before (porting to a 
non-supported PowerPC board and porting a x86 VMEbus driver), and wanted 
a taste of BSD, and NetBSD has the reputation to be the most cleanest in 
terms of code and most useful for embedded devices.

As I've read support for realtime scheduling is on the agenda since the 
2004 Annual Meeting, so is anyone actively working on this? May I help 
out in any way? What approach are you using, where can I read up on it 
(papers, articles, etc.)? Is there consensus about the topic?

I'm just a newbie with interests in OS technology who would like to get 
his hands dirty, so I hope for your understanding.

Thanks and with kind regards,
Oliver Korpilla
Permalink | Reply | 25 comments |
headers
Daniel Sieger | 4 Apr 2005 11:54
Picon
Picon

Re: Hard realtime scheduling

Hi,

On Mon, Apr 04, 2005 at 01:53:46PM +0200, Oliver Korpilla wrote:
> Hello!
> 
[snip]
> As I've read support for realtime scheduling is on the agenda since the 
> 2004 Annual Meeting, so is anyone actively working on this? May I help 
> out in any way? What approach are you using, where can I read up on it 
> (papers, articles, etc.)? Is there consensus about the topic?

We had some discussion[1] about the NetBSD scheduler some weeks
ago. You might want to read this first, although this won't give you
many hard facts.

Daniel

[1]: http://mail-index.NetBSD.org/tech-kern/2005/03/09/0000.html

--

-- 
Daniel Sieger           "Denn jeder, der sein inneres Selbst
Universität Bielefeld   Nicht zu regieren weiß, regierte gar zu gern
Technische Fakultät     Des Nachbars Willen, eignem stolzen Sinn gemäß..."
                        Goethe, Faust II
Permalink | Reply | 0 comments |
headers
Hubert Feyrer | 4 Apr 2005 12:02
Picon
Favicon

Re: Hard realtime scheduling

On Mon, 4 Apr 2005, Oliver Korpilla wrote:
> As I've read support for realtime scheduling is on the agenda since the 2004 
> Annual Meeting, so is anyone actively working on this? May I help out in any 
> way? What approach are you using, where can I read up on it (papers, 
> articles, etc.)? Is there consensus about the topic?

I don't know about any details in NetBSD, but the way to go is probably to 
make the kernel preemptive as first step. This will also (hugely) benefit 
SMP performance (i.e. no more biglock).

Recommended reading: Solaris Internals by Richard McDougall & Jim Mauro,
see http://www.solarisinternals.com/.

  - Hubert

--

-- 
NetBSD - Free AND Open!      (And of course secure, portable, yadda yadda)
Permalink | Reply | 23 comments |
headers
SODA Noriyuki | 4 Apr 2005 12:08
Picon

Re: Hard realtime scheduling

>>>>> On Mon, 4 Apr 2005 12:02:07 +0200 (CEST),
	Hubert Feyrer <hubert <at> feyrer.de> said:

> I don't know about any details in NetBSD, but the way to go is probably to 
> make the kernel preemptive as first step. This will also (hugely) benefit 
> SMP performance (i.e. no more biglock).

mm, first step.
I think this is really hard step, although it's worth consindering.

Adding realtime (fixed priority) scheduling class to our scheduler is
worth doing, and far easier than preemptive kernel.
--
soda
Permalink | Reply | 19 comments |

Gmane