Re: Audio probles like, slow response in applications that use audio and a little noise in the background

2015-02-13 Thread Alexandre Ratchov
On Fri, Feb 13, 2015 at 02:47:51AM -0200, Henrique Lengler wrote:
 Hi, Just an update.
 I continue with the lag. So I decided to try other players, and I discovered 
 that ffplay from ffmpeg don't lag, this is the only one I found that works, 
 with
 both audio and video. But the problem isn't solved yet since I like cmus and 
 mplayer and I wanna use them. This is really strange, why this could happen?

One second lag is cleary a bug. Could you get this file:

http://caoua.org/tmp/beep.wav

and test the lag with this command:

aucat -i beep.wav

The lag is supposed to be of 0.2 seconds. To debug this, you could
kill sndiod, run tmux and start:

sudo sndiod -dd your_options_if_any

Then, when you start a program it displays information about what
programs do, example:

mplayer0: 48000Hz, s32le, play 0:1, 13 blocks of 960 frames
mplayer0: attached at -7680, delta = 0

which allows to calculate the expected lag:

13 * 960 / 48000 = 0.26 seconds of lag

Do you see any warning messages?

[...]

Whenever the device starts, sndiod displays:

snd0: device started

when you observe the lag, does above message appear delayed as
well?

If you let:

aucat -i /dev/zero

running, do cmus and mplayer keep lagging?

-- Alexandre



Re: postgresql-server exiting abnormally after upgrade to -snapshot

2015-02-13 Thread Stuart Henderson
On 2015-02-12, Hugo Osvaldo Barrera h...@barrera.io wrote:
 On 2015-02-12 10:18, Stuart Henderson wrote:
 On 2015-02-11, Hugo Osvaldo Barrera h...@barrera.io wrote:
  Can
  someone else confirm postgres9.4 work fine on the latest -snapshot? (the
  confirmation would be helpful to reafirm that it's not an issue with some
  dependency or library).

 Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on amd64.


 Ok, so now I know that the issue is on my end. Which leaves me even more
 confused. You're running the latest snapshots too, right? (eg: the ones from
 feb 10th?).

 Aside from a clean install, do you have any more changes? Perhaps login.conf?

I have the login.conf section from the example in the pkg-readme,

postgresql:\
:openfiles-cur=768:\
:tc=daemon:

and this in sysctl.conf

# postgresql
kern.seminfo.semmni=256
kern.seminfo.semmns=2048
kern.shminfo.shmmax=50331648

sthen@hutch:~:532$ ls -l /bin/ls /usr/local/bin/postgres 
-r-xr-xr-x  1 root  bin   267968 Feb 10 23:19 /bin/ls*
-r-xr-xr-x  1 root  bin  6508711 Feb  9 03:21 /usr/local/bin/postgres*

sthen@hutch:~:533$ sysctl kern.version
kern.version=OpenBSD 5.7-beta (GENERIC) #797: Tue Feb 10 16:26:12 MST 2015
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC



Re: Mutt Sidebar not working properly

2015-02-13 Thread Dutch Ingraham
On 02/13/15 01:31, Jan Stary wrote:
 On Feb 12 20:19:05, s...@gmx.us wrote:
 Hello all:

 I installed the binary mutt last week with the compressed, sasl, and sidebar
 flavors.  I also used my standard .muttrc from other systems.  Everything
 worked fine except the sidebar.  While all folders are present, and I can
 scroll to any folder, no folder will open.  The folders do seem to be in 
 sync,
 though.

 As an exercise, I deleted the package and compiled the port with the gpgme,
 sasl, and sidebar flavors; there was no difference as to the sidebar issue.

 My current system is OpenBSD 5.7 GENERIC.MP#834 amd64 -current to Feb. 2.  I
 am using IMAP.

 Any hints as to where the issue may lie are appreciated.  If my .muttrc, 
 dmesg
 or anything else is needed, please let me know.  Thanks.
 
 On Feb 13 06:42:26, alexan...@salmin.biz wrote:
 Hi,

 I'd say its way easier to help you and debug it with your .muttrc-file. I'm 
 using sidebar
 with mutt and have no issues with it.

 Send both mutt -v output and .muttrc
 
 ... to ports@

