subject:"hardware"

On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
> On 2016/04/28 08:56, stan wrote:
> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> > > Stan, can you send the information that is output when you run
> > > sendbug -P as root? Just putting the whole thing inline in a
> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
> > > output as well. Ideally we want a way to identify the watchdog
> > > itself rather than the general machine type etc. which is why
> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
> > > standard for this).
> > 
> > 
> > Sorry got distracted and frgot to cc the list.
> 
> OK, pity, there doesn't seem to be anything to properly identify
> the watchdog in acpi tables. Just the vendor-specific thing which
> needs reading to figure things out further. If they had followed
> the usual spec then the driver would have been *very* generally
> useful.
> 
> In that case maybe the approach would be to do something similar
> to acpithinkpad, but matching SECD instead of MHKV, and then
> looking for the SEL0002 HID. But I only know a bit about how
> to find my way round the decompiled files, so ignore me if
> a real ACPI hacker steps in with a better idea ;)
> 
> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
> > hw.product=SEL-3355
> 
> An alternative might be to match on vendor/product, see the last
> commit to sys/dev/ic/re.c for how to do this, but then you're
> having to look at fixed addresses which they seem to be providing
> via acpi.
> 

As I look at what the vendor did, I discover they were working in the
arch/i386 codebase. 2 questions. First should this not be in amd64, as this
is a 64 bit machine, and if so does that change any of the discussions as to
how to detect the hardware?


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: FW: Re: watchdog suport for new hardware

2016-04-28 Thread Mike Larkin

On Thu, Apr 28, 2016 at 03:22:15PM +, Stuart Henderson wrote:
> On 2016-04-28, stan  wrote:
> > On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
> >> On 2016/04/28 08:56, stan wrote:
> >> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> >> > > Stan, can you send the information that is output when you run
> >> > > sendbug -P as root? Just putting the whole thing inline in a
> >> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
> >> > > output as well. Ideally we want a way to identify the watchdog
> >> > > itself rather than the general machine type etc. which is why
> >> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
> >> > > standard for this).
> >> > 
> >> > 
> >> > Sorry got distracted and frgot to cc the list.
> >> 
> >> OK, pity, there doesn't seem to be anything to properly identify
> >> the watchdog in acpi tables. Just the vendor-specific thing which
> >> needs reading to figure things out further. If they had followed
> >> the usual spec then the driver would have been *very* generally
> >> useful.
> >> 
> >> In that case maybe the approach would be to do something similar
> >> to acpithinkpad, but matching SECD instead of MHKV, and then
> >> looking for the SEL0002 HID. But I only know a bit about how
> >> to find my way round the decompiled files, so ignore me if
> >> a real ACPI hacker steps in with a better idea ;)
> >> 
> >> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
> >> > hw.product=SEL-3355
> >> 
> >> An alternative might be to match on vendor/product, see the last
> >> commit to sys/dev/ic/re.c for how to do this, but then you're
> >> having to look at fixed addresses which they seem to be providing
> >> via acpi.
> >> 
> >
> > Let me apologize right here for my lack of knowledge as to low level
> > hardware coding.
> >
> > So, given that, please help me to understand why reading the DSDT ACPI
> > table and finding the SEL0002 is not the correct solution here?  BTW, they
> > also identify an SEL0001 device, but I have not asked them what that is,
> > and )so far) I do not need to know. For what it is worth this hardware
> > vendor has been very helpful, and the corporate philosophy is to do things
> > "the right way". For instance, they released code to support this device for
> > Linux. When I talked to them, i brought up liscneing concerns with the
> > BSD's. The reply was, already been there, thought about that. It is dual
> > GPL, and BSD liscneced. Really a pleasant sunrise, as this is not in their
> > mainstream area of expertise. i was really pleased that the project team
> > had researched the OSS issues that well.
> 
> I was just chatting to mlarkin about this, he hasn't looked at the
> code but gave a few suggestions. 
> 
> I was wrong about the need to look for the SECD container - he gave an
> example of a better driver to crib from, sdhc_acpi, which is pretty
> simple in itself and shows the parts needed to find the device in the
> DSDT. Basically it just involves passing an array containing "SEL0002"
> to acpi_matchhids and it does the work.
> 

It does the work for the find and attach. After that, you'll need to plumb
the AML to find the device location and IRQ/etc. But sdhc_acpi is a simple
driver that has most of the system interface goo you need to get started.

-ml

Re: FW: Re: watchdog suport for new hardware

2016-04-28 Thread Stuart Henderson

On 2016-04-28, stan  wrote:
> On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
>> On 2016/04/28 08:56, stan wrote:
>> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
>> > > Stan, can you send the information that is output when you run
>> > > sendbug -P as root? Just putting the whole thing inline in a
>> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
>> > > output as well. Ideally we want a way to identify the watchdog
>> > > itself rather than the general machine type etc. which is why
>> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
>> > > standard for this).
>> > 
>> > 
>> > Sorry got distracted and frgot to cc the list.
>> 
>> OK, pity, there doesn't seem to be anything to properly identify
>> the watchdog in acpi tables. Just the vendor-specific thing which
>> needs reading to figure things out further. If they had followed
>> the usual spec then the driver would have been *very* generally
>> useful.
>> 
>> In that case maybe the approach would be to do something similar
>> to acpithinkpad, but matching SECD instead of MHKV, and then
>> looking for the SEL0002 HID. But I only know a bit about how
>> to find my way round the decompiled files, so ignore me if
>> a real ACPI hacker steps in with a better idea ;)
>> 
>> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
>> > hw.product=SEL-3355
>> 
>> An alternative might be to match on vendor/product, see the last
>> commit to sys/dev/ic/re.c for how to do this, but then you're
>> having to look at fixed addresses which they seem to be providing
>> via acpi.
>> 
>
> Let me apologize right here for my lack of knowledge as to low level
> hardware coding.
>
> So, given that, please help me to understand why reading the DSDT ACPI
> table and finding the SEL0002 is not the correct solution here?  BTW, they
> also identify an SEL0001 device, but I have not asked them what that is,
> and )so far) I do not need to know. For what it is worth this hardware
> vendor has been very helpful, and the corporate philosophy is to do things
> "the right way". For instance, they released code to support this device for
> Linux. When I talked to them, i brought up liscneing concerns with the
> BSD's. The reply was, already been there, thought about that. It is dual
> GPL, and BSD liscneced. Really a pleasant sunrise, as this is not in their
> mainstream area of expertise. i was really pleased that the project team
> had researched the OSS issues that well.

I was just chatting to mlarkin about this, he hasn't looked at the
code but gave a few suggestions. 

I was wrong about the need to look for the SECD container - he gave an
example of a better driver to crib from, sdhc_acpi, which is pretty
simple in itself and shows the parts needed to find the device in the
DSDT. Basically it just involves passing an array containing "SEL0002"
to acpi_matchhids and it does the work.

Re: FW: Re: watchdog suport for new hardware

On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
> On 2016/04/28 08:56, stan wrote:
> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> > > Stan, can you send the information that is output when you run
> > > sendbug -P as root? Just putting the whole thing inline in a
> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
> > > output as well. Ideally we want a way to identify the watchdog
> > > itself rather than the general machine type etc. which is why
> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
> > > standard for this).
> > 
> > 
> > Sorry got distracted and frgot to cc the list.
> 
> OK, pity, there doesn't seem to be anything to properly identify
> the watchdog in acpi tables. Just the vendor-specific thing which
> needs reading to figure things out further. If they had followed
> the usual spec then the driver would have been *very* generally
> useful.
> 
> In that case maybe the approach would be to do something similar
> to acpithinkpad, but matching SECD instead of MHKV, and then
> looking for the SEL0002 HID. But I only know a bit about how
> to find my way round the decompiled files, so ignore me if
> a real ACPI hacker steps in with a better idea ;)
> 
> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
> > hw.product=SEL-3355
> 
> An alternative might be to match on vendor/product, see the last
> commit to sys/dev/ic/re.c for how to do this, but then you're
> having to look at fixed addresses which they seem to be providing
> via acpi.
> 

Let me apologize right here for my lack of knowledge as to low level
hardware coding.

So, given that, please help me to understand why reading the DSDT ACPI
table and finding the SEL0002 is not the correct solution here?  BTW, they
also identify an SEL0001 device, but I have not asked them what that is,
and )so far) I do not need to know. For what it is worth this hardware
vendor has been very helpful, and the corporate philosophy is to do things
"the right way". For instance, they released code to support this device for
Linux. When I talked to them, i brought up liscneing concerns with the
BSD's. The reply was, already been there, thought about that. It is dual
GPL, and BSD liscneced. Really a pleasant sunrise, as this is not in their
mainstream area of expertise. i was really pleased that the project team
had researched the OSS issues that well.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: FW: Re: watchdog suport for new hardware

On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> Stan, can you send the information that is output when you run
> sendbug -P as root? Just putting the whole thing inline in a
> reply-to-all to this mail would be fine. Please add "sysctl hw"
> output as well. Ideally we want a way to identify the watchdog
> itself rather than the general machine type etc. which is why
> I'm hoping they follow Microsoft's spec (which is the de-facto 
> standard for this).

Sorry got distracted and frgot to cc the list.

