Hi, I'm trying to upgrade my DEC3000 M600 from 1.4.2 to 2.02. The installer hangs at "Terminal type? [vt100]". I'm using minicom from a linux i386 box with the terminal type set to vt102 onto the mmj serial port. Is there some way around this? Thanks, -- -- Mark Ter Morshuizen www.itbox.co.za
On Sat, 1 Oct 2005 23:00:12 +0200 Mark Ter Morshuizen <mark <at> itbox.co.za> wrote: > I'm trying to upgrade my DEC3000 M600 from 1.4.2 to 2.02. The > installer hangs at "Terminal type? [vt100]". I did several fresh installs of 2.0.2 on an identical machine. Are you actually using the "upgrade" option in the installer? I haven't tried that. I dodn't recall any problem similar to this. -- -- Michael Smith Network Applications www.netapps.com.au | +61 (0) 416 062 898 Web Hosting | Internet Services
Hello fellow netbsd/alpha users I' trying to install netbsd 2.0.2 on a DS10 using a 120 GB hard drive on the builtin IDE controller. The installation is all fine, however at the first reboot the machine hangs on" root file system type: ffs" and does not procede any further expect always repeating aceride0:0:1: lost interrupt type: ata tc_bcount: 512 tc_skip: 0ata port and messages of the like. When I boot from the install cd and chroot to the root partition on this disk, I get the following message mounting the root partition. stray isa irq 14 stray isa irq 14 wd0: transfer error, downgrading to Ultra-DMA mode 1 wd0(aceride0:0:1): using PIO mode 4, Ultra-DMA mode 1 (using DMA data transfers) wd0a: DMA error reading fsbn 128 of 128-143 (wd0 bn 128; cn 0 tn 2 sn 2), retryg stray isa irq 14; stopped logging wd0: soft error (corrected) After this message the system runs without problem in the chroot. Is this a software ore a hardware problem ?(Continue reading)
ek> stray isa irq 14
ek> wd0: transfer error, downgrading to Ultra-DMA mode 1
ek> wd0(aceride0:0:1): using PIO mode 4, Ultra-DMA mode 1 (using DMA data transfers)
ek> wd0a: DMA error reading fsbn 128 of 128-143 (wd0 bn 128; cn 0 tn 2 sn 2), retryg
ek> stray isa irq 14; stopped logging
ek> wd0: soft error (corrected)
this may be related:
http://mail-index.netbsd.org/port-alpha/2005/01/24/0000.html
It sounded like, on sparc64 there is MD code to manage the 'max
latency' pci register, while on alpha the SRM is expected to do it but
doesn't, and there are long-standing problems reported back to 2003
with IDE on alpha that might be related.
FWIW, whenever I reboot I get these:
tlp3: transmit underrun; new threshold: 96/256 bytes
tlp2: transmit underrun; new threshold: 96/256 bytes
tlp2: transmit underrun; new threshold: 128/512 bytes
tlp2: transmit underrun; new threshold: 160/1024 bytes
tlp3: transmit underrun; new threshold: 128/512 bytes
tlp3: transmit underrun; new threshold: 160/1024 bytes
These are a bunch of quad tulip PCI cards, four tulip chips behind a
PCI-PCI bridge. I have nothing to suggest it's related to PCI max
latency besides that some of the same words were used in the thread
above. I tried IDE on alpha once, and then switched to SCSI only
after seeing those degredation messages. too many Linux boxes have
(Continue reading)On Tue, Oct 04, 2005 at 10:18:51PM +0200, Emmanuel Ka wrote: > Hello fellow netbsd/alpha users > I' trying to install netbsd 2.0.2 on a DS10 using a 120 GB hard drive on > the builtin IDE controller. The installation is all fine, however at the > first reboot the machine hangs on" root file system type: ffs" and does > not procede any further expect always repeating > > aceride0:0:1: lost > interrupt > type: ata tc_bcount: 512 tc_skip: 0ata port > > and messages of the like. > When I boot from the install cd and chroot to the root partition on this > disk, I get the following message mounting the root partition. > > stray isa irq > 14 > stray isa irq > 14 > wd0: transfer error, downgrading to Ultra-DMA mode > 1 > wd0(aceride0:0:1): using PIO mode 4, Ultra-DMA mode 1 (using DMA data > transfers) > wd0a: DMA error reading fsbn 128 of 128-143 (wd0 bn 128; cn 0 tn 2 sn > 2), retryg > stray isa irq 14; stopped > logging > wd0: soft error (corrected) > > After this message the system runs without problem in the chroot.(Continue reading)
Hello As I know from BSD, the default root file system is hardcoded into the kernel. Is it possible to indicate another one at the boot prompt, so I can copy the INSTALL kernel on the root partition, tell this kernel to use /dev/wd0a and use that in the meantime ? Sorry for the first dmesg posted, it looked something went wrong with cut and paste. Manu Here follows a correct one : >>>boot dqa1 (boot dqa1.1.0.13.0 -flags 0,0) block 0 of dqa1.1.0.13.0 is a valid boot block reading 14 blocks from dqa1.1.0.13.0 bootstrap code read in base = 200000, image_start = 0, image_bytes = 1c00 initializing HWRPB at 2000 initializing page table at 1ff52000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code NetBSD/alpha 2.0.2 FFS Primary Bootstrap |/-\|/-\|/-\Jumping to entry point... NetBSD/alpha 2.0.2 Secondary Bootstrap, Revision 1.13 (builds <at> works.netbsd.org, Tue Mar 22 03:21:07 UTC 2005)(Continue reading)
On Thu, Oct 06, 2005 at 11:14:45AM +0200, Emmanuel Ka wrote: > Hello > As I know from BSD, the default root file system is hardcoded into the > kernel. No, it finds it from various infos passed by the boot loader. > Is it possible to indicate another one at the boot prompt, so I can copy > the INSTALL kernel on the root partition, tell this kernel to use > /dev/wd0a and use that in the meantime ? Yes, try boot -flags an > Sorry for the first dmesg posted, it looked something went wrong with > cut and paste. > Manu > > Here follows a correct one : If you can boot the INSTALL kernel with root on wd0a, make a diff between its dmesg and the generic one, it should point to the driver causing problems. -- -- Manuel Bouyer <bouyer <at> antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --
Hi, I'm pleased to announce the initial result of porting of John Polstra's ezm3 Modula-3 compiler, version 1.2, to two new NetBSD targets: alpha and big-endian MIPS. The target must run NetBSD 2.0 or higher. ezm3 is commonly used to compile CVSup, and I've verified that the resulting compilers produces working versions of cvsup on both of the above two new targets. The source diff and the bootstrap kits for alpha and mipseb can be found on ftp://quattro.urc.uninett.no/pub/NetBSD/ezm3/ For pointers to ezm3 itself, please see http://www.polstra.com/projects/freeware/ezm3/ I've also left some code in there from some stalled or failed attempts at porting ezm3 to amd64, m68k and sparc64. (Some of this code is now incomplete.) The file NetBSD-Notes.txt which will appear once the source diff is applied contains some more details about the status for each of the various NetBSD targets which there is code for in ezm3 + the patch. Assistance in getting the problems resolved would be appreciated. Best regards,(Continue reading)
On Sat, 08 Oct 2005 22:47:25 +0200, Havard Eidnes wrote: > Hi, > > I'm pleased to announce the initial result of porting of John > Polstra's ezm3 Modula-3 compiler, version 1.2, to two new NetBSD > targets: alpha and big-endian MIPS. > > The target must run NetBSD 2.0 or higher. > > ezm3 is commonly used to compile CVSup, and I've verified that > the resulting compilers produces working versions of cvsup on > both of the above two new targets. > > The source diff and the bootstrap kits for alpha and mipseb can > be found on > > ftp://quattro.urc.uninett.no/pub/NetBSD/ezm3/ Thank you very much for this effort, I would like to have CVSup on alpha. But your patch doesn't work - if I unpack the original ezm distribution and apply your patch in ezm3-1.2 directory, all files with should be created in not yet existing directories are created in the ezm3-1.2 directory itself instead, and those directories are not created: ezm3-1.2$ ls COPYRIGHT Uerror.i3.orig UsignalMD.i3 COPYRIGHT.orig Uexec.i3 UsignalMD.i3.orig Csetjmp.i3 Uexec.i3.orig UsignalMD.m3 Csetjmp.i3.orig Ugrp.i3 UsignalMD.m3.orig(Continue reading)
> Thank you very much for this effort, I would like to have CVSup on alpha. > But your patch doesn't work - if I unpack the original ezm distribution > and apply your patch in ezm3-1.2 directory, all files with should be > created in not yet existing directories are created in the ezm3-1.2 > directory itself instead, and those directories are not created: That's not good, of course. However, I think that if you invoke patch with "patch -p0 <file" instead of just "patch <file", it will create the necessary directories -- it does for me, anyway. Regards, - Håvard
RSS Feed4 | |
|---|---|
6 | |
25 | |
9 | |
14 | |
32 | |
22 | |
1 | |
1 | |
6 | |
1 | |
2 | |
6 | |
2 | |
14 | |
1 | |
6 | |
3 | |
30 | |
6 | |
13 | |
13 | |
6 | |
17 | |
21 | |
1 | |
4 | |
2 | |
2 | |
2 | |
3 | |
10 | |
10 | |
1 | |
3 | |
1 | |
5 | |
11 | |
5 | |
9 | |
23 | |
17 | |
19 | |
15 | |
12 | |
32 | |
24 | |
22 | |
9 | |
23 | |
2 | |
11 | |
2 | |
2 | |
26 | |
2 | |
35 | |
8 | |
9 | |
11 | |
15 | |
9 | |
22 | |
39 | |
7 | |
24 | |
39 | |
37 | |
35 | |
27 | |
43 | |
16 | |
22 | |
31 | |
22 | |
12 | |
22 | |
30 | |
23 | |
27 | |
32 | |
58 | |
31 | |
18 | |
23 | |
32 | |
22 | |
64 | |
85 | |
20 | |
31 | |
68 | |
50 | |
85 | |
87 | |
57 | |
44 | |
65 | |
34 | |
68 | |
46 | |
57 | |
43 | |
57 | |
37 | |
86 | |
38 | |
86 | |
33 | |
102 | |
96 | |
98 | |
43 | |
113 | |
128 | |
164 | |
68 | |
184 | |
132 | |
87 | |
112 | |
90 | |
74 | |
145 | |
135 | |
161 | |
66 | |
19 |
