headers
NetBSD source update | 1 Dec 2003 01:38
Picon

triweekly CVS update output


Updating release-1-5 src tree (netbsd-1-5):
U src/CHANGES-1.5.4
P src/sys/netinet/in.c
P src/sys/netinet/ip_mroute.c
P src/sys/netinet/ip_mroute.h

Running the SUP scanner:
SUP Scan for release-1-5 starting at Mon Dec  1 00:23:40 2003
SUP Scan for release-1-5 completed at Mon Dec  1 00:23:55 2003

Updating release-1-6 src tree (netbsd-1-6):

Running the SUP scanner:
SUP Scan for release-1-6 starting at Mon Dec  1 00:38:17 2003
SUP Scan for release-1-6 completed at Mon Dec  1 00:38:52 2003
Permalink | Reply | 0 comments |
headers
Xavier HUMBERT | 1 Dec 2003 02:30

Successful crossbuild hosted on MacOSX 10.3

Hi,

FYI, I succesfully compiled a -current tonight on a MacOSX 10.3 

The target was i386. To be honest, I haven't yet installed the binaries.

For those interested, my build script can be found here :
<http://www.xavhome.fr.eu.org//NetBSD/crossbuild.sh.html>

And the summary of the build :

<http://www.xavhome.fr.eu.org/NetBSD/2003-11-29-build-log.txt >

Hope this helps...

--

-- 
They who can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety (Ben. Franklin)
Permalink | Reply | 10 comments |
headers
Charlie Allom | 1 Dec 2003 02:40

Re: Successful crossbuild hosted on MacOSX 10.3

On Mon, Dec 01, 2003 at 02:30:16AM +0100, Xavier HUMBERT wrote:
> Hi,
> 
> FYI, I succesfully compiled a -current tonight on a MacOSX 10.3 
> 
> The target was i386. To be honest, I haven't yet installed the binaries.
> 
> For those interested, my build script can be found here :
> <http://www.xavhome.fr.eu.org//NetBSD/crossbuild.sh.html>