Script started on Thu Apr 28 08:45:28 2016
# sendbug -P
SENDBUG: -*- sendbug -*-
SENDBUG: Lines starting with `SENDBUG' will be removed automatically.
SENDBUG:
SENDBUG: Choose from the following categories:
SENDBUG:
SENDBUG: system user library documentation kernel alpha amd64 arm hppa i386 
m88k mips64 powerpc sh sparc sparc64 vax
SENDBUG:
SENDBUG:
To: b...@openbsd.org
Subject: 
From: root
Cc: root
Reply-To: root

>Synopsis:  
>Category:  
>Environment:
System  : OpenBSD 5.9
Details : OpenBSD 5.9 (GENERIC.MP) #0: Wed Apr 27 18:40:39 EDT 2016

r...@test.power.charleston.kapstonepaper.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:

>How-To-Repeat:

>Fix:

SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached.
SENDBUG: Feel free to delete or use the -D flag if they contain sensitive 
information.

dmesg:
OpenBSD 5.9 (GENERIC.MP) #0: Wed Apr 27 18:40:39 EDT 2016

r...@test.power.charleston.kapstonepaper.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16991633408 (16204MB)
avail mem = 16472473600 (15709MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0840 (59 entries)
bios0: vendor Schweitzer Engineering Laboratories, Inc. version "B_1.5.49152.2 
X64" date 12/18/2015
bios0: Schweitzer Engineering Laboratories, Inc. SEL-3355
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP SSDT HPET APIC MCFG FPDT ASF! SSDT SSDT SSDT SSDT UEFI 
POAT SSDT BERT HEST EINJ ERST UEFI UEFI DBG2
acpi0: wakeup devices P0P1(S0) GLAN(S0) EHC1(S0) EHC2(S0) HDEF(S0) PXSX(S0) 
PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) RP08(S0) PEG1(S0) PEG3(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3612QE CPU @ 2.10GHz, 2095.58 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-3612QE CPU @ 2.10GHz, 2095.24 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-3612QE CPU @ 2.10GHz, 2095.24 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-3612QE CPU @ 2.10GHz, 2095.24 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
cpu4 at mainbus0: apid 4 (application processor)
cpu4: Intel(R) Core(TM) i7-3612QE CPU @ 2.10GHz, 2095.24 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu4

Re: FW: Re: watchdog suport for new hardware

2016-04-28 Thread Stuart Henderson

On 2016/04/28 08:56, stan wrote:
> On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> > Stan, can you send the information that is output when you run
> > sendbug -P as root? Just putting the whole thing inline in a
> > reply-to-all to this mail would be fine. Please add "sysctl hw"
> > output as well. Ideally we want a way to identify the watchdog
> > itself rather than the general machine type etc. which is why
> > I'm hoping they follow Microsoft's spec (which is the de-facto 
> > standard for this).
> 
> 
> Sorry got distracted and frgot to cc the list.

OK, pity, there doesn't seem to be anything to properly identify
the watchdog in acpi tables. Just the vendor-specific thing which
needs reading to figure things out further. If they had followed
the usual spec then the driver would have been *very* generally
useful.

In that case maybe the approach would be to do something similar
to acpithinkpad, but matching SECD instead of MHKV, and then
looking for the SEL0002 HID. But I only know a bit about how
to find my way round the decompiled files, so ignore me if
a real ACPI hacker steps in with a better idea ;)

> hw.vendor=Schweitzer Engineering Laboratories, Inc.
> hw.product=SEL-3355

An alternative might be to match on vendor/product, see the last
commit to sys/dev/ic/re.c for how to do this, but then you're
having to look at fixed addresses which they seem to be providing
via acpi.

Re: FW: Re: watchdog suport for new hardware

On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> Stan, can you send the information that is output when you run
> sendbug -P as root? Just putting the whole thing inline in a
> reply-to-all to this mail would be fine. Please add "sysctl hw"
> output as well. Ideally we want a way to identify the watchdog
> itself rather than the general machine type etc. which is why
> I'm hoping they follow Microsoft's spec (which is the de-facto 
> standard for this).

Absolutely. I am in the process of bailing a 5.9 machine to install this
on, so hopefully I can send this today.

Thanks for the interest in our issues.


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: FW: Re: watchdog suport for new hardware

2016-04-28 Thread Stuart Henderson

Stan, can you send the information that is output when you run
sendbug -P as root? Just putting the whole thing inline in a
reply-to-all to this mail would be fine. Please add "sysctl hw"
output as well. Ideally we want a way to identify the watchdog
itself rather than the general machine type etc. which is why
I'm hoping they follow Microsoft's spec (which is the de-facto 
standard for this).

Re: FW: watchdog suport for new hardware

2016-04-27 Thread Chase Davis

Theo / Stuart,


I am e-mailing regarding the source code that Stan Brown sent for a new
watchdog driver. We modeled our code off of the wbsio driver that does a
write to the Super I/O chip first in order to read the device ID and
compare it with a known list of device IDs. The device that we wrote the
driver for does have an entry in the DSDT table of SEL0002, but when we
wrote the driver as an acpi device, the probe function never found an HID
of SEL0002.


I understand your concern about âsteppingâ on another device. This device
is found at IO port 0x192 which could potentially be re-used by some other
device I would assume. Is there a way to read the DSDT tables from within
an ISA probe function? I couldnât wrap my head around that process as the
ISA bus on this particular machine is hosted by a PCI-ISA bridge. Any help
you could provide would be appreciated.

Thanks,
Chase Davis


>
> From: stan 
> To: Stuart Henderson 
> Subject: Re: FW: Re: watchdog suport for new hardware
> Date: Tue, 26 Apr 2016 11:57:48 -0400
> User-Agent: Mutt/1.5.4i
> X-Operating-System: Debian GNU/Linux
> X-Kernel-Version: 2.4.23
> X-Uptime: 11:51:45 up 91 days, 10:53,  1 user,  load average: 0.00, 0.00,
> 0.00
> X-Editor: gVim
>
> On Tue, Apr 26, 2016 at 03:44:46PM +, Stuart Henderson wrote:
>
> On 2016-04-26, Theo de Raadt  wrote:
>
> int
>
> selwd_probe(struct device *parent, void *match, void *aux)
>
> {
>
>struct isa_attach_args *ia = aux;
>
>bus_space_tag_t iot;
>
>bus_space_handle_t ioh;
>
>
>
>/* Match by device ID */
>
>iot = ia->ia_iot;
>
>if (bus_space_map(iot, ia->ipa_io[0].base, SELWD_IOSIZE, 0, &ioh))
>
>return 0;
>
>
>
> ...
>
>
>
>/* read model number */
>
>char *model = malloc(sizeof(char)*16, M_DEVBUF, M_WAITOK | M_ZERO);
>
>selwd_read_modelno(iot, ioh, model);
>
>
>
> This is worrying.  It assumes that all systems have this hardware.
>
>
>
> And it starts by doing a "write".
>
>
>
> Is there no WDRT or WDAT table in ACPI on this hardware? Most "modern"
>
> (2006-on) watchdogs on PCs with ACPI support have the WDRT table described
>
> in https://msdn.microsoft.com/en-us/windows/hardware/gg463320.aspx
>
>
>
> Check for /tmp/acpi.WD[AR]T.* files after running acpidump -o /tmp/acpi ..
>
>
>
>
> Acording to the vendor documentation, yes we should be able to find SEL0002
> in the DSDT table. I am afrid I do not understand how to chek this. Could
> you point me to some documentation as to how to do this?
>
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> - End forwarded message -
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>
> --
>
> Confidentiality Notice:
>
> The information contained in this message is private and confidential.
> This information is intended only for the individual or entity named above.
> If the reader of this message is not the intended recipient, you are hereby
> notified that any use, review, dissemination, distribution, copying or
> action taken based on this message or its attachments, if any, is strictly
> prohibited. If you are not the intended recipient, please contact the
> sender by reply email and delete or destroy all copies of this message and
> any attachments. Thank you.
>



--
Chase Davis

Re: FW: Re: watchdog suport for new hardware

2016-04-26 Thread Stuart Henderson

On 2016-04-26, Theo de Raadt  wrote:
>> int
>> selwd_probe(struct device *parent, void *match, void *aux)
>> {
>>  struct isa_attach_args *ia = aux;
>>  bus_space_tag_t iot;
>>  bus_space_handle_t ioh;
>> 
>>  /* Match by device ID */
>>  iot = ia->ia_iot;
>>  if (bus_space_map(iot, ia->ipa_io[0].base, SELWD_IOSIZE, 0, &ioh))
>>  return 0;
>
> ...
>
>>  /* read model number */
>>  char *model = malloc(sizeof(char)*16, M_DEVBUF, M_WAITOK | M_ZERO);
>>  selwd_read_modelno(iot, ioh, model);
>
> This is worrying.  It assumes that all systems have this hardware.
>
> And it starts by doing a "write".

Is there no WDRT or WDAT table in ACPI on this hardware? Most "modern"
(2006-on) watchdogs on PCs with ACPI support have the WDRT table described
in https://msdn.microsoft.com/en-us/windows/hardware/gg463320.aspx

Check for /tmp/acpi.WD[AR]T.* files after running acpidump -o /tmp/acpi ..

FW: Re: watchdog suport for new hardware

2016-04-26 Thread stan

- Forwarded message from stan  -

From: stan 
To: Theo de Raadt 
Subject: Re: watchdog suport for new hardware
Date: Tue, 26 Apr 2016 09:19:20 -0400
User-Agent: Mutt/1.5.4i
X-Operating-System: Debian GNU/Linux
X-Kernel-Version: 2.4.23
X-Uptime: 09:17:17 up 91 days,  8:18,  1 user,  load average: 0.00, 0.02, 0.04
X-Editor: gVim

Hee is the core of the functionality:


/*  $OpenBSD: selwd.c,v 1.0 2016/04/01 05:00:00 jsg Exp $   */
/*
 * Copyright (c) 2016 PREMIER System Integrators
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 *
 * Schweitzer Engineering Laboratories: SEL-3355 Embedded controller
*/

#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 
#include 

struct selwd_softc {
/* sc_dev must be the first item in the struct */
struct device   sc_dev;
/* device access through bus space */
bus_space_tag_t sc_iot;
bus_space_handle_t  sc_ioh;
};

int selwd_wait(bus_space_tag_t, bus_space_handle_t, bool);

/* Autoconfiguration glue */
int selwd_probe(struct device *, void *, void *);
void selwd_attach(struct device *, struct device *, void *);
int selwd_print(void *, const char *);
int selwd_wd_cb(void *, int);

/* functions to interact with the controller */
void selwd_write_wdog(bus_space_tag_t, bus_space_handle_t, int);
u_int8_t selwd_read_wdog(bus_space_tag_t, bus_space_handle_t);
u_int8_t selwd_read_status(bus_space_tag_t, bus_space_handle_t);
void selwd_abort(bus_space_tag_t, bus_space_handle_t);
u_int32_t selwd_read_boardid(bus_space_tag_t, bus_space_handle_t);
u_int32_t selwd_read_mcversion(bus_space_tag_t, bus_space_handle_t);
u_int16_t selwd_read_pciboardid(bus_space_tag_t, bus_space_handle_t);
u_int8_t selwd_read_ledctl0(bus_space_tag_t, bus_space_handle_t);
void selwd_write_ledctl0(bus_space_tag_t, bus_space_handle_t, u_int8_t);
u_int8_t selwd_read_ledctl1(bus_space_tag_t, bus_space_handle_t);
void selwd_write_ledctl1(bus_space_tag_t, bus_space_handle_t, u_int8_t);
u_int8_t selwd_read_miscctl0(bus_space_tag_t, bus_space_handle_t);
u_int8_t selwd_read_miscctl1(bus_space_tag_t, bus_space_handle_t);
void selwd_read_modelno(bus_space_tag_t, bus_space_handle_t, char*);
void selwd_read_serialno(bus_space_tag_t, bus_space_handle_t, char*);
void selwd_read_configid(bus_space_tag_t, bus_space_handle_t, char*);

/* macros to extract bits from the status register */
#define EC_STATUS_IBF(status)   (((status) >> 0x1) & 0x1)
#define EC_STATUS_OBF(status)   (((status) & 0x1))
#define EC_STATUS_BUSY(status)  (((status) >> 0x4) & 0x1)
#define EC_STATUS_STATE(status) (((status) >> 0x6) & 0x3)

struct cfattach selwd_ca = {
sizeof(struct selwd_softc), selwd_probe, selwd_attach
};

struct cfdriver selwd_cd = {
NULL, "selwd", DV_DULL
};

const char* selwd_models[] = { SELWD_DEV_3355, SELWD_DEV_3360 };

int selwd_wait(bus_space_tag_t iot, bus_space_handle_t ioh, bool useobf)
{
uint32_t timeout = 0;
uint8_t status = 0;

while (timeout < 50) {
status = bus_space_read_1(iot, ioh, SELWD_CMD);
if ((EC_STATUS_IBF(status) == 0x0) &&
(EC_STATUS_BUSY(status) == 0x0) &&
(EC_STATUS_STATE(status) != 0x3) &&
((EC_STATUS_OBF(status) == 0x0) || !useobf)) {
return 1;
}
delay(10);
++timeout;
}
return 0;
}

static __inline void
selwd_conf_enable(bus_space_tag_t iot, bus_space_handle_t ioh, u_int8_t cmd)
{
/* write the desired command to the command register */
bus_space_write_1(iot, ioh, SELWD_CMD, cmd);
/* wait for controller to be ready */
selwd_wait(iot,ioh,0);
}

static __inline u_int8_t
selwd_conf_read(bus_space_tag_t iot, bus_space_handle_t ioh, u_int8_t target)
{
/* write the target address to the data register */
bus_space_write_1(iot, ioh, SELWD_DATA, target);
/* wait for controller to be ready */
selwd_wait(iot, ioh,1);
/* return the value from the data register */
return (bus_space_read_1(iot, ioh, SELWD_DATA));
}

static __inline void
selwd_conf_write(bu

Re: FW: Re: watchdog suport for new hardware

2016-04-26 Thread Theo de Raadt

> int
> selwd_probe(struct device *parent, void *match, void *aux)
> {
>   struct isa_attach_args *ia = aux;
>   bus_space_tag_t iot;
>   bus_space_handle_t ioh;
> 
>   /* Match by device ID */
>   iot = ia->ia_iot;
>   if (bus_space_map(iot, ia->ipa_io[0].base, SELWD_IOSIZE, 0, &ioh))
>   return 0;

...

>   /* read model number */
>   char *model = malloc(sizeof(char)*16, M_DEVBUF, M_WAITOK | M_ZERO);
>   selwd_read_modelno(iot, ioh, model);

This is worrying.  It assumes that all systems have this hardware.

And it starts by doing a "write".

> void
> selwd_read_modelno(bus_space_tag_t iot, bus_space_handle_t ioh, char* model)
> {
>   /* read the MODEL NUMBER value from the controller */
>   /* make sure status is 0 before proceeding */
>   selwd_abort(iot, ioh);
>   u_int8_t reg;
>   int i = 0;
> 
>   /* write the READCFG command to the command register */
>   selwd_conf_enable(iot, ioh, SELWD_CMD_READCFG);
>   /* read the MODELNO data value from the data register */
>   reg = selwd_conf_read(iot, ioh, SELWD_CFG_MODELNO);
>   while (reg != 0 && i < 15) {
>   model[i] = reg;
>   /* make sure status is 0 before proceeding */
>   selwd_abort(iot, ioh);
>   /* write the READCFG command to the command register */
>   selwd_conf_enable(iot, ioh, SELWD_CMD_READCFG);
>   /* read the MODELNO data value from the data register */
>   reg = selwd_conf_read(iot, ioh, SELWD_CFG_MODELNO);
>   i++;
>   }
> 
> }

I do not know what IO port this lands at, but we have had bad experiences
with this strategy in the past.  Specifically the uguru(4) chip which landed
right on top of an undocumented Dell server's cpu clock-generator, that was
even worse, since the clock generator appeared to change behaviour based only
upon read's...

Re: watchdog suport for new hardware

2016-04-26 Thread Theo de Raadt

obviously you show the code, and then when the complexity/simplicity of it
is seen, some people can jump in and help.

that is the traditional way: show it

> We are embarking on a project where we will be using a number of
> industrially hardened computers manufactured by  Schweitzer Engineering
> Laboratories, Inc. (SEL). SEL provides a very well whiten document
> describing certain special features of these computers. One of these is a
> hardware watchdog. 
> 
> We have contracted a systems integrator to write a device driver for this
> watchdog, with the stipulation that the code will be relapsed under the BSD
> licence. This work is essiantly complete, and I was wondering if someone could
> suggest to me the best way to submit this for (potential) inclusion in the
> OpenBSD base system?
> 
> Thanks for all the good work on a really solid OS!
> 
> 
> -- 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?

watchdog suport for new hardware

2016-04-26 Thread stan

We are embarking on a project where we will be using a number of
industrially hardened computers manufactured by  Schweitzer Engineering
Laboratories, Inc. (SEL). SEL provides a very well whiten document
describing certain special features of these computers. One of these is a
hardware watchdog. 

We have contracted a systems integrator to write a device driver for this
watchdog, with the stipulation that the code will be relapsed under the BSD
licence. This work is essiantly complete, and I was wondering if someone could
suggest to me the best way to submit this for (potential) inclusion in the
OpenBSD base system?

Thanks for all the good work on a really solid OS!


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: Several hardware issues on 13" MacBook Pro 2015

2016-04-15 Thread Joe Schillinger

Hi everyone, just wanted to reply back with a fix I discovered for the
graphical errors. I had TearFree enabled in my xorg.conf, and deleting
that line fixed it for me.


Joe

Re: Apr 4th amd64 snapshot problems, various outcomes including panic with USB hardware, no panic but fails without

OK, dmesg after reboot with radeon firmware.

OpenBSD 5.9-current (GENERIC.MP) #1983: Mon Apr  4 21:50:41 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277862400 (4079MB)
avail mem = 4143853568 (3951MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f800 (48 entries)
bios0: vendor American Megatrends Inc. version "080014" date 01/13/2009
bios0: BIOSTAR Group A760G M2+
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) 
PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2K(S1) PS2M(S1) UAR1(S1) 
P0PC(S4) UHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.50 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu2: AMD erratum 721 detected and fixed
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu3: AMD erratum 721 detected and fixed
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus 2 (PCE7)
acpiprt5 at acpi0: bus 3 (P0PC)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpicpu2 at acpi0: C1(@1 halt!), PSS
acpicpu3 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 127 degC
"PNP0401" at acpi0 not configured
"PNP0103" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
cpu0: 2200 MHz: speeds: 2200 1100 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD RS780 Host" rev 0x00
ppb0 at pci0 dev 2 function 0 "AMD RS780 PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 4350" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 4000 HD Audio" rev 0x00: msi
azalia0: no supported codecs
ppb1 at pci0 dev 7 function 0 "AMD RS780 PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
re0 at pci2 dev 0

Re: Apr 4th amd64 snapshot problems, various outcomes including panic with USB hardware, no panic but fails without

I have successfully installed this snap on an old 1GB flash drive and it
boots and can install packages.
Happy to know that the snap and my computer work fine together.

Proper dmesg:
Oops, just noticed I need to reboot for firmware. Will send this anyway.

Chris Bennett

OpenBSD 5.9-current (GENERIC.MP) #1983: Mon Apr  4 21:50:41 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277862400 (4079MB)
avail mem = 4143853568 (3951MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f800 (48 entries)
bios0: vendor American Megatrends Inc. version "080014" date 01/13/2009
bios0: BIOSTAR Group A760G M2+
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) 
PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2K(S1) PS2M(S1) UAR1(S1) 
P0PC(S4) UHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.45 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu2: AMD erratum 721 detected and fixed
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu3: AMD erratum 721 detected and fixed
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus 2 (PCE7)
acpiprt5 at acpi0: bus 3 (P0PC)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpicpu2 at acpi0: C1(@1 halt!), PSS
acpicpu3 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 127 degC
"PNP0401" at acpi0 not configured
"PNP0103" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
cpu0: 2200 MHz: speeds: 2200 1100 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD RS780 Host" rev 0x00
ppb0 at pci0 dev 2 function 0 "AMD RS780 PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 4350" rev 0x00
drm0 at rad

Re: Apr 4th amd64 snapshot problems, various outcomes including panic with USB hardware, no panic but fails without

On Tue, Apr 12, 2016 at 02:06:51PM -0700, Philip Guenther wrote:
> To track this down, we need to have a clue when it broke.
> What was the date of the last snap where this *worked*?
> 

Sorry I can't give an exact answer for sure.
I get bad downloads occasionally, so I re-download when I have a
problem.
It was working on the snap before this one or the one right before that.

But I can't be sure. After doing a fresh install on top, There just
aren't the dates or files anymore to be sure.

Best I can offer is to do as many builds as are necessary to find
problem.

The usb stick does mount and work correctly. I see no other problems at
all except with booting.

Chris Bennett

Re: Apr 4th amd64 snapshot problems, various outcomes including panic with USB hardware, no panic but fails without

2016-04-12 Thread Philip Guenther

On Tue, Apr 12, 2016 at 12:52 PM, Chris Bennett
 wrote:
> I bring this up late, but I was out of town with i386 laptop.
>
> I have a Sandisk 32G USB3 compatible flash.
> I have been running snaps for a good while with no problems at all.
> I am also running a USB3 compatible 1TB passport drive too.
>
> Once I upgraded to this snap, I got a panic right after booting showed a
> problem with usb6 and it being disabled. Re-updated snap, not fixed.

To track this down, we need to have a clue when it broke.
What was the date of the last snap where this *worked*?


Philip Guenther

Re: Apr 4th amd64 snapshot problems, various outcomes including panic with USB hardware, no panic but fails without

I put pictures of what I could get from ddb at:
www.bennettconstruction.us/our_house/

Chris Bennett

Re: Apr 4th amd64 snapshot problems, various outcomes including panic with USB hardware, no panic but fails without

On Tue, Apr 12, 2016 at 02:52:38PM -0500, Chris Bennett wrote:
> Once I upgraded to this snap, I got a panic right after booting showed a
> problem with usb6 and it being disabled. Re-updated snap, not fixed.
> 

 Sorry, right after delaying on usb6, said uhub1 was disabled

 Chris

Apr 4th amd64 snapshot problems, various outcomes including panic with USB hardware, no panic but fails without

I bring this up late, but I was out of town with i386 laptop.

I have a Sandisk 32G USB3 compatible flash.
I have been running snaps for a good while with no problems at all.
I am also running a USB3 compatible 1TB passport drive too.

Once I upgraded to this snap, I got a panic right after booting showed a
problem with usb6 and it being disabled. Re-updated snap, not fixed.

Did a fresh install today from a CD, no fix.

I had removed a Radeon video card to make a space, but no problems with
other snaps. Still, I thought it best to put things as before. Nope.

I played with many BIOS settings for USB, legacy support, usb 2
high-speed or slower, EHCI handoff. Could only stop booting from drive,
no other changes.

Legacy support on auto said that it only turned on if usb devices
attached. This gave me the idea to remove all other usb and use ps/2
keyboard.

No panic but stopped at boot method:
typing help showed the other methods such as network cards.

Could this be a problem with the snap? Or is a hardware problem more
likely?

I will try getting ddb info using the ps/2 key now. USB keyboard was
dead after panic.

Thanks
Chris Bennett


flash disk is:
umass2 at uhub1 port 3 configuration 1 interface 0 "SanDisk Ultra" rev 
2.10/1.00 addr 3
umass2: using SCSI over Bulk-Only
scsibus6 at umass2: 2 targets, initiator 0
sd2 at scsibus6 targ 1 lun 0:  SCSI4 0/direct removable 
serial.07815581431206101032
sd2: 29664MB, 512 bytes/sector, 60751872 sectors


OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277862400 (4079MB)
avail mem = 4144320512 (3952MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f800 (48 entries)
bios0: vendor American Megatrends Inc. version "080014" date 01/13/2009
bios0: BIOSTAR Group A760G M2+
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) 
PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2K(S1) PS2M(S1) UAR1(S1) 
P0PC(S4) UHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.47 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu2: AMD erratum 721 detected and fixed
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Phenom(tm) 9550 Quad-Core Processor, 2200.14 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu3: ITLB

Re: Several hardware issues on 13" MacBook Pro 2015

2016-04-09 Thread Ulf Brosziewski

Hi,

the hardware driver for your touchpad model isn't up-to-date yet.
I believe it's not much that's missing, so maybe it will be changed
soon.

On 04/09/2016 05:24 AM, Joe Schillinger wrote:
> Hi,
> 
> New OpenBSD user here, I decided to install OpenBSD 5.9 (now on -current) on 
> my MacBook this past week. Installation was smooth, but now I'm having a few 
> seemingly hardware-related issues.
> 
> Firstly, I'm experiencing some quite crippling graphical glitches in X11 that 
> make the system nearly unusable. Terminal windows (urxvt) are often missing 
> text, and windows will flash and just generally "glitch out". I realize this 
> description isn't probably too helpful, but I don't know how else to describe 
> it. Here are a couple pictures that I could capture of what's going on. I'm 
> using spectrwm, although these issues exist in other WM's as well (I tried 
> fvwm).
> https://u.teknik.io/Gapfb.png https://u.teknik.io/ckdGa.png 
> https://u.teknik.io/1Ji7K.png https://u.teknik.io/uJjQZ.png
> 
> Secondly, the audio from the speakers is tinny and quiet. I've tried changing 
> values in mixerctl with no success. I think it seems as though the bass 
> speakers aren't being used. The volume I'm getting while in OpenBSD seems to 
> be about half of what I'm able to get in OS X and Windows on the same machine.
> 
> Thirdly, this is probably a synaptics driver issue, but when I two-finger 
> scroll in an application like Chromium, and let go of my second finger, the 
> cursor will jump up about a quarter of the screen height. In general, the 
> cursor jumps around my screen an awful lot, and I've never had this problem 
> in the past.
> 
> I mention these issues only because I've not had them in either of the Linux 
> distros I've installed on here (Arch and CRUX). If there's any other 
> information I can provide, I'd love to help. I think OpenBSD is a wonderfully 
> designed system and I really would love to use it.
> 
> dmesg: http://sprunge.us/MAVR
> Xorg.0.log: http://sprunge.us/jgCH
> mixerctl: http://sprunge.us/JUCh
> 
> Thanks,
> Joe

Re: OT: True hardware UNIX terminal

2016-04-05 Thread John Long

On Mon, Apr 04, 2016 at 04:40:20PM -0600, Nick Bender wrote:

> I wonder if any FORTRAN programmers out there remember the trick of putting
> line numbers after column 72 so the card sort could sort your program back
> into order when you dropped your card deck?

This was not limited to FORTRAN. We always used sequence numbers in 73-80
for exactly this reason. To this day the MVS (z/OS) editor will place them
for you in those colums automatically when you say "num on" or "renum". This
works for assembler, COBOL, and PL/I too.

And yeah you won't understand unless you ever dropped a box of cards or saw
the look of horror on somebody else's face when he did.

> Finally I'll never get back the three days I spent finding the zero I had
> mistakenly put in place of the letter O in my JCL at the front of the card
> deck. Good times...

We're still keeping the faith!

/jl

-- 
ASCII ribbon campaign ( ) Powered by Lemote Fuloong
 against HTML e-mail   X  Loongson MIPS and OpenBSD
   and proprietary/ \http://www.mutt.org
 attachments /   \  Code Blue or Go Home!
 Encrypted email preferred  PGP Key 2048R/DA65BC04

Re: OT: True hardware UNIX terminal

2016-04-04 Thread Nick Bender

Just a couple added memories.

Punched cards were my first experience with "copy/paste" - there was a
"duplicate card" key on the card machine which would create a duplicate of
the card you queued up in the input slot. Of course you could also
cut/paste just by moving the card :-).

Above the card reader at the computing center there was a very colorful
"beware the rubber bandito" sign to remind you to remove the rubber band
from your card deck :-)

I also remember the transition from 300 baud modems to 1200 baud modems
than made a full screen editor usable vs. the line editor that we used with
300 baud modems.

I wonder if any FORTRAN programmers out there remember the trick of putting
line numbers after column 72 so the card sort could sort your program back
into order when you dropped your card deck?

Finally I'll never get back the three days I spent finding the zero I had
mistakenly put in place of the letter O in my JCL at the front of the card
deck. Good times...

On Sun, Apr 3, 2016 at 10:31 PM, Dave Anderson 
wrote:

> On Mon, 4 Apr 2016, ropers wrote:
>
> On 4 April 2016 at 02:06, Adam Thompson  wrote:
>>
>> On 2016-04-01 11:07, ropers wrote:
>>>
>>> And if anyone has ever operated the OpenBSD installer via a teleprinter,
 I want to hear that story.


>>> I think there's still a first-generation TI Silent 700 somewhere in my
>>> parents' basement.  If, when they either die and/or move out to a
>>> seniors'
>>> residence prior to that certain event, I should run across it, and I can
>>> find a compatible telephone (acoustic handset coupler, remember!), and
>>> can
>>> find a compatible 300bps modem to dial into, and can find an
>>> honest-to-god
>>> POTS phone line (I expect this to be the hardest part) and can find a
>>> compatible system with a serial console that can be stepped down to
>>> 300bps,
>>> and the thermal paper is still viable, I'll do a fresh install just so I
>>> can mail you the ~3-4m of thermal paper I suspect that would generate.
>>> Would that be close enough for you?  :-)
>>>
>>>
>> YES! I'd be extremely honoured to receive something like that. But, I
>> think
>> there are probably more worthy recipients. Computer museums, even.
>>
>>
>> (Actually, it just occurred to me that I don't need the phone line as long
>>> as I can also find the old PENRIL modem that can start training on a
>>> front-panel button-press instead of a -90v ring signal.  Or maybe the
>>> local
>>> museum will have a 300bps acoustic-coupler modem I can borrow?)
>>>
>>>
>> Wikipedia currently says that at least some Silent 700s could be locally
>> connected:
>> https://en.wikipedia.org/wiki/Silent_700
>> Of course, that technically sort of takes away the tele- part from the
>> teleprinter (which is not to say that the device was now just a printer),
>> but I definitely think that an install to a locally attached teleprinter
>> counts. The key here is that it's monitorless, so not a glass terminal;
>> the
>> paper is the only place where you get to see output.
>>
>
> I love it, btw., that the Wikipedia article speaks of "the new high-speed
>> interactive computing environment" -- at 1200 baud. :)
>>
>
> That was advanced stuff.  I remember how pleased we were when we upgraded
> to blazingly fast 300 baud 'glass teletypes' from 110 baud KSR35 teletypes.
>
> Dave
>
>
> Those were days when actual interactive use of a computer was not unlike
>> getting telescope time at a major observatory -- and before time-sharing
>> allowed concurrent multi-user access, it must have been almost exactly
>> alike.
>> Like Woz said in the Youtube video I linked: "Your use on these company
>> computers, it was so far above us in value."
>>
>>
>> I vaguely recall once doing an OpenBSD install where the "console" path
>>> was:
>>> Local VT220 -> multiplexer -> modem -> DATAPAC 3101 (Canadian X.25
>>> service) PAD -> remote PAD -> remote dial-out service -> another modem ->
>>> another multiplexer -> serial line into, IIRC, ttyA on a Sun system I was
>>> helping someone repurpose.  The entire install completed successfully
>>> off a
>>> network boot in about an hour at 2400bps (*and* simultaneously 2400baud,
>>> all you pedants out there...).
>>>
>>>
>> Wow.
>>
>>
> --
> Dave Anderson
>

Re: OT: True hardware UNIX terminal

2016-04-03 Thread Dave Anderson


On Mon, 4 Apr 2016, ropers wrote:


On 4 April 2016 at 02:06, Adam Thompson  wrote:


On 2016-04-01 11:07, ropers wrote:


And if anyone has ever operated the OpenBSD installer via a teleprinter,
I want to hear that story.



I think there's still a first-generation TI Silent 700 somewhere in my
parents' basement.  If, when they either die and/or move out to a seniors'
residence prior to that certain event, I should run across it, and I can
find a compatible telephone (acoustic handset coupler, remember!), and can
find a compatible 300bps modem to dial into, and can find an honest-to-god
POTS phone line (I expect this to be the hardest part) and can find a
compatible system with a serial console that can be stepped down to 300bps,
and the thermal paper is still viable, I'll do a fresh install just so I
can mail you the ~3-4m of thermal paper I suspect that would generate.
Would that be close enough for you?  :-)



YES! I'd be extremely honoured to receive something like that. But, I think
there are probably more worthy recipients. Computer museums, even.



(Actually, it just occurred to me that I don't need the phone line as long
as I can also find the old PENRIL modem that can start training on a
front-panel button-press instead of a -90v ring signal.  Or maybe the local
museum will have a 300bps acoustic-coupler modem I can borrow?)



Wikipedia currently says that at least some Silent 700s could be locally
connected:
https://en.wikipedia.org/wiki/Silent_700
Of course, that technically sort of takes away the tele- part from the
teleprinter (which is not to say that the device was now just a printer),
but I definitely think that an install to a locally attached teleprinter
counts. The key here is that it's monitorless, so not a glass terminal; the
paper is the only place where you get to see output.



I love it, btw., that the Wikipedia article speaks of "the new high-speed
interactive computing environment" -- at 1200 baud. :)


That was advanced stuff.  I remember how pleased we were when we 
upgraded to blazingly fast 300 baud 'glass teletypes' from 110 baud 
KSR35 teletypes.


Dave


Those were days when actual interactive use of a computer was not unlike
getting telescope time at a major observatory -- and before time-sharing
allowed concurrent multi-user access, it must have been almost exactly
alike.
Like Woz said in the Youtube video I linked: "Your use on these company
computers, it was so far above us in value."



I vaguely recall once doing an OpenBSD install where the "console" path
was:
Local VT220 -> multiplexer -> modem -> DATAPAC 3101 (Canadian X.25
service) PAD -> remote PAD -> remote dial-out service -> another modem ->
another multiplexer -> serial line into, IIRC, ttyA on a Sun system I was
helping someone repurpose.  The entire install completed successfully off a
network boot in about an hour at 2400bps (*and* simultaneously 2400baud,
all you pedants out there...).



Wow.



--
Dave Anderson

Re: OT: True hardware UNIX terminal

2016-04-03 Thread ropers

On 4 April 2016 at 02:06, Adam Thompson  wrote:

> On 2016-04-01 11:07, ropers wrote:
>
>> And if anyone has ever operated the OpenBSD installer via a teleprinter,
>> I want to hear that story.
>>
>
> I think there's still a first-generation TI Silent 700 somewhere in my
> parents' basement.  If, when they either die and/or move out to a seniors'
> residence prior to that certain event, I should run across it, and I can
> find a compatible telephone (acoustic handset coupler, remember!), and can
> find a compatible 300bps modem to dial into, and can find an honest-to-god
> POTS phone line (I expect this to be the hardest part) and can find a
> compatible system with a serial console that can be stepped down to 300bps,
> and the thermal paper is still viable, I'll do a fresh install just so I
> can mail you the ~3-4m of thermal paper I suspect that would generate.
> Would that be close enough for you?  :-)
>

YES! I'd be extremely honoured to receive something like that. But, I think
there are probably more worthy recipients. Computer museums, even.

> (Actually, it just occurred to me that I don't need the phone line as long
> as I can also find the old PENRIL modem that can start training on a
> front-panel button-press instead of a -90v ring signal.  Or maybe the local
> museum will have a 300bps acoustic-coupler modem I can borrow?)
>

Wikipedia currently says that at least some Silent 700s could be locally
connected:
https://en.wikipedia.org/wiki/Silent_700
Of course, that technically sort of takes away the tele- part from the
teleprinter (which is not to say that the device was now just a printer),
but I definitely think that an install to a locally attached teleprinter
counts. The key here is that it's monitorless, so not a glass terminal; the
paper is the only place where you get to see output.
I love it, btw., that the Wikipedia article speaks of "the new high-speed
interactive computing environment" -- at 1200 baud. :)
Those were days when actual interactive use of a computer was not unlike
getting telescope time at a major observatory -- and before time-sharing
allowed concurrent multi-user access, it must have been almost exactly
alike.
Like Woz said in the Youtube video I linked: "Your use on these company
computers, it was so far above us in value."

> I vaguely recall once doing an OpenBSD install where the "console" path
> was:
> Local VT220 -> multiplexer -> modem -> DATAPAC 3101 (Canadian X.25
> service) PAD -> remote PAD -> remote dial-out service -> another modem ->
> another multiplexer -> serial line into, IIRC, ttyA on a Sun system I was
> helping someone repurpose.  The entire install completed successfully off a
> network boot in about an hour at 2400bps (*and* simultaneously 2400baud,
> all you pedants out there...).
>

Wow.

Re: OT: True hardware UNIX terminal

2016-04-03 Thread wmcowan

Adam Thompson writes:
> On 2016-04-01 11:07, ropers wrote:
> > And if anyone has ever operated the OpenBSD installer via a 
> > teleprinter, I want to hear that story.
> 
> I think there's still a first-generation TI Silent 700 somewhere in my 
> parents' basement.  If, when they either die and/or move out to a 
> seniors' residence prior to that certain event, I should run across it, 
> and I can find a compatible telephone (acoustic handset coupler, 
> remember!), and can find a compatible 300bps modem to dial into, and can 
> find an honest-to-god POTS phone line (I expect this to be the hardest 
> part) and can find a compatible system with a serial console that can be 

Well, I have the hardest part: a dial telephone (ca. 1930) with an
old-style handset and an analogue line right through the switch to
the telephone I'm talking to.

Why on earth would anybody have such a thing? The combination of a
handset with the speaker near my ear and the microphone near my
mouth plus an analogue line provides me with signal-to-noise good
enough that my aging ears can actually understand what's being said
to me, and that the listener at the other end can understand me
without the rest of the world being forced to share my end of the
conversation.

My 300bps acoustic handset coupler, however, is gathering dust in
the basement.

Bill

Re: OT: True hardware UNIX terminal

2016-04-03 Thread Adam Thompson


On 2016-04-01 11:07, ropers wrote:
And if anyone has ever operated the OpenBSD installer via a 
teleprinter, I want to hear that story.


I think there's still a first-generation TI Silent 700 somewhere in my 
parents' basement.  If, when they either die and/or move out to a 
seniors' residence prior to that certain event, I should run across it, 
and I can find a compatible telephone (acoustic handset coupler, 
remember!), and can find a compatible 300bps modem to dial into, and can 
find an honest-to-god POTS phone line (I expect this to be the hardest 
part) and can find a compatible system with a serial console that can be 
stepped down to 300bps, and the thermal paper is still viable, I'll do a 
fresh install just so I can mail you the ~3-4m of thermal paper I 
suspect that would generate.  Would that be close enough for you?  :-)


(Actually, it just occurred to me that I don't need the phone line as 
long as I can also find the old PENRIL modem that can start training on 
a front-panel button-press instead of a -90v ring signal.  Or maybe the 
local museum will have a 300bps acoustic-coupler modem I can borrow?)


Many of the readers here have absolutely installed OpenBSD (and other 
*NIXes) via serial port, sometimes using a local terminal, sometimes 
using a modem, sometimes even vastly more esoteric combinations than 
anyone could reasonably expect.

I vaguely recall once doing an OpenBSD install where the "console" path was:
Local VT220 -> multiplexer -> modem -> DATAPAC 3101 (Canadian X.25 
service) PAD -> remote PAD -> remote dial-out service -> another modem 
-> another multiplexer -> serial line into, IIRC, ttyA on a Sun system I 
was helping someone repurpose.  The entire install completed 
successfully off a network boot in about an hour at 2400bps (*and* 
simultaneously 2400baud, all you pedants out there...).
So while that wasn't quite an actual teletype, the whole purpose of 
serial ports and serial terminals as a "standard" is that crazy shit 
like that can actually happen!


-Adam

Re: OT: True hardware UNIX terminal

2016-04-01 Thread ropers

Steve Litt wrote:

> I was a DEC PDP/11 TSX over RT-11 guy back then, but as I remember, a
> terminal was a television that printed letters and numbers plus a
> keyboard on which you could type.

I have to disagree a little bit in that actual TVs were too low-rez for
good 80-column text, which has a longer tradition. However, TV-compatible
40-column or lower text modes did come into play during the microcomputer
revolution, at the Homebrew Computer Club, and with the TV Typewriter
(which was more of an electronics hobbyist project, but could be turned
into a terminal, though not a "professional" one). The DOS PC CGA also
supported 40-column modes--it had a composite/TV output besides RGBI. Of
course, if by television you basically meant CRT, then I'd agree.

I'll add some more, actually.
(This isn't first-hand knowledge, but I forget where I got it from --
possibly various sources.)

Here's some
-=PREHISTORY=-
which explains more of how terminals came to be:

The kind of early electronic data processing that lead to terminals really
started with (electromechanical) tabulating machines. Those gave us the
standardized punch card. Edwin Black's "IBM and the Holocaust" contains
(not very detailed and technical) descriptions, and even photos of such a
machine and some punch cards. An early use for these evolving machines was
the census, in the US and later in (Nazi-) Germany.
The way this worked was, these cardboard punch cards got holes stamped into
them to encode information on them. This was done in dedicated card punches
(keypunches: https://en.wikipedia.org/wiki/Keypunch), which generally were
a cross between a hole punch and a typewriter. There was an array of rows
and columns and a clerical worker would type and thereby punch the right
holes in the right positions. IBM soon standardized on the 80-column card,
and that's why most terminals, screen fidelity permitting, got 80-column
text. One punch card could encode one such line of text. (ASCII text? Well,
sort of, similar. Let's forget that EBCDIC ever existed.)
https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_formats_and_character_codes
I don't know if there's a specific reason for the 24 (later sometimes 25)
lines of most terminals, but I guess it had to do with being a multiple of
8 and just how many 80-column lines could legibly be fit onto a 4:3 aspect
ratio CRT display. But that came later. Back to the cards.

Those punch cards were fed to a reader, which was an array of contacts that
would be lowered onto and --holes permitting-- through a card. Early
tabulators had little pockets of liquid mercury underneath each position,
and the electrical circuit was closed by the contacts dipping into that.
(Hello OSHA.) Those tabulating machines weren't computers, and some early
ones just had clock dial counters, on which hands would advance when a
contact was closed. This already allowed electromechanical addition though:
Feed in a card, read it, have the hands advance. Feed in a second card,
read it, have the hands advance some more.
https://en.wikipedia.org/wiki/File:HollerithMachine.CHM.jpg
Other tabulating machine setups included sorters, where cards would be
sorted in different output stacks depending on their hole-encoded
information. (There's a link from that to VisiCalc and Excel, but that's OT
to this OT post.)

When computers were invented, these 80-column cards quickly became the
industry-standard input/output mechanism.
https://en.wikipedia.org/wiki/Punched_card_input/output
The programmer/user would write a program or calculation on paper, mail or
hand that paper to the clerical staff who would type/punch that information
into cards, and then a whole pile of punched cards would be delivered to
the computer operators, who would carefully deposit them into the punch
card reader, and these machines had feeders which could quickly process a
whole batch of cards, one after another. This is what gave us batch
processing.
For output, these computers could either themselves punch cards and/or they
could use a line printer. https://en.wikipedia.org/wiki/Line_printer
(Sometimes the output was the way the cards got sorted, but that was mostly
a tabulating machine thing.)

It was pretty standard then to hand in your program sheets and get back
your printed results back on continuous stationery.
https://en.wikipedia.org/wiki/Continuous_stationery
This was technically multi-user, but you had to queue and wait maybe hours
or a day for your cards to be processed and to get your results back.
Longer if it went through the mail. (DO NOT BEND was very important if
punch cards were mailed, because punch card readers really don't like
warped cards.) https://en.wikipedia.org/wiki/Time-sharing#Batch_processing

Meanwhile, the telegraphy industry had developed the teletype, which was a
teleprinter, basically a typewriter that could electronically transmit
typed characters, across a room or across the country, and

Re: OT: True hardware UNIX terminal

2016-03-30 Thread Joseph Pumphrey

On Mar 30, 2016 4:29 PM, "Mihai Popescu"  wrote:
>
> I can see now why our keyboards are using Ctrl key, PgUp, PgDn, or why
> the serial port is so close programmed using terminal terminology.
>
> Thank you and please excuse me for the OT.
>

I still have IBM 122-key keyboards lying around from working in government
buildings and ripping out old terminals. Quite an education, as was this
thread!

Re: OT: True hardware UNIX terminal

2016-03-30 Thread Adam Thompson


On 16-03-30 03:07 AM, Sean Kamath wrote:

Still using a Wyse (50?) on my Ultrasparc 80.

In college, we had these weird DEC PC’s that we used as VT100 compatible
terminals.
That would either have been a DEC Rainbow, which was a 
hybrid-dual-processor 8088/Z80 machine that ran MS/DOS, CP/M *and* had a 
full-blown VT220 emulator in ROM, or a VT180 "Robin" which was basically 
a (Z80-based) VT102/VT103 with enough memory (i.e. 64k) to run CP/M off 
the attached floppy drives.


I had a Rainbow, which is in *many* ways an architecturally fascinating 
machine, during the late '80s/early '90s as my primary PC.  I also had a 
Northern Telecom Displayphone, and then later a DisplayPhone II, for 
those of you with a perverse bent for terminal history.


Of course, I'm also the author of at least five termcap(5)/terminfo(5) 
entries, some of which have not yet been superseded by better 
definitions in the ncurses master list... so naturally I had some really 
f*ing weird terminals at various points in my life.


I wish I could remember what the name was of the "portable" terminal I 
once had - off-white (of course), looked like a Buck Rogers spaceship 
(pointy cylinder) in profile, and the entire front two inches of it 
unsnapped to become the keyboard kind of like an Osborne...


-Adam

Re: OT: True hardware UNIX terminal

2016-03-30 Thread Mihai Popescu

Thank you all for the answers. I can say I got the idea of what a
terminal was back then.
Reading all your posts and searching again on web using the mentioned
keywords move away any if not all of my confusions about "terminals".
I can see now why our keyboards are using Ctrl key, PgUp, PgDn, or why
the serial port is so close programmed using terminal terminology.

Thank you and please excuse me for the OT.

Re: OT: True hardware UNIX terminal

2016-03-30 Thread Eric Huiban

Sent from my WIKO PULP 4G
Le 30 mars 2016 10:07, Sean Kamath  a écrit :
>
> Still using a Wyse (50?) on my Ultrasparc 80. 
>
> In college, we had these weird DEC PC’s that we used as VT100 compatible 
> terminals. 
>
> There were so many.  The VT100 was the prototype what XTerm emulated. 
>
> Sean 
>
> > On Mar 29, 2016, at 5:18 AM, Nick Holland  
> wrote: 
> > Some things to search for: 
> > * DEC VT100  (a terminal that still influcences the standards today) 
> > * DEC VT52   (a terminal with an easier to understand command set) 
> > * ADM3A  (a terminal that was old when the DEC vt100 came out) 
> > * DECwriter  (printing terminal.  DECwriter II was a beautiful machine) 
> > * TI Silent 700 ("home oriented" printing terminal.  At the time, in the 
> > US, it was illegal to attach non-telephone company equipment to the 
> > telephone company's phone lines...) 
> > * ASCII  (the non-IBM standard character coding system) 
> > * EBCDIC (the IBM standard) 
> > * ASR33  (one of the earliest printing terminals.  And why we use 
> > "TTY" today in the Unix world!  If you wonder why unix commands are so 
> > short, imagine typing on this...) 
> > * Tektronix 4010 (In case you thought terminals were dull and graphics 
> > free...and I suspect a LOT of people who have been rolling their eyes at 
> > everything I've said up to now will have their eyes bug out a bit when 
> > they figure out how these things work) 
> > 
> > Anything more than that (and probably a lot less than that), probably 
> > best to ask me off list. :)  (and yes, I've glossed over and simplified 
> > a few things here) 
> > 
> > Nick. 
>

You may have also a look at the ncd 88k terminal which was also a very common 
terminal. Wikipedia has a small article about this at "X terminal". 

Éric

Re: OT: True hardware UNIX terminal

2016-03-30 Thread Sean Kamath

Still using a Wyse (50?) on my Ultrasparc 80.

In college, we had these weird DEC PC’s that we used as VT100 compatible
terminals.

There were so many.  The VT100 was the prototype what XTerm emulated.

Sean

> On Mar 29, 2016, at 5:18 AM, Nick Holland 
wrote:
> Some things to search for:
> * DEC VT100  (a terminal that still influcences the standards today)
> * DEC VT52   (a terminal with an easier to understand command set)
> * ADM3A  (a terminal that was old when the DEC vt100 came out)
> * DECwriter  (printing terminal.  DECwriter II was a beautiful machine)
> * TI Silent 700 ("home oriented" printing terminal.  At the time, in the
> US, it was illegal to attach non-telephone company equipment to the
> telephone company's phone lines...)
> * ASCII  (the non-IBM standard character coding system)
> * EBCDIC (the IBM standard)
> * ASR33  (one of the earliest printing terminals.  And why we use
> "TTY" today in the Unix world!  If you wonder why unix commands are so
> short, imagine typing on this...)
> * Tektronix 4010 (In case you thought terminals were dull and graphics
> free...and I suspect a LOT of people who have been rolling their eyes at
> everything I've said up to now will have their eyes bug out a bit when
> they figure out how these things work)
>
> Anything more than that (and probably a lot less than that), probably
> best to ask me off list. :)  (and yes, I've glossed over and simplified
> a few things here)
>
> Nick.

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Steve Litt

On Tue, 29 Mar 2016 14:20:35 +0300
Mihai Popescu  wrote:

> I want to get and idea of what was or is an old true hardware UNIX
> terminal.

I was a DEC PDP/11 TSX over RT-11 guy back then, but as I remember, a
terminal was a television that printed letters and numbers plus a
keyboard on which you could type.

The television and keyboard connected to the computer with a serial
cable (RS-232). The serial cable conducted 1 byte letters, numbers, and
a few control and special characters, in each direction. So even a pig
slow serial connection could fill up the television pretty fast: The
computer had no concept of pixels.

To convert letters and digits from the computer to screen pixels, the
television part of the terminal contained a hardware-implemented
character generator. Similarly, switch pairs, from the keyboard,
representing key presses, were converted, at the terminal, to ascii
bytes before being sent to the computer.

The benefits were many. This was an incredibly thin interface, such
that pretty much anything that could send and receive ascii bytes could
be used interchangeably. The 1 byte per letter meant the serial
connection wouldn't be taxed too heavily. The offloading of letter to
graphics to the terminal meant the computer, which had less power than
today's cell phones, could spend its time running jobs rather than
shuffling pixels.

And one benefit that carries over to today: The thin ascii interface
meant the terminal would come up live incredibly early in the boot,
which helped a lot in troubleshooting and bootstrapping up to a useful
system. I can't count the times when, faced with a no-boot, partial
POST computer, I wish I had a terminal to plug into the serial port,
probably after removing the video card. Sure, I could use another
computer plus minicom, but minicom itself introduces so many variables
it's not worth it. 

SteveT

Steve Litt 
March 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Eike Lantzsch

On Tuesday 29 March 2016 14:20:35 Mihai Popescu wrote:
> Hello,
> 
> This question is somehow off topic but I know there are some readers
> here old enough to shade some light in this matter.
> I want to get and idea of what was or is an old true hardware UNIX
> terminal. I have searched google, but the word "terminal" associated
> with UNIX points most of the time to what we know today as UNIX shell.
> If someone, please, can show me a doc or explain a little bit what was
> a terminal at that moment back in time. I know that it was some kind
> of hardware, maybe RS232 related, used to connect to some main frame.
> But I am unable to find the details. I even lack some tech words to
> search deeper on the web.
> 
> Thank you.

Hazeltine 2000 anyone?
http://terminals.classiccmp.org/wiki/index.php/Hazeltine_2000

When I started building my own Z80 system I got a used Hazeltine 2000. As soon 
as I saw it was only capable of capital chars I slaughtered it and replaced 
the boards with my own V24 terminal card on a 160x100mm board. It was also 
based on a Z80.
The keyboard was a reprogrammed (EPROM) parallel WANG keyboard - it was also 
based on a Z80.

Eike

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Christian Weisgerber

On 2016-03-29, Mihai Popescu  wrote:

> This question is somehow off topic but I know there are some readers
> here old enough to shade some light in this matter.
> I want to get and idea of what was or is an old true hardware UNIX
> terminal.

Start here:
https://en.wikipedia.org/wiki/Computer_terminal

http://vt100.net/

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: OT: True hardware UNIX terminal

2016-03-29 Thread ropers

On 29 March 2016 at 14:18, Nick Holland wrote:

> * ADM3A  (a terminal that was old when the DEC vt100 came out)
>

I want to add special emphasis to Nick's mention of this terminal. It is
more fully known as the LSI ADM-3A. LSI for Lear Siegler Incorporated.
This for some reason was yuuugely influential. There are Wikipedia articles:

https://en.wikipedia.org/wiki/ADM-3A#Legacy

https://en.wikipedia.org/wiki/Lear_Siegler

The design looked very Space Age. And indeed, when it first came out,
Apollo was still flying.

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Tor Houghton

On Tue, Mar 29, 2016 at 08:18:34AM -0400, Nick Holland wrote:
> 
> * TI Silent 700 ("home oriented" printing terminal.  At the time, in the
> US, it was illegal to attach non-telephone company equipment to the
> telephone company's phone lines...)

!!

I fondly remember playing Adventure on one of these. At one end, a
CDC Cyber, and the other, a teenager amazed at the yards and yards of
unrolled thermal paper that was left after each session. :-)

Tor

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Francois Pussault

> 
> From: Mihai Popescu 
> Sent: Tue Mar 29 13:20:35 CEST 2016
> To: 
> Subject: OT: True hardware UNIX terminal
>
>
> Hello,
>
> This question is somehow off topic but I know there are some readers
> here old enough to shade some light in this matter.
> I want to get and idea of what was or is an old true hardware UNIX
> terminal. I have searched google, but the word "terminal" associated
> with UNIX points most of the time to what we know today as UNIX shell.
> If someone, please, can show me a doc or explain a little bit what was
> a terminal at that moment back in time. I know that it was some kind
> of hardware, maybe RS232 related, used to connect to some main frame.
> But I am unable to find the details. I even lack some tech words to
> search deeper on the web.
>
> Thank you.
>

Hello,

you may search on teletype or serial port or getty
I currently use both a vt320 (orange) & a ibm 3151  (green) on a linux
station.

When I run my D200 HPPA OpenBSD I also use the IBM model.


Cordialement
Francois Pussault
10 chemin de négo saoumos
apt 202 - bat 2
31300 Toulouse
+33 6 17 230 820   +33 5 34 365 269
fpussa...@contactoffice.fr

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Nick Holland

On 03/29/16 07:20, Mihai Popescu wrote:
> Hello,
> 
> This question is somehow off topic but I know there are some readers
> here old enough to shade some light in this matter.
> I want to get and idea of what was or is an old true hardware UNIX
> terminal. I have searched google, but the word "terminal" associated
> with UNIX points most of the time to what we know today as UNIX shell.
> If someone, please, can show me a doc or explain a little bit what was
> a terminal at that moment back in time. I know that it was some kind
> of hardware, maybe RS232 related, used to connect to some main frame.
> But I am unable to find the details. I even lack some tech words to
> search deeper on the web.
> 
> Thank you.

long, long ago...on a computer in a dump far far away...

Rather than having a video display device inside the computer, a serial
terminal was used.  The terminal provided the keyboard and the display
of some kind and communicated with the computer over relatively simple
protocol, typically a RS-232 serial port.

The first generation "display of some kind" were typically printers.
After killing huge quantities of trees, the industry switched to using
CRTs as the display device.

If the computer sent out the sequence of bytes (in hex)
48 65 6c 6c 6f 0d 0a 57 6f 72 6c 64 21
the terminal would display something like:
+---
| Hello
| World!_
|

the "0d" is a "carriage return" (CR), and moves the cursor (where the
next character will be displayed (and represented by the "_"  after the
"!" above) to the beginning of the SAME line, and "0a" is a Line Feed
(LF) and moves the character DOWN a line, so the next characters are at
the beginning of the next line.  (This is a point of confusion -- while
most terminals required a CR and a LF to move the cursor to the
beginning of the next line, different computers used different character
sequences to indicate the end of the line internally.  MSDOS, CP/M and
most other older, non-Unix systems used the CR/LF combination.  Apple
used CR only.  Unix uses LF only.  I'd argue that Unix is technically
WRONG, but it is ever so convenient for a LOT of reasons.

Most CRT-based terminals supported magic character sequences that did
things like clear the screen, locate the cursor at a particular
position, increase the intensity of the character (bold face) or reverse
video the character, etc.  More advanced (i.e., "less ancient")
terminals could do different sized characters (though usually an integer
multiple of the standard size -- double high, double wide),

Meanwhile, characters you type on the keyboard are sent to the computer
over the same serial interface.  One thing worth understanding is that
some keys on the keyboard generate one character (a-z, numbers,
punctuation), others generate NONE, but modify the other key's sent code
(i.e., "a" sends 61 hex, shift-a sends 41 hex, ctrl-a sends 01 hex), and
others send MULTIPLE characters (arrow keys, function keys).

Terminals were not a "Unix" thing -- most terminals (ignoring IBM's
products) were device agnostic, and could be used with almost any
computer that spoke the same language, which was usually ASCII (again,
ignoring IBM).  And yes, most of them were horribly Western language
(and even then, mostly "English") focused.

You can still attach a serial terminal to a unix machine and use it as
back in the 1970s and 1980s, but today, we generally use a full computer
running a terminal emulator program.  And in fact, when you ssh to a
machine, you are using a terminal-like system, with SSH as the protocol
over an ethernet cable instead of the serial cable.

Some things to search for:
* DEC VT100  (a terminal that still influcences the standards today)
* DEC VT52   (a terminal with an easier to understand command set)
* ADM3A  (a terminal that was old when the DEC vt100 came out)
* DECwriter  (printing terminal.  DECwriter II was a beautiful machine)
* TI Silent 700 ("home oriented" printing terminal.  At the time, in the
US, it was illegal to attach non-telephone company equipment to the
telephone company's phone lines...)
* ASCII  (the non-IBM standard character coding system)
* EBCDIC (the IBM standard)
* ASR33  (one of the earliest printing terminals.  And why we use
"TTY" today in the Unix world!  If you wonder why unix commands are so
short, imagine typing on this...)
* Tektronix 4010 (In case you thought terminals were dull and graphics
free...and I suspect a LOT of people who have been rolling their eyes at
everything I've said up to now will have their eyes bug out a bit when
they figure out how these things work)

Anything more than that (and probably a lot less than that), probably
best to ask me off list. :)  (and yes, I've glossed over and simplified
a few things here)

Nick.

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Kapetanakis Giannis


On 29/03/16 14:20, Mihai Popescu wrote:

Hello,

This question is somehow off topic but I know there are some readers
here old enough to shade some light in this matter.
I want to get and idea of what was or is an old true hardware UNIX
terminal. I have searched google, but the word "terminal" associated
with UNIX points most of the time to what we know today as UNIX shell.
If someone, please, can show me a doc or explain a little bit what was
a terminal at that moment back in time. I know that it was some kind
of hardware, maybe RS232 related, used to connect to some main frame.
But I am unable to find the details. I even lack some tech words to
search deeper on the web.

Thank you.



We still use some of these:
https://en.wikipedia.org/wiki/VT420
http://q7.neurotica.com/Oldtech/Terminals/VT420.html

You might also want to check "terminal server"

G

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Andreas Kusalananda Kähäri

On Tue, Mar 29, 2016 at 02:20:35PM +0300, Mihai Popescu wrote:
> Hello,
> 
> This question is somehow off topic but I know there are some readers
> here old enough to shade some light in this matter.
> I want to get and idea of what was or is an old true hardware UNIX
> terminal. I have searched google, but the word "terminal" associated
> with UNIX points most of the time to what we know today as UNIX shell.
> If someone, please, can show me a doc or explain a little bit what was
> a terminal at that moment back in time. I know that it was some kind
> of hardware, maybe RS232 related, used to connect to some main frame.
> But I am unable to find the details. I even lack some tech words to
> search deeper on the web.
> 
> Thank you.
> 

I owned, until a few years ago, an orange-on-black vt320 terminal
(https://en.wikipedia.org/wiki/VT320).  I used it to interface with my
Sun Ultra 5 workstation and I also used it for an older Sun SPARCstation
4.  I believe I ran OpenBSD on them, but I'm sure I used NetBSD most of
the time (late 90's).  I've always been working at the command line.
so I'm not really interested in the X stuff, especially not on slower
hardware.

Working on the vt320 was easy on the eyes (soft large-ish letters) and
the monitor itself was smaller than the bulky CRTs of the pre-LCD era.

I used it at home from time to time, not at work.  I gave it, and the
Sun machines, up when I got tired of the long compile times of the
machines and the slow serial line to the terminal.  But I still regret
dumping the terminal, it was kinda neat.  I might be trying to find
another one eventually, or something like it, but I have nothing to
connect it to at the moment...

-- 
Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden
OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Martijn van Duren

On 03/29/16 13:20, Mihai Popescu wrote:
> Hello,
> 
> This question is somehow off topic but I know there are some readers
> here old enough to shade some light in this matter.
> I want to get and idea of what was or is an old true hardware UNIX
> terminal. I have searched google, but the word "terminal" associated
> with UNIX points most of the time to what we know today as UNIX shell.
> If someone, please, can show me a doc or explain a little bit what was
> a terminal at that moment back in time. I know that it was some kind
> of hardware, maybe RS232 related, used to connect to some main frame.
> But I am unable to find the details. I even lack some tech words to
> search deeper on the web.
> 
> Thank you.
> 
Maybe this will be of help: http://www.vt100.net/docs/vt220-rm/

OT: True hardware UNIX terminal

2016-03-29 Thread Mihai Popescu

Hello,

This question is somehow off topic but I know there are some readers
here old enough to shade some light in this matter.
I want to get and idea of what was or is an old true hardware UNIX
terminal. I have searched google, but the word "terminal" associated
with UNIX points most of the time to what we know today as UNIX shell.
If someone, please, can show me a doc or explain a little bit what was
a terminal at that moment back in time. I know that it was some kind
of hardware, maybe RS232 related, used to connect to some main frame.
But I am unable to find the details. I even lack some tech words to
search deeper on the web.

Thank you.

Re: OT: True hardware UNIX terminal

2016-03-29 Thread Otto Moerbeek

On Tue, Mar 29, 2016 at 02:20:35PM +0300, Mihai Popescu wrote:

> Hello,
> 
> This question is somehow off topic but I know there are some readers
> here old enough to shade some light in this matter.
> I want to get and idea of what was or is an old true hardware UNIX
> terminal. I have searched google, but the word "terminal" associated
> with UNIX points most of the time to what we know today as UNIX shell.
> If someone, please, can show me a doc or explain a little bit what was
> a terminal at that moment back in time. I know that it was some kind
> of hardware, maybe RS232 related, used to connect to some main frame.
> But I am unable to find the details. I even lack some tech words to
> search deeper on the web.
> 
> Thank you.

The word to search for is "teletype",

-Otto

Re: What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

2016-03-03 Thread Chris Cappuccio

Tinker [ti...@openmailbox.org] wrote:
> On 2016-02-28 05:26, Karel Gardas wrote:
> >Open firmware? What do you mean by that precisely?
> 
> Or just as little firmware as possible, just to minimize that as attack
> vector.
> 
> >Anyway, while asking such question it would also help if you tell
> >something about intended usage scenario of such box(es). fw?/app
> >server?/storage?/nas? etc.
> 
> Network infrastructure, so, among those categories it would be FW.
> 
> 
> What hardware is advisable here?
> 

PC Engines APU uses open source CoreBoot.

I wouldn't be surprised if the CoreBoot load still includes binary-only
support for AMD's remote management stuff (similar to Intel ME).

Re: What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

2016-02-28 Thread Christian Weisgerber

On 2016-02-28, Tinker  wrote:

>> Open firmware? What do you mean by that precisely?
>
> Or just as little firmware as possible, just to minimize that as attack 
> vector.

Remember that your brain architecture and firmware isn't open either.
Who knows what's hiding there.  Just looking at a random picture
on the Internet may open you up to a Langford hack.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

2016-02-27 Thread Tinker


On 2016-02-28 05:26, Karel Gardas wrote:

Open firmware? What do you mean by that precisely?


Or just as little firmware as possible, just to minimize that as attack 
vector.



Anyway, while asking such question it would also help if you tell
something about intended usage scenario of such box(es). fw?/app
server?/storage?/nas? etc.


Network infrastructure, so, among those categories it would be FW.


What hardware is advisable here?


On Sat, Feb 27, 2016 at 11:10 PM, Tinker  wrote:

Hi!

What's good PPC/MIPS/SPARC networking hardware with open firmware that 
works

well with OpenBSD?

Minimalistic for minimizing attack surface.

(Many ethernet ports would be a bonus. 1U rack mount would be a bonus. 
ECC

would be a bonus.)

Thanks!
Tinker

Re: What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

2016-02-27 Thread Karel Gardas

Open firmware? What do you mean by that precisely?

Anyway, while asking such question it would also help if you tell
something about intended usage scenario of such box(es). fw?/app
server?/storage?/nas? etc.

On Sat, Feb 27, 2016 at 11:10 PM, Tinker  wrote:
> Hi!
>
> What's good PPC/MIPS/SPARC networking hardware with open firmware that works
> well with OpenBSD?
>
> Minimalistic for minimizing attack surface.
>
> (Many ethernet ports would be a bonus. 1U rack mount would be a bonus. ECC
> would be a bonus.)
>
> Thanks!
> Tinker

What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

2016-02-27 Thread Tinker


Hi!

What's good PPC/MIPS/SPARC networking hardware with open firmware that 
works well with OpenBSD?


Minimalistic for minimizing attack surface.

(Many ethernet ports would be a bonus. 1U rack mount would be a bonus. 
ECC would be a bonus.)


Thanks!
Tinker

Re: Hardware compatibility

2016-02-16 Thread Gabriele Tozzi

> That was early on, but you should probably see NXE in the dmesg of all
> intel cpus these days.
>  
> [...]
> 
> I'm not certain I have tried exactly Pro 1000 PT Dual, but all intel gig
> dual cards
> I did try worked like a charm. I assume the quads work out nicely too.

The card arrived today and it worked out-of-the box.

I have now installed amd64 version and it has NXE enabled.

Thank you!

Gabriele Tozzi

-- 
GPG Key Fingerprint:
DAD1 E3E3 C3E9 36FB C570 F405 9B5F 7108 A1D0 2FFF

Re: Hardware compatibility (was: Hi There! I am trying to install OpenBSD)

2016-02-02 Thread Janne Johansson

2016-02-02 7:03 GMT+01:00 Gabriele Tozzi :

> Now, back to the topic, I kindly have two questions, to avoid mistakes
> of the past:
>
> 1. The CPU is and Intel Atom D425.
>The OpenBSD manual says that "Some Intel processors lack support
>for important PAE NX bit. But I couldn't find a list of them.
>Is there a way for me to check if this one supports W^X on amd64?
>

That was early on, but you should probably see NXE in the dmesg of all
intel cpus these days.


> 2. Unfortunately this board has only 1 network card, but I need at
>least 3. Having only 1 PCI-E slot available for expansion, I am
>forced to buy a many-in-one network card. Because of budget
>issues, I have narrowed my choice to:
>- Intel Pro 1000 PT dual
>- Intel Pro 1000 VT quad
>The PT variant is listed in the (em) module documentation, but with
>no explicit reference to the dual version. The VT is not listed at
>all,  but also it is not explicitly excluded.
>Does anyone had some good or bad experiences with those cards and
>OpenBSD?
>
>
I'm not certain I have tried exactly Pro 1000 PT Dual, but all intel gig
dual cards
I did try worked like a charm. I assume the quads work out nicely too.

-- 
May the most significant bit of your life be positive.

Hardware compatibility (was: Hi There! I am trying to install OpenBSD)

2016-02-01 Thread Gabriele Tozzi

I really wanted to install OpenBSD so, this morning I went back to the
shop and the kind guy accepted to replace the bugged motherboard with a
different one for a reasonable extra. This one is an overkill for my
needs (it has a 1.8Ghz 64bit atom CPU!!!), but good news: I've finally
managed to install OpenBSD.

It's amazing to see how everything fit in a bit more than 200Mb!

# df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd0a 1007M   42.3M914M 4%/
/dev/sd0d 1007M6.0K957M 0%/tmp
/dev/sd0e  7.9G164M7.3G 2%/usr
/dev/sd0f  7.9G2.6M7.5G 0%/var


Now, back to the topic, I kindly have two questions, to avoid mistakes
of the past:

1. The CPU is and Intel Atom D425.
   The OpenBSD manual says that "Some Intel processors lack support
   for important PAE NX bit. But I couldn't find a list of them.
   Is there a way for me to check if this one supports W^X on amd64?

2. Unfortunately this board has only 1 network card, but I need at
   least 3. Having only 1 PCI-E slot available for expansion, I am
   forced to buy a many-in-one network card. Because of budget
   issues, I have narrowed my choice to:
   - Intel Pro 1000 PT dual
   - Intel Pro 1000 VT quad
   The PT variant is listed in the (em) module documentation, but with
   no explicit reference to the dual version. The VT is not listed at
   all,  but also it is not explicitly excluded.
   Does anyone had some good or bad experiences with those cards and
   OpenBSD?

Thank you again

Gabriele

GPG Key Fingerprint:
DAD1 E3E3 C3E9 36FB C570 F405 9B5F 7108 A1D0 2FFF

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread Ben Alex

On Tue, Feb 2, 2016 at 5:19 AM, Tinker  wrote:
>  1) I need some SSD storage but don't like that it could break together - I
> mean, a bug in your system will feed your SSD at full bandwidth for ~7h-7
> days, it's completely fried - that's not OK, so putting a "redundance layer"
> in the from of an underlying magnet storage layer is really justified.
>
>  2) I need some bulk storage, and I want the terabytes to be really cheap so
> that i NEVER will run out of archival space. An 8TB magnet HDD costs in the
> range USD 500.

Last month I purchased another 400 TB of magnetic and SSD storage, so
with that recent research in mind:

* SSD models are differentiated by write endurance, interface
(SATA/SAS vs NVMe), and consumer vs data centre grade. The latter
offer continuous (24x7) workload latency guarantees and work well in
RAID configurations as there is minimal latency variability between
units. I'm unsure of the OpenBSD NVMe status, but you need NVMe if you
want to pull the rated ~2500 MB/sec out of NVMe units. Sticking with
SATA/SAS SSD means closer to 1/5th that maximum read performance,
although that may well be enough (and will save you a lot of money,
too). I'd avoid doing RAID with consumer grade SSDs if you have high
throughput expectations.

* Some magnetic drives are now also being rated with annual workload
limits and have associated warranty implications. See for example
http://www.seagate.com/au/en/products/enterprise-servers-storage/nearline-storage/.
Be careful to review the data sheets so you don't have future warranty
claims rejected.

I've found it's easy to KISS by grouping by file type (eg immutable or
mutable or append-only, sequentially accessed vs randomly accessed,
main reader bottleneck being CPU/RAM or IO etc) and putting them in
optimal primary and backup locations accordingly. I find the idea of
transparent storage tiers undesirable, as there's no way I can reason
about that and guarantee consistent throughput and latency results
(let alone how to recover when a few drives out of the 60+ fail, or a
non-JBOD controller dies).

Are you able to share more about your storage requirements (capacity,
sequential throughput, IO latency, resiliency, target chassis details
etc) so we can offer suggestions?

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread Adam Thompson

On 16-02-01 12:19 PM, Tinker wrote:

My purpose with asking for SSD-accelerated HDD was DOUBLE:

1) I need some SSD storage but don't like that it could break
together - I mean, a bug in your system will feed your SSD at full
bandwidth for ~7h-7 days, it's completely fried - that's not OK, so
putting a "redundance layer" in the from of an underlying magnet
storage layer is really justified.

...so what? I don't understand what your concern is here. If you buy a
batch of HDDs from the same lot, they'll probably all die around the
same time, too. I don't think I understand what you're trying to say.

If you're worried about SSD write endurance, I'd say... don't. Or buy
better-quality SSDs ;-).

See http://ssdendurancetest.com/ for real-world stress-test data.
Especially
http://ssdendurancetest.com/ssd-endurance-test-report/Intel-SSD-520-60.

The Intel DC P3700 series should last about 1.5yrs in an absolutely
worst-case scenario. Even the worst-case DC series I could find should
still last about a month and a half under murderous stress-test conditions.

http://estimator.intel.com/ssdendurance/

This report
(http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead)
confirms that even if you completely fill an SSD, that's no big deal.

If your application has a "bug" it's unlikely the sort of bug that would
fill the entire SSD, erase it all, fill it again, erase it all again,
etc... and most SSDs can handle ~3000 full-device writes nowadays.

Also remember to factor in the fact that UFS/UFS2 doesn't (usually)
saturate a block device with I/O write requests. Maybe if it was just
writing to a single enormous file it might, but could that actually
happen in your situation?

2) I need some bulk storage, and I want the terabytes to be really
cheap so that i NEVER will run out of archival space. An 8TB magnet
HDD costs in the range USD 500.

Here, I like it to be stored "symmetrically" with how I store the
other stuff, that is having separate disks, directories, mount points
etc. for the two doesn't really appeal to me in this particular case -

Simply knowing that the less frequently accessed data will be
taken from magnet and the more frequently accessed data from SSD seems
both convenient and practical for my usecase, and, I'll try to have
SSD volume to cover for *MORE THAN ALL* of my frequently stored data.

Perhaps knowing the prioritization algorithm as to be able to
calculate more closely what's in the SSD and what's on the HDD only
would make some sense, BUT, training it by telling it what's to load
fast using "cat `find the-relevant-data/` > /dev/null" single-shot and
perhaps via crontab, should deliver really well.

Cheap storage is a valid argument. HDD vs SSD is still easily an order
of magnitude difference in price.

So go run FreeNAS (or TrueNAS, or Solaris, or FreeBSD, or even
Linux...), run ZFS with both a L2ARC and ZIL device on fast SSD, and
remote-mount the directory. You even have a choice of protocols :-).
(NFS or iSCSI. I suspect you'd want to use NFS, but YMMV.)

Short answer: I don't think any part of OpenBSD does what you're asking,
natively. Some supported hardware devices (like the MegaRAID Cachecade,
et al.) do this for you. But at that point, what's the difference
between having the disks hooked up to some speciality hardware in an
OpenBSD box, versus having the disks hooked up to generic, not-special
hardware on a non-OpenBSD box? (Particularly given that UFS/UFS2 on
OpenBSD isn't exactly known for its award-winning performance in the
first place?)

FYI, even if Intel SRT was available on a Xeon board, you'd still be out
of luck, because it requires device driver support - it relies on the
Intel fake-raid technology which, IIRC, is not supported at all under
OpenBSD.

I'd also like to see something like this available in OpenBSD's VFS
layer, but I'm not holding my breath.

IIRC there was some interest in integrating Hammer/Hammer2 into OpenBSD
instead of ZFS due to licensing issues, but even Hammer2 doesn't appear
to have tiered storage in its feature list.

Some more random thoughts:
- the Dell H800 supports up to 1GB NVRAM, which is just a CacheCade
implementation.
- CacheVault is the newer version of CacheCade (AFAICT), and is
supported on newer MegaRAID cards. See
http://www.avagotech.com/products/server-storage/raid-controllers/cache-protection#overview
for some pretty skimpy info.
- moving your data from HDD to SSD isn't going to dramatically speed up
READ operations. Carefully examine the specsheets on both the HDDs and
SSDs and compare read bandwidths. Access time (latency) is where SSDs
are useful, along with acting as write-back caches.
- Areca raid controllers suppo

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread Tinker


On 2016-02-01 22:13, andrew fabbro wrote:
On Mon, Feb 1, 2016 at 8:16 AM, patric conant 


wrote:

Why can't the solution be all flash? $400 for 1 TB flash, * 7 sata 
ports on

a decent $100 Motherboard, gets you 7TB of flash for under $3000



Well, yes, and for a few hundred thousand you can get persistent DRAM
fusion-io.

OTOH, you can get 4TB SATA drives for $250.

The OP was just pointing out that SSD-acceleted (aka SSD-cached) 
SATA/SAS

is very common in Win/Lin/OSX and was wondering what the status is on
OpenBSD.



My purpose with asking for SSD-accelerated HDD was DOUBLE:

 1) I need some SSD storage but don't like that it could break together 
- I mean, a bug in your system will feed your SSD at full bandwidth for 
~7h-7 days, it's completely fried - that's not OK, so putting a 
"redundance layer" in the from of an underlying magnet storage layer is 
really justified.


 2) I need some bulk storage, and I want the terabytes to be really 
cheap so that i NEVER will run out of archival space. An 8TB magnet HDD 
costs in the range USD 500.


Here, I like it to be stored "symmetrically" with how I store the 
other stuff, that is having separate disks, directories, mount points 
etc. for the two doesn't really appeal to me in this particular case -


Simply knowing that the less frequently accessed data will be taken 
from magnet and the more frequently accessed data from SSD seems both 
convenient and practical for my usecase, and, I'll try to have SSD 
volume to cover for *MORE THAN ALL* of my frequently stored data.


Perhaps knowing the prioritization algorithm as to be able to 
calculate more closely what's in the SSD and what's on the HDD only 
would make some sense, BUT, training it by telling it what's to load 
fast using "cat `find the-relevant-data/` > /dev/null" single-shot and 
perhaps via crontab, should deliver really well.



Tinker

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread andrew fabbro

On Mon, Feb 1, 2016 at 8:16 AM, patric conant 
wrote:

> Why can't the solution be all flash? $400 for 1 TB flash, * 7 sata ports on
> a decent $100 Motherboard, gets you 7TB of flash for under $3000
>

Well, yes, and for a few hundred thousand you can get persistent DRAM
fusion-io.

OTOH, you can get 4TB SATA drives for $250.

The OP was just pointing out that SSD-acceleted (aka SSD-cached) SATA/SAS
is very common in Win/Lin/OSX and was wondering what the status is on
OpenBSD.

-- 
andrew fabbro
and...@fabbro.org

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread patric conant

On Sun, Jan 31, 2016 at 8:42 PM, Tinker  wrote:

> Patrick,
>
> On 2016-02-01 07:10, Patrick Dohman wrote:
>
>> There is some hardware solution, e.g. Intel made the
>>>
>>
>>
http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB04
>> 0LX using the "Nytro MegaRAID" chip.
>>
>>>
>>> Someone would need to port its driver to OpenBSD.
>>>
>>> Also in the past there was a "Adaptec MaxIQ". Those are the only two
>>> "Raid
>>>
>> controller cache" hardware solutions I am aware of, do you know any more?
>>
>>>
>>>
>>>
>>>
>> Some of the MegaRaid cards feature cache cade.
>>
>
> Do you know any MegaRaid that a) supports that, b) is modern and not
> archaic, and c) is supported by OpenBSD?
>
> Essentially disk cache is written to SSD before being âcopiedâ to
spinning
>> disk.
>>
>
> I was mostly considering read acceleration.
>
> (
>
>> Keep in mind DRAM based cache can improve performance when implemented in
>> conjunction with hardware write back.
>>
>
> Sure.
>
> Also magnetic disk & SSD with super cap / fault tolerant on disk cache can
>> seed up I/O significantly..
>>
>
> Can you give a practical example of this?
> )
>
> Thanks,
> Tinker
>
>
Why can't the solution be all flash? $400 for 1 TB flash, * 7 sata ports on
a decent $100 Motherboard, gets you 7TB of flash for under $3000

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread Janne Johansson

I saw it on a desktop, didn't think to see if it was ever used or not on
motherboards for other types of machines, I just assumed that Z68 could be
used on other places also.


2016-02-01 11:00 GMT+01:00 Tinker :

> On 2016-02-01 16:33, Janne Johansson wrote:
>
>> 2016-01-31 9:16 GMT+01:00 Tinker :
>>
>> This could be made in software with benefit, as a Softraid patch.
>>> So the frequently accessed stuff ends up cached on the SSD for faster
>>> read
>>> speed.
>>> There is some hardware solution, e.g. Intel made the
>>>
>>> http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB040LX
>>> using the "Nytro MegaRAID" chip.
>>> Also in the past there was a "Adaptec MaxIQ". Those are the only two
>>> "Raid
>>> controller cache" hardware solutions I am aware of, do you know any more?
>>>
>>>
>>> Intel Z68 motherboards also have this in hardware. A bit tiresome to set
>> up
>> for bootdrives (since the disk type changes from normal SATA to raid)
>> but should be transparent to the OS after it is set up.
>>
>
> Thanks for mentioning, however, this tech (called "Intel Smart Response")
> is a laptop/desktop thing only currently isn't it, you don't see it on any
> 1-2-4x Xeon:s at least now right?
>
>


-- 
May the most significant bit of your life be positive.

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread Tinker


On 2016-02-01 16:33, Janne Johansson wrote:

2016-01-31 9:16 GMT+01:00 Tinker :


This could be made in software with benefit, as a Softraid patch.
So the frequently accessed stuff ends up cached on the SSD for faster 
read

speed.
There is some hardware solution, e.g. Intel made the
http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB040LX
using the "Nytro MegaRAID" chip.
Also in the past there was a "Adaptec MaxIQ". Those are the only two 
"Raid
controller cache" hardware solutions I am aware of, do you know any 
more?



Intel Z68 motherboards also have this in hardware. A bit tiresome to 
set up

for bootdrives (since the disk type changes from normal SATA to raid)
but should be transparent to the OS after it is set up.


Thanks for mentioning, however, this tech (called "Intel Smart 
Response") is a laptop/desktop thing only currently isn't it, you don't 
see it on any 1-2-4x Xeon:s at least now right?

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-02-01 Thread Janne Johansson

2016-01-31 9:16 GMT+01:00 Tinker :

> This could be made in software with benefit, as a Softraid patch.
> So the frequently accessed stuff ends up cached on the SSD for faster read
> speed.
> There is some hardware solution, e.g. Intel made the
> http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB040LX
> using the "Nytro MegaRAID" chip.
> Also in the past there was a "Adaptec MaxIQ". Those are the only two "Raid
> controller cache" hardware solutions I am aware of, do you know any more?
>
>
Intel Z68 motherboards also have this in hardware. A bit tiresome to set up
for bootdrives (since the disk type changes from normal SATA to raid)
but should be transparent to the OS after it is set up.

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything


Patrick,

To sum up, neat to see that (from what we can see without having tested 
it,) there is (even inexpensive) hardware for this on the market, neat!



My last question related to this would be, what if drives start breaking 
down (storage or CacheCade drives), would the OpenBSD system learn to 
know somehow, is there any tool or would the MFI driver report it in the 
syslog?


(So you as admin will know and can go and shut it down and replace the 
broken drive.)





On 2016-02-01 11:14, Patrick Dohman wrote:

Do you know any MegaRaid that a) supports that, b) is modern and not

archaic, and c) is supported by OpenBSD?




It appears the MFI driver provides support for the MegaRAID SAS 9260-8i

Pleas note Iâ€™ve not tested the 9260-8i on openbsd

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/mfi.4
<http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/mfi.4>

My current understanding is that Cache Cade is licensed add-on for the 
9260-8i

that can be configured in the RAID bios.


Without having tried it myself, I share your understanding.

You buy a separate license that is distributed in the form of a tiny PCB 
that you mount on the controller card.



http://www.avagotech.com/products/server-storage/raid-controllers/megaraid-ca
checade-pro-software#specifications
<http://www.avagotech.com/products/server-storage/raid-controllers/megaraid-c
achecade-pro-software#specifications>

http://www.avagotech.com/products/server-storage/raid-controllers/megaraid-sa
s-9260-8i
<http://www.avagotech.com/products/server-storage/raid-controllers/megaraid-s
as-9260-8i>



I was mostly considering read acceleration.


Read Ahead caching is supported by the 9260-8i this essentially caches 
to
onboard DRAM contiguous blocks if the controllers algorithm determines 
they

will be needed.


What I see is that it will use the whole SSD for read acceleration.

BUT, the current version (that is CacheCadePro 2.0) only supports "512GB 
of CacheCade [i.e. read acceleration] per controller".


Luckily, 
http://docs.avagotech.com/docs-and-downloads/advanced-software/lsi-megaraid-cachecade-software/CacheCadePro2_TechBrief.pdf 
points out that an "upcoming release" will support ">2TB".


I emailed them and asked for clarification.





Can you give a practical example of this?
)


A RAID 10 with four disks running enterprise Intel SSD disk drives with
MegaRAID disk caching enabled, Essentially the Intel Enterprise SSD on 
board

cache augments the NAND flash. Fault tolerance is provided by a
â€œcapacitorâ€ that flushes the cache to disk after a power loss..


Right - and now we see that actual read acceleration of a magnet HDD 
using SSD is possible, that is what CacheCade is about.

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-01-31 Thread Patrick Dohman

> Do you know any MegaRaid that a) supports that, b) is modern and not
archaic, and c) is supported by OpenBSD?
>

It appears the MFI driver provides support for the MegaRAID SAS 9260-8i

Pleas note Iâve not tested the 9260-8i on openbsd

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/mfi.4


My current understanding is that Cache Cade is licensed add-on for the 9260-8i
that can be configured in the RAID bios.

http://www.avagotech.com/products/server-storage/raid-controllers/megaraid-ca
checade-pro-software#specifications


http://www.avagotech.com/products/server-storage/raid-controllers/megaraid-sa
s-9260-8i


>
> I was mostly considering read acceleration.

Read Ahead caching is supported by the 9260-8i this essentially caches to
onboard DRAM contiguous blocks if the controllers algorithm determines they
will be needed.

>
> Can you give a practical example of this?
> )

A RAID 10 with four disks running enterprise Intel SSD disk drives with
MegaRAID disk caching enabled, Essentially the Intel Enterprise SSD on board
cache augments the NAND flash. Fault tolerance is provided by a
âcapacitorâ that flushes the cache to disk after a power loss..

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything


Patrick,

On 2016-02-01 07:10, Patrick Dohman wrote:

There is some hardware solution, e.g. Intel made the

http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB04
0LX using the "Nytro MegaRAID" chip.


Someone would need to port its driver to OpenBSD.

Also in the past there was a "Adaptec MaxIQ". Those are the only two 
"Raid
controller cache" hardware solutions I am aware of, do you know any 
more?






Some of the MegaRaid cards feature cache cade.


Do you know any MegaRaid that a) supports that, b) is modern and not 
archaic, and c) is supported by OpenBSD?


Essentially disk cache is written to SSD before being “copied” to 
spinning

disk.


I was mostly considering read acceleration.

(
Keep in mind DRAM based cache can improve performance when implemented 
in

conjunction with hardware write back.


Sure.

Also magnetic disk & SSD with super cap / fault tolerant on disk cache 
can

seed up I/O significantly..


Can you give a practical example of this?
)

Thanks,
Tinker

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-01-31 Thread Patrick Dohman

> There is some hardware solution, e.g. Intel made the
http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB04
0LX using the "Nytro MegaRAID" chip.
>
> Someone would need to port its driver to OpenBSD.
>
> Also in the past there was a "Adaptec MaxIQ". Those are the only two "Raid
controller cache" hardware solutions I am aware of, do you know any more?
>
>
>

Some of the MegaRaid cards feature cache cade.

Essentially disk cache is written to SSD before being “copied” to spinning
disk.

Keep in mind DRAM based cache can improve performance when implemented in
conjunction with hardware write back.

Also magnetic disk & SSD with super cap / fault tolerant on disk cache can
seed up I/O significantly..

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

2016-01-31 Thread Karel Gardas

IMHO it's for misc.

So, yes, feel free to donate to either OpenBSD foundation or directly
to interested developer. I'm sure your donation will be appreciated.

In your list you omitted two other options how to speed your hdd access:

- buy more RAM and increase caching, on AMD64 it would probably need
to use IOMMU so either new development or resurrection of this from
the past would be needed. This should help you with read.

- sponsor WAPBL enhancements to support data logging and external
journal. This should speed your write access.

If you are interested in softraid, then perhaps some funding of fixes
which would allow running several softraid drives on top of another
would be great way to reuse your specific caching softraid discipline
with whatever softraid OpenBSD supports now.

And do not forget that development takes time so I would strongly
recommend you to contact OpenBSD foundation just on Monday morning and
send them your money contribution with a plea for work -- especially
if you like to use that in 12 month timeframe in production
environment.

On Sun, Jan 31, 2016 at 12:45 PM, Tinker  wrote:
> Ah, I now understand that this problem is mindbogglingly complex because of
> tons and tons of work needed to make it work, including the storage format
> on the SSD cache, and tools for "fsck":ing it etc etc. In a way that maybe
> answered my question, thanks!
>
>
>
> On 2016-01-31 19:00, Tinker wrote:
>>
>> If there is nothing like this implemented in software in OpenBSD,
>>
>>  * If someone implemented it, would there be interest to actually
>> include the patch in OpenBSD?
>>
>>  * Could a direct personal donation (separate from the normal
>> donations to the OpenBSD project) to a developer be of use for making
>> this happen, if so how big a donation, of what value would USD 1,000
>> be in proportion?
>>
>>Not sure right now but next 12 months I could consider this, if you
>> have any ideas about who feel free to respond or PM or anything you
>> like.
>>
>>
>>
>> On 2016-01-31 16:16, Tinker wrote:
>>>
>>> This could be made in software with benefit, as a Softraid patch.
>>>
>>> So the frequently accessed stuff ends up cached on the SSD for faster
>>> read speed.
>>>
>>>
>>> ZFS on FreeBSD etc. does it in its "ARC"/"ARC2L" feature?
>>>
>>>
>>> There is some hardware solution, e.g. Intel made the
>>>
>>> http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB040LX
>>> using the "Nytro MegaRAID" chip.
>>>
>>> Someone would need to port its driver to OpenBSD.
>>>
>>> Also in the past there was a "Adaptec MaxIQ". Those are the only two
>>> "Raid controller cache" hardware solutions I am aware of, do you know
>>> any more?
>>>
>>>
>>>
>>> (Was not sure if this belonged on tech@ or misc@, any clarification
>>> for me to never more crosspost please let me know)

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything

Ah, I now understand that this problem is mindbogglingly complex because 
of tons and tons of work needed to make it work, including the storage 
format on the SSD cache, and tools for "fsck":ing it etc etc. In a way 
that maybe answered my question, thanks!



On 2016-01-31 19:00, Tinker wrote:

If there is nothing like this implemented in software in OpenBSD,

 * If someone implemented it, would there be interest to actually
include the patch in OpenBSD?

 * Could a direct personal donation (separate from the normal
donations to the OpenBSD project) to a developer be of use for making
this happen, if so how big a donation, of what value would USD 1,000
be in proportion?

   Not sure right now but next 12 months I could consider this, if you
have any ideas about who feel free to respond or PM or anything you
like.



On 2016-01-31 16:16, Tinker wrote:

This could be made in software with benefit, as a Softraid patch.

So the frequently accessed stuff ends up cached on the SSD for faster
read speed.


ZFS on FreeBSD etc. does it in its "ARC"/"ARC2L" feature?


There is some hardware solution, e.g. Intel made the
http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB040LX
using the "Nytro MegaRAID" chip.

Someone would need to port its driver to OpenBSD.

Also in the past there was a "Adaptec MaxIQ". Those are the only two
"Raid controller cache" hardware solutions I am aware of, do you know
any more?



(Was not sure if this belonged on tech@ or misc@, any clarification
for me to never more crosspost please let me know)

Re: Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything


If there is nothing like this implemented in software in OpenBSD,

 * If someone implemented it, would there be interest to actually 
include the patch in OpenBSD?


 * Could a direct personal donation (separate from the normal donations 
to the OpenBSD project) to a developer be of use for making this happen, 
if so how big a donation, of what value would USD 1,000 be in 
proportion?


   Not sure right now but next 12 months I could consider this, if you 
have any ideas about who feel free to respond or PM or anything you 
like.




On 2016-01-31 16:16, Tinker wrote:

This could be made in software with benefit, as a Softraid patch.

So the frequently accessed stuff ends up cached on the SSD for faster
read speed.


ZFS on FreeBSD etc. does it in its "ARC"/"ARC2L" feature?


There is some hardware solution, e.g. Intel made the
http://ark.intel.com/products/70029/Intel-RAID-SSD-Cache-Controller-RCS25ZB040LX
using the "Nytro MegaRAID" chip.

Someone would need to port its driver to OpenBSD.

Also in the past there was a "Adaptec MaxIQ". Those are the only two
"Raid controller cache" hardware solutions I am aware of, do you know
any more?



(Was not sure if this belonged on tech@ or misc@, any clarification
for me to never more crosspost please let me know)

Can I accelerate my magnet HDD using a SSD in any way?? E.g. softraid patch/ARC, dedicated hardware e.g. Intel RCS25ZB040LX="Nytro MegaRAID", anything