Andy Ruhl | 1 May 07:06 2005
Picon

Re: ABIT AV8 and NetBSD

On 4/30/05, Pekka Niiranen <pekka.niiranen <at> wlanmail.com> wrote:
> After having similar problems with another motherboard
> I wondered if "supporting everything" really means
> "supporting nothing fully"....

Nobody is giving away hardware for free last time I checked. And I
don't have the skill to fix it or I would do it myself. I'm not
complaining, it just is what it is.

I found a well supported gigabit adapter on ebay for less than $20
shipped to me. That's dandy as far as I'm concerned.

And I'm still willing to test any fixes for the onboard card.

Andy

Dave Huang | 1 May 07:36 2005

intr_establish: can't share intr source between different PIC types

Well, despite you guys telling me that the Tyan S2895 wouldn't be
well-supported, I got one anyway :) I'm having some trouble getting
the onboard SATA ports to work (at all... in the BIOS or in any OS)
that tech support is looking at, so in the meantime, I'm using an
Adaptec SATAConnect 1205SA controller. However, when I have the card
plugged in, booting the NetBSD/amd64 2.0.2 CD gives a "Disk read
error." The CD boots fine when the Adaptec card isn't plugged in...
maybe a bug in the BIOS's support for floppy emulation on boot CDs? I
seem to remember hearing about something like that a while back, and I
believe there was some talk into switching to a no emulation CD
(Windows XP and SUSE Linux CDs boot fine with and without the
Adaptec).

In any case, that's not the real problem... I set it up to PXE boot
the NetBSD/amd64 2.0.2 INSTALL kernel, and the satalink driver doesn't
work:

mainbus0 (root)
mainbus0: Intel MP Specification (Version 1.4) (AMD      HAMMER      )
cpu0 at mainbus0: apid 0 (boot processor)
[ ... ]
cpu1 at mainbus0: apid 1 (application processor)
cpu1: not started
mpbios: bus 0 is type PCI
mpbios: bus 1 is type PCI
mpbios: bus 2 is type PCI
mpbios: bus 8 is type PCI
mpbios: bus 9 is type PCI
mpbios: bus 10 is type PCI
mpbios: bus 128 is type PCI
(Continue reading)

Emmanuel Dreyfus | 1 May 10:46 2005
Picon

gdb can't trace

Hello

I'm working on COMPAT_LINUX/amd64 and I experience unexpected problems.

When launching a Linux binary, the program starts but hangs before doing
any system call. Running gdb shows it is stopped on a hlt instruction.
What is it? halt? halt until when?

Thanks to sysctl proc.$$.stopexec I can use gdb to attach the program
before it starts. Stack and registers are correctly set up.

In order to find out what goes wrong, I'd like to trace the Linux binary
running on NetBSD using gdb. But gdb seems unable to trace. Anyone see
any reason why it could not? 

$ gdb /emul/linux/bin/hello  
(gdb) attach 632
Attaching to program: /emul/linux/bin/hello, process 632
_start () at ../sysdeps/x86_64/elf/start.S:48
48      ../sysdeps/x86_64/elf/start.S: No such file or directory.
        in ../sysdeps/x86_64/elf/start.S
Current language:  auto; currently asm
(gdb) info reg
rax            0x0      0
rbx            0x0      0
rcx            0x4001c0 4194752
rdx            0x0      0
rsi            0x0      0
rdi            0x0      0
rbp            0x0      0
(Continue reading)

Emmanuel Dreyfus | 1 May 17:09 2005
Picon

Re: gdb can't trace

Emmanuel Dreyfus <manu <at> netbsd.org> wrote:

> When launching a Linux binary, the program starts but hangs before doing
> any system call.

I tracked that down: it was doing system calls but I did not added the
code to see them with ktrace. Silly bug.

--

-- 
Emmanuel Dreyfus
Un bouquin en fran├žais sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu <at> netbsd.org

Frank van der Linden | 1 May 17:15 2005
Picon

Re: intr_establish: can't share intr source between different PIC types

Hi Dave,

If you can, try out a GENERIC.MPACPI kernel. It looks like the default
MPBIOS interrupt mappings aren't complete, the ACPI mappings have a much
better chance of working.

I've been meaning to make ACPI the default, but sadly, size limits in
our current boot/install setup prohibit this right now.