I seem to be unable to post to ports@, even though I am subscribed and
receiving posts.  Thanks for your replies, and I'll pick this back up
when I get that posting issue straightened out.



Re: Best filesystem options for large drive

2015-02-13 Thread Boris Goldberg
Hello Nick,

Thursday, February 12, 2015, 9:26:01 AM, you wrote:

NH On 02/12/15 10:10, Boris Goldberg wrote:
 Hello Nick,
NH ...
   I was entertaining the idea of making a 100 TB OpenBSD based archive
 storage, even asked the list. The only answer pointed to that FAQ page, and
 it stopped me from pursuing that idea. Servers with 128 GB of RAM aren't
 uncommon, but expensive (comparing to 64/32 GB ones).

NH I don't care what OS you are using, 100TB single volume archive is
NH doing it wrong.

NH Chunk your data, you will thank me; when it comes time to upgrade and
NH migrate your hardware, you will be kissing my feet.

NH The numbers have changed a bit (for the bigger) but the idea is as valid
NH today as it was eight years ago:
NH http://archives.neohapsis.com/archives/openbsd/2007-04/1572.html

  Thanks. The facts aren't new, but well put together. Will try to don't
plan the storage needs more than a (half) year ahead.

  It's too bad we don't have 10 TB disks yet. ;)

-- 
Best regards,
 Borismailto:bo...@twopoint.com



where to start troubleshooting pfsync?

2015-02-13 Thread Adam Thompson
Firstly: this problem never occurred even once in ~6 months of operation 
with pf(4) disabled; it never occurred in ~2 months of operation with 
pf(4) enabled, an accept-all ruleset and no pfsync, and now with pfsync 
configured it's happening about once a week.


My setup is complex enough that I expect I'm hitting some odd corner 
case... apologies for the dense description.


I've got two OpenBSD 5.6-STABLE (courtesy of M:Tier packages, thanks 
guys!) BGP routers running carp  pfsync between them for some of the 
internal interfaces.  Yes, I probably should have done this using two 
routers, two firewalls  ECMP, but I didn't have enough hardware, so I 
collapsed the firewall function onto the routers and used CARP instead 
of ECMP for outbound traffic.


The problem is that one or the other router will start dropping traffic 
randomly.  Never both at the same time (so far).  The first symptom I 
notice is usually that DNS lookups suddenly start to fail.  Rebooting 
the problem router always fixes the issue... but sometimes I pick the 
wrong router to reboot and have to reboot both.  This is, of course, a 
crappy solution in the first place - the issue isn't that I'm not sure 
which one to reboot, it's that I have to reboot it at all.


I *believe* the dropped packets are inbound replies; I run two BGP 
sessions with my upstream, so traffic is stochastically (I think) split 
between the two routers.


There's enough traffic running through them that leaving tcpdump(8) 
running on both is not feasible.  The pf(4) ruleset is trivial, and 
should never be able to block DNS traffic to or from my workstation - 
the rule that hits (or should, anyway) is pass all flags any keep state 
(sloppy, pflow) allow-opts!


If it matters, pfsync0 and all the routing interfaces are vlan(4) 
interfaces on top of trunk(4) LACP interfaces.  The pfsync0/vlan8 is a 
dedicated VLAN that only exists on these two trunk ports, and I'm using 
private IPv4 address space with syncpeer to set up pfsync0.


This problem never occurred even once in many months of operation with 
pf(4) disabled; it never occurred in about two months of operation with 
pf(4) enabled, an accept-all ruleset and no pfsync, and now with pfsync 
configured it's happening about once a week.


None of my customers have complained yet, but since it affects my own 
workstation, I must assume it's only a matter of time...


