looking for a contact at ATI...

I've got a radeonfb driver for NetBSD that we'd *like* to give away. 
Unfortunately, while I didn't use them much, I have had access to NDA
documentation from ATI, which prevents me from being able to release
this driver back to NetBSD without specific approval from ATI.

I would *like* to be able to do so.  If anyone has any contacts at ATI
who could give my code the once over, and maybe sign an approval for us
to release this code, I'd love to do so.  (I have two versions of the
code, one that is fairly clean and doesn't really have any IP in it that
isn't also part of xfree, and another that includes initialization for
processors without BIOS -- ala MIPS -- that does have some as yet
unreleased ATI IP.  I'd be happy releasing either version, if I can get
permission from ATI.

FWIW, I think my employer will approve open sourcing the code if we get
approval from ATI, but going thru the channels we have has not gotten a
response from ATI at all yet -- so maybe somebody on one of these lists
has a contact who can be more helpful...

Thanks!

--

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

Re: merge of freebsd eventhandler

Folks,

Attached is the updated eventhandler.h, all the other code remains
unchanged.

-- 
Brett Lymn

/*-
 * Copyright (c) 1999 Michael Smith <msmith <at> freebsd.org>
 * All rights reserved.
 *
 * 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 AUTHOR 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 AUTHOR 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)

kern.ldscript error

Hi there,
when I try to compile the current kernel, everything goes fine, except that when
linking the kernel, ld spits out:

#      link  PRESARIO/netbsd
ld -T ../../../../arch/i386/conf/kern.ldscript -Ttext c0100000 -e start -X -o
netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
../../../../arch/i386/conf/kern.ldscript:45 non constant expression for load
base
*** Error code 1

What is strange, is that kern.ldscript actually has 44 lines and not 45…

Any idea?
Vincent

SIGINFO and NOKERNINFO

Chuck found a bug in ping where if ping was backgrounded, it would stop.
This exposed an issue in the SIGINFO functionality. Ping wants to trap
siginfo to print statistics, but at the same time it does not want the
kernel to print statistics. This is currently accomplished by ping
setting the tty flag NOKERNINFO. Unfortunately, in order to set this
flag we need to call tcsetattr, and this causes the process to stop
if it has a tty, but the tty is not in the current tty control group.

Well, one can detect if the process is in the current tty control group
and choose not to set the flag. This is not good enough, because the
process can start in the foreground, and then be placed in the background.
In this case, not restoring the flag will end up modifying the tty
state.

In the end, the more basic issue is that there should be a way to
avoid printing kerninfo in the current process, that does not modify
global state [the tty state] that persists after the process ends.

Chuck had a good idea, indicating this via a signal flag. The following
code does this.

Opinions?

christos

Index: kern/tty.c
===================================================================
RCS file: /cvsroot/src/sys/kern/tty.c,v
retrieving revision 1.182

Re: kern.ldscript error

In article <1149241941.44800a551681a <at> imp5-g19.free.fr>,  <10.50 <at> free.fr> wrote:
>Hi there,
>when I try to compile the current kernel, everything goes fine, except that when
>linking the kernel, ld spits out:
>
>#      link  PRESARIO/netbsd
>ld -T ../../../../arch/i386/conf/kern.ldscript -Ttext c0100000 -e start -X -o
>netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
>../../../../arch/i386/conf/kern.ldscript:45 non constant expression for load
>base
>*** Error code 1
>
>What is strange, is that kern.ldscript actually has 44 lines and not 45…

You probably need to install new binutils (before building the kernel).
This is a lose 

christos

TR: Why Pstate could make NetBSD buggy ?

Hello,

I really need help on this :) Thx in advance.

www.dedibox.fr is a new dedicaded server provider in France.  They build their 
own server (base on VIA C7 on a custom motherboard).  Every machine is the 
same. There is only ONE difference: the version of the BIOS mplemented on the 
motherboard. (see after)

Several persons have installed NetBSD 3.0 on those dedicated servers. A  part 
has a stable installation, the other part has a buggy  installation. After 
investigation, the ONLY difference is the version  of the BIOS. and the 
difference is:
The Pstate has been disabled on buggy BIOS and vcore as been augmented  by 
0.1v

The 2 BIOS are working fine on *Linux and FreeBSD but the newest is not on 
NetBSD and OpenBSD

I've tested OpenBSD and the problem is exactly the same. OpenBSD is also buggy 
with this BIOS revision.

The hardware is fine (long hardware test + intensive usage of the machine (via 
make build, excessive tar, make kernel, and stress  program). It's really an 
NetBSD/OpenBSD problem.

I'm running NetBSD3.0-stable, the problems are:
 Kernel panic
 Machine is crashing
 Many seg fault (signal 11)

Re: kern.ldscript error

Christos Zoulas gegraphe:

> You probably need to install new binutils (before building the kernel).
> This is a lose 

Nenikekamas ! :) It works fine with GCC 4, by the way.

Evkallisto polu !

Vincent

PS: Sorry for the approximate translation ;)

Re: TR: Why Pstate could make NetBSD buggy ?

On 2-Jun-06, at 9:31 PM, Jerome Loyet wrote:
> Several persons have installed NetBSD 3.0 on those dedicated  
> servers. A  part
> has a stable installation, the other part has a buggy   
> installation. After
> investigation, the ONLY difference is the version  of the BIOS. and  
> the
> difference is:
> The Pstate has been disabled on buggy BIOS and vcore as been  
> augmented  by
> 0.1v
>
> The 2 BIOS are working fine on *Linux and FreeBSD but the newest is  
> not on
> NetBSD and OpenBSD
>
> I've tested OpenBSD and the problem is exactly the same. OpenBSD is  
> also buggy
> with this BIOS revision.

Are you booting a NetBSD kernel with ACPI support?

Cheers,
Jared

[simonb-timecounters] branch updated & status

Status update:

The simonb-timecounters branch was synced to head on 20060531.
Currently the ports i386, amd64, sparc and sparc64 have been converted
to timecounters.
I am out of test-accessible hardware now... so...

I sketched what is needed to convert a port to timecounters.
A current version of the description and the current status
of the time counter project can be found on
http://www.kardel.name/timecounters-status.html.

below is a copy if the section describing the conversion:

                  Converting a port to Timecounters

Ideally all ports should be converted to timecounters so that the old
microtime implementation can be completely retired and we can get rid of
the dual code (__HAVE_TIMECOUNTER). The requirements for timecounter
support are minimal. The porting strategies are as follows:

Common steps to perform:

    1. #define __HAVE_TIMECOUNTER in arch/<arch>/include/types.h
    2. register a struct timecounter timecountername with
       tc_init(&timecountername) during/close to clock interrupt
       initialization
    3. implement the timecounter reading function (referred to in
       timecountername)
    4. remove any support/references to cc_microtime/kern_microtime.c

Re: Why Pstate could make NetBSD buggy ?

> > Several persons have installed NetBSD 3.0 on those
> dedicated servers. 
> > A  part
> > has a stable installation, the other part has a buggy   
> > installation. After
> > investigation, the ONLY difference is the version  of the BIOS. and 
> > the difference is:
> > The Pstate has been disabled on buggy BIOS and vcore as
> been augmented
> > by 0.1v
> >
> > The 2 BIOS are working fine on *Linux and FreeBSD but the newest is 
> > not on NetBSD and OpenBSD
> >
> > I've tested OpenBSD and the problem is exactly the same. OpenBSD is 
> > also buggy with this BIOS revision.
> 
> Are you booting a NetBSD kernel with ACPI support?

No, I'm using GENERIC kernel. Why ?

Thx
Jerome