"Good" amd64 NetBSD 2.0 kernel needed

Hi,

I've been plagued with "device timeout"s on every NIC I try in the
amd64 box running NetBSD 2-0.  I just can't seem to find/generate
a stable kernel.  Can't keep the network working for more than
about about a minute once heave network traffic to the machine
begins.  I can't tell if this is my pavilion a530n or the kernel.

Does anyone out there have a GENERIC kernel they trust from the 2-0
or -current tree that they could forward/refer me?

Thanks,
-scott

Re: ``K8, issue #93''.

Richard Rauch wrote:

>I'm presently running my AMD64 box in a 3-way boot.  Partition
>#1 has NetBSD, but some of the stability issues (plus an itch
>to see DRI running; (^&) pushed me to look at other systems.
>
>I tried FreeBSD, but it was a bit rough.  SuSE GNU/LINUX also had
>problems when I last tried it.  However, a recent Mandrake GNU/LINUX
>is running---and, I think, is running more stably than NetBSD.
>(sigh)
>
>
>The reason for my posting here is that the GNU/LINUX kernel comes up
>with a report about a ``K8'' issue (typed by hand):
>
>****** Your BIOS seems to not contain a fix for K8 errata #93
>****** Working around it, but it may cause SEGVs or burn power.
>****** Please consider a BIOS update.
>****** Disabling USB legacy in the BIOS may also help.
>
>...and I thought that it might help in isolating the problems
>in NetBSD if I forwarded this information.
>
>I have the latest BIOS already, as far as I know.
>
>I could not find "legacy" options for USB, but perhaps that's
>just a synonym for something else?  I could disable USB 1.1
>when booting Mandrake...but for NetBSD, I think that I need
>USB 1.1.
>  

Re: ``K8, issue #93''.

Stephen Degler wrote:

>
> Legacy options for usb include bios support for usb keyboard and mouse.
>
> I've surfed around a little bit but haven't found an exact description 
> of k8 errata #93, but I don't think its the reboot problem.

Note to self: Think first, then post.
Looking at the linux 2.6.4 sources, the probem is pretty severe, but its 
not clear to me how it might be getting triggered.

skd
.

Re: ``K8, issue #93''.

On Mon, May 03, 2004 at 09:21:27PM -0400, Stephen Degler wrote:
> Richard Rauch wrote:
 [...]
> >I could not find "legacy" options for USB, but perhaps that's
> >just a synonym for something else?  I could disable USB 1.1
> >when booting Mandrake...but for NetBSD, I think that I need
> >USB 1.1.
> > 
> >
> 
> Legacy options for usb include bios support for usb keyboard and mouse.

Hm.  Well, if I turn off that, as I recall, I could not configure BIOS with
a USB keyboard.

At least with the original BIOS, I recall needing a PS/2 keyboard
to configure BIOS.

--

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: ``K8, issue #93''.

On Mon, May 03, 2004 at 09:54:16PM -0400, Stephen Degler wrote:
> Stephen Degler wrote:
> 
> >
> >Legacy options for usb include bios support for usb keyboard and mouse.
> >
> >I've surfed around a little bit but haven't found an exact description 
> >of k8 errata #93, but I don't think its the reboot problem.
> 
> Note to self: Think first, then post.
> Looking at the linux 2.6.4 sources, the probem is pretty severe, but its 
> not clear to me how it might be getting triggered.

Hm.  Well, I figured anything that might cause segfaults even when
"worked around" could be pretty nasty to an OS that doesn't have
any defenses.  (^&

Thanks for the information, though.

--

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

MPACPI fix (for those who had trouble with it, urgent!)

Hi,

I looked into the problem of MPACPI related panics and am trying to
fix it.  If you had any panic with the existing MPACPI code,
please try the patch attached to this message ASAP, so that
we can make it for 2.0-release.

And if you still see any panic with this patch, please let me know.
What I need to investigate is, quoting from what fvdl wrote on
March 29:

> 1) The name of the motherboard you have
> 2) Boot message output (preferably with MPVERBOSE switched on)
> 3) The output of acpidump. acpidump can be found in
>   pkgsrc/sysutils/acpidump

As well as failure report, any success reports are also welcome!

The problem seems that the logic finding subordinate bus number is
somewhat fragile and sometimes it can fail to find the number on some
ACPI BIOS implementation.
In the patch I tried to make the bus discovery logic more robust.

I tested this on two systems (dual P3 VIA chipset motherboard,
and P4 HT 865PE-based motherboard) and they are ok.