I don't see anything unusual in /var/log or dmesg, I don't see anything 
unusual in netstat -s output either - but I'm not sure I know what to 
look for.


With apologies for suppressing part of the data, the *entire* pf ruleset 
(pfctl -s rules) on each router is:

pass all flags any keep state (sloppy, pflow) allow-opts
block drop inet from any to 198.xxx.xxx.xxx/28
pass inet from 198.yyy.yyy.yyy/25 to 198.xxx.xxx.xxx/28 flags S/SA 
keep state (sloppy, pflow)
pass log (matches) inet proto tcp from any to 198.xxx.xxx.xxx port = 
 flags S/SA keep state (sloppy, pflow)
pass log (matches) inet proto tcp from any to 198.xxx.xxx.xxx port = 
 flags S/SA keep state (sloppy, pflow)
pass log (matches) inet proto tcp from any to 198.xxx.xxx.xxx port = 
 flags S/SA keep state (sloppy, pflow)
My workstation - where I see the effect of this problem most immediately 
- and my local DNS resolvers - all live in that 198.yyy.yyy.yyy/25 
subnet; I don't know if this is relevant or not.



So... at this point, what problem indicators (counters? log messages?) 
should I be looking at or monitoring?


--
-Adam Thompson
 athom...@athompso.net
 +1 (204) 291-7950 - cell
 +1 (204) 489-6515 - fax



Re: Audio probles like, slow response in applications that use audio and a little noise in the background

2015-02-13 Thread Henrique Lengler
On Fri, Feb 13, 2015 at 09:59:47AM +0100, Alexandre Ratchov wrote:
 One second lag is cleary a bug. Could you get this file:
 
   http://caoua.org/tmp/beep.wav
 
 and test the lag with this command:
 
   aucat -i beep.wav
 
 The lag is supposed to be of 0.2 seconds. To debug this, you could
 kill sndiod, run tmux and start:
 
   sudo sndiod -dd your_options_if_any
 
 Then, when you start a program it displays information about what
 programs do, example:
 
   mplayer0: 48000Hz, s32le, play 0:1, 13 blocks of 960 frames
   mplayer0: attached at -7680, delta = 0
 
 which allows to calculate the expected lag:
 
   13 * 960 / 48000 = 0.26 seconds of lag

When I do aucat -i beep.wav, this is what I receive:

# sndiod -dd
snd0.default: rec=0:1 play=0:1 vol=23170 dup
snd0: 48000Hz, s16le, play 0:1, rec 0:1, 9 blocks of 960 frames
aucat0: 48000Hz, s16le, play 0:0, 8 blocks of 960 frames
snd0: device started
aucat0: attached at -8640, delta = 0
snd0: device stopped

8 * 960 / 48000 = 0.16, this mean it have no lag, strange.

 Do you see any warning messages?

No.

 Whenever the device starts, sndiod displays:
 
   snd0: device started
 
 when you observe the lag, does above message appear delayed as
 well?

When I start mplayer, cmus, aucat, the first message appear instatly. But the 
others 
that I received during execution come delayed.

For example in mplayer the audio looks synchronize with the video, the delay 
comes when 
I click, for example, in the arrow to jump on the audio/music.

**This is the mplayer output when I start it:

snd0.default: rec=0:1 play=0:1 vol=23170 dup
snd0: 48000Hz, s16le, play 0:1, rec 0:1, 9 blocks of 960 frames
mplayer0: 44100Hz, s32le, play 0:1, 13 blocks of 882 frames
snd0: device started
mplayer0: attached at -7938, delta = 0
** And it stay playing, when I click the arrow key, I receive this two messages 
with 
the delay.
mplayer0: 44100Hz, s32le, play 0:1, 13 blocks of 882 frames
mplayer0: attached at -7938, delta = 0
** So I press quit, mplay quit in the same time, but the audio still playing 
for a while.
And I receive this one with the same delay
snd0: device stopped

In ffplay, that don't lag, this is the messages I get:

