headers
Bella Riosa | 17 Jun 2009 17:22
Picon
Picon

Turbochannel Adapter

hi,

it seems the turbochannel-adapter-driver is broken.

the kernel won't detect it (nor the SCSI-Card on it), although it works fine under VMS.

There is not a trace of it in dmesg. Maybe the address is wrong?
Has someone successfully tested the tc-adapter on an VAXStation 4000?

NetBSD-Kernel: NetBSD-5.0_STABLE
(builds <at> b7.netbsd.org:/home/builds/ab/netbsd-5/vax/200906150000Z-obj/home/builds/ab/netbsd-5/src/sys/arch/vax/compile/GENERIC)

--

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Permalink | Reply | 2 comments |
headers
Martin Husemann | 17 Jun 2009 17:36
Picon

Re: Turbochannel Adapter

On Wed, Jun 17, 2009 at 05:22:35PM +0200, Bella Riosa wrote:
> There is not a trace of it in dmesg. Maybe the address is wrong?
> Has someone successfully tested the tc-adapter on an VAXStation 4000?

int
tcbus_match(device_t parent, cfdata_t cfdata, void *aux)
{
        return 0;
}

So not a big suprise it doesn't get attached ;-)

Martin
Permalink | Reply | 1 comment |
headers
Lukas Kaminski | 20 Jun 2009 12:56
Picon

Re: Turbochannel Adapter

Well, is someone working on this issue? i have a tc-adapter and some
cards to donate.

Am Mi 17.06.2009 17:36 schrieb Martin Husemann <martin <at> duskware.de>:

> On Wed, Jun 17, 2009 at 05:22:35PM +0200, Bella Riosa wrote:
> > There is not a trace of it in dmesg. Maybe the address is wrong?
> > Has someone successfully tested the tc-adapter on an VAXStation
> > 4000?
>
> int
> tcbus_match(device_t parent, cfdata_t cfdata, void *aux)
> {
> return 0;
> }
>
> So not a big suprise it doesn't get attached ;-)
>
> Martin
Permalink | Reply | 0 comments |
headers
Lukas Kaminski | 24 Jun 2009 20:04
Picon

internal compiler error while compiling sqlite3

hi,

when compiling sqlite3 with debugging support, it reports an internal
compiler error:

CFLAGS="-O0 -g"

./libtool --mode=compile --tag=CC gcc -O0 -g -DSQLITE_OS_UNIX=1 -I.
-I./src -D_HAVE_SQLITE_CONFIG_H -DNDEBUG -DSQLITE_THREADSAFE=1
-DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_TEMP_STORE=1 -c ./src/date.c
libtool: compile:  gcc -O0 -g -DSQLITE_OS_UNIX=1 -I. -I./src
-D_HAVE_SQLITE_CONFIG_H -DNDEBUG -DSQLITE_THREADSAFE=1
-DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_TEMP_STORE=1 -c ./src/date.c
-fPIC -DPIC -o .libs/date.o
./src/date.c: In function 'strftimeFunc':
./src/date.c:957: internal compiler error: in
vax_expand_addsub_di_operands, at config/vax/vax.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.NetBSD.org/Misc/send-pr.html> for instructions.
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/databases/sqlite3/work/sqlite-3.6.14.2
Permalink | Reply | 2 comments |
headers
Jan-Benedict Glaw | 24 Jun 2009 23:36
Picon
Favicon

Re: internal compiler error while compiling sqlite3

