http://permalink.gmane.org/gmane.os.netbsd.ports.news68k hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/63 <pre>Yet another "this port is still alive" message: --- NEWS&gt; bo NetBSD/news68k Primary Boot NetBSD/news68k Secondary Boot, Revision 1.7 (from NetBSD 5.99.64) Booting hd(0,0,0) 2952628+133964 [205968+197427]=0x3544e4 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 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 5.99.64 (GENERIC) #0: Fri Feb 10 17:26:20 JST 2012 tsutsui&lt; at &gt;mirage:/s/src/sys/arch/news68k/compile/obj.news68k/GENERIC SONY NET WORK STATION, Model NWS-1750, Machine ID #10557 total memory = 16368 KB avail memory = 12104 KB mainbus0 (root) hb0 at mainbus0 le0 at hb0 addr 0xe0f00000 ipl 4: address 08:00:46:00:35:36 le0: 8 receive buffers, 2 transmit buffers timer0 at hb0 addr 0xe1000000 ipl 6 mkclock0 at hb0 addr 0xe0d80000: mk48t02 kbc0 at hb0 addr 0xe0d00000 ipl 5 kb0 at kbc0 wskbd0 at kb0 (mux ignored) ms0</pre> Izumi Tsutsui 2012-02-10T16:51:24 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/62 <pre>Dear news68k users, As seen in source-changes&lt; at &gt;, I've committed preliminary PROM internal function based framebuffer console output support: http://mail-index.NetBSD.org/source-changes/2011/11/20/msg029148.html --- Module Name:src Committed By:tsutsui Date:Sun Nov 20 15:38:00 UTC 2011 Modified Files: src/sys/arch/news68k/conf: GENERIC INSTALL files.news68k majors.news68k src/sys/arch/news68k/dev: if_le.c kb_hb.c si.c zs.c src/sys/arch/news68k/include: cpu.h vmparam.h src/sys/arch/news68k/news68k: locore.s machdep.c pmap_bootstrap.c Added Files: src/sys/arch/news68k/news68k: romcalls.S romcons.c Log Message: Add preliminary PROM internal function based framebuffer console support, which was demonstrated at Open Source Conference 2011 Kansai &lt; at &gt; Kyoto back in July: http://www.NetBSD.org/gallery/events.html#opensourceconf2011-Kansai - map 0xc0000000-0xffffffff PA region (which is mirror of PA 0x0-0x3fffffff) to the same VA via %tt0 and %tt1 registers and move KVA space accordingly (like luna68k d</pre> Izumi Tsutsui 2011-11-20T16:27:51 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/61 <pre>Here's some of the healthcare lists we have: Massage Therapists - 76,701 records and 8,305 emails Acupuncturists - 23,988 records 1,826 emails Physical Therapists - 125,460 total records with 5,483 emails and 4,405 fax numbers Theres many more too, just send me an email here for additional info/samples: Robin.Kimball&lt; at &gt;tools4success.co.cc to stop this email in future email us at disappear&lt; at &gt;tools4success.co.cc </pre> Peters aqueduct 2010-05-04T04:34:18 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/60 <pre>Please feel free to contact me at the email below for more info and to get samples. Regards, Rae Meadows Email: Jocelyn.Rose&lt; at &gt;optinmailinglists.co.cc By emailing disappear&lt; at &gt;optinmailinglists.co.cc you will have your email taken off </pre> Warren Carrier 2010-04-08T20:32:22 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/58 <pre>Hi, After cleanup of pmap_bootstrap.c on all hp300 derived ports, I also made some changes in my local tree which make NetBSD/news68k kernel also work with 8KB/page settings. I've tried pkgsrc/benchmark/bytebench on both 4KB/page and 8KB/page kernels on the same machine (NWS-1750D, 68030/25MHz with 16KB L2 cache), and I'm surprised because 8KB/page kernel is significantly faster than 4KB/page kernel. Are these results really expected? On 4KB/page kernel: ------------------------------------------------------------ BYTE UNIX Benchmarks (Version 4.1.0) System -- libero Start Benchmark Run: Tue Dec 8 22:11:49 JST 2009 1 interactive users. 10:11PM up 10 mins, 1 user, load averages: 0.47, 0.79, 0.54 -r-xr-xr-x 1 root wheel 135783 Apr 27 2009 /bin/sh /bin/sh: ELF 32-bit MSB executable, Motorola 68020, version 1 (SYSV), \ dynamically linked (uses shared libs), for NetBSD 5.0, not stripped /dev/sd0a 314015 44559 253756 14% / Dhrystone 2 using register variables 792</pre> Izumi Tsutsui 2009-12-08T16:20:20 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/57 <pre>2009/11/1 Izumi Tsutsui &lt;tsutsui&lt; at &gt;ceres.dti.ne.jp&gt;: Interesting that the firmware itself fails to load the bootloader from scsi, but the bootloader can use firmware calls to load the kernel from scsi... In this case I would agree that it looks like a hardware issue - particularly given the issue loading the firmware, I was just thinking about a general solution... Ow.... If there is a linear framebuffer then its *really* easy to write an attach routine for genfb and away you go (I was helping gavan when he added wsdisplay via genfb support to iyonix) - you literally just need to know the address, width, height &amp; bitdepth. </pre> David Brownlee 2009-11-01T20:29:13 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/56 <pre> Ah, no, the bootloader just calls the rom_read() function in firmware, and maybe it uses DMA for SCSI but not for floppy. Well, SCSI DMA on my NWS-1460 worked at least when news68k port was imported, so I'm afraid there might be some hardware malfunction which causes the DMA failure. We need wsdisplay support first (though we already have wskbd support ;-) I toasted a framebuffer chip when I was playing on CRTC on my NWS-1460 about nine years ago... --- Izumi Tsutsui </pre> Izumi Tsutsui 2009-11-01T17:56:15 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/55 <pre>2009/10/31 TOMARI Hisanobu &lt;posco.grubb&lt; at &gt;gmail.com&gt;: So the NetBSD/news68k bootloader does not use DMA &amp; works, but the firmware does use DMA and does not :/ Hmm, theoretically it shouldn't be too difficult to have code on attach read the first sector twice: once with DMA enabled and once without, and then warn and disable DMA if they differ. I think there are still some sun3 &amp; mac68k machine/disk combinations where the DMA hardware is not 'just broken', which might benefit from that, though I don't know if its really generally useful :) [... very lean dmesg...] excellent stuff! Whats next? Playing with X on it or maybe trying to write the news rd remote disk netboot support? :) :) :) </pre> David Brownlee 2009-11-01T17:01:11 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/54 <pre>I tried following config: si0 at hb0 addr 0xe0cc0000 ipl 4 flags 0x20000 and it did the trick! I partitioned the original 240MB disk on the machine then put NetBSD on it, all went really smoothly. However, when the firmware tries to load the bootloader, it seems to use DMA transfers, and therefore cannot boot. So I ended up creating a "Startup Floppy" containing bootloader and kernel. This is how it goes on my half-broken machine: 16M bytes available, 16K byte(s) reserved. SONY NET WORK STATION MC68030 Monitor Release 1.5A Model NWS-1460, Machine ID #10087, Ethernet address 08:00:46:00:4c:d3 NEWS&gt; bo fh NetBSD/news68k Primary Boot NetBSD/news68k Secondary Boot, Revision 1.7 (from NetBSD 5.0.1_PATCH) Booting fh(0,0,0) 1455268+34172+271228=0x1b0044 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All right</pre> TOMARI Hisanobu 2009-10-31T01:19:33 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/53 <pre> Umm, I'm afraid so because DMA is used only for &gt;128 bytes xfers. (defined as MIN_DMA_LEN in sys/arch/news68k/dev/si.c) If you can rebuild a kernel on other host, you can disable SCSI DMA as mentioned in sys/arch/news68k/conf/GENERIC: --- # For example: "flags 0x1000f" would disable DMA interrupts, # and disable disconnect/reselect for targets 0-3 # si0 at hb0 addr 0xe0cc0000 ipl 4 flags 0x0 --- Ok, thanks. If you have some spare time, I'd like to see how NetBSD 4.0.1 goes on the same machine.. --- Izumi Tsutsui </pre> Izumi Tsutsui 2009-10-27T14:51:25 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/52 <pre>This test passed without problem on my machine, and it took about 2-3 hours. SIMMs are of the type that you mentioned. I also tried installing 4-chip and 2-chip 1MB SIMMs from my Mac IIci but it didn't work indeed. I removed some of the SIMMs, but the stack trace didn't change a bit. Thank you for the disk image. I dd'ed the image, but the machine didn't boot. To further investigate the problem, I made a small(8KB) test pattern image and tested writing and reading it back from the harddrive. The data that are read from the drive were all-0's or just pile of random bytes. I replaced the cable and reseated all the chips that are mounted on socket, but the situation didn't change. What is strange is that the controller identifies the drive correctly, which means only DMA transfers are affected? Anyways, thanks for your help! I'll keep the machine so I can repair it when I feel like! -- TOMARI, Hisanobu </pre> TOMARI Hisanobu 2009-10-26T00:28:45 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/51 <pre> I'm afraid it. It looks the kernel somehow jumped into adress 0x0 where the entry point of kernel, and the address 0xe1280000 is "AST disable" port around line 260 in locore.s. It's really unlikely. On my NWS-1750, the similar operation works without problem: --- : scsibus0 at si0: 8 targets, 8 luns per target scsibus0: waiting 2 seconds for devices to settle... sd0 at scsibus0 target 1 lun 0: &lt;I-O DATA, HDVS-UM8.4G, 104S&gt; disk fixed sd0: 8063 MB, 16383 cyl, 16 head, 63 sec, 512 bytes/sect x 16514064 sectors sd0: async, 8-bit transfers : # dd if=/dev/zero of=/dev/rsd0c count=100 100+0 records in 100+0 records out 51200 bytes transferred in 0.790 secs (64810 bytes/sec) # halt : NEWS&gt; bo fh NetBSD/news68k Primary Boot NetBSD/news68k Secondary Boot, Revision 1.7 (from NetBSD 5.0.1) Booting fh(0,0,0) 1020024+1501304+193876=0x2990d8 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, </pre> Izumi Tsutsui 2009-10-23T13:14:36 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/50 <pre>Thanks for replies. I found nothing in /tmp, and I didn't enable logging. When the same process is tried with mfs mounted on /tmp and the logging on, the log says only `installation started' before sysinst quits. I think what David says is right, and that the problem isn't really about disk full. Even though I was almost sure that the 9GB disk I used earlier is good and working, I replaced it with another working 1.2GB Quantum drive to see if the situation changes. Not really. It's like this: # /dev/rsd0c: type: SCSI disk: FIREBALL_TM1280S label: fictitious flags: bytes/sector: 512 sectors/track: 183 tracks/cylinder: 2 sectors/cylinder: 366 cylinders: 6810 total sectors: 2503872 rpm: 4500 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0# microseconds track-to-track seek: 0# microseconds drivedata: 0 3 partitions: # size offset fstype [fsize bsize cpg/sgs] a: 2503872 0 4.2BSD 0 0 0 # (Cyl. 0 - 6841*) c: 2503872 0 unused</pre> TOMARI Hisanobu 2009-10-23T00:15:26 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/49 <pre>I wonder if the disk full is a symptom rather than the cause - because the bus error made sysinst try to dump core, which filled the disk? </pre> David Brownlee 2009-10-21T16:56:52 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/48 <pre> Yes, of course :-) Wow, I'm really amazed to see still a new user of this port, even with a working ~20 years old NEWS machine ;-) Hmm, on my NWS-1750, 5.0.1 sysinst works without problem. (at least it goes though newfs root file system) On 5.0.1 installation disk, ramdisk size is actually tight so something might flood ramdisk root easily. By default, df(1) should print as the following right after boot: --- # df Filesystem 512-blocks Used Avail %Cap Mounted on /dev/md0a 2767 2729 38 98% / # --- Is there any file in /tmp (or other directories) after crash? Did you enable logging in the utility menu, for example? If so, "mount -t mfs swap /tmp" command before starting sysinst might work around. I'm not sure which point the bus error occured on, but another possibility is that the NetBSD kernel was confused by existing old disklabel on your sd0 disk. What "disklabel sd0" on the ramdisk prompt shows? --- Izumi Tsutsui </pre> Izumi Tsutsui 2009-10-21T16:11:33 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/47 <pre>Hello, is anybody here? ;-) I have a NWS-1460 with 16 megabytes of memory, which I'd like to install NetBSD on. I downloaded 5.0.1 boot.fs from one of the mirror, booted it, ran the installer, and after the message &gt; I found only one disk, sd0. &gt; Therefore I assume you want to install NetBSD on it. the installer terminates with following output: &gt; uid 0, pid 7, command sysinst, on /: file system full &gt; &gt; pid 7 (sysinst): user write of 28672&lt; at &gt;0x12c000 at 1112 failed: 28 &gt; /: write failed, file system is full &gt; [1] Illegal instruction /sysinst &gt; # I tried copying all the contents of rootfs to one of my NFS servers and chrooted into it from the INSTALL kernel from the floppy, then run /sysinst manually, but no luck: the installer terminates with bus error. Does anyone here have the same problem? Is there a solution? Full dmesg follows: Testing memories................ done. 16M bytes available, 16K byte(s) reserved. SONY NET WORK STATION MC68030 Monitor Release 1.5A Model NWS-1460, Machine </pre> TOMARI Hisanobu 2009-10-20T23:44:49 http://permalink.gmane.org/gmane.os.netbsd.ports.news68k/46 <pre>This list has phone, fax, email, contact name and much more 2,000,000 total records all with emails Cost just slashed - $297 - Only until the end of this week reply to: Amelia&lt; at &gt;BestAccurateReliable.com to terminate please send a blank message to exit&lt; at &gt;BestAccurateReliable.com </pre> Phillip R Bowen 2009-08-11T23:52:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.news68k