# sndiod -dd
snd0.default: rec=0:1 play=0:1 vol=23170 dup
snd0: 48000Hz, s16le, play 0:1, rec 0:1, 9 blocks of 960 frames
snd0: 48000Hz, s16le, play 0:1, rec 0:1, 9 blocks of 960 frames
ffplay0: 44100Hz, s16le, play 0:1, 2 blocks of 882 frames
snd0: device started
ffplay0: attached at -7938, delta = 0
snd0: device stopped

In ffplay, I don't receive any message if I advance the video, and the message
of device stopped come instatly.

First thing I can see is that:
2 * 882 / 44100 = 0.04 - the value is lower

But looks this isn't the problem, the audio in mplayer is synchronized with the 
video, 
the lag only happens when I advance or quit the app.

 If you let:
 
   aucat -i /dev/zero
 
 running, do cmus and mplayer keep lagging?

Yes, everything continue behaving as before. 

-- 
Regards

Henrique Lengler 



root partition full; /dev taking up all the space?

2015-02-13 Thread Jason Hunt
In the midst of setting up my laptop (fresh install of 5.6), I found I was
out of space on root::

# df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd1a 1005M   1004M  -49.2M   105%/
/dev/sd1k 49.2G1.4G   45.3G 3%/home
/dev/sd1d  3.9G138K3.7G 0%/tmp
/dev/sd1f  2.0G917M995M48%/usr
/dev/sd1g 1005M191M764M20%/usr/X11R6
/dev/sd1h  9.8G   1015M8.4G11%/usr/local
/dev/sd1j  2.0G2.0K1.9G 0%/usr/obj
/dev/sd1i  2.0G2.0K1.9G 0%/usr/src
/dev/sd1e 11.2G9.2M   10.6G 0%/var

The culprit: looks to be /dev:

# du -sh /dev
938M/dev

But I don't understand why /dev would be using so much space?  Nothing
looks out of place in /dev, but there sure is a lot of files (more than I
expected):

# ls -l /dev | wc -l
1173

I don't have another OpenBSD system in front of me at the moment for
comparison; is this normal?  I never thought I would need more than 1GB for
root?  I guess I need to make a new root partition (2GB this time?) and
migrate to that?

OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug  8 00:20:21 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3959619584 (3776MB)
avail mem = 3845431296 (3667MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (67 entries)
bios0: vendor LENOVO version GCET98WW (2.58 ) date 03/12/2014
bios0: LENOVO 3434CT0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT AS
F! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3)
EHC2(S3) HDEF(S4)
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) i5-3320M CPU @ 2.60GHz, 2594.58 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpicpu2 at acpi0: C2, C1, PSS
acpicpu3 at acpi0: C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2
acpitz0 at acpi0: critical temperature is 103 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 45N1079 serial 28341 type LION oem LGC
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, 2300, 220
0, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09
vga1 

Re: root partition full; /dev taking up all the space?

2015-02-13 Thread Martin Brandenburg
 From owner-misc+m146...@openbsd.org  Sat Feb 14 04:44:09 2015
 Date: Fri, 13 Feb 2015 23:28:21 -0500
 Subject: root partition full; /dev taking up all the space?
 From: Jason Hunt jh...@lynden.on.ca
 To: misc@openbsd.org
 List-ID: misc.openbsd.org

 In the midst of setting up my laptop (fresh install of 5.6), I found I was
 out of space on root::

 # df -h
 Filesystem SizeUsed   Avail Capacity  Mounted on
 /dev/sd1a 1005M   1004M  -49.2M   105%/
 /dev/sd1k 49.2G1.4G   45.3G 3%/home
 /dev/sd1d  3.9G138K3.7G 0%/tmp
 /dev/sd1f  2.0G917M995M48%/usr
 /dev/sd1g 1005M191M764M20%/usr/X11R6
 /dev/sd1h  9.8G   1015M8.4G11%/usr/local
 /dev/sd1j  2.0G2.0K1.9G 0%/usr/obj
 /dev/sd1i  2.0G2.0K1.9G 0%/usr/src
 /dev/sd1e 11.2G9.2M   10.6G 0%/var

 The culprit: looks to be /dev:

 # du -sh /dev
 938M/dev

