Re: Help with the NET_LOCK()

2017-01-26 Thread RD Thrush
On 01/25/17 01:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
> 
> If you're looking for some small coding tasks related to the NET_LOCK()
> just do:
> 
>   # sysctl kern.splassert=2
>   # sysctl kern.pool_debug=2
>   
> Then watch for the traces on your console.
> 
> You'll see something like:
> 
>   Starting stack trace...
>   yield(0,1,d09dac52,f5549dbc,d94e9378) at yield+0xa4
>   yield(d0bc8f40,1,f5549e18,80,14) at yield+0xa4
>   pool_get(d0bc8f40,1,f5549ec8,d03ecbfb,d97815f4) at pool_get+0x1ba
>   m_get(1,3,f5549ec0,d03a9362,d0bc22e0) at m_get+0x30
>   doaccept(d977e6c4,3,cf7ee4f8,cf7ee4ec,2000) at doaccept+0x193
>   sys_accept(d977e6c4,f5549f5c,f5549f7c,0,f5549fa8) at sys_accept+0x37
>   syscall() at syscall+0x250
>   
> This means accept(2) is doing a memory allocation that can sleep, here
> with m_get(9), while holding the NET_LOCK().  Even if these should be
> ok, it is easy to avoid them.  In the case of doaccept() a mbuf could
> be allocated beforehand or simply use the stack for that.


I updated a nuc w/ amd64 -current (GENERIC.MP) #154 and have more data.  The 
nuc doesn't have a serial port so I extracted[1] dmesg parts from 
/var/log/messages.  Here's a bit of a summary:

>cut -d\  -f4- messages.nuc2.NET_LOCK.01|grep -e 'syscall ' | sort|uniq -c|sort 
>-nr
  32 --- syscall (number 97) ---
  31 --- syscall (number 55) ---
  21 --- syscall (number 54) ---
  13 --- syscall (number 118) ---
   9 --- syscall (number 105) ---

[1]


##
OpenBSD 6.0-current (GENERIC.MP) #154: Wed Jan 25 19:50:16 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16959188992 (16173MB)
avail mem = 16440545280 (15678MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x9eee3000 (56 entries)
bios0: vendor Intel Corporation version "MYBDWi5v.86A.0033.2016.1124.2006" date 
11/24/2016
bios0: Intel Corporation NUC5i5MYBE
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT SSDT ASF! SSDT 
SSDT SSDT DMAR BGRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2295.06 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2295060110 Hz
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.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2294.69 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2294.70 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2294.69 MHz
cpu3: 

Re: Help with the NET_LOCK()

2017-01-26 Thread RD Thrush
On 01/25/17 01:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
> 
> If you're looking for some small coding tasks related to the NET_LOCK()
> just do:
> 
>   # sysctl kern.splassert=2
>   # sysctl kern.pool_debug=2
>   
> Then watch for the traces on your console.
> 
> You'll see something like:
> 
>   Starting stack trace...
>   yield(0,1,d09dac52,f5549dbc,d94e9378) at yield+0xa4
>   yield(d0bc8f40,1,f5549e18,80,14) at yield+0xa4
>   pool_get(d0bc8f40,1,f5549ec8,d03ecbfb,d97815f4) at pool_get+0x1ba
>   m_get(1,3,f5549ec0,d03a9362,d0bc22e0) at m_get+0x30
>   doaccept(d977e6c4,3,cf7ee4f8,cf7ee4ec,2000) at doaccept+0x193
>   sys_accept(d977e6c4,f5549f5c,f5549f7c,0,f5549fa8) at sys_accept+0x37
>   syscall() at syscall+0x250
>   
> This means accept(2) is doing a memory allocation that can sleep, here
> with m_get(9), while holding the NET_LOCK().  Even if these should be
> ok, it is easy to avoid them.  In the case of doaccept() a mbuf could
> be allocated beforehand or simply use the stack for that.

I updated my firewall w/ amd64 -current (GENERIC.MP) #154 and got quite a lot 
of data.  The full serial console[1] is ~130k.  Here's a bit of a summary:

>grep -e 'syscall ' Log.tarpit.NET_LOCK.ddb.01 | sort|uniq -c|sort -nr
  94 --- syscall (number 105) ---
  86 --- syscall (number 54) ---
  33 --- syscall (number 97) ---
  24 --- syscall (number 118) ---
   3 --- syscall (number 202) ---

[1]

#
OpenBSD 6.0-current (GENERIC.MP) #154: Wed Jan 25 19:50:16 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4273856512 (4075MB)
avail mem = 4139667456 (3947MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7fbf0420 (7 entries)
bios0: vendor coreboot version "ADI_RCCVE-01.00.00.08-nodebug" date 01/22/2016
bios0: ADI Engineering RCC-VE
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC MCFG SSDT
acpi0: wakeup devices EHC1(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) Atom(TM) CPU C2358 @ 1.74GHz, 1750.32 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 1750324380 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2358 @ 1.74GHz, 1749.99 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 1 (RP01)
acpiprt1 at acpi0: bus 2 (RP02)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
cpu0: Enhanced SpeedStep 1750 MHz: speeds: 2100, 1800, 1600, 1400 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x1f0e rev 0x02
ppb0 at pci0 dev 1 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 2 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 3 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 4 function 0 "Intel Atom C2000 PCIE" rev 0x02: msi
pci4 at ppb3 bus 4
vendor "Intel", unknown product 0x1f18 (class processor subclass Co-processor, 
rev 0x02) at pci0 dev 11 function 0 not configured
pchb1 at pci0 dev 14 function 0 "Intel Atom C2000 RAS" rev 0x02
"Intel Atom C2000 RCEC" rev 0x02 at pci0 dev 15 function 0 not configured
"Intel Atom C2000 SMBus" rev 0x02 at pci0 dev 19 function 0 not configured
em0 at pci0 dev 20 function 0 "Intel I354 SGMII" rev 0x03: msi, address 
00:08:a2:0a:73:bd
em1 at pci0 dev 20 function 1 "Intel I354 SGMII" rev 0x03: msi, address 
00:08:a2:0a:73:be
em2 at pci0 dev 20 function 2 "Intel I354 SGMII" rev 0x03: msi, address 

Re: Allow install from https server w/ self signed cert

2017-01-10 Thread RD Thrush
On 01/06/17 06:28, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
> 
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

Many thanks to rpe@ for this fix. install.sub v1.943 works perfectly with my 
legacy nas and its self-signed cert.



Re: Allow install from https server w/ self signed cert

2017-01-07 Thread RD Thrush
On 01/07/17 16:13, Bob Beck wrote:
> 
> On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
>> On 01/06/17 06:28, Stuart Henderson wrote:
>>> Related to this (and particularly thinking about autoinstalls),
>>> would it make sense to allow explicit protocols in the hostname?
>>>
>>> some.host -> https with http fallback
>>> http://some.host/ -> http only
>>> https://some.host/ -> https only, no fallback
>>
>> That would totally work for my install problem.
>>
>> FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes 
>> the install bypass the https attempt.
>>
> 
> Note, if you're upgrading or otherwise have a way to et a cert.pem bundle 
> onto there to *replace*
> the default, you could always drop the signer for your private self-signed 
> server into the cert.pem
> bundle, at which point it would be accepted as trusted.

In an ideal world, I'd have a valid certificate for this local nas server...


> of course if you're just installing you have an interesting chicken and egg 
> problem, unless
> you put it somewhere on an https site that does have a real certificate, drop 
> out of the
> installer and do
> 
> ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> 
> then continue the install, and you're good.

Thanks.  Unfortunately, I've been spoiled by the continually improving snapshot 
install methods and want to preserve typing "a" once for a new -current.


> Almost wonder if it's worth an extra question in the installer to ask
> for an https address to retrieve a certficiate bundle to be appended to 
> cert.pem
> for the install...

That would also solve the self signed cert problem.  Since the install 
/etc/ssl/cert.pem is transient, your method wouldn't trigger any /etc/daily 
alarm about a chang in cert.pem.

I hacked a bit on sthen's suggestion but ran into problems testing the https 
part w/ the OpenBSD servers.  I'm currently unable to do a snapshot autoinstall 
from ftp[35] via the latest bsd.rd.

FWIW, here's my weak attempt at sthen's suggestion:
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.942
diff -u -p -u -p -r1.942 install.sub
--- install.sub 4 Jan 2017 13:47:29 -   1.942
+++ install.sub 7 Jan 2017 22:02:52 -
@@ -1502,9 +1502,11 @@ install_files() {
 
 # Get several parameters from the user, and xfer files from the http server.
 install_http() {
+   local _proto=$1
local _file_list _prompt _mirror _url_base _err _idx=/tmp/i/index.txt
local _idx_url _rc
 
+   HTTP_PROTO=$_proto
# N.B.: 'http_proxy' is an environment variable used by ftp(1). DON'T
# change the name or case!
ask "HTTP proxy URL? (e.g. 'http://proxy:8080', or 'none')" \
@@ -1568,8 +1570,9 @@ install_http() {
# Get list of files from the server.
# Assumes index file is "index.txt" for http (or proxy).
# We can't use index.html since the format is server-dependent.
-   # If ftp(1) has tls, fetch index.txt via https. If that fails
-   # tell the user about it and switch to http.
+   # If ftp(1) has tls and doesn't explicitly request http,
+   # fetch index.txt via https. If https fails tell the user about
+   # it and switch to http.
rm -f $_idx
if $FTP_TLS; then
_idx_url=$_url_base/index.txt
@@ -2310,7 +2313,7 @@ feed_random() {
 # selects from that location. Repeat as many times as the user needs to get all
 # desired sets.
 install_sets() {
-   local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http" _src
+   local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http https" 
_src
 
echo
 
@@ -2343,7 +2346,9 @@ install_sets() {
;;
[dD]*)  install_disk && INSTALL_METHOD=disk
;;
-   [hH]*)  isin http $_locs && install_http && INSTALL_METHOD=http
+   [hH]*s) isin https $_locs && install_http https && 
INSTALL_METHOD=https
+   ;;
+   [hH]*)  isin http $_locs && install_http http && 
INSTALL_METHOD=http
;;
[nN]*)  isin nfs $_locs && install_nfs && INSTALL_METHOD=nfs
;;




Re: Allow install from https server w/ self signed cert

2017-01-06 Thread RD Thrush
On 01/06/17 06:28, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
> 
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

That would totally work for my install problem.

FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes 
the install bypass the https attempt.



Allow install from https server w/ self signed cert

2017-01-05 Thread RD Thrush
Rather than add load to the OpenBSD snapshot servers, for years I download a 
snapshot to a local netgear nas server.  With the recent https changes, I'm no 
longer able to install from that server.  I've appended a console log of a 
failed install attempt.

Per src/distrib/miniroot/install.sub v1.940, I added the recommended question 
to the response file, ie.
Unable to connect using https. Use http instead = yes

However, the "ftp: SSL write error: certificate verification failed: self 
signed certificate" message causes the install to abort.

Here's the patch I used to account for the self signed certificate:
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.942
diff -u -p -u -p -r1.942 install.sub
--- install.sub 4 Jan 2017 13:47:29 -   1.942
+++ install.sub 5 Jan 2017 11:12:32 -
@@ -1578,7 +1578,7 @@ install_http() {
 
# Consider the https connect failed either if it was refused by
# the server, or it took longer than -w sec (exit code 2).
-   if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] ) ||
+   if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] || 
[[ $_err == *'self signed'* ]] ) ||
(($_rc == 2)); then
ask_yn "Unable to connect using https. Use http 
instead?" ||
return


 serial console #
