still loosing connections
Hi misc@!
I run OpenBSD-{amd64,i386}-current for several years now on 3 machines,
having reinstalled everything late this summer because s.th. related to
either adsuck, ftp, cvs, pf or the netstack in general feels broken.
I have complained before in the last weeks but unfortunatelly the
usually reliable strategy shut up - the devs know already -
use the next shnapshot seems to be not really successfull this time...
Let me describe what I am doing and what happens (the laptop being
idefix @ 192.168.178.31):
Running -current I try to use the latest snapshot, being ~amd64 #477
from yesterday (dmesg below). This is how I do it:
#!/bin/sh
#
print Laufwerk wechseln
cd /home/user/Downloads/amd64/
print Dateien loeschen
rm *
print Dateien neu holen
#wget
ftp://openbsd.cs.fau.de/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
#wget
ftp://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
#wget ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/{IN*,SHA*,bsd*,*tgz}
wget http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/INSTALL.amd64
wget http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/SHA256{,.sig}
wget http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/bsd{,.rd,.mp}
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/{base,comp,game,man}56.tgz
wget
http://ftp.hostserver.de/pub/OpenBSD/snapshots/amd64/x{base,font,serv,share}56.tgz
print Altes /bsd.rd sichern
sudo cp /bsd.rd /bsd.rd.1
print Neues /bsd.rd kopieren
sudo cp -p bsd.rd /
print Neues bsd.mp als /bsd kopieren
sudo cp -p bsd.mp /bsd
print /usr RW mounten
sudo mount -uw /usr
print untar xfonts
sudo tar -C / -xzphf xfont*.tgz
print untar xserv
sudo tar -C / -xzphf xserv*.tgz
print untar xshare
sudo tar -C / -xzphf xshare*.tgz
print untar man
sudo tar -C / -xzphf man*.tgz
print untar comp
sudo tar -C / -xzphf comp*.tgz
print untar xbase
sudo tar -C / -xzphf xbase*.tgz
print untar base
sudo tar -C / -xzphf base*.tgz
print run sysmerge
sudo sysmerge
print mount /usr RO
sudo mount -ur /usr
cd
I switched to the http-protocol because of the issue desribed below
though it didn't help.
After updating the snapshot I _always_ update the apps and sources like so:
#!/bin/sh
#
cd /tmp
sudo mount -uw /usr
print /usr/src updaten
cd /usr/src
sudo cvs -q up -Pd
print /usr/xenocara updaten
cd /usr/xenocara
sudo cvs -q up -Pd
print /usr/ports updaten
cd /usr/ports
sudo cvs -q up -Pd
cd
print packages updaten
sudo pkg_add -ui
print locate-db updaten
sudo /usr/libexec/locate.updatedb
sudo mount -ur /usr
So my guess is that my system is up2date. Except that since several
weeks now both scripts suffer from the same shortcomming:
After some (non repeatable) time the network looses it's connection. Not
always, but way too often. And it doesn't matter if I
am at home wired or travelling using the mobile or the hotel-wlan. It
doesn't matter which mirror I use.
Simplyfying the observation it seems that the very moment the load
increases the connection decreases to zero.
I have gkrellm running at the side showing the network performance. So
please be patient with me as I have no scientifically
valid test data - only visual observation: The system is getting the
fresh data, at first at an acceptabel pace (e.g. 800 KB/s)
but then quickly gets slower and slower until connection to the net is
entirely lost. Not only ftp but http as well. Please do not get mislead
by the fact that
/var/log/messages mentions adsuck - without the behaviour is the same:
~ $ tail -f /var/log/messages
Oct 25 23:28:28 idefix /bsd: drm: PCIE GART of 512M enabled (table at
0x0004).
Oct 25 23:28:28 idefix /bsd: radeondrm0: 1400x1050
Oct 25 23:28:28 idefix /bsd: wsdisplay0 at radeondrm0 mux 1: console
(std, vt100 emulation), using wskbd0
Oct 25 23:28:28 idefix /bsd: wskbd1: connecting to wsdisplay0
Oct 25 23:28:28 idefix /bsd: wsdisplay0: screen 1-5 added (std, vt100
emulation)
Oct 25 23:28:44 idefix savecore: no core dump
Oct 25 23:29:09 idefix apmd: battery status: high. external power
status: connected. estimated battery life 100%
Oct 25 23:30:09 idefix sensorsd[12040]: acpithinkpad0.temp5: marked invalid
Oct 25 23:30:09 idefix sensorsd[12040]: acpithinkpad0.temp7: marked invalid
Oct 25 23:30:09 idefix sensorsd[12040]: acpidock0.indicator0: Off, UNKNOWN
Oct 25 23:35:50 idefix sensorsd[12040]: cpu0.temp0: exceeds limits:
75.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: cpu1.temp0: exceeds limits:
75.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: acpitz0.temp0: exceeds limits:
85.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: acpitz1.temp0: exceeds limits:
86.00 degC is above 70.00 degC
Oct 25 23:35:50 idefix sensorsd[12040]: acpithinkpad0.temp0: exceeds
limits: 85.00 degC is above 70.00 degC
Oct 25 23:38:06 idefix ntpd[22421]: 2 out of 4 peers valid
Oct 25 23:38:06 idefix ntpd[22421]: bad peer from pool pool.ntp.org
(213.95.21.43)
Oct 25 23:38:06 idefix ntpd[22421]: bad peer from pool pool.ntp.org
Re: mutt and gmail
Dmitrij D. Czarkoff, 25 Oct 2014 22:21: FWIW I use mbsync (from mail/isync) to sync Gmail to local maildir, and have my mutt set up to work in maildir only. I set up cron to call mbsync on schedule, and I from then I totally forgot about the crappiness of Gmail's IMAP interface. thanks for the tip. i got a couple of other tips off-list, all describing some offline sync, fetchmail and other solutions, which are fine. however mutt is seen as a fine gmail and/or imap client and i would normally take this to the mutt mailing list (obviously). without full debugging it is not possible to know which component is failing in the chain. it's just that there is a lot of ongoing work on SSL in openbsd, so i thought i might bring it up here as the error message specifically mentioned SSL. -f -- smile, its the second best thing you can do with your lips.
panic: ffs_blkfree: bad size
memtest did not reveal errors. unfortunately i got another panic, during some routine file operations. (after the 2 previous panics, fsck required manual running, and even multiple runs, so maybe this one is choking on fsck's best efforts, i dont know.) savecore: reboot after panic: ffs_blkfree: bad size savecore: system went down at Sun Oct 26 12:26:47 2014 savecore: writing core to /var/crash/bsd.2.core savecore: writing kernel to /var/crash/bsd.2 # gdb (gdb) file /var/crash/bsd.2 Reading symbols from /var/crash/bsd.2...(no debugging symbols found)...done. (gdb) target kvm /var/crash/bsd.2.core #0 0xd0557603 in boot () (gdb) where #0 0xd0557603 in boot () #1 0xd03bbba6 in reboot () #2 0xd037cdd2 in db_boot_dump_cmd () #3 0xd037d4a4 in db_command () #4 0xd037d6ec in db_command_loop () #5 0xd03818da in db_trap () #6 0xd0553c1b in kdb_trap () #7 0xd05643b7 in trap () #8 0xd0200b31 in alltraps () #9 0xd0553937 in Debugger () #10 0xd03ca2c1 in panic () #11 0xd04c98d4 in ffs_blkfree () #12 0xd04d1249 in ffs_indirtrunc () #13 0xd04d26d9 in ffs_truncate () #14 0xd04e3bb3 in ufs_inactive () #15 0xd03f8814 in VOP_INACTIVE () #16 0xd03f14ce in vput () #17 0xd04e8f05 in ufs_remove () #18 0xd03f84a9 in VOP_REMOVE () #19 0xd03f5a14 in dounlinkat () #20 0xd03f5ada in sys_unlink () #21 0xd0563dd4 in syscall () #22 0xd0200bf3 in Xsyscall () #23 0xf5cf4fa8 in ?? () #24 0x005b in ?? () #25 0x0063 in ?? () #26 0x0033 in ?? () #27 0x0033 in ?? () #28 0x814a2c80 in ?? () #29 0x841844f0 in ?? () #30 0xcfbd2248 in ?? () #31 0x37944cb4 in ?? () #32 0x37938aba in ?? () #33 0x0028 in ?? () #34 0x000a in ?? () #35 0x0003 in ?? () #36 0x0002 in ?? () #37 0x08b08735 in ?? () #38 0x002b in ?? () #39 0x00200257 in ?? () #40 0xcfbd221c in ?? () #41 0x0033 in ?? () #42 0x in ?? () -f -- go and catch a falling star...
Re: The Book of PF, 3rd ed: You own the first author signed copy and support OpenBSD!
On Sat, Oct 25, 2014 at 11:23:38PM -0400 or thereabouts, Michael W. Lucas wrote: MY auction raised $1145. There is no way that BoPF3 can POSSIBLY raise more than that! Consider the gauntlet thrown. Nice one Michael! :-)
64-bit amd64 : actual memory limitations?
64-bit supposedly supports upto 16 exabytes of memory ('ram').
would such large capacities actually be possible to ue with
openbsd for amd64 architecture?
use-case: working with large in-memory storage for financial applications.
thanks.
Re: 64-bit amd64 : actual memory limitations?
2014-10-26 20:02 GMT+01:00 Mayuresh Kathe mayur...@devio.us:
64-bit supposedly supports upto 16 exabytes of memory ('ram').
Current hardware supports only 2^48...
https://en.wikipedia.org/wiki/X86-64#Physical_address_space_details
Best
Martin
crypto softraid and keydisk on same harddrive
Hello, I have a usecase for full disk encryption using softraid where the keydisk is placed on the same harddrive as the encrypted partition. This is not for protecting data on the drive in case it gets stolen, but rather to allow for a quick way of making the data unrecoverable (by destroying the keydisk and rebooting). I am not sure this is even supposed to work, but I have now been trying to make this work for a few hours and am getting pretty strange results. I am currently testing this on a virtual machine which when booted into the installer has a single physical drive: wd0. The way i have been going about this is to start the installer, directly drop to a shell and then do the following: # fdisk -iy wd0 # disklabel -E wd0 Create the following partitions (in this order to make the biggest partition last): wd0b (swap) wd0d (RAID) - keydisk (1M) wd0a (RAID) - the remaining part of the drive that will be encrypted. # bioctl -c C -l /dev/wd0a -k /dev/wd0d softraid0 After this sd0 is created, and i exit back to the installer where i select install and answer all the questions as usual. When it asks for a drive I give it sd0, and use the automatic partition layout inside sd0. Everything looks good at this point, but when rebooting the bootloader stops with the following message: === Using drive 0, partition 3. Loading. ERR M === If I boot back into the the installer at this point sd0 appears automatically, so even while the bootloader does not like what it finds, the softraid crypto device is able to assemble itself like it is supposed to. This is where it gets really funky. I _have_ been able to get it to work using the following schema: #1. Install the system with only wd0b (swap) and wd0a (RAID) using a passphrase. #2. Reinstall the system and modify the disklabel to look like: wd0b (swap), wd0d (RAID, 1M), wd0a. (Like my original plan). When I do this the system manages to boot without a passphrase, using the encrypted drive. It feels to me like the key is that in the above order, the keydisk (wd0d) will align to the where wd0a with the passphrase was originally. As if there are some remains that makes it possible for the bootloader to locate it or something (that is not overwritten when it is used as the target for the -k argument. Any input on this would be greatly appreaciated! Regards, Patrik Lundin
Re: 64-bit amd64 : actual memory limitations?
On Sun, Oct 26, 2014 at 12:02 PM, Mayuresh Kathe mayur...@devio.us wrote:
64-bit supposedly supports upto 16 exabytes of memory ('ram').
would such large capacities actually be possible to ue with
openbsd for amd64 architecture?
use-case: working with large in-memory storage for financial applications.
Currently, in the amd64 pmap we only allocate a single PML4 slot for
the 'direct' map, limiting the system to 512GB of physical memory.
Multiplying that by a factor of 4 or even 64 would be easy, but
lacking someone actually planning to *use and test* that it just
hasn't been seen as worth the effort to do, verify the change in kva
layout doesn't break some hidden assumption, etc. (IIRC, dlg@ did
this once just to get a dmesg from a 2TB machine going to other,
non-OpenBSD use.)
There's an upper limit to that growth: there's only 256 PML4 slots for
kva, from which this comes, so at some point the kva remaining for
normal use and management would shrink too much and the whole pmap
would need to be rethought...
Philip Guenther
Re: panic: ffs_blkfree: bad size
On Sun, Oct 26, 2014 at 7:27 AM, frantisek holop min...@obiit.org wrote: memtest did not reveal errors. unfortunately i got another panic, during some routine file operations. (after the 2 previous panics, fsck required manual running, and even multiple runs, so maybe this one is choking on fsck's best efforts, i dont know.) savecore: reboot after panic: ffs_blkfree: bad size From the backtrace, either a bogus block number ended up in a single-indirect block, or the filesystem superblock was corrupted. Or something is scrambling memory. I think you're correct that this filesystem has been damaged by whatever memory corruption you've been experiencing beyond the point fsck handles. Time to backup, newfs, reinstall and restore. And if you're still seeing memory corruptions then maybe roll back to a version that didn't experience those and see if you can bisect to whatever change caused the problem. Philip Guenther
Wireless PCIe (Host AP mode) recommendations
Hey List, I am planning a new router / firewall / Wifi AP based on the Supermicro SYS-5015A-EHF-D525 (http://www.newegg.ca/Product/Product.aspx?Item=N82E16816101364) and was hoping that I could get some feedback on PCIe wifi cards. After going over the wireless FAQ and then doing some research, I was planning to use either one of these cards: Rosewill RNX-N150PCe (http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166047) - Up to 150Mbps - Atheros AR9285 - Supported by athn http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/athn.4 Rosewill RNX-G300LX (http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166021) - Up to 54Mbps - Chipset RaLink RT2561/RT61 - Supported by ral http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ral.4?query=ralsec=4 Am I correct that these are both supported by OpenBSD? Has anyone used these in Host AP mode? Does anyone have other PCIe wifi cards that support Host AP mode they can recommend? Thanks! Gord. -- http://gordonturner.ca
Re: Wireless PCIe (Host AP mode) recommendations
2014-10-26 22:31 GMT+01:00 Gordon Turner tur...@ftn.net: Rosewill RNX-G300LX (http://www.newegg.ca/Product/Product.aspx?Item=N82E16833166021) - Up to 54Mbps - Chipset RaLink RT2561/RT61 - Supported by ral http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ral.4?query=ralsec=4 That's PCI, not PCIe. Best Martin
Re: 64-bit amd64 : actual memory limitations?
From owner-misc+m143...@openbsd.org Sun Oct 26 15:47:12 2014
X-Original-To: mayur...@devio.us
Delivered-To: mayur...@devio.us
X-Virus-Scanned: amavisd-new at devio.us
Authentication-Results: wolfman.devio.us (amavisd-new);
dkim=fail (2048-bit key) reason=fail (message has been
altered)
header.d=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com;
s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type; bh=g+b9WM1CHoZgRIbDTtcEW+4ffYsNrMcqe+SrsRYpK/8=;
b=hMD+OY1qyIjx4CP//oXSjRlmPc2Z+rpmcBDINqlN9i6n9RHvbamV8lb3PmP9eWiWd7
nt1L2gydz/BZtfzWnqgYvnCGfqA9us8DBYyAltXbol2zvWwdi+yfcqYeV0PWnrzcRhV2
YS/He3hh98UzS5hvVK1GiBGUIX0MFoYGjVTXyIiFwxN8dLf2pSPb/fJHm7O0LmkD9sP2
3/NUjbLECwtjCIm05fq9HWzajbYWoPWboWxEqWVqwzGB1KARPA51dpWPt4ZymKKkPZUe
WG54UyeW3yIqfpB1ESYmdzVh8MzY1ORC72htySEaJArIsOUEOxvm5OdfnYRgmJLHSUUe ZdYQ==
MIME-Version: 1.0
X-Received: by 10.182.33.138 with SMTP id
r10mr2529167obi.67.1414352746570; Sun, 26 Oct 2014 12:45:46 -0700 (PDT)
References: 20141026190245.b09d21b5...@wolfman.devio.us
X-Google-Sender-Auth: IKmvhqt48rk7l4iDtc9vhUAcBew
Subject: Re: 64-bit amd64 : actual memory limitations?
From: =?UTF-8?Q?Martin_Schr=C3=B6der?= mar...@oneiros.de
To: Mayuresh Kathe mayur...@devio.us
Cc: misc@openbsd.org
Content-Type: text/plain; charset=UTF-8
List-Help: mailto:majord...@openbsd.org?body=help
List-ID: misc.openbsd.org
List-Owner: mailto:owner-m...@openbsd.org
List-Post: mailto:misc@openbsd.org
List-Subscribe: mailto:majord...@openbsd.org?body=sub%20misc
List-Unsubscribe: mailto:majord...@openbsd.org?body=unsub%20misc
X-Loop: misc@openbsd.org
Precedence: list
Sender: owner-m...@openbsd.org
2014-10-26 20:02 GMT+01:00 Mayuresh Kathe mayur...@devio.us:
64-bit supposedly supports upto 16 exabytes of memory ('ram').
Current hardware supports only 2^48...
https://en.wikipedia.org/wiki/X86-64#Physical_address_space_details
Best
Martin
if the intended application actually requires larger memory to be
accessible, would it be better to go for a non-x86-64 64-bit hardware?
if yes, could you please recommend something easily available?
and yes, i would really prefer it being supported by openbsd.
thanks.
Re: 64-bit amd64 : actual memory limitations?
From guent...@gmail.com Sun Oct 26 17:01:26 2014
X-Original-To: mayur...@devio.us
Delivered-To: mayur...@devio.us
X-Virus-Scanned: amavisd-new at devio.us
Authentication-Results: wolfman.devio.us (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=Y1DSnnU9Wt7FwAio1jfk5gZlL2jKuJHPCCViFatjQ70=;
b=QGMPBl8DVLa7kSfBRI1pTbf0edQnJ8VAwk3s3vDKeXKBR9LTLzJ63504oLMcqdVDYy
aC9ABaVEoT+K3LE31Gh1aJs5xIcfUgfznIWB3jgm8AzBXtsWET6eN5M0qDsuf8l9vy8j
WoPgIQs1rag8xEALXfc0TgBS6lu6EYEPNxQJ6+gepqkhJkr/FZpPsBaz1DKJ7Yusk6Ip
Hr/6QTjDnha2DAPeIEle7bpCYBnpQw5lFIYW1B/EhpAGYQnqLHl40NyQFCZwN1ohV4Nj
Xa5t/cNwJwDLte70c+aVrpc+FA8TbzxJu1AdwoNvNkXISfb4R9c3ZUG1+4LekbHWisjL
LBXg==
MIME-Version: 1.0
X-Received: by 10.107.164.129 with SMTP id
d1mr18706558ioj.37.1414357262671;
Sun, 26 Oct 2014 14:01:02 -0700 (PDT)
References: 20141026190245.b09d21b5...@wolfman.devio.us
Subject: Re: 64-bit amd64 : actual memory limitations?
From: Philip Guenther guent...@gmail.com
To: Mayuresh Kathe mayur...@devio.us
Cc: OpenBSD misc misc@openbsd.org
Content-Type: text/plain; charset=UTF-8
On Sun, Oct 26, 2014 at 12:02 PM, Mayuresh Kathe mayur...@devio.us
wrote:
64-bit supposedly supports upto 16 exabytes of memory ('ram').
would such large capacities actually be possible to ue with
openbsd for amd64 architecture?
use-case: working with large in-memory storage for financial
applications.
Currently, in the amd64 pmap we only allocate a single PML4 slot for
the 'direct' map, limiting the system to 512GB of physical memory.
Multiplying that by a factor of 4 or even 64 would be easy, but
lacking someone actually planning to *use and test* that it just
hasn't been seen as worth the effort to do, verify the change in kva
layout doesn't break some hidden assumption, etc. (IIRC, dlg@ did
this once just to get a dmesg from a 2TB machine going to other,
non-OpenBSD use.)
There's an upper limit to that growth: there's only 256 PML4 slots for
kva, from which this comes, so at some point the kva remaining for
normal use and management would shrink too much and the whole pmap
would need to be rethought...
Philip Guenther
thanks for the details, but, since i am nowhere close to being a
systems programmer, would like to know if there's any chance such
support might be added in, in the near future?
thanks.
Re: 64-bit amd64 : actual memory limitations?
On Sun, Oct 26, 2014 at 12:02 PM, Mayuresh Kathe mayur...@devio.us wrote:
64-bit supposedly supports upto 16 exabytes of memory ('ram').
would such large capacities actually be possible to ue with
openbsd for amd64 architecture?
use-case: working with large in-memory storage for financial applications.
Check for my posts from October or November of last year for dmesg of
machine with 256 GB or RAM and 64 CPUs which ended as a computing node
running Red Hat. I have several computing nodes with 512 GB or RAM in
the lab running Red Hat. if any of them crashes I will use live USB and
send dmesg.
Predrag
Re: unknown ethernet: intel dual-port gig copper
Jim Rowan [j...@computing.com] wrote: That's really odd... I cut/paste that line directly from the serial console.. I don't know how it got to be showing 0x8096 instead of 0x8086. Sorry for the false alarm! (I'll still have to track down what's wrong with flashrd... as I want to use it.) Growing the GENERIC kernel (such as by adding a ramdisk) can write beyond the intended area. Raising NKPTP on i386 isn't always enough. I don't understand the problem well enough to provide an immediate solution. It has been a while since I've seen problems on i386 or amd64, but GENERIC keeps getting bigger :) Chris
Re: 64-bit amd64 : actual memory limitations?
On Sun, Oct 26, 2014 at 5:59 PM, Mayuresh Kathe mayur...@devio.us wrote: ... thanks for the details, but, since i am nowhere close to being a systems programmer, would like to know if there's any chance such support might be added in, in the near future? You're asking whether in the near future we'll add support for amd64 machines with 2^64 bytes of memory, machines which don't even exist? Nope, not in the near future. Philip Guenther
Re: 64-bit amd64 : actual memory limitations?
From owner-misc+m143...@openbsd.org Sun Oct 26 22:06:49 2014 X-Original-To: mayur...@devio.us Delivered-To: mayur...@devio.us X-Virus-Scanned: amavisd-new at devio.us Authentication-Results: wolfman.devio.us (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sEri+l1iSWKQ4TcoPVtDy6sxUagGso7gqORGN8Zm42s=; b=de/KKfiBVqLr0Xrl0wdQIe8ew6yV/WbS8iquSLlJN2lioNTEgheHjVxvbc4EJg43po pfHyhEguTOzpDxNKC9sDADQ92AWUaCtAhvQ3mrgl51snD5br6nBFBu2hqg+ulxoSf9tt NxQW1ZDYAAhXKx3NFpm6e5ftd3dTUFrl6KRT63a91su2fYu+pjykyPak0wvkb74cPJcM Vz1rfF4hVBIf5w6FgOn2HJVRWR2RlhM9J1MchN6D3z6hISmmpcNmPBI9tou8gLR4VrGP +HqLIpp3D2H118T00VFkyQ3R2ZFISqA1XBkdh/f/0qNdiRg785BETz5W7sXlccxMejJX wRZA== MIME-Version: 1.0 X-Received: by 10.107.136.169 with SMTP id s41mr8262068ioi.36.1414375526232; Sun, 26 Oct 2014 19:05:26 -0700 (PDT) References: 20141027005944.b2fb81b5...@wolfman.devio.us Subject: Re: 64-bit amd64 : actual memory limitations? From: Philip Guenther guent...@gmail.com To: Mayuresh Kathe mayur...@devio.us Cc: OpenBSD misc misc@openbsd.org Content-Type: text/plain; charset=UTF-8 List-Help: mailto:majord...@openbsd.org?body=help List-ID: misc.openbsd.org List-Owner: mailto:owner-m...@openbsd.org List-Post: mailto:misc@openbsd.org List-Subscribe: mailto:majord...@openbsd.org?body=sub%20misc List-Unsubscribe: mailto:majord...@openbsd.org?body=unsub%20misc X-Loop: misc@openbsd.org Precedence: list Sender: owner-m...@openbsd.org On Sun, Oct 26, 2014 at 5:59 PM, Mayuresh Kathe mayur...@devio.us wrote: ... thanks for the details, but, since i am nowhere close to being a systems programmer, would like to know if there's any chance such support might be added in, in the near future? You're asking whether in the near future we'll add support for amd64 machines with 2^64 bytes of memory, machines which don't even exist? Nope, not in the near future. Philip Guenther apologies for being such a spaaz. i just missed the point that the currently available amd64 hardware itself doesn't support 2^64 bytes of memory. :) thanks for responding.
Re: 64-bit amd64 : actual memory limitations?
2014-10-27 1:56 GMT+01:00 Mayuresh Kathe mayur...@devio.us: if the intended application actually requires larger memory to be accessible, would it be better to go for a non-x86-64 64-bit hardware? 256TB (2^48) should be good enough till 2020.
Re: 64-bit amd64 : actual memory limitations?
From owner-misc+m143...@openbsd.org Sun Oct 26 22:22:57 2014 X-Original-To: mayur...@devio.us Delivered-To: mayur...@devio.us X-Virus-Scanned: amavisd-new at devio.us Authentication-Results: wolfman.devio.us (amavisd-new); dkim=fail (2048-bit key) reason=fail (message has been altered) header.d=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=GC1Vko0XAF6MuhMIbP8y5QLmaRAvLR5H0N6fPxvMr4M=; b=i/jfX6mzyrvK45i7yXEvlqGgLlLU5r31gpaARg1avnJcviDDmRMjJV9qEp0cbZZsmX 4veHMISAhNAM2ABChH5m84wSVqkmAZxmffl8a3Xj7fnWDSWboSWvPtWpoZwVp6FKYT3a 6v1XuIn+WMkdTKjTwb9jSYRzg88HnkrkGxlQMAuSY5uB6MqsO0jqGLyxuO604UgKnfdw cFrZfPjyAiiHt5VVO/7YMRlWzq/6GAyCFRyA9LcSv170KPnNIi5dPqLASNGrwvVqXUsZ dW0kTF8qxmqnJxeYYxm0BH4s7KPMZ8+IvN1zA9RcjXnmIGtEEi94pCR5nbj9OwwcG3xJ g4dw== MIME-Version: 1.0 X-Received: by 10.202.185.139 with SMTP id j133mr16754802oif.25.1414376481358; Sun, 26 Oct 2014 19:21:21 -0700 (PDT) References: 20141027005634.3416a1b5...@wolfman.devio.us X-Google-Sender-Auth: _qqD-ym4zFJb3ZiF5l9BkvwN5DM Subject: Re: 64-bit amd64 : actual memory limitations? From: =?UTF-8?Q?Martin_Schr=C3=B6der?= mar...@oneiros.de To: OpenBSD general usage list misc@openbsd.org Content-Type: text/plain; charset=UTF-8 List-Help: mailto:majord...@openbsd.org?body=help List-ID: misc.openbsd.org List-Owner: mailto:owner-m...@openbsd.org List-Post: mailto:misc@openbsd.org List-Subscribe: mailto:majord...@openbsd.org?body=sub%20misc List-Unsubscribe: mailto:majord...@openbsd.org?body=unsub%20misc X-Loop: misc@openbsd.org Precedence: list Sender: owner-m...@openbsd.org 2014-10-27 1:56 GMT+01:00 Mayuresh Kathe mayur...@devio.us: if the intended application actually requires larger memory to be accessible, would it be better to go for a non-x86-64 64-bit hardware? 256TB (2^48) should be good enough till 2020. it is for a lot of records (data-sets) to held in memory instead of approaching the disk every time that data is requested. the use-case is primarily for financial system, but, will also hold 'gis' data going forward. the owner of the system isn't rich enough to afford an 'ibm' mainframe, hence a unix based system written in c89 under openbsd. i am just the adviser/consultant. :)
Re: 64-bit amd64 : actual memory limitations?
2014-10-27 3:37 GMT+01:00 Mayuresh Kathe mayur...@devio.us: From owner-misc+m143...@openbsd.org Sun Oct 26 22:22:57 2014 Fix your mail client, please. 256TB (2^48) should be good enough till 2020. it is for a lot of records (data-sets) to held in memory instead of approaching the disk every time that data is requested. the use-case is primarily for financial system, but, will also hold 'gis' data going forward. the owner of the system isn't rich enough to afford an 'ibm' mainframe, hence a unix based system written in c89 under openbsd. i am just the adviser/consultant. :) Then think a second about how large 256 TB are. And how long your machine will need to load 256 TB of data. And what 256 TB of RAM will cost. Today we see machines with 2TB. SGI UV 2000 goes up to 64TB with 256 CPUs. I seriously doubt that we will see OpenBSD in production on these machines. :-) What exactly is your application? Best Martin
Re: 64-bit amd64 : actual memory limitations?
On Sun, Oct 26, 2014, at 10:21 PM, Martin Schröder wrote: 2014-10-27 1:56 GMT+01:00 Mayuresh Kathe mayur...@devio.us: if the intended application actually requires larger memory to be accessible, would it be better to go for a non-x86-64 64-bit hardware? 256TB (2^48) should be good enough till 2020. And all the Browser coders are rubbing their hands with glee over all the ways they can waste that memory. ;)
apology about my email screw-up ...
i am using mailx under openbsd, and instead of using the said combination of tilde + p, i used tilde + m while attempting to include original messages in my replies. i apologize for the screw-up.
openbsd : mailx users : how-to include previous mail text (only)?
hello, i have been trying to fix the problem of mailx including the entire header-set when issuing a tilde + m in a reply to include only the previous emails body text (content). one of the docs suggested using tilde + p, but dang, it didn't work for me during tests executed just now. if anyone here uses mailx under openbsd regularly, can they please advise? thanks.