BTW, Frank, have you got any reply to the mail?
If you already have any DSDT that caused panic, I'd like to
investigate it.

Re: MPACPI fix (for those who had trouble with it, urgent!)

From: Takayoshi Kochi <kochi <at> netbsd.org>
Subject: MPACPI fix (for those who had trouble with it, urgent!)
Date: Tue, 04 May 2004 11:31:44 +0900 (JST)

> Hi,
> 
> I looked into the problem of MPACPI related panics and am trying to
> fix it.  If you had any panic with the existing MPACPI code,
> please try the patch attached to this message ASAP, so that
> we can make it for 2.0-release.

I forgot to mention that the patch was for the very -current.

If you would like to test on 2.0-BETA, please replace
/sys/arch/x86/x86/mpacpi.c with the attached new file.

---
Takayoshi Kochi

/*	$NetBSD: mpacpi.c,v 1.23 2004/04/25 11:25:35 tron Exp $	*/

/*
 * Copyright (c) 2003 Wasabi Systems, Inc.
 * All rights reserved.
 *
 * Written by Frank van der Linden for Wasabi Systems, Inc.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions

Re: MPACPI fix (for those who had trouble with it, urgent!)

> > I looked into the problem of MPACPI related panics and am trying to
> > fix it.  If you had any panic with the existing MPACPI code,
> > please try the patch attached to this message ASAP, so that
> > we can make it for 2.0-release.
> 
> I forgot to mention that the patch was for the very -current.
> If you would like to test on 2.0-BETA, please replace
> /sys/arch/x86/x86/mpacpi.c with the attached new file.

Hi Takayoshi:

I took the lastest 2.0 Beta sources from NetBSD-current this morning
and replaced the mpacpi.c file with the one you posted to the mailing
list.

On my ACPI laptop, I still get the exact same behavour that I had
with earlier kernels.  Basically with MPACPI, if I still unable to
use my laptop's PCMCIA slot.

If I enable cardbus (option cbb* & option cardslot*) and
PCIBIOS_ADDR_FIXUP in my kernel, the kernel panics during boot:

=======================================================================
...
ppb0 at pci0 dev 30 function 0: Intel 82801BAM Hub-to-PCI Bridge (rev. 0x83)
pci1 at ppb0 bus1
pci1: i/o space, memory space enabled
cbb0 at pci1 dev 3 function 0: Ricoh 5C475 PCI-CardBus bridge (rev. 0xb8)
uvm_fault(0xc05ddd3c0, 0, 0, 1) -> 0xe
kernel: page fault trap, code=0

Re: MPACPI fix (for those who had trouble with it, urgent!)

Hi,

While looking into interrupt related problems, I found a bug
in arch/x86/x86/intr.c, which can result in wrong interrupt
routing for devices behind PCI-to-PCI bridge (with MPACPI or
MPBIOS).

For -current, I commited the fix (in rev 1.16) and issued
a pullup request for 2.0.  The patch is attached to this mail.

Also, I found a corner case in MPACPI when a card containing
PCI-to-PCI bridge is inserted in the last PCI bus.

For example, pci0..pci2 is found in ACPI namespace, mp_busses[]
will be:

mp_busses[0] : PCI
mp_busses[1] : PCI
mp_busses[2] : PCI
mp_busses[3] : ISA

and if a PCI-to-PCI bridge card is on the bus2, the secondary bus
number will be 3.  Then interrupt routing code gets confused.

I think ideally we would like to have separate arrays for each type
of busses, but it requires agreement with others and somewhat big
change.  So I don't think this will eligible for 2.0.

So I workaround this by adding some space between last PCI bus
and ISA to accomodate some PCI-to-PCI busses.

recommendation?

We are looking at setting up an experimental/development
database/workflow server. While seemingly simplistic, we have
determined that we basically just need three primary things: plenty
of ram, fast cpu and fast disk. I have absolutely no experience
with using Opterons with NetBSD, so have a few questions:

The amd64 port isn't 'released'. Is it stable enough to use in a
single-cpu environment?

What's the fastest disk subsystem that works with it? I was planning
on a scsi/320 controller (raid?) with a WD 37G 10krpm drive to
start with. Anyone have experience with something like this?

If the amd64 port isn't stable enough, can I drop back and use the
i386 port with the Opteron until the amd64 port comes up to speed?
( I only get one shot at hardware for a while for this).

Recommendations welcome. Thanks