>> OpenBSD/amd64 BOOT 3.33
DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
hd0 0x80label   1023255 63  0x2 0xdce59776
hd1 0x81label   1023255 63  0x2 0x2db005d6
Region 0: type 1 at 0x0 for 639KB
Region 1: type 2 at 0x9fc00 for 1KB
Region 2: type 2 at 0xf for 64KB
Region 3: type 1 at 0x10 for 2096000KB
Region 4: type 2 at 0x7ffe for 128KB
Region 5: type 2 at 0xfeffc000 for 16KB
Region 6: type 2 at 0xfffc for 256KB
Low ram: 639KB  High ram: 2096000KB
Total free memory: 2096639KB
boot> 
booting hd0a:bsd.rd.new: 3396680+1430528+3876632+0+606208 
[72+431976+281240]=0x9914c8
entry point at 0x1001000 [7205c766, 3404, 24448b12, 3550a304]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.0-current (RAMDISK_CD) #103: Wed Jan  4 21:48:20 MST 2017
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 2130575360 (2031MB)
avail mem = 2062315520 (1966MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf0cd0 (9 entries)
bios0: vendor SeaBIOS version 
"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP SSDT APIC HPET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Common KVM processor, 3400.46 MHz
cpu0: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: apic clock running at 1000MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu at acpi0 not configured
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
vga1: aperture needed
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Memory" rev 0x00
virtio0: no matching child driver; not configured
virtio1 at pci0 dev 10 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at 

Re: Is loss of read-only /usr permanent?

2016-05-14 Thread RD Thrush
On 05/13/16 19:37, Edgar Pettijohn wrote:
>> On May 13, 2016, at 4:16 PM, RD Thrush <openbsd-t...@thrush.com> wrote:
>>
>> On 05/13/16 11:07, Theo de Raadt wrote:
>>>> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
>>>> with read-only /usr produces something like the following message:
>>>> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
>>>> system
>>>
>>> Look, your statement is false.  I can install a snapshot right now,
>>> and I won't see what you report.
>>
>> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
>> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
>> appended a transcript.
>>
>>> That is the result of a mis-configuration on your part.
>>
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
>>
>>>> I thought I was following best practice by mounting /usr,
>>>> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
>>>> patch to fix my problem [2] but have had no response.
>>>
>>> That is not best practice.  If it was, we would be heading towards
>>> making it the default.
>>>
>>> And why is not best practice? Because it stands directly against the
>>> primary purpose of OpenBSD: A development platform, where people
>>> constantly rebuild their binaries, iterating and fixing bugs.
>>>
>>> What you are describing here is really just "you make a local change,
>>> you own it".
>>
>> [ ... snip ... ]
> 
> Why not just put the appropriate mount command in /etc/rc.local?

Thanks, that would work fine.  It may be useful as a note in the upgrade guide
for 6.0 for those (apparently few of us) who have a read-only /usr.



Re: Is loss of read-only /usr permanent?

2016-05-14 Thread RD Thrush
On 05/13/16 23:34, Theo de Raadt wrote:
>> The report is fairly easy to reproduce.  Make the /usr filesystem
>> read-only in /etc/fstab, go to single user mode and exit back to
>> multi-user.  I've appended a transcript.
> 
> This does not matter.  It is your configuration.  It is not the default.
> 
> Can you make /usr readonly on 90% of other operating systems, without
> downsides?  Then switch.  The reality is that you can't, since it is
> your own brave configuration choice.  You own it.
> 
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 
> It was never a valid configuration.  Next up, you will ask for readonly
> /etc.  Or readonly /var.  Or readonly something.  Or operation without
> half the files that are in /etc.  Who knows.
> 
> It is your change --> you own it.

I have nothing but praise for the related security improvement as well as 
countless others that influenced my choice of OpenBSD since 2.6. I have 
upgraded 100s of times with /usr{,/X11R*,/local} as ro in /etc/fstab.  I made 
the 'bugs' report including a diff [1] two weeks ago when I noticed the 
conflict after a -current upgrade.

After no response, I asked again and unintentionally triggered angry responses, 
although 2 good suggestions emerged.

Edgar Pettijohn [2] suggested adding the mount -ur ... commands to 
/etc/rc.local which works but may warrant a note when [3] is created.

Craig Skinner [4] greatly improved my diff. 

I've been managing the read-only /usr partitions since the change w/ a custom 
autoinstall.

[1]
[2]
[3]
[4]



Re: Is loss of read-only /usr permanent?

2016-05-14 Thread RD Thrush
On 05/13/16 19:40, Chris Cappuccio wrote:
> RD Thrush [openbsd-t...@thrush.com] wrote:
>> On 05/13/16 11:07, Theo de Raadt wrote:
>>>> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
>>>> with read-only /usr produces something like the following message:
>>>> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
>>>> system
>>>
>>> Look, your statement is false.  I can install a snapshot right now,
>>> and I won't see what you report.
>>
>> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
>> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
>> appended a transcript.
>>
>>> That is the result of a mis-configuration on your part.
>>
>> It's unfortunate that mounting /usr read-only is now a mis-configuration.
>>
> 
> Robert, what do you suggest?
> 
> 1. Say sorry, no mitigation because we want to support all possible
> configurations
> 
> 2. Say OK, and provide a work-around in /etc/rc that might (or might not)
> work with your situation, and makes the overall situation more complicated
> for everyone
> 
> 3. Say sorry, the mitigation technique will not be changed. You are on your
> own.
> 
> I think it comes down to this. If you want read-only /etc, you'll have to
> modify /etc/rc, if you still want the mitigation.

Thanks, Chris.  I provided a diff in my original bugs report.  Craig Skinner
enhanced it and I'll update my autoinstall accordingly.

I didn't mention read-only /etc.  Not sure where that came from.



Re: Is loss of read-only /usr permanent?

2016-05-14 Thread RD Thrush
On 05/14/16 04:34, Craig Skinner wrote:
> Hi RD/all,
> 
> On 2016-05-13 Fri 17:16 PM |, RD Thrush wrote:
>>
>> # cp -p /etc/fstab /etc/fstab.orig
>> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
>> # shutdown -f now
>> Shutdown NOW!
>> shutdown: [pid 82541]
> 
> Something like this in /etc/rc might help here:
> 
> rebuildlibs() {
>   mount -d /usr | fgrep -wq ro && _ro_usr='true'
>   [[ -n ${_ro_usr} ]] && mount -u -o 'nordonly' /usr
>   
>   ...
>   ..
>   [[ -n ${_ro_usr} ]] && mount -u -o 'rdonly' /usr
> }
> 
> 
> Let us know what works for you.

Thanks, Craig.  That is much better than what I proposed [1].  I'll update my
autoinstall accordingly.

[1]<http://marc.info/?l=openbsd-tech=146159002802803=2>



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread RD Thrush
On 05/13/16 11:07, Theo de Raadt wrote:
>> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
>> with read-only /usr produces something like the following message:
>> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file system
> 
> Look, your statement is false.  I can install a snapshot right now,
> and I won't see what you report.

The report is fairly easy to reproduce.  Make the /usr filesystem read-only in 
/etc/fstab, go to single user mode and exit back to multi-user.  I've appended 
a transcript.

> That is the result of a mis-configuration on your part.

It's unfortunate that mounting /usr read-only is now a mis-configuration.

>> I thought I was following best practice by mounting /usr,
>> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
>> patch to fix my problem [2] but have had no response.
> 
> That is not best practice.  If it was, we would be heading towards
> making it the default.
> 
> And why is not best practice? Because it stands directly against the
> primary purpose of OpenBSD: A development platform, where people
> constantly rebuild their binaries, iterating and fixing bugs.
> 
> What you are describing here is really just "you make a local change,
> you own it".

# cp -p /etc/fstab /etc/fstab.orig
# sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
# shutdown -f now
Shutdown NOW!
shutdown: [pid 82541]
#
?*** FINAL System shutdown message from r...@obsd32.thrush.com ***?
System going down IMMEDIATELY



System shutdown time has arrived
Enter pathname of shell or RETURN for sh:
# exit
Fast boot: skipping disk checks.
setting tty flags
pfctl: pf already enabled
machdep.allowaperture: 2 -> 2
starting network
DHCPREQUEST on vio0 to 255.255.255.255
DHCPACK from 10.1.2.18 (14:da:e9:b5:84:cf)
bound to 10.1.2.6 -- renewal in 302400 seconds.
re-ordering libraries:install: /usr/lib/INS@73BiVBOVcW: Read-only file system
 done.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
starting local daemons: cron.
Fri May 13 16:30:55 EDT 2016


##
OpenBSD 6.0-beta (GENERIC.MP) #1742: Fri May 13 08:52:53 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
cpu0: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
real mem  = 2146844672 (2047MB)
avail mem = 2093015040 (1996MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfd4be, SMBIOS rev. 2.8 @ 
0xf0cd0 (9 entries)
bios0: vendor SeaBIOS version 
"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
cpu1: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
bios0: ROM list: 0xc/0x9200 0xc9800/0xa00 0xca800/0x2400 0xed000/0x3000!
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: 

sysmerge w/ local sets

2014-08-28 Thread RD Thrush
sysmerge hangs while fetching the SHA256.sig file when working with local sets, 
ie.:
#export SM_PATH=/nas2/public/OpenBSD/snapshots/amd64
#cd $SM_PATH
#ls -l SHA256.sig xetc56.tgz
-rw-r--r--  1 rd  rd   1977 Aug 26 23:39 SHA256.sig
-rw-r--r--  1 rd  rd  69066 Aug  6 16:10 xetc56.tgz
#sysmerge -bd -x $SM_PATH/xetc56.tgz
=== Fetching file:///usr/share/sysmerge/etc.tgz
=== Fetching file:///nas2/public/OpenBSD/snapshots/amd64/xetc56.tgz
=== Fetching /nas2/public/OpenBSD/snapshots/amd64/SHA256.sig
ftp: /nas2/public/OpenBSD/snapshots/amd64/SHA256.sig: no address associated 
with name

The following fixes it for me:
Index: sysmerge.sh
===
RCS file: /pub2/cvsroot/OpenBSD/src/usr.sbin/sysmerge/sysmerge.sh,v
retrieving revision 1.154
diff -u -p -u -p -r1.154 sysmerge.sh
--- sysmerge.sh 27 Aug 2014 14:44:42 -  1.154
+++ sysmerge.sh 28 Aug 2014 15:41:56 -
@@ -145,7 +145,12 @@ sm_fetch_and_verify() {
done
if [ -z ${NOSIGCHECK} -a -n ${XTGZ} ]; then
echo === Fetching ${XTGZ%/*}/SHA256.sig
-   /usr/bin/ftp -Vm -k ${FTP_KEEPALIVE-0} -o 
${WRKDIR}/SHA256.sig ${XTGZ%/*}/SHA256.sig /dev/null || \
+   _url=${XTGZ%/*}/SHA256.sig
+   [[ -f ${_url} ]]  _url=file://$(readlink -f ${_url})
+   _file=${WRKDIR}/${_url##*/}
+   [[ ${_url} == @(file|ftp|http|https)://*/*[!/] ]] ||
+   error_rm_wrkdir ${_url}: invalid URL
+   /usr/bin/ftp -Vm -k ${FTP_KEEPALIVE-0} -o ${_file} 
${_url} /dev/null || \
error_rm_wrkdir could not retrieve SHA256.sig
echo === Verifying ${XTGZ##*/} against ${_key}
(cd ${WRKDIR}  /usr/bin/signify -qC -p ${_key} -x SHA256.sig 
${XTGZ##*/}) || \



Re: Fix of sysctl.c rev. 1.191 related bug and unbreak diskless(8)

2013-07-15 Thread RD Thrush
On 07/14/13 23:50, Philip Guenther wrote:
 On Sun, Jul 14, 2013 at 12:54 AM, Rafael Neves rafaelne...@gmail.com wrote:
 The patch below fixes a bug on sysctl(8) introduced by revision 1.191
 of sysctl.c. After rev1.191, `sysctl vfs' mangles information about
 filesystems (mounted instances of ffs are attributed to nfs, of nfs
 are atrributed to mfs, and so on). As a consequence, `sysctl
 vfs.mounts.nfs' reports 0 mounted instances on a diskless(8) setup,
 thus /etc/rc script (lines 335 to 342) doesn't add pf rules that allow
 NFS, and system hangs when it enables pf.
 
 First off: thank you for (a) noticing this, and (b) tracking down the 
 mismatch.
 
 ...
 --- sysctl.c9 Jun 2013 12:54:38 -   1.192
 +++ sysctl.c14 Jul 2013 07:09:28 -
 @@ -1175,8 +1175,8 @@ vfsinit(void)

 vfsname[0].ctl_name = mounts;
 vfsname[0].ctl_type = CTLTYPE_NODE;
 -   vfsvars[0].list = vfsname + 1;
 -   vfsvars[0].size = maxtypenum - 1;
 +   vfsvars[0].list = vfsname;
 +   vfsvars[0].size = maxtypenum;
 
 Soo close...
 
 While this fixes the observed problem, it's not 100% correct.  The
 glitch is that it fails a negative test: the command
  sysctl vfs.mounts.mounts
 should fail with the error
  sysctl: third level name mounts in vfs.mounts.mounts is invalid
 
 but with your patch it silently succeeds.  The vfsname list is offset
 by one in vfsvars[0].list to prevent that, so the fix that avoids the
 unwanted match against vfsname[0] is to keep the offset, but undo it
 in the lookup:
 
 --- sysctl.c9 Jun 2013 12:54:38 -   1.192
 +++ sysctl.c15 Jul 2013 03:43:27 -
 @@ -1200,7 +1200,7 @@ sysctl_vfsgen(char *string, char **bufpp
 
 mib[1] = VFS_GENERIC;
 mib[2] = VFS_CONF;
 -   mib[3] = indx;
 +   mib[3] = indx + 1;
 size = sizeof vfc;
 if (sysctl(mib, 4, vfc, size, (void *)0, (size_t)0)  0) {
 if (errno != EOPNOTSUPP)
 
 
 That make sense?

Sorry, I previously replied to the wrong list...

Your patch produces correct results for my previous report.  Without repeating
that email, here's the current summary:

172diff -wbu before after
--- before  Mon Jul 15 05:53:23 2013
+++ after   Mon Jul 15 05:53:58 2013
@@ -17,9 +17,9 @@
 a8v:/pub2 on /a8v/pub2 type nfs (nodev, nosuid, read-only, v3, udp, timeo=100,
retrans=101)
 nas2:/work on /nas2/work type nfs (nodev, nosuid, v3, udp, timeo=100, 
retrans=101)
 nas2:/media on /nas2/media type nfs (nodev, nosuid, v3, udp, rdirsize=4096,
timeo=100, retrans=101)
-vfs.mounts.nfs has 12 mounted instances
-vfs.mounts.mfs has 6 mounted instances
-vfs.mounts.msdos has 1 mounted instance
+vfs.mounts.ffs has 12 mounted instances
+vfs.mounts.nfs has 6 mounted instances
+vfs.mounts.mfs has 1 mounted instance
 vfs.ffs.doclusterread=1
 vfs.ffs.doclusterwrite=1
 vfs.ffs.doreallocblks=1

Thanks.



Re: Fix of sysctl.c rev. 1.191 related bug and unbreak diskless(8)

2013-07-14 Thread RD Thrush
Your patch applies correctly.

5sysctl kern.version
kern.version=OpenBSD 5.4-beta (GENERIC.MP) #27: Fri Jul 12 10:35:54 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
6mount
/dev/sd0a on / type ffs (local, softdep)
mfs:26558 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=512000 
1K-blocks)
/dev/sd0d on /usr type ffs (local, nodev, read-only)
/dev/sd2l on /usr/local type ffs (local, nodev, read-only)
/dev/sd0e on /var type ffs (local, nodev, nosuid, softdep)
/dev/sd2h on /home type ffs (local, nodev, nosuid, softdep)
/dev/sd2p on /pub type ffs (NFS exported, local, nodev, nosuid, softdep)
/dev/sd3p on /v type ffs (NFS exported, local, nodev, nosuid)
/dev/wd0m on /var/crash type ffs (local, nodev, nosuid, softdep)
/dev/wd0o on /usr/obj type ffs (asynchronous, local, noatime, nodev)
/dev/sd1d on /cosmo-rescue type ffs (local, nodev, nosuid, read-only, softdep)
/dev/sd1e on /another-rescue type ffs (local, nodev, nosuid, read-only, softdep)
/dev/sd1f on /p type ffs (NFS exported, local, nodev, nosuid, read-only, 
softdep)
localhost:/pub/cvsroot on /var/www/cvs type nfs (nosuid, read-only, v3, udp, 
timeo=100, retrans=101)
localhost:/pub/src on /var/www/htdocs/src type nfs (nosuid, read-only, v3, udp, 
timeo=100, retrans=101)
a8v:/pub on /a8v/pub type nfs (nodev, nosuid, read-only, v3, udp, timeo=100, 
retrans=101)
a8v:/pub2 on /a8v/pub2 type nfs (nodev, nosuid, read-only, v3, udp, timeo=100, 
retrans=101)
nas2:/work on /nas2/work type nfs (nodev, nosuid, v3, udp, timeo=100, 
retrans=101)
7sysctl vfs | tee before
vfs.mounts.nfs has 12 mounted instances
vfs.mounts.mfs has 5 mounted instances
vfs.mounts.msdos has 1 mounted instance
vfs.ffs.doclusterread=1
vfs.ffs.doclusterwrite=1
vfs.ffs.doreallocblks=1
vfs.ffs.doasyncfree=1
vfs.ffs.max_softdeps=23704
vfs.ffs.sd_tickdelay=2
vfs.ffs.sd_worklist_push=0
vfs.ffs.sd_blk_limit_push=0
vfs.ffs.sd_ino_limit_push=0
vfs.ffs.sd_blk_limit_hit=0
vfs.ffs.sd_ino_limit_hit=0
vfs.ffs.sd_sync_limit_hit=0
vfs.ffs.sd_indir_blk_ptrs=43
vfs.ffs.sd_inode_bitmap=66
vfs.ffs.sd_direct_blk_ptrs=427
vfs.ffs.sd_dir_entry=35
vfs.ffs.dirhash_dirsize=2560
vfs.ffs.dirhash_maxmem=2097152
vfs.ffs.dirhash_mem=236147
vfs.nfs.iothreads=4
8/usr/src/sbin/sysctl/obj/sysctl vfs | tee after
vfs.mounts.ffs has 12 mounted instances
vfs.mounts.nfs has 5 mounted instances
vfs.mounts.mfs has 1 mounted instance
vfs.ffs.doclusterread=1
vfs.ffs.doclusterwrite=1
vfs.ffs.doreallocblks=1
vfs.ffs.doasyncfree=1
vfs.ffs.max_softdeps=23704
vfs.ffs.sd_tickdelay=2
vfs.ffs.sd_worklist_push=0
vfs.ffs.sd_blk_limit_push=0
vfs.ffs.sd_ino_limit_push=0
vfs.ffs.sd_blk_limit_hit=0
vfs.ffs.sd_ino_limit_hit=0
vfs.ffs.sd_sync_limit_hit=0
vfs.ffs.sd_indir_blk_ptrs=43
vfs.ffs.sd_inode_bitmap=68
vfs.ffs.sd_direct_blk_ptrs=427
vfs.ffs.sd_dir_entry=37
vfs.ffs.dirhash_dirsize=2560
vfs.ffs.dirhash_maxmem=2097152
vfs.ffs.dirhash_mem=241014
vfs.nfs.iothreads=4
9diff -wbu before after
--- before  Sun Jul 14 06:27:13 2013
+++ after   Sun Jul 14 06:31:50 2013
@@ -16,9 +16,9 @@
 a8v:/pub on /a8v/pub type nfs (nodev, nosuid, read-only, v3, udp, timeo=100, 
retrans=101)
 a8v:/pub2 on /a8v/pub2 type nfs (nodev, nosuid, read-only, v3, udp, timeo=100, 
retrans=101)
 nas2:/work on /nas2/work type nfs (nodev, nosuid, v3, udp, timeo=100, 
retrans=101)
-vfs.mounts.nfs has 12 mounted instances
-vfs.mounts.mfs has 5 mounted instances
-vfs.mounts.msdos has 1 mounted instance
+vfs.mounts.ffs has 12 mounted instances
+vfs.mounts.nfs has 5 mounted instances
+vfs.mounts.mfs has 1 mounted instance
 vfs.ffs.doclusterread=1
 vfs.ffs.doclusterwrite=1
 vfs.ffs.doreallocblks=1
@@ -32,10 +32,10 @@
 vfs.ffs.sd_ino_limit_hit=0
 vfs.ffs.sd_sync_limit_hit=0
 vfs.ffs.sd_indir_blk_ptrs=43
-vfs.ffs.sd_inode_bitmap=67
+vfs.ffs.sd_inode_bitmap=68
 vfs.ffs.sd_direct_blk_ptrs=427
-vfs.ffs.sd_dir_entry=36
+vfs.ffs.sd_dir_entry=37
 vfs.ffs.dirhash_dirsize=2560
 vfs.ffs.dirhash_maxmem=2097152
-vfs.ffs.dirhash_mem=236147
+vfs.ffs.dirhash_mem=241014
 vfs.nfs.iothreads=4

Thanks.

On 07/14/13 03:54, Rafael Neves wrote:
 Hi tech@,
 
 The patch below fixes a bug on sysctl(8) introduced by revision 1.191
 of sysctl.c. After rev1.191, `sysctl vfs' mangles information about
 filesystems (mounted instances of ffs are attributed to nfs, of nfs
 are atrributed to mfs, and so on). As a consequence, `sysctl
 vfs.mounts.nfs' reports 0 mounted instances on a diskless(8) setup,
 thus /etc/rc script (lines 335 to 342) doesn't add pf rules that allow
 NFS, and system hangs when it enables pf.
 
 For example, on -current I get (dmesg at end):
 output of mount(8):
   /dev/wd0a on / type ffs (local)
   /dev/wd0k on /home type ffs (local, nodev, nosuid)
   /dev/wd0d on /tmp type ffs (local, nodev, nosuid)
   /dev/wd0f on /usr type ffs (local, nodev)
   /dev/wd0g on /usr/X11R6 type ffs (local, nodev)
   /dev/wd0h on /usr/local type ffs (local, nodev)
   /dev/wd0j on /usr/obj type ffs (local, nodev, nosuid)
   /dev/wd0e 

Re: 5.3 -current installation problem

2013-04-04 Thread RD Thrush
On 04/03/13 09:08, Stuart Henderson wrote:
 moving this to tech@ - original message with dmesg is at
 http://marc.info/?l=openbsd-miscm=136498447228598w=2 - summary:
 asus P8H77-M, intel 7 series chipset, Intel HD Graphics 3000
 running i386 or amd64, fails during boot with recent kernels unless
 inteldrm disabled.
 [ snip ]
 
 The most useful thing if it's possible (short of getting a system to
 a developer working in this area), would probably be to get a serial
 console on the machine and capture a boot log with option DRMDEBUG
 in kernel config. Though maybe someone on tech@ will have an idea of
 something else to try.

I've attached the boot log from a kernel compiled with both option DRMDEBUG
and Mark Kettenis patch.

booting hd0a:bsd.dbg2: 6107292+1771500+1021568+0+638720 
[80+550488+367351]=0xdfa3a0
entry point at 0x10001e0 [7205c766, 3404, 24448b12, 1978a304]
[ using 918688 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2013 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.3-current (GENERIC.MP) #6: Thu Apr  4 08:54:28 EDT 2013
r...@a8v.thrush.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16818126848 (16039MB)
avail mem = 16362627072 (15604MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba40 (112 entries)
bios0: vendor American Megatrends Inc. version 1002 date 02/04/2013
bios0: ASUSTeK COMPUTER INC. P8Q77-M
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT DMAR ASF!
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) P0P1(S4) PXSX(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) 
PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) 
PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.51 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
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 100MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu3: 256KB 64b/line 8-way L2 cache
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu4: 256KB 64b/line 8-way L2 cache
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 MHz
cpu5: 
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
cpu5: 256KB 64b/line 8-way L2 cache
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 MHz
cpu6: 

Re: 5.3 -current installation problem

2013-04-03 Thread RD Thrush
On 04/03/13 09:52, Mark Kettenis wrote:
 Date: Wed, 3 Apr 2013 14:08:20 +0100
 From: Stuart Henderson s...@spacehopper.org

 moving this to tech@ - original message with dmesg is at
 http://marc.info/?l=openbsd-miscm=136498447228598w=2 - summary:
 asus P8H77-M, intel 7 series chipset, Intel HD Graphics 3000
 running i386 or amd64, fails during boot with recent kernels unless
 inteldrm disabled.
 
 /var/log/Xorg.0.log, from before you upgraded the machine, might
 provide us some clues.  And defenitely also provide pcidump -vxx output.
 
 But ultimately having serial console output is pretty much a
 requirement for being able to debug this properly.

I have a similar problem which results in a panic (dmesg appended).  This
machine has a radeon (asus 7770) pcie adapter in addition to the integrated
intel hd4000.  The latter adapter seems to elicit the panic.  If I set the bios
to make the hd4000 the primary display, the panic will repeatably occur.

I have also appended pcidump -vxx when the bios primary adapter is *not* set to
the hd4000.

X will run on the radeon adapter in vesa mode.  I can provide the associated
Xorg.0.log.


## serial console - dmesg including panic ##
booting hd0a:bsd: 6049532+1730828+1021088+0+639040 [80+550560+367349]=0xde2528
entry point at 0x10001e0 [7205c766, 3404, 24448b12, 9978a304]
[ using 918760 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2013 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.3-current (GENERIC.MP) #60: Tue Apr  2 18:53:53 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16818126848 (16039MB)
avail mem = 16362725376 (15604MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba40 (112 entries)
bios0: vendor American Megatrends Inc. version 1002 date 02/04/2013
bios0: ASUSTeK COMPUTER INC. P8Q77-M
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT BGRT DMAR ASF!
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) P0P1(S4) PXSX(S4) RP01(S4)
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4)
PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.45 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
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 100MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu3: 256KB 64b/line 8-way L2 cache
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 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
cpu4: 256KB 64b/line 8-way L2 cache
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.03 MHz
cpu5:

Xorg triggers panic w/ Intel HD4000 graphics

2013-02-06 Thread RD Thrush
Using startx as root w/ no Xorg.conf causes -current to panic when using the 
i7-3770 integrated graphics adapter.  I built a debug kernel and sent a sendbug 
report[1] on Sunday.  I've appended a (serial console) excerpt from that 
report.  The panic is easily reproducible.  Is this a known problem?

[1]http://marc.info/?l=openbsd-bugsm=135990465408901w=2

# /usr/X11R6/bin/startx -- /usr/X11R6/bin/X -keepPriv

xauth:  file /root/.serverauth.29813 does not exist
xauth:  file /root/.Xauthority does not exist


X.Org X Server 1.12.3
Release Date: 2012-07-09
X Protocol Version 11, Revision 0
Build Operating System: OpenBSD 5.3 amd64 
Current Operating System: OpenBSD v1.thrush.com 5.3 GENERIC.MP#3 amd64
Build Date: 02 February 2013  07:39:03PM
 
Current version of pixman: 0.28.0
Before reporting problems, check http://wiki.xextent_create: extent 
`agpgtt', \
start 0xd000, end 0xdfffefff
panic: extent_create: end  start
Stopped at  Debugger+0x5:   leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{5} trace
Debugger() at Debugger+0x5
panic() at panic+0xe4
extent_create() at extent_create+0x36b
sg_dmatag_init() at sg_dmatag_init+0x70
agp_bus_dma_init() at agp_bus_dma_init+0x75
i915_gem_init_ioctl() at i915_gem_init_ioctl+0xa1
inteldrm_ioctl() at inteldrm_ioctl+0x79
VOP_IOCTL() at VOP_IOCTL+0x37
vn_ioctl() at vn_ioctl+0x71
sys_ioctl() at sys_ioctl+0x150
syscall() at syscall+0x249
--- syscall (number 54) ---
end of kernel
end trace frame: 0x7f7ca9b0, count: -11
0x19437493b85a:
ddb{5} ps
   PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
*31231   2165  31231  0  7   0Xorg
  2165  29813  29813  0  30x88  pause xinit
 29813  31363  29813  0  30x88  pause sh
 16114  1  16114  0  30x80  ttyin getty
 31363  1  31363  0  30x88  pause ksh
  8360  1   8360  0  30x80  ttyin getty
  1780  1   1780  0  30x80  ttyin getty
 13621  1  13621  0  30x80  ttyin getty
 25853  1  25853  0  30x80  ttyin getty
 15418  1  15418  0  30x80  ttyin getty
  6590  26627  26627  0  30x80  nanosleep perl
  7773  1   7773  0  30x80  poll  wsmoused
 26627482  26627  0  30x88  pause sh
   482  15537  15537  0  30x80  piperdcron
 15537  1  15537  0  30x80  selectcron
 13904  1  13904  0  30x80  kqreadapmd
 32065  1  32065 99  30x80  poll  sndiod
 31682  1  31682  0  30x80  selectinetd
 23803  12668  12668 67  30x80  netconhttpd
  9625  12668  12668 67  30x80  netconhttpd
 26717  12668  12668 67  30x80  netconhttpd
 10383  12668  12668 67  30x80  netconhttpd
  4499  12668  12668 67  30x80  netconhttpd
 12668  1  12668 67  30x80  selecthttpd
 31347  1  31347  0  30x80  selectsendmail
  2140  1   2140  0  30x80  selectlpd
 13211  1  13211  0  30x80  selectsshd
 13997  1  13997  0  30x80  poll  rpc.statd
 24517  1  24517  0  30x80  poll  rpc.lockd
 19248  16738  16738  0  30x80  nfsd  nfsd
 14135  16738  16738  0  30x80  nfsd  nfsd
 24143  16738  16738  0  30x80  nfsd  nfsd
 12836  16738  16738  0  30x80  nfsd  nfsd
 16738  1  16738  0  30x80  netconnfsd
 30526  1  30526  0  30x80  selectmountd
 18642  1  18642 28  30x80  poll  portmap
   724  1724  0  30x80  poll  ntpd
  9889  17960   9889 83  30x80  poll  ntpd
 17960  1  17960 83  30x80  poll  ntpd
  3237  21232  21232 70  30x80  selectnamed
 21232  1  21232  0  30x80  netio named
  9421  17441  17441 74  30x80  bpf   pflogd
 17441  1  17441  0  30x80  netio pflogd
 14664  29584  29584 73  70x80syslogd
 29584  1  29584  0  30x80  netio syslogd
 12495  1  12495 77  30x80  poll  dhclient
 20605  1  20605  0  30x80  poll  dhclient
 29919  0  0  0  30x100280  nfsidlnfsio
 19950  0  0  0  30x100280  nfsidlnfsio
  3825  0  0  0  30x100280  nfsidlnfsio
 29512  

Re: Xorg triggers panic w/ Intel HD4000 graphics

2013-02-06 Thread RD Thrush
On 02/06/13 09:52, Mark Kettenis wrote:
 Date: Wed, 06 Feb 2013 06:39:48 -0500
 From: RD Thrush r...@thrush.com

 Using startx as root w/ no Xorg.conf causes -current to panic when
 using the i7-3770 integrated graphics adapter.  I built a debug
 kernel and sent a sendbug report[1] on Sunday.  I've appended a
 (serial console) excerpt from that report.  The panic is easily
 reproducible.  Is this a known problem?
 
 No.
 
 Please send the output from pcidump -vxx.


Domain /dev/pci0:
 0:0:0: Intel Xeon E3-1200v2 Host
0x: Vendor ID: 8086 Product ID: 0150
0x0004: Command: 0006 Status ID: 2090
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 09
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1043 Product ID: 84ca
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
0x00e0: Capability 0x09: Vendor Specific
0x: 01508086 2096 0609 
0x0010:    
0x0020:    84ca1043
0x0030:  00e0  
0x0040: fed19001  fed10001 
0x0050: 0241 0019 cf17 be01
0x0060: f805  fed18001 
0x0070: fe00 0003 fe000c00 007f
0x0080: 0010 0011 001a 
0x0090: fe01 0003 2ed1 0004
0x00a0: 0001 0004 2ee1 0004
0x00b0: bf21 bf01 be01 cf21
0x00c0:    
0x00d0:    
0x00e0: 010c0009 e200a092 164000d0 
0x00f0:   00090fc8 
 0:1:0: Intel Xeon E3-1200v2 PCIE
0x: Vendor ID: 8086 Product ID: 0151
0x0004: Command: 0007 Status ID: 0010
0x0008: Class: 06 Subclass: 04 Interface: 00 Revision: 09
0x000c: BIST: 00 Header Type: 81 Latency Timer: 00 Cache Line Size: 10
0x0010: 
0x0014: 
0x0018: Primary Bus: 0 Secondary Bus: 1 Subordinate Bus: 1
Secondary Latency Timer: 00
0x001c: I/O Base: e0 I/O Limit: e0 Secondary Status: 2000
0x0020: Memory Base: f7d0 Memory Limit: f7d0
0x0024: Prefetch Memory Base: e001 Prefetch Memory Limit: eff1
0x0028: Prefetch Memory Base Upper 32 Bits: 
0x002c: Prefetch Memory Limit Upper 32 Bits: 
0x0030: I/O Base Upper 16 Bits:  I/O Limit Upper 16 Bits: 
0x0038: Expansion ROM Base Address: 
0x003c: Interrupt Pin: 01 Line: 0b Bridge Control: 0010
0x0088: Capability 0x0d: PCI-PCI
0x0080: Capability 0x01: Power Management
0x0090: Capability 0x05: Message Signaled Interrupts (MSI)
0x00a0: Capability 0x10: PCI Express
Link Speed: 8.0 / 8.0 GT/s Link Width: x4 / x16
0x: 01518086 0017 06040009 00810010
0x0010:   00010100 2000e0e0
0x0020: f7d0f7d0 eff1e001  
0x0030:  0088  0010010b
0x0040:    
0x0050:    
0x0060:    
0x0070:    0a00
0x0080: c8039001 0008 800d 84ca1043
0x0090: 0001a005 fee0 0060 
0x00a0: 01420010 8001 0020 0261ad03
0x00b0: d0430040 000c2580 0040 
0x00c0:    000e
0x00d0: 001e0043   
0x00e0:    
0x00f0:  0001  0011
 0:2:0: Intel HD Graphics 4000
0x: Vendor ID: 8086 Product ID: 0162
0x0004: Command: 0007 Status ID: 0090
0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 09
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR mem 64bit addr: 0xf780/0x0040
0x0018: BAR mem prefetchable 64bit addr: 0xd000/0x1000
0x0020: BAR io addr: 0xf000/0x0040
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1043 Product ID: 84ca
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
0x0090: Capability 0x05: Message Signaled Interrupts (MSI)
0x00d0: Capability 0x01: Power

Re: UQ_BAD_HID

2012-08-12 Thread RD Thrush
On 08/10/12 08:13, Stuart Henderson wrote:
 On 2012/08/10 13:46, Martin Pieuchot wrote:

 I'm also in favor of removing quirks however I would suggest to remove
 them on a case-by-case basis until libusb have full support for
 communicating with any usb device (hopefully in this release cycle). 
 
 Many items on that list are UPS which share a single usbhid-ups driver
 in NUT and were added speculatively from NUT's vid/pid list.
 
 I think it would be safe to remove quirks for the devices which
 are only supported by the common NUT driver.  Do you think this is
 reasonable?
 
 We have other software in the ports tree (sysutils/apcupsd, not
 sysutils/apc-upsd which is different) that can drive USB-connected APC
 devices so, given your comments, so I'd like to see that tested
 before removing the UQ_BAD_HID for APC UPS.
 
 Index: usb_quirks.c
 [...snip...]

apcupsd fails when running a kernel without the UQ_BAD_HID quirk entries.

I also noticed 50+ new uhidev entries in the dmesg since the Aug 1 snapshot.
dmesg at end.  I'm reverting to the last snapshot.

I patched the apcupsd package to enable DEBUG and see the following:
x2:Projects/apcupsd 949diff -wbu /etc/rc.conf.local.20120612 /etc/rc.conf.local
--- /etc/rc.conf.local.20120612 Tue Jun 12 21:21:01 2012
+++ /etc/rc.conf.local  Sun Aug 12 18:13:39 2012
@@ -12,3 +12,4 @@
 sshd_flags=-u0   # for normal use: 
 wsmoused_flags=  # for ps/2 or usb mice: , serial: -p /dev/cua00
 pkg_scripts=samba spamassassin dbus_daemon arpwatch ladvd apcupsd
+apcupsd_flags=--kill-on-powerfail -d301
x2:Projects/apcupsd 950sudo /etc/rc.d/apcupsd -d start
doing rc_read_runfile
doing rc_check
apcupsd
doing rc_pre
doing rc_start
0.000 apcupsd: apcupsd.c:219 Options parsed.
0.001 apcupsd: apcconfig.c:799 After config scriptdir: /etc/apcupsd
0.001 apcupsd: apcconfig.c:800 After config pwrfailpath: /etc/apcupsd
0.001 apcupsd: apcconfig.c:801 After config nologinpath: /etc
0.001 apcupsd: apcupsd.c:242 Config file /etc/apcupsd/apcupsd.conf processed.
0.001 apcupsd: newups.c:102 write_lock at drivers.c:208
0.013 apcupsd: drivers.c:210 Looking for driver: usb
0.013 apcupsd: drivers.c:214 Driver dumb is configured.
0.013 apcupsd: drivers.c:214 Driver apcsmart is configured.
0.013 apcupsd: drivers.c:214 Driver net is configured.
0.013 apcupsd: drivers.c:214 Driver usb is configured.
0.013 apcupsd: drivers.c:217 Driver usb found and attached.
0.013 apcupsd: newups.c:108 write_unlock at drivers.c:234
0.013 apcupsd: drivers.c:236 Driver ptr=0x5357a0
0.013 apcupsd: apcupsd.c:261 Attached to driver: usb
doing rc_write_runfile
(ok)
x2:Projects/apcupsd 9510.018 apcupsd: newups.c:102 write_lock at bsd-usb.c:728
0.018 apcupsd: bsd-usb.c:253 Found bus /dev/usb0.
0.019 apcupsd: bsd-usb.c:253 Found bus /dev/usb1.
0.061 apcupsd: bsd-usb.c:253 Found bus /dev/usb2.
0.061 apcupsd: bsd-usb.c:253 Found bus /dev/usb3.
0.062 apcupsd: bsd-usb.c:253 Found bus /dev/usb4.
0.062 apcupsd: newups.c:108 write_unlock at bsd-usb.c:747
apcupsd FATAL ERROR in bsd-usb.c at line 755
Cannot find UPS device --
For a link to detailed USB trouble shooting information,
please see http://www.apcupsd.com/support.html.
0.063 apcupsd: apclog.c:62 apcupsd FATAL ERROR in bsd-usb.c at line 755
Cannot find UPS device --
For a link to detailed USB trouble shooting information,
please see http://www.apcupsd.com/support.html.

0.063 apcupsd: newups.c:102 write_lock at bsd-usb.c:770
0.064 apcupsd: newups.c:108 write_unlock at bsd-usb.c:777
0.064 apcupsd: apclog.c:62 apcupsd error shutdown completed


### dmesg stuff ###
With the Aug 1 snapshot kernel the APC UPS showed as:
ugen0 at uhub1 port 1 American Power Conversion Smart-UPS 1000 XL FW:631.3.D 
USB FW:1.5 rev 1.10/0.06 addr 2

OpenBSD 5.2-current (USB_UPS) #0: Sun Aug 12 16:35:33 EDT 2012
r...@x2.thrush.com:/usr/src/sys/arch/amd64/compile/USB_UPS
real mem = 1072365568 (1022MB)
avail mem = 1021456384 (974MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0530 (67 entries)
bios0: vendor American Megatrends Inc. version 0221 date 12/06/2005
bios0: ASUSTeK Computer Inc. A8V
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC OEMB
acpi0: wakeup devices PCI0(S4) PS2K(S4) PS2M(S4) UAR1(S4) AC97(S4) USB1(S4) 
USB2(S4) USB3(S4) USB4(S4) EHCI(S4) PWRB(S4) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2002.86 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,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application 

Re: diff: fix waiting problem on AMD Hudson's AHCI (Re: AMD APU report)

2012-04-12 Thread RD Thrush

On 04/12/12 09:40, SASANO Takayoshi wrote:

Hello,


I have a system with an asrock a75m-itx motherboard and an amd a6-3500
processor.  I notice there is a 40 second delay after the 'ahci0 at pci0
  dev 17
...' line.


I have IBM's ThinkPad Edge E525, AMD A8-3500M based machine.
And I checked this diff fix that problem.

ok or comment?


Thanks, your patch eliminates the 40 second delay.



AMD APU report

2012-04-03 Thread RD Thrush
I have a system with an asrock a75m-itx motherboard and an amd a6-3500 
processor.  I notice there is a 40 second delay after the 'ahci0 at pci0 dev 17 
...' line.  I also notice there are two 'not configured' items and 4 'unknown 
product' items.


It appears that I have selected a combination that is not yet supported...

How can I help troubleshoot these anomalies?

I've appended dmesgs for amd64 GENERIC and GENERIC.MP as well as a slightly 
older i386 GENERIC.  In addition, I have collected pcidump, biosdecode, 
dmidecode and acpidump results for each of the amd64 boots at [1] and [2] 
respectively.


[1]http://arp.thrush.com/openbsd/a75m/bsd.sp/
[2]http://arp.thrush.com/openbsd/a75m/bsd.mp/

# amd64 GENERIC dmesg ###
OpenBSD 5.1-current (GENERIC) #214: Mon Apr  2 12:19:30 MDT 2012
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 8297402368 (7913MB)
avail mem = 8054210560 (7681MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb0c0 (17 entries)
bios0: vendor American Megatrends Inc. version P1.50 date 02/09/2012
bios0: ASRock A75M-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG AAFT HPET SSDT SSDT
acpi0: wakeup devices SBAZ(S4) CIR_(S3) PS2K(S4) PS2M(S4) UAR1(S4) P0PC(S4) 
GEC_(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) XHC0(S4) 
XHC1(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) 
PCE6(S4) PCE7(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 A6-3500 APU with Radeon(tm) HD Graphics, 2096.49 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,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 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: apic clock running at 199MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
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 2 (PE20)
acpiprt2 at acpi0: bus -1 (PE21)
acpiprt3 at acpi0: bus -1 (PE22)
acpiprt4 at acpi0: bus -1 (PE23)
acpiprt5 at acpi0: bus -1 (PCE2)
acpicpu0 at acpi0: C2, PSS
acpibtn0 at acpi0: PWRB
cpu0: 2096 MHz: speeds: 2100 1900 1600 1400 1200 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 AMD AMD64 12h Host rev 0x00
vga1 at pci0 dev 1 function 0 vendor ATI, unknown product 0x964a rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
azalia0 at pci0 dev 1 function 1 vendor ATI, unknown product 0x1714 rev 0x00: 
msi
azalia0: no supported codecs
AMD Hudson xHCI rev 0x03 at pci0 dev 16 function 0 not configured
AMD Hudson xHCI rev 0x03 at pci0 dev 16 function 1 not configured
ahci0 at pci0 dev 17 function 0 AMD Hudson AHCI rev 0x40: msi, AHCI 1.3
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, ST3808110AS, 3.AA SCSI3 0/direct fixed 
t10.ATA_ST3808110AS_5LR250N5

sd0: 76319MB, 512 bytes/sector, 156301488 sectors
sd1 at scsibus0 targ 1 lun 0: ATA, ST3250620AS, 3.AA SCSI3 0/direct fixed 
t10.ATA_ST3250620AS_5QE0N070

sd1: 238475MB, 512 bytes/sector, 488397168 sectors
sd2 at scsibus0 targ 2 lun 0: ATA, ST500DM002-1BD14, KC44 SCSI3 0/direct fixed 
naa.5000c500443ee774

sd2: 476940MB, 512 bytes/sector, 976773168 sectors
cd0 at scsibus0 targ 3 lun 0: LITE-ON, DVDRW SH-16A7S, WS04 ATAPI 5/cdrom 
removable
ohci0 at pci0 dev 18 function 0 AMD Hudson USB rev 0x11: apic 4 int 18, 
version 1.0, legacy support

ehci0 at pci0 dev 18 function 2 AMD Hudson USB rev 0x11: apic 4 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 AMD Hudson USB rev 0x11: apic 4 int 18, 
version 1.0, legacy support

ehci1 at pci0 dev 19 function 2 AMD Hudson USB rev 0x11: apic 4 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 AMD EHCI root hub rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 AMD Hudson-2 SMBus rev 0x13: polling
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600
spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600
pciide0 at pci0 dev 20 function 1 AMD Hudson-2 IDE rev 0x00: DMA, channel 0 
configured to compatibility, channel 1 configured to compatibility

azalia1 at pci0 dev 20 function 2 AMD Hudson HD Audio rev 0x01: apic 4 int 16
azalia1: codecs: Realtek/0x0892
audio0 at azalia1
pcib0 at pci0 dev 20 function 3 AMD Hudson LPC rev 0x11
ppb0 at pci0 dev 20 function 4 AMD Hudson 

Re: ddb symbol derefence error, test, ok?

2011-05-18 Thread RD Thrush
On 05/18/11 18:32, Ariane van der Steldt wrote:
 It turns out that on sparc64, doing something like
show map /f *kernel_map
 in ddb, makes you crash with a nullpointer exception.
 Diff below makes sure we read all bytes of the pointer. The int in the
 original code also explains why amd64 (little-endian arch) never had a
 problem.

 To test this, drop into ddb and type
show map /f *kernel_map
 Without this diff, any big-endian 64-bit arch should have a null-pointer
 excepction.
 With this diff applied, the kernel allocation map should be printed.

 Please test the above to confirm this (I don't have the hardware here).
 PS, unmount your filesystems before testing!

 Ok?

Works for me on amd64.

Before:
ddb{0} show map /f *kernel_map
show map /f *kernel_map
kernel: page fault trap, code=0
Faulted in DDB; continuing...
ddb{0} boot reboot
boot reboot
rebooting...

After:
# sysctl -w ddb.trigger=1
sysctl -w ddb.trigger=1
Stopped at  Debugger+0x5:   leave
ddb{1} show map /f *kernel_map
show map /f *kernel_map
MAP 0x80cf6780: [0x8000-0x8001]
 #ent=12, sz=246595584, ref=1, version=2280, flags=0x1
 pmap=0x80d5c6a0(resident=511)
  - 0x80d1a7d0: 0x8000-0x80013000: obj=0x0/0x0, 
amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0x80d1a740: 0x80013000-0x88013000: 
obj=0x80cceaa0/0x0, amap=0x0/0
 submap=T, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0x80d1a6b0: 0x88013000-0x88133000: 
obj=0x80cf6740/0x8013000, amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0x80d1a590: 0x88133000-0x88533000: 
obj=0x80014f00/0x0, amap=0x0/0
 submap=T, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0x80d1a500: 0x88533000-0x8865f000: 
obj=0x80014e00/0x0, amap=0x0/0
 submap=T, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0x80d1a470: 0x8865f000-0x8e89f000: obj=0x0/0x0, 
amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=0/0, inh=2, wc=0, adv=0
  - 0x80d1a350: 0x8e89f000-0x8e8ab000: 
obj=0x80cf6740/0xe89f000, amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0x80d1a3e0: 0x8e8ab000-0x8e8ab040: 
obj=0x80cf6740/0xe8ab000, amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=7/7, inh=2, wc=1, adv=1
  - 0x80d1a230: 0x8e8ab040-0x8e8af000: 
obj=0x80cf6740/0xe8ab040, amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0x80d1a1a0: 0x8e8af000-0x8eac8000: 
obj=0x80cf6740/0xe8af000, amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=7/7, inh=2, wc=0, adv=1
  - 0xfe803fe2f1b0: 0x8eac8000-0x8eb18000: 
obj=0x80cf6740/0xeac8000, amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=3/3, inh=2, wc=0, adv=1
  - 0xfe803fe2f6c0: 0x8eb5a000-0x8eb6e000: 
obj=0x80cf6740/0xeb5a000, amap=0x0/0
 submap=F, cow=F, nc=F, prot(max)=3/3, inh=2, wc=0, adv=1
ddb{1} boot reboot
boot reboot
rebooting...
booting hd0a:bsd.ddbfix: 5612792+1596908+944936+0+628256 
[89+496392+319941]=0xd28e90
entry point at 0x1001e0 [7205c766, 3404, 24448b12, 8c58a304]
[ using 817264 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2011 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.9-current (GENERIC.MP) #21: Thu May 19 00:36:11 EDT 2011
r...@x2.thrush.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1072627712 (1022MB)
avail mem = 1030017024 (982MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (5 entries)
bios0: vendor innotek GmbH version VirtualBox date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
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, 2191.01 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,NXE,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 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: apic clock running at 999MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) 9550 Quad-Core Processor, 2190.72 MHz
cpu1: 

Shuttle XPC SK21 hangs unless acpimadt is disabled

2010-08-06 Thread RD Thrush
 This problem first occurred between the Dec 15, 2008 and
the Jan 16, 2009 amd64 snapshots.  Bug reports kernel/6138
and kernel/6164 have been submitted.

The problem still remains, ie. both RAMDISK_CD and GENERIC
hang unless acpimadt is disabled.  With acpimadt disabled,
the system runs ok.  Both amd64 and i386 versions of GENERIC hang.

I have appended a diff from the current amd64 snapshot, ie.
OpenBSD 4.8-beta (GENERIC) #159: Thu Aug  5 21:28:36 MDT 2010
with and without acpimadt disabled.  I have also appended a
dmesg which includes ddb trace  ps during the hang.

Apparently, with acpimadt enabled, interrupts are handled
differently and since wd0 times out, the hang occurs.  I
compiled a kernel yesterday with ACPIDEBUG enabled but am
lost trying to interpret the results[1] and learn more.
[1] ftp://www.thrush.com/tarpit2/acpidebug.out

FWIW, the hanging dmesgs are also at [2] and [3].
[2] ftp://www.thrush.com/tarpit2/dmesg.amd64
[3] ftp://www.thrush.com/tarpit2/dmesg.i386

With the recent ACPI changes, perhaps this is related and
someone can help?


# diff 
--- dmesg.acpimadt_hang Fri Aug  6 10:05:02 2010
+++ dmesg.no_acpimadt   Fri Aug  6 10:06:03 2010
@@ -11,7 +11,11 @@
 acpi0: tables DSDT FACP APIC
 acpi0: wakeup devices PCI0(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1) USB4(S1)
USB5(S1) USB6(S1) LAN0(S5) AC97(S5) UAR1(S5)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
-acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
+acpiprt0 at acpi0: bus 0 (PCI0)
+acpicpu0 at acpi0
+acpitz0 at acpi0: critical temperature 110 degC
+acpibtn0 at acpi0: PWRB
+mpbios0 at bios0: Intel MP Specification 1.4
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD Sempron(tm) Processor 2800+, 1600.08 MHz
 cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
@@ -20,11 +24,10 @@
 cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
 cpu0: AMD erratum 89 present, BIOS upgrade may be required
 cpu0: apic clock running at 199MHz
+mpbios0: bus 0 is type PCI
+mpbios0: bus 1 is type PCI
+mpbios0: bus 2 is type ISA
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 3, 24 pins
-acpiprt0 at acpi0: bus 0 (PCI0)
-acpicpu0 at acpi0
-acpitz0 at acpi0: critical temperature 110 degC
-acpibtn0 at acpi0: PWRB
 pci0 at mainbus0 bus 0
 pchb0 at pci0 dev 0 function 0 VIA K8M800 Host rev 0x00
 agp at pchb0 not configured
@@ -42,7 +45,7 @@
 re0 at pci0 dev 11 function 0 Realtek 8169 rev 0x10: RTL8110S (0x0400), apic
2 int 18 (irq 10), address 00:e0:4c:77:6d:ab
 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0
 pciide0 at pci0 dev 15 function 0 VIA VT6420 SATA rev 0x80: DMA
-pciide0: using apic 2 int 15 (irq 15) for native-PCI interrupt
+pciide0: using apic 2 int 20 (irq 15) for native-PCI interrupt
 wd0 at pciide0 channel 0 drive 0: ST3808110AS
 wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
 wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6

# dmesg when system hangs ###
OpenBSD 4.8-beta (GENERIC) #159: Thu Aug  5 21:28:36 MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 518979584 (494MB)
avail mem = 491380736 (468MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf (30 entries)
bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 12/01/2005
bios0: Shuttle Inc SK21V10
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices PCI0(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1) USB4(S1)
USB5(S1) USB6(S1) LAN0(S5) AC97(S5) UAR1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Sempron(tm) Processor 2800+, 1600.08 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 256KB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: AMD erratum 89 present, BIOS upgrade may be required
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 3, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpitz0 at acpi0: critical temperature 110 degC
acpibtn0 at acpi0: PWRB
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 VIA K8M800 Host rev 0x00
agp at pchb0 not configured
pchb1 at pci0 dev 0 function 1 VIA K8M800 Host rev 0x00
pchb2 at pci0 dev 0 function 2 VIA K8M800 Host rev 0x00
pchb3 at pci0 dev 0 function 3 VIA K8M800 Host rev 0x00
pchb4 at pci0 dev 0 function 4 VIA K8M800 Host rev 0x00
pchb5 at pci0 dev 0 function 7 VIA K8M800 Host rev 0x00
ppb0 at pci0 dev 1 function 0 VIA K8HTB AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 VIA S3 

Re: infrastructure/build/out-of-date unusable with '@option always-update'

2010-01-27 Thread RD Thrush
Matthias Kilian wrote:
 On Mon, Jan 25, 2010 at 10:44:26AM -0500, RD Thrush wrote:
 ${PORTSDIR}/infrastructure/build/out-of-date generates unusable data
 for a port with a packing list containing '@option always-update'.

 The following patch fixes the problem (which appears to be fallout from the
 recent pkg_add improvements):
 [...]
 
 Here's a diff that actually applies (no tabs expanded) and
 that uses
 
   $plist-has('always-update')
 
 instead of
 
   defined $plist-{'always-update'}

Thanks.  Your patch fixes the problem in a better way.

Sorry about the expanded tabs...



infrastructure/build/out-of-date unusable with '@option always-update'

2010-01-25 Thread RD Thrush
${PORTSDIR}/infrastructure/build/out-of-date generates unusable data
for a port with a packing list containing '@option always-update'.

The following patch fixes the problem (which appears to be fallout from the
recent pkg_add improvements):

Index: out-of-date
===
RCS file: /pub/cvsroot/OpenBSD/ports/infrastructure/build/out-of-date,v
retrieving revision 1.17
diff -u -p -r1.17 out-of-date
--- out-of-date 2 Jan 2010 12:54:22 -   1.17
+++ out-of-date 25 Jan 2010 15:15:34 -
@@ -53,9 +53,13 @@ sub collect_installed
$pkg-{$subdir}-{name}  = $name;
$pkg-{$subdir}-{stem}  = $stem;
$pkg-{$subdir}-{version}   = $version;
-   my $sig = $plist-signature;
-   if (ref($sig)) { $sig = $sig-string; }
-   $pkg-{$subdir}-{signature} = $sig;
+   if (defined $plist-{'always-update'}) {
+ $pkg-{$subdir}-{signature} = 'always-update';
+   } else {
+ my $sig = $plist-signature;
+ if (ref($sig)) { $sig = $sig-string; }
+ $pkg-{$subdir}-{signature} = $sig;
+   }
}
return $pkg;
 }

Here's a simple way to replicate the problem from an empty ${PKG_DBDIR}:
x4v64:build/packages 2120sudo pkg_add -rxi pkg_mgr
x4v64:build/packages 2121pkg_info
p5-Curses-1.20p0terminal screen handling and optimisation
p5-Curses-UI-0.9607 curses based user interface framework for Perl
p5-DBD-SQLite-1.25v0 SQLite drivers for the Perl DBI
p5-DBI-1.609unified perl interface for database access
p5-Net-Daemon-0.43  extension for portable daemons
p5-PlRPC-0.2018p0   module for writing rpc servers and clients
p5-Term-ReadKey-2.30p1 change terminal modes, and perform non-blocking reads
pkg_mgr-0.1p0   user-friendly package browser and manager
quirks-1.6  exceptions to pkg_add rules
sqlite3-3.6.16.1embedded SQL implementation
sqlports-1.7sqlite database of ports, user version
x4v64:build/packages 2122/usr/ports/infrastructure/build/out-of-date
Collecting installed packages
Collecting port versions: ok
Collecting port signatures: ok
Outdated ports:

databases/sqlports,-main   # -main cdrom=yes ftp=yes
@arch amd64
+DESC
@sha RJuKFE16R4FCIZ7y8y2PnPF0XkYTLOddknbdsfQDuBM=
@size 2297
@cwd /usr/local
share/sqlports
@sha qmpuuuMQRYvPyMAu0wL1J8DYCkeb0bw9/V+a+qJZjUY=
@size 36389888
,@comment $OpenBSD: PLIST-main,v 1.2 2009/12/01 18:27:46 espie Exp $
@name sqlports-1.7
@option always-update
@comment subdir=databases/sqlports -
devel/quirks   # @comment $OpenBSD: PLIST,v 1.1.1.1 2009/12/04
16:50:48 espie Exp $
@name quirks-1.6
@option always-update
@comment subdir=devel/quirks cdrom=yes ftp=yes
@arch *
+DESC
@sha ZcShuBxD9cPsWmJce9rnoKKlC4qYQve7PwElfX/uk8Q=
@size 348
@cwd /usr/local
libdata/perl5/site_perl/OpenBSD/
libdata/perl5/site_perl/OpenBSD/Quirks.pm
@sha 5rWWNlXYKVZaVzQGwzHb5AvcvdSBOk/A07+PzJ2F2fk=
@size 5646
 -


Here's what is generated after applying the patch:

x4v64:build/packages 2123/usr/ports/infrastructure/build/out-of-date
Collecting installed packages
Collecting port versions: ok
Collecting port signatures: ok
Outdated ports:

databases/sqlports,-main   # always-update - sqlports-1.7
devel/quirks   # always-update - quirks-1.6