Re: Tru64 AdvFS porting to NetBSD - 1. status 2014-09-17
Am 17.09.14 11:25, schrieb Kamil Rytarowski: This is the first status of significant efforts of porting AdvFS [1] [2] to NetBSD. [...] Help and motivation support is appreciated. AdvFS for NetBSD! A dream comes true. :-) I liked AdvFS very much when I used Tru64 back in its days. -- tschüß, Jochen
Re: pulse-per-second API status
On Fri, 1 Nov 2013 14:48:51 -0400
Terry Moore t...@mcci.com wrote:
But using a serial port handshaking line over an emulated com port over USB
is not likely to be terribly wonderful. Long-term accuracy (tick count)
probably no problem, but jitter it will depend on how that's filtered.
That's the key. Once I did a DCF77 decoder in an Atmel AVR. (DCF77 is a
radio station that sends a PPS signal plus BCD encoded absolute time.)
The cheap radio reciver had a considerably jitter. So I simply summed up
the PPS count from the receiver and the tics from the local quarz clock
over the period of hours. Some ms of jitter are negligible compared to
several hours. Using this I was able to calibrate the local quarz
oscilator down into the ppm range. I.e. I was able to notice the
temperature drift of the local quarz oscilator.
If you know what to do, even a jitterish PPS signal can be of good use.
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
Re: USB console or sshd support on installation media?
On Thu, 18 Oct 2012 16:58:45 +0200
Martin Husemann mar...@duskware.de wrote:
That won't work for most laptops, USB ports are not symetric, you
need an OTG variant (which lots of embeded designs have though).
I think he meant somthing different: The kernel collects messages in a
buffer. When the USB subsystem is up and running as a host, it attaches
a ucom(4) that was pluged in prior to boot. Then the kernel dumpes the
collected messages to that ucom(4) and uses it as /dev/console.
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
Re: Sun keyboard on i386?
On Wed, 13 Jul 2011 16:16:30 -0400 (EDT)
Mouse mo...@rodents-montreal.org wrote:
Completely other solution, you may have a look at this:
http://www.kbdbabel.org/
[...]
Protocol conversion is significantly more elaborate.
That is the reason why a kbdbabel needs a microcontroller...
Strange that you call a Sun type 3 keyboard good. They are one of
the most hideously keyboards I've come across.
Keyboard taste is intensely personal.
This is exactely what I intended to express. :-)
Contrast with the PS/2 interface which is a horrible error-prone botch
designed, apparently, to save one wire on the cable - at least, I can't
think of any other reason both directions' data would be wire-ORed
together.
Well. Wired OR or AND isn't that umcommon in such applications. The
1-Wire Bus uses it, I²C, ...
Close to a DEC LK201.
Good heavens, no. The LK201 is mushier,
[...]
I see, we entirely agree on our opinion of the LK201. :-)
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
Re: 5.99.30 sparc panic during startup
On Sun, 20 Jun 2010 17:13:42 +1000 matthew green m...@eterna.com.au wrote: the ss10/ss20 are the ones to test. Attached are dmesg.boot from my SS20. One with serial console, the other with local framebuffer console / wscons. I net-booted the machine to single user mode only. -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/ Loaded initial symtab at 0xf0481ce8, strtab at 0xf04c0b84, # entries 15143 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 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.31 (GENERIC.MPLD) #0: Sun Jun 20 13:34:25 PDT 2010 m...@space-bird.eterna23.net:/var/obj/sparc/usr/src/sys/arch/sparc/compile/GENERIC.MPLD total memory = 447 MB avail memory = 433 MB timecounter: Timecounters tick every 10.000 msec bootpath: /io...@f,e000/s...@f,e0001000/le...@f,400010/l...@f,c0 mainbus0 (root): SUNW,SPARCstation-20: hostid 7276aaba cpu0 at mainbus0: mid 8: TMS390Z50 v0 or TMS390Z55 @ 60 MHz, on-chip FPU cpu0: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled cpu1 at mainbus0: mid 10: TMS390Z50 v0 or TMS390Z55 @ 60 MHz, on-chip FPU cpu1: physical 20K instruction (64 b/l), 16K data (32 b/l), 1024K external (32 b/l): cache enabled obio0 at mainbus0 clock0 at obio0 slot 0 offset 0x20: mk48t08 timer0 at obio0 slot 0 offset 0x30: delay constant 28, frequency = 200 Hz timecounter: Timecounter timer-counter frequency 200 Hz quality 100 zs0 at obio0 slot 0 offset 0x10 level 12 softpri 6 zstty0 at zs0 channel 0 (console i/o) zstty1 at zs0 channel 1 zs1 at obio0 slot 0 offset 0x0 level 12 softpri 6 zstty4 at zs1 channel 0 kbd0 at zstty4 zstty5 at zs1 channel 1 ms0 at zstty5 wsmouse0 at ms0 mux 0 fdc0 at obio0 slot 0 offset 0x70 level 11 softpri 4: chip 82077 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec auxreg0 at obio0 slot 0 offset 0x80 power0 at obio0 slot 0 offset 0xa01000 level 2 cgfourteen0 at obio0 slot 2 offset 0x0 level 8: 8 MB VRAM: 1152x900 wsdisplay1 at cgfourteen0 kbdmux 1 wsmux1: connecting to wsdisplay1 cgfourteen0: attached to /dev/fb0 iommu0 at mainbus0 ioaddr 0xe000: version 0x3/0x1, page-size 4096, range 64MB sbus0 at iommu0: clock = 25 MHz dma0 at sbus0 slot 15 offset 0x40: DMA rev 2 esp0 at dma0 slot 15 offset 0x80 level 4: ESP200, 40MHz, SCSI ID 7 scsibus0 at esp0: 8 targets, 8 luns per target ledma0 at sbus0 slot 15 offset 0x400010: DMA rev 2 le0 at ledma0 slot 15 offset 0xc0 level 6: address 08:00:20:76:aa:ba le0: 8 receive buffers, 2 transmit buffers bpp0 at sbus0 slot 15 offset 0x480 level 2 (ipl 3): DMA rev 2 bpp: hcr 0 ocr 200a tcr 8 or 0 dbri0 at sbus0 slot 14 offset 0x1 level 9: rev e hme0 at sbus0 slot 2 offset 0x8c0 level 4 (ipl 7): Sun Happy Meal Ethernet (SUNW,hme) hme0: Ethernet address 08:00:20:76:aa:ba nsphy0 at hme0 phy 1: DP83840 10/100 media interface, rev. 0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto esp1 at sbus0 slot 2 offset 0x880 level 3 (ipl 5): FAS366/HME, 40MHz, SCSI ID 7 scsibus1 at esp1: 16 targets, 8 luns per target eccmemctl0 at mainbus0 ioaddr 0x0: version 0x0/0x2 timecounter: Timecounter clockinterrupt frequency 100 Hz quality 0 cpu0: booting secondary processors: cpu1 scsibus0: waiting 2 seconds for devices to settle... scsibus1: waiting 2 seconds for devices to settle... wskbd0 at kbd0 mux 1 sd0 at scsibus0 target 3 lun 0: SEAGATE, ST34371W, 0338 disk fixed sd0: 4148 MB, 5168 cyl, 10 head, 164 sec, 512 bytes/sect x 8496960 sectors sd0: sync (100.00ns offset 15), 8-bit (10.000MB/s) transfers, tagged queueing kbd0: reset failed wskbd0: connecting to wsdisplay1 dbri0: speakerbox detected dbri0: cs4215 rev E found at offset 8 audio0 at dbri0: full duplex, playback, capture, mmap cd0 at scsibus0 target 6 lun 0: TOSHIBA, XM-4101TASUNSLCD, 1755 cdrom removable cd0: async, 8-bit transfers Kernelized RAIDframe activated root on le0 mountroot: trying nfs... nfs_boot: trying DHCP/BOOTP nfs_boot: wrong IP addr 0.0.0.0 (bad reply from 192.168.2.1) nfs_boot: DHCP next-server: 192.168.1.1 cpu0: bogus interrupt ipl 0xa pc=0xf027e9b4 npc=0xf027e9b8 psr=0x404000c6S,PS nfs_boot: my_addr=192.168.1.9 nfs_boot: my_mask=255.255.255.0 nfs_boot: gateway=192.168.1.254 root on 192.168.1.1:/nfsroot/NetBSD/sparc root time: 0x4c1fb2e8 root file system type: nfs init: copying out path `/sbin/init' 11 Loaded initial symtab at 0xf0481ce8, strtab at 0xf04c0b84, # entries 15143 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 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.31 (GENERIC.MPLD) #0: Sun Jun 20 13:34:25 PDT 2010
Re: 5.99.30 sparc panic during startup
On Sun, 20 Jun 2010 12:38:18 +1000 matthew green m...@eterna.com.au wrote: it would still be nice to have a good multi-zs user test to make sure. Would a Ultra2 or a SPARCstation 10 / 20 fit that bill? I could throw a test kernel at that hardware easily. -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Re: Forcing a serial console for the kernel
On Sat, 27 Mar 2010 21:25:25 -0700 STEPHEN JONES, W0TTY s...@cirr.com wrote: I've also looked using the new boot.cfg file and also installboot, but there does not see to be a well documented method for setting up serial console support. $ l /usr/mdec/mbr_com0_9600 -r--r--r-- 1 root wheel 512 Jul 30 2009 /usr/mdec/mbr_com0_9600 $ man i386/mbr or $ man bootselect -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Re: Writing to multiple descriptors with one system call
On Wed, 17 Mar 2010 16:53:11 + Sad Clouds cryintotheblue...@googlemail.com wrote: This is because it is common for web server to send many small text files to many concurrent clients. You could fit several of those files in a socket's TCP send buffer. Only if you have pipelined requests. In case of pipelining you can send multiple files in a row and writev(2) will do for you. You wane use writev(2) anyway, as you have to send HTTP headers in front of each file. Without pipelining you have a request - response - request - response - etc. sequence. A new request will only be sent after the client received the complete response. And completely forget about sending those pipelined files to multiple clients simultaneously in a single system call. This will only work if all clients request the same files in the same sequence at about the same time. To filter out matching client connections will cost more CPU power then handling each client in a separate writev(2). Also don't forget that browsers usually use multiple connections to the same server to fetch multiple parts of a page. E.g. if you have a page with four JPEGs the browser will not issue a single pipelined request for those four JPEGs, but open for concurrent connections to the server and request each JPEG on a separate TCP stream. On a busy server you cache the most frequently accessed files in memory, so the data is ready to be sent down the TCP sockets. Todays web pages are 99.9% dynamic. Even if they seem to be static at first sight. Think of CMS etc.. Delivering a file like a bitmap picture or PDF from disk is an exeption. In that case you wane do mmap(2) and write(2) / writev(2). On NetBSD this is equivalent to what Linux calls sendfile(2). The VM subsytem will take care of caching etc. for you and it will do better then you as it knows better then you how much physical memory is free at the moment etc.. E.g. thttpd(8) does this: Files get mmap(2)ed. Headers get written to a malloc(3)ed buffer. Then the headers and the file are sent with a single writev(2) using non-blocking IO. -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