On Wed, 2009-06-24 19:04:01 +0100, Lukas Kaminski <kaminski <at> ikp.tu-darmstadt.de> wrote:
> hi,
> 
> when compiling sqlite3 with debugging support, it reports an internal
> compiler error:
> 
> CFLAGS="-O0 -g"
> 
> ./libtool --mode=compile --tag=CC gcc -O0 -g -DSQLITE_OS_UNIX=1 -I.
> -I./src -D_HAVE_SQLITE_CONFIG_H -DNDEBUG -DSQLITE_THREADSAFE=1
> -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_TEMP_STORE=1 -c ./src/date.c
> libtool: compile:  gcc -O0 -g -DSQLITE_OS_UNIX=1 -I. -I./src
> -D_HAVE_SQLITE_CONFIG_H -DNDEBUG -DSQLITE_THREADSAFE=1
> -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_TEMP_STORE=1 -c ./src/date.c
> -fPIC -DPIC -o .libs/date.o
> ./src/date.c: In function 'strftimeFunc':
> ./src/date.c:957: internal compiler error: in
> vax_expand_addsub_di_operands, at config/vax/vax.c:2002
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.NetBSD.org/Misc/send-pr.html> for instructions.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/pkgsrc/databases/sqlite3/work/sqlite-3.6.14.2

Which GCC is this? At least not the current upstream version? The
NetBSD archive version I guess?

MfG, JBG
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lukas Kaminski | 25 Jun 2009 09:08
Picon

Re: internal compiler error while compiling sqlite3

> > hi,
> >
> > when compiling sqlite3 with debugging support, it reports an
> > internal
> > compiler error:
> >
...
> > make: stopped in /usr/pkgsrc/databases/sqlite3/work/sqlite-3.6.14.2
>
> Which GCC is this? At least not the current upstream version? The
> NetBSD archive version I guess?
>
> MfG, JBG

oh, well sorry....

it's the system compiler from NetBSD-5_STABLE (around a week old).

# gcc --version
gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb2 20081120)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Permalink | Reply | 0 comments |
headers
Lukas Kaminski | 25 Jun 2009 09:14
Picon

sqlite3 core dump on vax

sqlite3-3.6.14.2 (from pkgsrc) dumps core on vax (invalid instruction)

to avoid that, patch src/sqliteInt.h

change

# define SQLITE_BIG_DBL (1e99)

to

# define SQLITE_BIG_DBL (1.701411834604692294E+38)
Permalink | Reply | 1 comment |
headers
David Brownlee | 25 Jun 2009 15:45
Gravatar

Re: sqlite3 core dump on vax

------- Original message -------
> From: Lukas Kaminski <kaminski <at> ikp.tu-darmstadt.de>
> Sent: 25.6.'09,  8:14
>
> sqlite3-3.6.14.2 (from pkgsrc) dumps core on vax (invalid instruction)
>
> to avoid that, patch src/sqliteInt.h
>
> change
>
> # define SQLITE_BIG_DBL (1e99)
>
> to
>
> # define SQLITE_BIG_DBL (1.701411834604692294E+38)
>
Is there an existing system #define we could use for this?
Permalink | Reply | 0 comments |
headers
Martin Husemann | 25 Jun 2009 15:53
Picon

Re: sqlite3 core dump on vax

On Thu, Jun 25, 2009 at 02:45:21PM +0100, David Brownlee wrote:
> Is there an existing system #define we could use for this? 

DBL_MAX ?

Martin
Permalink | Reply | 0 comments |
headers
Lukas Kaminski | 30 Jun 2009 15:16
Picon

NetBSD wiki

some of the problems documented on http://wiki.netbsd.se/vax seem to
have been resolved.

i'm referring to:
- "build.sh fails on native build",
- "some machines hang under load"
- the 4GB filesystem issues (I'm using a 16 GB filesystem for over a
year now and everything works).

could someone delete these entries (or: can i delete these entries ;-)
)?

- Blaz Antonic's driver works, too. At least on my VS4000/90 with a
LCSPX graphics-board. But not as console device.

- X11: OpenBSD 4.0 and 4.1 has a working xserver for these devices. It
works great, but in newer OpenBSD releases they switched to Xenocara
which breaks the xserver. Maybe this could be a starting point for our
own x-server?
Permalink | Reply | 2 comments |

Gmane