Re: Lockup on current-ish system

On Sun, Sep 28, 2003 at 03:47:16AM -0500, Dave Huang wrote:
> I upgraded my PC164 system from 1.6.1 to current as of September 17,
> and it hung on the 23rd and the 28th. When it's hung, it's still
> responsive to pings, but hitting Enter on the console doesn't bring up
> a login prompt or echo blank lines. However, Ctrl-Alt-Esc still breaks

I figured it might lock up again while I was out of town, so I
switched it to serial console (yay for serial console :) in case I
needed to reboot it remotely. And sure enough, it locked up... here's
another stack trace. upsd was the current process again, and the trace
looks very similar to the one from last time:

cpu_Debugger() at netbsd:cpu_Debugger+0x4
comintr() at netbsd:comintr+0x160
alpha_shared_intr_dispatch() at netbsd:alpha_shared_intr_dispatch+0x6c
sio_iointr() at netbsd:sio_iointr+0x68
interrupt() at netbsd:interrupt+0x274
XentInt() at netbsd:XentInt+0x1c
--- interrupt (from ipl 0) ---
pmap_emulate_reference() at netbsd:pmap_emulate_reference+0x14c
trap() at netbsd:trap+0x238
XentMM() at netbsd:XentMM+0x20
--- memory management fault ---
memcpy() at netbsd:memcpy+0x19c
copyout() at netbsd:copyout+0x4c
sys_select() at netbsd:sys_select+0x4a4
syscall_plain() at netbsd:syscall_plain+0x138
XentSys() at netbsd:XentSys+0x5c
--- syscall (93) ---
--- user mode ---

Re: MAGMA driver source licence [UPDATE]

Felix,

Thank you.  This is a great service to the community; the previous license
would have effectively prevented the use of this code or anything based on
it in any free operating system.  The new license should work for just
about anyone who needs to use it.

I do have one recommendation.  In the email that you provide as the
license, you snip out everything but the BSD license segment, and include
in your own comments the fact that it applies to the code, and that the
embedded copyright notices can be ignored.  If that is in the original
message, I would include it.  Indeed, barring specific reasons to not do
so, I would include the message in its entirety.
The thing that concerns me is that five years from now, a Magma lawyer
will discover Magma source code in NetBSD.  The people who approved the
release of the code won't be around anymore, and the heavily redacted
email won't be nearly as convincing as a complete one.

Also, perhaps if you know anything about the code, you could write a
README to include with the distribution.  For example, do you know what
versions of Unix and VMS these are supposed to compile under?  I did a
rough sanity check, comparing the includes to those in /usr/sys/include on
Tru64 5.1b (via HP TestDrive), and they are similar.  I didn't try
compiling the drivers, however.

As far as hosting the code, perhaps starting a project on sourceforge.net
would be best?  You could just add the tarball as a released file.

Noah Misch
noah <at> caltech.edu

Re: MAGMA driver source licence [UPDATE]

Noah J. Misch wrote:

> I do have one recommendation.  In the email that you provide as the
> license, you snip out everything but the BSD license segment, and include
> in your own comments the fact that it applies to the code, and that the
> embedded copyright notices can be ignored.  If that is in the original
> message, I would include it.

It is not in the original message, unfortunately. Chuck wants me to 
maintain the archive now, he only modified a BSD license "dummy" which I 
had sent to him before. I had to put everything into a suitable form.

> The thing that concerns me is that five years from now, a Magma lawyer
> will discover Magma source code in NetBSD.  The people who approved the
> release of the code won't be around anymore, and the heavily redacted
> email won't be nearly as convincing as a complete one.

Believe me: MAGMA is not interested in anything concerning the 
TurboChannel or old DEC hardware anymore. Support has ended. They aren't 
interested in wasting money.
And even if MAGMA put lawyers on NetBSD, they would have to consider 
Chuck Brost and me 

So accept "my" license or bug Chuck Brost again. But he won't tell you 
anything new...

> Also, perhaps if you know anything about the code, you could write a
> README to include with the distribution.  For example, do you know what
> versions of Unix and VMS these are supposed to compile under?  I did a
> rough sanity check, comparing the includes to those in /usr/sys/include on

AS4000 dual..etc for the right price.