That's way too much.

$ du -sh /dev
34.0K   /dev

My guess is you typoed a dd command and ended up creating some huge file
in there.

ls -l /dev | grep '^[^cb]' will show you the non-devices. There's a
few non-devices that are supposed to be there, but my guess is that
you'll see the culprit quickly.

-- Martin



Re: root partition full; /dev taking up all the space?

2015-02-13 Thread Christopher Barry
On Fri, 13 Feb 2015 23:28:21 -0500
Jason Hunt jh...@lynden.on.ca wrote:

In the midst of setting up my laptop (fresh install of 5.6), I found I
was out of space on root::

# df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd1a 1005M   1004M  -49.2M   105%/
/dev/sd1k 49.2G1.4G   45.3G 3%/home
/dev/sd1d  3.9G138K3.7G 0%/tmp
/dev/sd1f  2.0G917M995M48%/usr
/dev/sd1g 1005M191M764M20%/usr/X11R6
/dev/sd1h  9.8G   1015M8.4G11%/usr/local
/dev/sd1j  2.0G2.0K1.9G 0%/usr/obj
/dev/sd1i  2.0G2.0K1.9G 0%/usr/src
/dev/sd1e 11.2G9.2M   10.6G 0%/var

The culprit: looks to be /dev:

# du -sh /dev
938M/dev

But I don't understand why /dev would be using so much space?  Nothing
looks out of place in /dev, but there sure is a lot of files (more
than I expected):

# ls -l /dev | wc -l
1173

I don't have another OpenBSD system in front of me at the moment for
comparison; is this normal?  I never thought I would need more than
1GB for root?  I guess I need to make a new root partition (2GB this
time?) and migrate to that?

OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug  8 00:20:21 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3959619584 (3776MB)
avail mem = 3845431296 (3667MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (67 entries)
bios0: vendor LENOVO version GCET98WW (2.58 ) date 03/12/2014
bios0: LENOVO 3434CT0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT
FPDT AS F! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3)
EHC1(S3) EHC2(S3) HDEF(S4)
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) i5-3320M CPU @ 2.60GHz, 2594.58 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpicpu2 at acpi0: C2, C1, PSS
acpicpu3 at acpi0: C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2
acpitz0 at acpi0: critical temperature is 103 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 45N1079 serial 28341 type LION oem
LGC acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400,
2300, 220 0, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300,
1200 MHz pci0 at 

Re: root partition full; /dev taking up all the space?

2015-02-13 Thread Christopher Barry
On Fri, 13 Feb 2015 23:28:21 -0500
Jason Hunt jh...@lynden.on.ca wrote:

In the midst of setting up my laptop (fresh install of 5.6), I found I
was out of space on root::

# df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd1a 1005M   1004M  -49.2M   105%/
/dev/sd1k 49.2G1.4G   45.3G 3%/home
/dev/sd1d  3.9G138K3.7G 0%/tmp
/dev/sd1f  2.0G917M995M48%/usr
/dev/sd1g 1005M191M764M20%/usr/X11R6
/dev/sd1h  9.8G   1015M8.4G11%/usr/local
/dev/sd1j  2.0G2.0K1.9G 0%/usr/obj
/dev/sd1i  2.0G2.0K1.9G 0%/usr/src
/dev/sd1e 11.2G9.2M   10.6G 0%/var

The culprit: looks to be /dev:

# du -sh /dev
938M/dev

But I don't understand why /dev would be using so much space?  Nothing
looks out of place in /dev, but there sure is a lot of files (more
than I expected):

# ls -l /dev | wc -l
1173

I don't have another OpenBSD system in front of me at the moment for
comparison; is this normal?  I never thought I would need more than
1GB for root?  I guess I need to make a new root partition (2GB this
time?) and migrate to that?

OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug  8 00:20:21 MDT 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3959619584 (3776MB)
avail mem = 3845431296 (3667MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (67 entries)
bios0: vendor LENOVO version GCET98WW (2.58 ) date 03/12/2014
bios0: LENOVO 3434CT0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT
FPDT AS F! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3)
EHC1(S3) EHC2(S3) HDEF(S4)
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) i5-3320M CPU @ 2.60GHz, 2594.58 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
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) i5-3320M CPU @ 2.60GHz, 2594.11 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,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,D
EADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpicpu2 at acpi0: C2, C1, PSS
acpicpu3 at acpi0: C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2
acpitz0 at acpi0: critical temperature is 103 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 45N1079 serial 28341 type LION oem
LGC acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400,
2300, 220 0, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300,
1200 MHz pci0 at 

Re: root partition full; /dev taking up all the space?

2015-02-13 Thread dan
On Fri, 13 Feb 2015 23:28:21 -0500 Jason Hunt jh...@lynden.on.ca wrote:
 In the midst of setting up my laptop (fresh install of 5.6), I found I was
 out of space on root::
 
 # df -h
 Filesystem SizeUsed   Avail Capacity  Mounted on
 /dev/sd1a 1005M   1004M  -49.2M   105%/
 /dev/sd1k 49.2G1.4G   45.3G 3%/home
 /dev/sd1d  3.9G138K3.7G 0%/tmp
 /dev/sd1f  2.0G917M995M48%/usr
 /dev/sd1g 1005M191M764M20%/usr/X11R6
 /dev/sd1h  9.8G   1015M8.4G11%/usr/local
 /dev/sd1j  2.0G2.0K1.9G 0%/usr/obj
 /dev/sd1i  2.0G2.0K1.9G 0%/usr/src
 /dev/sd1e 11.2G9.2M   10.6G 0%/var
 
 The culprit: looks to be /dev:
 
 # du -sh /dev
 938M/dev
 
 But I don't understand why /dev would be using so much space?  Nothing
 looks out of place in /dev, but there sure is a lot of files (more than I
 expected):
 
 # ls -l /dev | wc -l
 1173

nothing odd about that. just for starters, each disk has 16 files (one for
each partition), and double that with raw devices (so 32 files per disk).
ide disks alone [0..7] use 256 files.

 
 I don't have another OpenBSD system in front of me at the moment for
 comparison; is this normal?  I never thought I would need more than 1GB for
 root?  I guess I need to make a new root partition (2GB this time?) and
 migrate to that?
 

that certainly does not seem right. /dev should be almost zero (its not much
more than inodes.)

this is from my -current:

$ du -sh /dev
38.0K   /dev
$ ls -l /dev | wc -l
1429

to see what is bigger than it should be, try:

$ du -sh /dev/* | grep -v ^0
12.0K   /dev/MAKEDEV
2.0K/dev/fd

and since almost everything in /dev is either a block or char device:

$ ls -l /dev/|grep -v ^[cb]
total 28
-r-xr-xr-x  1 root  wheel11424 Jan 28 14:22 MAKEDEV
lrwxr-xr-x  1 root  wheel6 Oct 24 23:02 audio - audio0
lrwxr-xr-x  1 root  wheel9 Oct 24 23:02 audioctl - audioctl0
dr-xr-xr-x  2 root  wheel 1024 Oct 24 23:02 fd
srw-rw-rw-  1 root  wheel0 Jan 28 07:19 log
lrwxr-xr-x  1 root  wheel6 Oct 24 23:02 mixer - mixer0
lrwxr-xr-x  1 root  wheel4 Oct 24 23:02 pci - pci0
lrwxr-xr-x  1 root  wheel6 Oct 24 23:02 radio - radio0
lrwxr-xr-x  1 root  wheel6 Oct 24 23:02 sound - sound0
lrwxr-xr-x  1 root  wheel6 Oct 24 23:02 video - video0