Re: What happened when 5.5 met my old reliable box
On 12/16/14 06:09, Rod Whitworth wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) at the boot prompt: boot stty com0 9600 boot set tty com0 Then use cu(1) to do the rest hth Fred
Re: What happened when 5.5 met my old reliable box
Thanks much. A different approach to some others. I'll file them all because I suspect that one method will suit one problem better than others. On Tue, 16 Dec 2014 07:48:05 +0100, Adriaan wrote: From the OpenBSD FAQ: At the boot loader prompt, enter boot *set tty com0* This will tell OpenBSD to use the first serial port (often called COM1 or COMA in PC documentation) as a serial console. The default baud rate is 9600. You set the speed higher by first typing stty com0 19200 This is documented in the boot.conf man page. On your workstation you can use tip(1) as terminal emulator. You can easily record the session to file by creating a .tiprc file: beautify record='LOGS/serial-log.txt' script verbose Create the LOGS directory, add yourself to the dialer group. With something liketip -v -19200 tty00 you can then start tip. If you have an USB-Serial converter you need to use ttyU0 as mentioned in ucom(4) On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth glis...@witworx.com wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: What happened when 5.5 met my old reliable box
On Tue, 16 Dec 2014 21:22:35 +1100, Rod Whitworth wrote: Thanks much. A different approach to some others. I'll file them all because I suspect that one method will suit one problem better than others. On Tue, 16 Dec 2014 07:48:05 +0100, Adriaan wrote: From the OpenBSD FAQ: At the boot loader prompt, enter boot *set tty com0* This will tell OpenBSD to use the first serial port (often called COM1 or COMA in PC documentation) as a serial console. The default baud rate is 9600. You set the speed higher by first typing stty com0 19200 This is documented in the boot.conf man page. On your workstation you can use tip(1) as terminal emulator. You can easily record the session to file by creating a .tiprc file: beautify record='LOGS/serial-log.txt' script verbose Create the LOGS directory, add yourself to the dialer group. With something liketip -v -19200 tty00 you can then start tip. If you have an USB-Serial converter you need to use ttyU0 as mentioned in ucom(4) On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth glis...@witworx.com wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
What happened when 5.5 met my old reliable box
[dmesg follows] I have several light weight i386 boxes made by Aopen around y2k at the time of the shonky motherboard caps. A customer gave me all the ones that had not failed until well out of warranty and I bought a bag of superior caps and swapped out all the bad ones and they all have been running for at least 8 years. One box is due to be brought up with a new install. It crashed on 5.6 at the point where it was due to get the sets from the CD. I wish I could catch what it says but it closes the message too fast for my eyes. I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. dmesg: OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(TM) CPU 1300MHz (GenuineIntel 686-class) 1.31 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX, FXSR,SSE,PERF real mem = 527953920 (503MB) avail mem = 507879424 (484MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/27/02, BIOS32 rev. 0 @ 0xfb4b0, SMBIOS rev. 2.3 @ 0xf0800 (35 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 02/27/2002 bios0: VIA Technologies, Inc. VT8601 apm0 at bios0: Power Management spec V1.2 (slowidle) acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0xde94 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfde10/128 (6 entries) pcibios0: PCI Exclusive IRQs: 5 10 11 pcibios0: PCI Interrupt Router at 000:07:0 (VIA VT82C596A ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xc000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 VIA VT8601 PCI rev 0x05 viaagp0 at pchb0: v2 agp0 at viaagp0: aperture at 0xe000, size 0x1000 ppb0 at pci0 dev 1 function 0 VIA VT82C601 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 Trident CyberBlade i1 rev 0x6a wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 7 function 0 VIA VT82C686 ISA rev 0x40 pciide0 at pci0 dev 7 function 1 VIA VT82C571 IDE rev 0x06: ATA100, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: Maxtor 6Y080L0 wd0: 16-sector PIO, LBA, 78167MB, 160086528 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI-CD, ROM-DRIVE-52MAX, 52AW ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 uhci0 at pci0 dev 7 function 2 VIA VT83C572 USB rev 0x1a: irq 5 uhci1 at pci0 dev 7 function 3 VIA VT83C572 USB rev 0x1a: irq 5 viapm0 at pci0 dev 7 function 4 VIA VT82C686 SMBus rev 0x40: SMI iic0 at viapm0 iic0: addr 0x2d 00=01 01=40 02=97 03=ff 04=ff 07=50 08=ad 09=3d 0b=55 13=d7 14= 45 16=78 17=8a 1d=40 1f=7f 20=a6 21=96 22=7d 23=d0 24=d2 25=cd 26=cc 27=80 28 =80 29=a1 2b=ff 2d=d6 2e=c1 2f=d4 30=bf 31=cd 32=ba 33=cb 34=b8 37=08 38=02 39 =ff 3d=ff 3f=a2 40=01 43=ff 44=ff 47=50 48=ad 49=3d 4b=55 53=7f 54=12 56=f8 57=81 5d=40 5f=7f 60=a6 61=96 62=7d 63=d0 64=d2 65=cd 66=cc 67=80 68=80 69=a5 6b=ff 6d=d6 6e=c1 6f=d4 70=bf 71=cd 72=ba 73=cb 74=b8 77=08 78=02 79=ff 7d=ff 7f=a2 80 =01 83=ff 84=ff 87=50 88=ad 89=3d 8b=55 93=7f 94=1b 96=15 97=01 9d=40 9f=7f a0 =a6 a1=96 a2=7d a3=d0 a4=d2 a5=cd a6=cc a7=80 a8=80 a9=a5 ab=ff ad=d6 ae=c1 af=d4 b0=bf b1=cd b2=ba b3=cb b4=b8 b7=08 b8=02 b9=ff bd=ff bf=a2 c0=01 c3=ff c4 =ff c7=50 c8=ad c9=3d cb=55 d3=7f d4=15 d6=06 d7=01 dd=40 df=7f e0=a6 e1=96 e2= 7d e3=d0 e4=d2 e5=cd e6=cc e7=80 e8=80 e9=a5 eb=ff ed=d6 ee=c1 ef=d4 f0=bf f1 =cd f2=ba f3=cb f4=b8 f7=08 f8=02 f9=ff fd=ff ff=a2 words 00=01ff 01=00ff 02=00ff 03 = 04= 05=00ff 06=00ff 07=50ff spdmem0 at iic0 addr 0x50: 256MB SDRAM non-parity PC133CL2 spdmem1 at iic0 addr 0x51: 256MB SDRAM non-parity PC133CL2 viapm0: 24-bit timer at 3579545Hz rl0 at pci0 dev 17 function 0 Realtek 8139 rev 0x10: irq 11, address 00:01:80:0f:2b:94 rlphy0 at rl0 phy 0: RTL internal PHY isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 VIA UHCI root hub rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1 mtrr: Pentium Pro MTRR support vscsi0 at root
Re: What happened when 5.5 met my old reliable box
On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain.
Re: What happened when 5.5 met my old reliable box
On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: What happened when 5.5 met my old reliable box
On Tue, Dec 16, 2014 at 17:09, Rod Whitworth wrote: 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) set tty com0 or something at the boot prompt. man boot.
Re: What happened when 5.5 met my old reliable box
From the OpenBSD FAQ: At the boot loader prompt, enter boot *set tty com0* This will tell OpenBSD to use the first serial port (often called COM1 or COMA in PC documentation) as a serial console. The default baud rate is 9600. You set the speed higher by first typing stty com0 19200 This is documented in the boot.conf man page. On your workstation you can use tip(1) as terminal emulator. You can easily record the session to file by creating a .tiprc file: beautify record='LOGS/serial-log.txt' script verbose Create the LOGS directory, add yourself to the dialer group. With something liketip -v -19200 tty00 you can then start tip. If you have an USB-Serial converter you need to use ttyU0 as mentioned in ucom(4) On Tue, Dec 16, 2014 at 7:09 AM, Rod Whitworth glis...@witworx.com wrote: On Tue, 16 Dec 2014 00:16:52 -0500, Ted Unangst wrote: On Tue, Dec 16, 2014 at 16:05, Rod Whitworth wrote: I tried 5.5 - crashes there too. 5.4 and earlier work well. Clues? I love these low power skinny boxes in my rack and I'm betting that the problem exists in all the ones I have, but I cannot take the others down until I have one to swap in. 1. connect a serial cable or something to record output. I like the idea of getting chars ready to print but how do I get the data going to the rs232 port that is on all of these boxes (luckily!) ? I missed the class that taught that trick. 8-) 2. get a video camera. smartphone should be good enough. 3. brute force. build kernels from source from 5.4 onwards. the good news is this will only take about seven kernels to find the offending commit; the bad news is building old snapshot ramdisk kernels is quite a pain. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