- Frank

Dave Huang | 1 May 22:02 2005

Re: intr_establish: can't share intr source between different PIC types

On Sun, May 01, 2005 at 05:15:35PM +0200, Frank van der Linden wrote:
> Hi Dave,
> 
> If you can, try out a GENERIC.MPACPI kernel. It looks like the default
> MPBIOS interrupt mappings aren't complete, the ACPI mappings have a much
> better chance of working.

Is a precompiled one available anywhere? If not, that's fine... I'm
setting up a amd64 cross-build environment right now, but it's running
on a fairly old alpha :)

Dave Huang | 2 May 02:19 2005

Re: intr_establish: can't share intr source between different PIC types

On Sun, May 01, 2005 at 05:15:35PM +0200, Frank van der Linden wrote:
> Hi Dave,
> 
> If you can, try out a GENERIC.MPACPI kernel. It looks like the default
> MPBIOS interrupt mappings aren't complete, the ACPI mappings have a much
> better chance of working.

OK, I built a MPACPI kernel (not GENERIC.MPACPI; amd64 doesn't have
that config file), but it's even worse :( Not all PCI busses are
configured, and it thinks I have 3 CPUs instead of 2 :)

I tried it with MPACPI_SCANPCI enabled and disabled, and it didn't
make any difference. The config file I used is:

include	"arch/amd64/conf/std.amd64"
options 	INCLUDE_CONFIG_FILE	# embed config file in kernel binary
maxusers	32		# estimated number of users
options 	INSECURE	# disable kernel security levels - X needs this
options 	RTC_OFFSET=0	# hardware clock is this many mins. west of GMT
options 	NTP		# NTP phase/frequency locked loop
options 	KTRACE		# system call tracing via ktrace(1)
options 	SYSTRACE	# system call vetting via systrace(1)
options 	SYSVMSG		# System V-like message queues
options 	SYSVSEM		# System V-like semaphores
options 	SYSVSHM		# System V-like memory sharing
options 	P1003_1B_SEMAPHORE
options 	LKM		# loadable kernel modules
options 	USERCONF	# userconf(4) support
options 	SYSCTL_INCLUDE_DESCR	# Include sysctl descriptions in kernel
options 	COMPAT_20	# NetBSD 2.0,
(Continue reading)

Frank van der Linden | 3 May 22:46 2005
Picon

Re: intr_establish: can't share intr source between different PIC types

Hmm.. can you try MPVERBOSE kernels with MPACPI and MPBIOS respectively,
and send the dmesg outputs? I'm not quite sure what's going on here.

- Frank

Dave Huang | 4 May 03:53 2005

Re: intr_establish: can't share intr source between different PIC types

On Tue, May 03, 2005 at 10:46:47PM +0200, Frank van der Linden wrote:
> Hmm.. can you try MPVERBOSE kernels with MPACPI and MPBIOS respectively,
> and send the dmesg outputs? I'm not quite sure what's going on here.

Sure... here's the dmesg from a kernel with MPACPI and MPACPI_SCANPCI
(and acpi0 at mainbus0; I assume that's required for MPACPI? I didn't
actually try without it):

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 3.99.3 (CHEETAH) #6: Tue May  3 20:33:12 CDT 2005
	khym <at> yerfable.azeotrope.org:/usr2/obj.amd64/sys/arch/amd64/compile/CHEETAH
total memory = 2046 MB
avail memory = 1959 MB
mainbus0 (root)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron(tm) Processor 246, 2009.36 MHz
cpu0: features: e7dbfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features: e7dbfbff<PGE,MCA,CMOV,PAT,PSE36,MPC,NOX,MMXX,MMX>
cpu0: features: e7dbfbff<FXSR,SSE,SSE2,LONG,3DNOW2,3DNOW>
cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way
cpu0: L2 cache 1 MB 64B/line 16-way
cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associative
cpu0: calibrating local timer
cpu0: apic clock running at 200 MHz
cpu0: 16 page colors
(Continue reading)

Gary Duzan | 5 May 13:45 2005

Java Support

   I did some minor tweaking to get sablevm to work on amd64, and
I've submitted the patches as pkg/30137 and pkg/30138. The testing
I did was minimal, so additional testing would be welcome.

					Gary Duzan


Gmane