403 :(

> 
> And the summary of the build :
> 
> <http://www.xavhome.fr.eu.org/NetBSD/2003-11-29-build-log.txt >
> 
> Hope this helps...
> 

--

-- 
 charlie <at> rubberduck.com - Melbourne, Australia
 http://rubberduck.com/~yeled/
 PGP: 0x14AA7941 || finger yeled <at> lazy.spodder.com
Permalink | Reply | 8 comments |
headers
Olaf Seibert | 1 Dec 2003 02:50
Picon

Re: Low AAC performance but only when tested through the file system

On Sun 30 Nov 2003 at 15:07:33 -0800, Bill Studenmund wrote:
> What's your stripe depth? For optimal performance, you want it to be 16k.  
> The file system will do 64k i/o's. With 4 data drives & a 16k stripe
> depth, a 64k i/o (on a 64k boundary) will hit all 4 drives at once.

It's the default 64k. In the previous hardware I tried 16k also but it
made no difference, so I never tried it on this one.

> Bill
-Olaf.
--

-- 
___ Olaf 'Rhialto' Seibert - rhialto <at>        -- "What good is a Ring of Power
\X/ polderland.nl            -- if you're unable...to Speak." - Agent Elrond
Permalink | Reply | 6 comments |
headers
Andrew Brown | 1 Dec 2003 02:57

LKM kernel version mismatch

to be honest, while i think the lkm thing is a wonderful idea, it's
really annoying me, personally.  this lkm in particular:

LKM 'nosys': kernel version mismatch - LKM 106290000, kernel 106320000

does *NOTHING*.  it installs a syscall that ignores all its arguments,
does nothing else, and then returns.  all so that i have one.  it,
therefore, *CANNOT* fail to match any api in the kernel, because it
doesn't use any.

this one, on the other hand:

LKM 'eb164_frobnitz': kernel version mismatch - LKM 106290000, kernel 106320000

installs a syscall that calls printf() and then calls
eb164_intr_enable().  now, granted, it could fall behind the api, but
i can't imagine either of them changing, and i imagine that if they
did, the link prior to loading would fail...

is there any easy way of disabling it?  or making an lkm that will
load more "easily"?

--

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior <at> daemon.org             * "ah!  i see you have the internet
twofsonet <at> graffiti.com (Andrew Brown)                that goes *ping*!"
werdna <at> squooshy.com       * "information is power -- share the wealth."
Permalink | Reply | 11 comments |
headers
NetBSD source update | 1 Dec 2003 06:42
Picon

daily CVS update output


Updating src tree:
P src/distrib/i386/floppies/common/list.ramdisk
P src/distrib/utils/sysinst/Makefile.inc
P src/distrib/utils/sysinst/aout2elf.c
P src/distrib/utils/sysinst/bsddisklabel.c
P src/distrib/utils/sysinst/defs.h
P src/distrib/utils/sysinst/disks.c
P src/distrib/utils/sysinst/label.c
P src/distrib/utils/sysinst/menus.mi
P src/distrib/utils/sysinst/msg.mi.en
P src/distrib/utils/sysinst/msg.mi.fr
P src/distrib/utils/sysinst/msg.mi.pl
P src/distrib/utils/sysinst/net.c
P src/distrib/utils/sysinst/run.c
P src/distrib/utils/sysinst/target.c
P src/distrib/utils/sysinst/txtwalk.c
P src/distrib/utils/sysinst/txtwalk.h
P src/distrib/utils/sysinst/upgrade.c
P src/distrib/utils/sysinst/util.c
P src/distrib/utils/sysinst/arch/acorn26/md.c
P src/distrib/utils/sysinst/arch/acorn26/md.h
P src/distrib/utils/sysinst/arch/acorn32/md.c
P src/distrib/utils/sysinst/arch/acorn32/md.h
P src/distrib/utils/sysinst/arch/alpha/md.c
P src/distrib/utils/sysinst/arch/alpha/md.h
P src/distrib/utils/sysinst/arch/amiga/md.c
P src/distrib/utils/sysinst/arch/arc/md.c
P src/distrib/utils/sysinst/arch/atari/md.c
P src/distrib/utils/sysinst/arch/atari/md.h
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martti Kuparinen | 1 Dec 2003 09:47
Picon
Picon
Favicon

Re: Problems with rccide0

Manuel Bouyer wrote:

> OK, this is likely an interrupt problem then. Can you add printfs to
> serverworks_pci_intr() to see if there's a loop at this level (or add

I added few printfs:

int
serverworks_pci_intr(arg)
         void *arg;
{
         struct pciide_softc *sc = arg;
         struct pciide_channel *cp;
         struct channel_softc *wdc_cp;
         int rv = 0;
         int dmastat, i, crv;

printf("1\n");
         for (i = 0; i < sc->sc_wdcdev.nchannels; i++) {
printf("2 i=%d\n", i);
                 cp = &sc->pciide_channels[i];
                 dmastat = bus_space_read_1(sc->sc_dma_iot,
                     cp->dma_iohs[IDEDMA_CTL], 0);
printf("3 dmastat=0x%x\n", dmastat);
                 if ((dmastat & (IDEDMA_CTL_ACT | IDEDMA_CTL_INTR)) !=
                     IDEDMA_CTL_INTR)
                         continue;
printf("4\n");
                 wdc_cp = &cp->wdc_channel;
                 crv = wdcintr(wdc_cp);
(Continue reading)

Permalink | Reply | 5 comments |
headers
Robert Elz | 1 Dec 2003 09:57
Picon

Re: LKM kernel version mismatch

    Date:        Sun, 30 Nov 2003 20:57:05 -0500
    From:        Andrew Brown <atatat <at> atatdot.net>
    Message-ID:  <20031130205705.A10086 <at> noc.untraceable.net>

  | it installs a syscall that ignores all its arguments,
  | does nothing else, and then returns.  all so that i have one.  it,
  | therefore, *CANNOT* fail to match any api in the kernel, because it
  | doesn't use any.

Hmm?   Isn't there an API in the kernel being used to install a new syscall?

While I don't much believe in LKMs for available source systems, I do
however understand what you're requesting I think - that is, a more finely
grained way to tell just what API may have altered, so LKMs could
determine whether they will still work, or need to be recompiled.  The
current "nothing has changed" (which is often a lie anyway), or "anything
might have changed" is a little crude.

kre
Permalink | Reply | 4 comments |
headers
Jaromir Dolecek | 1 Dec 2003 13:40
Picon

Re: LKM kernel version mismatch

Andrew Brown wrote:
> is there any easy way of disabling it?  or making an lkm that will
> load more "easily"?

How do you determine what's 'safe' and what not? Once you
dereference any kernel struct pointer (e.g. struct proc or struct lwp),
there is incompatibility. Obviously it's not possible for a LKM
to do anything useful and be ABI safe.

If you really know what you are doing and you are 100% positive
it's safe, you can use modload -f. Be prepared for panics in that
case, which will be caused by the incompatible LKM.

Jaromir
--

-- 
Jaromir Dolecek <jdolecek <at> NetBSD.org>            http://www.NetBSD.cz/
-=- We should be mindful of the potential goal, but as the Buddhist -=-
-=- masters say, ``You may notice during meditation that you        -=-
-=- sometimes levitate or glow.   Do not let this distract you.''   -=-
Permalink | Reply | 5 comments |
headers
Andrew Brown | 1 Dec 2003 14:38

Re: LKM kernel version mismatch

>  | it installs a syscall that ignores all its arguments,
>  | does nothing else, and then returns.  all so that i have one.  it,
>  | therefore, *CANNOT* fail to match any api in the kernel, because it
>  | doesn't use any.
>
>Hmm?   Isn't there an API in the kernel being used to install a new syscall?

um...yeah, though i would expect that if *that* changed, the version
of the lkm interface would refuse to load *any* module, not just those
that are three days too old...

that's fine.

>While I don't much believe in LKMs for available source systems, I do
>however understand what you're requesting I think - that is, a more finely
>grained way to tell just what API may have altered, so LKMs could
>determine whether they will still work, or need to be recompiled.  The
>current "nothing has changed" (which is often a lie anyway), or "anything
>might have changed" is a little crude.

maybe something like that, yes.

--

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior <at> daemon.org             * "ah!  i see you have the internet
twofsonet <at> graffiti.com (Andrew Brown)                that goes *ping*!"
werdna <at> squooshy.com       * "information is power -- share the wealth."
Permalink | Reply | 0 comments |

Gmane