Dual AS4000 (as is) free for pick up in Ronkonkoma New York, USA.
Machine is on wheels weight ~150LB.
-Mel
--

-- 
mel kravitz <melk <at> switchpwr.com>
switching power inc

Heads up, siginfo changes about to be committed

Hello,

I'm about to commit the siginfo changes for the alpha platform.

You will need to add COMPAT_16 and recompile your kernels before
updating userland.

Enjoy,
skd

pciide -> atabus change

Hi,
I suspect the attached diff is needed for alpha booting from pciide devices
to find the root device.
Can someone check and confirm ?

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer <at> lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--

Index: alpha/api_up1000.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/alpha/api_up1000.c,v
retrieving revision 1.14
diff -u -r1.14 api_up1000.c
--- alpha/api_up1000.c	2003/06/14 17:01:07	1.14
+++ alpha/api_up1000.c	2003/10/08 20:42:42
 <at>  <at>  -275,7 +275,7  <at>  <at> 
 	 */
 	if ((ideboot || scsiboot) && !strcmp(name, "wd")) {
 		struct ata_device *adev = aux;
-		if ((strncmp("pciide", parent->dv_xname, 6) != 0)) {
+		if ((strncmp("atabus", parent->dv_xname, 6) != 0)) {
 			return;
 		} else {
 			if (parent != scsipidev)
Index: alpha/dec_550.c
===================================================================
RCS file: /cvsroot/src/sys/arch/alpha/alpha/dec_550.c,v

Re: WARNING: 328.56ns period on non-DT device??

On Saturday, October 11, 2003, at 06:18  PM, Paul Mather wrote:

> I just built and rebooted a new 1.6-CURRENT kernel on an AlphaServer
> 1000A.  Now, on probing the SCSI buses, some of the drives include
> a line which says "WARNING: 328.56ns period on non-DT device."
>
> What does this mean?

That I made a mistake.  I'll try to correct it shortly.

         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Possible Sale: AlphaServer 4100 in Sydney, Australia

Hi guys,

I've got an AlphaServer 4100 sitting in my room, and I'm about to move to
Perth. I'm not sure I want to lug this thing all the way over there and so
I'm wondering if anyone in Australia (Sydney specifically) would be
interested in buying this baby off me. System details are as below:

4 x 466MHz EV5 CPUs with 4MB Cache each
3 x PSU's (Only one seems to work. Don't know if it's the PSUs or the
system)
12 x 4.3GB SBBs in 2 storageworks bays each with 2 x psu modules, plus a 3rd
storageworks bay in the rear of the machine
CD-ROM, DDS2 tape drive
3 x DAC960 raid cards
Number 9 video card
2 x DE500 NICs
Powerstorm 3D30T (?) video card
all power cables / scsi cables

Spares:
466MHz CPU
300MHz CPU
Power control module
PCI bus

System powers up and rund Tru64, WinNT4 and RedHat linux well. Can supply
RedHat 7.2 AXP (originals) + Install wrapper (download) cdroms and printed
booklets of most of the AS4100 manuals.

I paid around $2000 Australian. I'd like to recover as much of this as

Re: Vinum on alpha?

On Sat, Oct 11, 2003 at 08:33:54PM -0400, Paul Mather wrote:
> I noticed in a recent CVS update of -CURRENT that vinum appeared in
> the tree.  However, only majors.i386 appeared to be updated with a
> device number entry.  Does this mean vinum only works on NetBSD/i386,
> or is the omission in majors.alpha just an oversight a la the nsmb
> device for a while?

It was a mistake. It has been backed out, and a MI major number added.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--

Re: pciide -> atabus change

Manuel Bouyer <bouyer <at> antioche.lip6.fr> writes:

> I suspect the attached diff is needed for alpha booting from pciide devices
> to find the root device.
> Can someone check and confirm ?

Your patch was half of what was necessary. The parent name did change
from pciide to atabus, but the scsipidev became associated with the
higher-up IDE device (aceride0, in my case), so the next test
failed. I wasn't sure if there will always be the same number of
layers between the wd device and the ide controller, so I made a
loop that searches up the device tree until it finds the scsipidev
device or hits root. If the device distance is fixed, than the "parent
!= scsipidev" test can be changed to "parent->dv_parent != scsipidev"
instead of having a loop.

        - Nathan