Re: QEMU + snapshots - pvclock0: unstable result on stable clock

[RD Thrush]

On 12/3/18 5:00 AM, Reyk Floeter wrote:
> thanks for the report.
> 
> We’re going to disable pvclock until I found a solution. It seems that old 
> KVMs or KVM on old CPUs report stable support incorrectly.
> 
> Do you have a dmesg?

I mistakenly sent the following to bugs@ and it appears to be greytrapped.

I've attached the serial console output from an older proxmox MP with i386 
6.4-release dmesg as well as the install and fail of the recent snapshot.  One 
additional point I noticed was the console hung after entering 'machine ddbcpu 
1' requiring a (simulated) hard reset.
syncing disks... done
rebooting...
>> OpenBSD/i386 BOOT 3.34
DiskBIOS#   TypeCylsHeads   SecsFlags   Checksum
hd0 0x80label   1023255 63  0x2 0xdce59776
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: 9210635+2221060+196628+0+1105920 
[711378+98+521184+541602]=0xdd84d0
entry point at 0x2000d4

[ using 1774800 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-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.4 (GENERIC.MP) #943: Thu Oct 11 13:51:32 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem  = 2146844672 (2047MB)
avail mem = 2092564480 (1995MB)
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)
cpu0: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz, 0f-06-01
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,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 999MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz, 0f-06-01
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,MELTDOWN
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
acpicmos0 at acpi0
"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: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Memory" rev 0x00
viomb0 at virtio0
virtio0: apic 0 int 11
virtio1 at pci0 dev 10 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus2 at vioblk0: 2 targets
sd0 at scsibus2 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 32768MB, 512 bytes/sector, 67108864 sectors
virtio1: apic 0 int 10
virtio2 at pci0 dev 18 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio2: address 36:31:4d:56:db:75
virtio2: apic 0 int 10
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; 

Re: Android device detach/attach loop

[RD Thrush]

On 01/03/17 11:16, Adam Van Ymeren wrote:
> On 01/03/17 02:15, Anthony J. Bentley wrote:
>> Adam Van Ymeren writes:
>>> I was attempting to to use android's adb toolbut when I enable usb
>>> debugging on my phoneit appears to repeatedly detach/reattach the device.
>>>
>>> Anyone experience this before or have any advice on how to debug this?
>>>
>>> Jan  2 15:12:30 adam-laptop /bsd: ugen2 at uhub0 port 5 "Samsung Galaxy
>>> Nexus" rev 2.00/2.16 addr 2
>> This seems to be a problem with the Galaxy Nexus, and I've seen it on
>> mine. I did buy another Galaxy Nexus to pass on to any dev with
>> potential interest but couldn't reproduce the problem on the new phone;
>> maybe I forgot to enable USB debugging.
> 
> Interesting, it doesn't happen plugging my Galaxy Nexus into a Linux of macOS 
> machine, also doesn't happen on OpenBSD using different android phones.  
> Definitely something specific with the combination of OpenBSD and the Galaxy 
> Nexus.
> 
> I did some more digging, if I'm reading this right, shortly after the device 
> connects, ehci.c reads the "Connect Status Change" register, triggers another 
> uhub_explore, which calls uhub_port_connect, which detaches the existing 
> device.
> 
> 
> I'm reading the linux usb drivers to try to fiure out what it's doing 
> different, but this isn't my area of expertise :).
> 
> 
> Follows is some more debugging information if anyone is interested
> 
> Here's the lsusb -v output from a linux machine:
> 
> [ ... snip ...]
> 
> Also some dmesg output with usbdebug = 0xff; of the device re-attaching a few 
> times.
> 
> [ ... snip ...]

I have a similar galaxy nexus and noticed the same degradation when usb 
debugging is enabled.

I built a USB_DEBUG kernel and collected some additional information from the 
usb of a pc engines apu2c4.  The -current dmesg is appended. The details are at 
http://arp.thrush.com/obsd/galaxy_nexus/:

[1] Briefly annotated transcript of console log from debug kernel (grep '#' 
messages.annotated)
[2] Another copy of the -current dmesg
[3] directory w/ linux info about the nexus device including excerpt from 
/var/log/messages and a few lsusb -v results.

[1]
[2]
[3]

Re: Recommendation for firewall appliance running of and OpenBSD

[RD Thrush]

On 11/24/16 15:15, Tito Mari Francis H. Escaño wrote:
> Hi everyone,
> Can somebody please recommend me a firewall appliance that can run OpenBSD
and
> pf, and can be upgradeable to the latest version? It would be a great plus
if
> the appliance can also be configured as part of CARP firewall group.
pfSense
> with FreeBSD doesn't cut it :)

I had previous success w/ the alix boards via netgate.com.  I recently
upgraded to an ADI Engineering RCC-VE 2440[1] and have been pleased for the
past 8 months.  dmesg appended.

[1]

OpenBSD 6.0-current (GENERIC.MP) #0: Fri Nov 25 10:59:10 MST 2016
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4273856512 (4075MB)
avail mem = 4139732992 (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, 1166.89 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,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: 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, 1166.67 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,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 1166 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
00:08:a2:0a:73:bf
em3 at pci0 dev 20 function 3 "Intel I354 SGMII" rev 0x03: msi, address
00:08:a2:0a:73:c0
ehci0 at pci0 dev 22 function 0 "Intel Atom C2000 USB" rev 0x02: apic 2 int
22
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ahci0 at pci0 dev 23 function 0 "Intel Atom C2000 AHCI" rev 0x02: msi, AHCI
1.3
scsibus1 at ahci0: 32 targets
ahci1 at pci0 dev 24 function 0 "Intel Atom C2000 AHCI" rev 0x02: msi, AHCI
1.3
scsibus2 at ahci1: 32 targets
pcib0 at pci0 dev 31 function 0 "Intel Atom C2000 PCU" rev 0x02
ichiic0 at pci0 dev 31 function 3 "Intel Atom C2000 PCU SMBus" rev 0x02: apic
2 int 22
iic0 at ichiic0
iic0: addr 0x2e 00=41 words 00=4141 01= 02= 03= 04= 05=
06= 07=
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 with thermal sensor
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com1: console
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
uhub1 at uhub0 port 1 configuration 1 interface 0 "Intel product 0x07db" rev
2.00/0.02 addr 2
umass0 at uhub1 port 4 configu

Re: install openbsd to the area made by LINUX's fdisk

[RD Thrush]

On 03/30/15 10:12, Peter Kay wrote:
> On 30 March 2015 13:03:36 BST, RD Thrush  wrote:
>> The OP's OpenBSD partition is located above 128G, ie. sector
>> start=842752000, which may have led to the complicated work-around.
> 
>  I'm pretty certain the artificial 128GB limit was removed a few releases 
> back - I've installed above that with no issues. Don't know if there's a new, 
> ludicrously high limit

The FAQ reiterates the 128G limit[1]. I don't have any large drives to verify.  
However, current source for amd64/i386 installboot shows:

x2:usr.sbin/installboot 72>grep -C1 -n BOOTBIOS_MAXSEC 
/usr/src/usr.sbin/installboot/i386_installboot.c
188-
189:if (start + (blksize / dl->d_secsize) > BOOTBIOS_MAXSEC)
190-warnx("%s extends beyond sector %u. OpenBSD might not boot.",
191:stage1, BOOTBIOS_MAXSEC);
192-

[1]<http://www.openbsd.org/faq/faq14.html#LargeDrive>

Re: install openbsd to the area made by LINUX's fdisk

[RD Thrush]

On 03/29/15 22:19, Nick Holland wrote:
> On 03/29/15 14:25, Tuyosi Takesima wrote:
>> Hi all.
>>
>> this is my little expirience , it may be useful using openbsd & linux in
>> tha same hard disk .
> ...
>> i want to install openbsd OS into sdb4 .
>> But to install OpenBSD directly is risky .
>> if i fail , i lose all (including linux) .
> 
> You have added a lot of steps, and I don't really think you improved the
> "safety" of the install.  You also managed to create a really bad system
> with just a root and swap volume (ok, what I call "really bad" is what
> Linux does normally, but I don't like to set my goals that low).
> 
> I DO agree with creating the OpenBSD partition in a utility that you are
> familiar with and/or one that your other OSs respect, as the process is
> a bit tricky, and it is a bad time to be learning new tools (that's
> ignoring my other advice of "know all the OSs you are trying to
> multiboot).  But once that was done, the OpenBSD install will only use
> the OpenBSD fdisk partition by default unless you push it elsewhere.
> But from that point onwards, no, I do not recommend people follow your
> process.


The OP's OpenBSD partition is located above 128G, ie. sector start=842752000, 
which may have led to the complicated work-around.

[1] has a kernel patch (w/ help from krw) I've used while experimenting w/ 
large disks.  However, that patch (doubling to 256G) wouldn't appear to be 
enough for the OP's problem (842752000 sectors or ~400G).

[1]

Re: [wip] Firefox 35.0rc3

[RD Thrush]

On 01/13/15 16:26, Landry Breuil wrote:
[ .. snip .. ]
>> On 1/10/15, Landry Breuil  wrote:
[ .. snip .. ]
>>
>> Interesting, your cpu doesnt have SSSE3 nor SSE4.1, while binutils/the
>> configure script detects so.. that might explain why it built here and
>> not on your machine. That doesnt explain why configure things they're
>> here though...
[ .. snip .. ]
> so fixed this way in my git repo:
> 
> http://cgit.rhaalovely.net/mozilla-firefox/commit/?h=release&id=41cef5a7e563083c40cb52f8c764f10ef32bfe8b
> 
> Thx for the testing!
> 
> Landry

Without the above patch, I had the same problem as .  With
this latest patch, firefox-35.0rc3 has been working well for about an hour.
Here's the associated dmesg:

OpenBSD 5.7-beta (GENERIC.MP) #756: Mon Jan 12 00:38:13 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8304197632 (7919MB)
avail mem = 8079261696 (7704MB)
warning: no entropy supplied by boot loader
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (72 entries)
bios0: vendor American Megatrends Inc. version "2701" date 10/08/2010
bios0: ASUSTeK Computer INC. M3A78-EM
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) RLAN(S4)
PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4) UAR1(S4)
P0PC(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 2212.21 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 201MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) 9550 Quad-Core Processor, 2211.90 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Phenom(tm) 9550 Quad-Core Processor, 2211.90 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu2: AMD erratum 721 detected and fixed
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Phenom(tm) 9550 Quad-Core Processor, 2211.90 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,ITSC
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache, 2MB 64b/line 32-way L3 cache
cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu3: AMD erratum 721 detected and fixed
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus -1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus 2 (PCE4)
acpiprt5 at acpi0: bus -1 (PCE5)
acpiprt6 at acpi0: bus 3 (PCE6)
acpiprt7 at acpi0: bus 4 (P0PC)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpicpu2 at acpi0: PSS

Help w/ masquerade feature now that sendmail[1] has been removed from base

[RD Thrush]

sendmail's masquerade function is missing from OpenSMTPD.  What are the plans 
for masquerade?  Update OpenSMTPD or create a sendmail port or document the 
smtpd filter API or ???  I've previously asked for help on the opensmtpd-misc 
mailing list[2].

Searching the archives shows that work (on masquerade) was started but appears 
to have stopped.  Apparently, masquerade functionality would be possible using 
the (undocumented) OpenSMTPD filter API.

Here's some items from my search:

o Gilles Chehade(2010) "I have a diff somewhere which bring initial (and basic) 
support for masquerading, I need to dig it up and see if it still works" [3]

o Gilles Chehade(2012) "However there is no masquerading at the envelope level 
yet" [4]

o poolpOrg(2013-06-12)[5]

Not forgotten.

@ericfaurot and I think that it should be implemented at the filters level. We 
do not require the FULL filter API to be ready to perform that, but at least 
the part of it that allows headers rewrite should be working reliably.

Note that lack address rewrite / masquerade is a showstopper to many users, we 
definitely want it asap.

ericfaurot(2014-02-28) "i have a filter-masquerade which is basically working 
but needs polishing.
It will be a nice test case for the filter framework."


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

5.6 sysmerge no longer works w/ read-only /usr

[RD Thrush]

For many years, I have reliably used read-only partitions for /usr and 
/usr/local.  -current sysmerge breaks that assumption.

i7v64:OpenBSD/sysmerge 980>CMD="env PAGER=cat sysmerge -b -s ${ETC_TGZ} -x 
${XETC_TGZ}"
i7v64:OpenBSD/sysmerge 981>sudo $CMD
===> Fetching file:///nas2/public/OpenBSD/snapshots/amd64/etc56.tgz
===> Fetching file:///nas2/public/OpenBSD/snapshots/amd64/SHA256.sig
===> Verifying etc56.tgz against /etc/signify/openbsd-56-base.pub
===> Fetching file:///nas2/public/OpenBSD/snapshots/amd64/xetc56.tgz
===> Verifying xetc56.tgz against /etc/signify/openbsd-56-base.pub
===> Populating temporary root under /var/tmp/sysmerge.GhoorXuSHR/temproot
mv: rename /var/tmp/sysmerge.GhoorXuSHR/etcsum to //usr/share/sysmerge/etcsum: 
Read-only file system
mv: rename /var/tmp/sysmerge.GhoorXuSHR/xetcsum to 
//usr/share/sysmerge/xetcsum: Read-only file system
===> Starting comparison
===> ./etc/changelist will remain for your consideration
===> ./etc/rc.conf will remain for your consideration
===> ./etc/ssh/sshd_config will remain for your consideration
===> ./etc/systrace/usr_sbin_lpd will remain for your consideration
===> ./etc/systrace/usr_sbin_named will remain for your consideration
===> ./etc/ttys will remain for your consideration
===> ./etc/X11/xdm/xdm-config will remain for your consideration
===> ./etc/mail/aliases will remain for your consideration
sha256: ///usr/share/sysmerge/examplessum: Read-only file system
 ERROR: failed to create examplessum checksum file


Here's a fix for current and the FAQ:
retrieving revision 1.526
diff -u -p -u -p -r1.526 current.html
--- current.html14 Jul 2014 05:48:51 -  1.526
+++ current.html18 Jul 2014 16:14:07 -
@@ -62,6 +62,7 @@
 2014/07/10 - ifconfig(8) ABI break
 2014/07/11 - IPv6 autoconf changes
 2014/07/13 - Addition of sendsyslog(2) system call
+2014/07/16 - sysmerge requires writeable /usr 
partition

 

@@ -628,6 +629,11 @@ sendsyslog(2) system call introduced aro
 
 A kernel containing the system call is required perhaps even for getting
 single user; so use of upgrades is recommended.
+
+
+2014/07/16 - sysmerge requires writeable /usr partition
+The /usr filesystem must be writeable.  A read-only partition will
+result in failures reported by sysmerge.

 
 


Index: faq4.html
===
RCS file: /pub2/cvsroot/OpenBSD/www/faq/faq4.html,v
retrieving revision 1.339
diff -u -p -u -p -r1.339 faq4.html
--- faq4.html   15 Jul 2014 00:24:32 -  1.339
+++ faq4.html   18 Jul 2014 15:58:50 -
@@ -2331,9 +2331,7 @@ Some of the things that end up here (and
 This is where most of OpenBSD resides.
 Program binaries, libraries, documentation, manual pages, etc. are all
 located in the /usr directory.
-The files in this mount point are relatively unchanging -- in many
-cases, you could easily mount the /usr partition read-only with
-no other system changes until your next upgrade or update.
+The files in this mount point are relatively unchanging.

 /usr/X11R6:
 This is where the X Window system resides.

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

On 02/12/14 02:53, Philip Guenther wrote:
> On Tue, Feb 11, 2014 at 11:37 PM, RD Thrush  wrote:
> ...
>> I didn't expect those perms to matter w/ Xorg -configure -keepPriv.
> 
> With the perms on /dev/drm[0-3] set so that you own them, what happens
> when you don't use the -configure and -keepPriv options?

Thanks.  I see the root screen.  Cursor tracks mouse.  ctl-alt-backspace 
transitions cleanly to text mode.  I've appended the typescript, associated 
Xorg.0.log and dmesg.


> (You don't say why you use -configure, so I'll just quote Matthieu

I was expecting better than 1024x768 resolution and the X11 section of the faq 
<http://www.openbsd.org/faq/faq11.html#amd64i386example> suggested Xorg 
-configure.

> Herb from July 2012(!):
>> Also forget about X -configure. It's known to be more or less broken and 
>> nowadays
>> you don't need an xorg.conf file to run X in most cases.
> )

I'll stop using X -configure.  Other recommendations for getting better 
resolution?

### typescript ###
Script started on Wed Feb 12 07:06:58 2014
a8v2:home/rd 384>export DISPLAY=
a8v2:home/rd 385>Xorg

X.Org X Server 1.14.5
Release Date: 2013-12-12
X Protocol Version 11, Revision 0
Build Operating System: OpenBSD 5.5 amd64 
Current Operating System: OpenBSD a8v2.thrush.com 5.5 GENERIC.MP#287 amd64
Build Date: 10 February 2014  11:19:30AM
 
Current version of pixman: 0.32.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Feb 12 07:07:20 2014
(==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d"
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension SECURITY
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
Initializing built-in extension XFree86-VidModeExtension
Initializing built-in extension XFree86-DGA
Initializing built-in extension XFree86-DRI
Initializing built-in extension DRI2
Loading extension GLX
(EE) Server terminated successfully (0). Closing log file.
a8v2:home/rd 386>exit

Script done on Wed Feb 12 07:07:50 2014


# Xorg.0.log ###
[250360.398] (--) checkDevMem: using aperture driver /dev/xf86
[250360.421] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode 
(version 3.32)
[250361.450] 
X.Org X Server 1.14.5
Release Date: 2013-12-12
[250361.450] X Protocol Version 11, Revision 0
[250361.450] Build Operating System: OpenBSD 5.5 amd64 
[250361.450] Current Operating System: OpenBSD a8v2.thrush.com 5.5 
GENERIC.MP#287 amd64
[250361.451] Build Date: 10 February 2014  11:19:30AM
[250361.451]  
[250361.451] Current version of pixman: 0.32.4
[250361.451]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[250361.451] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[250361.451] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Feb 12 07:07:20 
2014
[250361.452] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[250361.452] (==) No Layout section.  Using the first Screen section.
[250361.452] (==) No screen section available. Using defaults.
[250361.452] (**) |-->Screen "Default Screen Section" (0)
[250361.452] (**) |   |-->Monitor ""
[250361.453] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[250361.453] (==) Disabling SIGIO handlers for input devices
[250361.453] (==) Automatically adding devices
[250361.453] (==) Automatically enabling devices
[250361.453] (==) Not automatically adding GPU devices
[250361.453] (==) FontPath set to:
/usr

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

On 02/11/14 19:53, Jonathan Gray wrote:
> On Tue, Feb 11, 2014 at 10:32:25AM -0500, RD Thrush wrote:
>> On 02/10/14 13:20, Kenneth Westerback wrote:
>>> On 10 February 2014 13:11, RD Thrush  wrote:
>>>> With a somewhat recent i7 desktop, using startx, X seems to run ok; 
>>>> however, at 1024x768 rather than the expected 1920x1200 resolution. 
>>>> ctl-alt-keypad+ or - have no effect on resolution.  ctl-alt-backspace  
>>>> correctly reverts to text mode.  I then tried Xorg -configure to look for 
>>>> hints to improve resolution; however, that resulted in a segfault almost 
>>>> immediately.
>>>>
>>>
>>> I'm pretty sure
>>>
>>> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
>>>
>>> is not supported in the sense of working as opposed to being
>>> recognized. i.e. 1024x768 is likely as good as it gets until support
>>> is added. Even 4400 is problematic at the moment.
>>>
>>> But I'm willing to be corrected by people more in the know. :-)
>>>
>>>  Ken
>>
>> Thanks for the feedback.  Apparently, Intel HD Graphics 4000 is similarly 
>> not yet supported...
> 
> Ivy bridge works fine, what you didn't point out is that you
> have both radeondrm and inteldrm in that machine.
> 
> Setups with multiple cards may have been broken by the fbtab changes
> 
> Try adjust your /etc/fbtab along these lines and restart your xorg server.
> 
> --- fbtab.prevWed Feb 12 11:46:14 2014
> +++ fbtab Wed Feb 12 11:47:15 2014
> @@ -2,6 +2,6 @@
>  # login(1) reads this file to determine which devices should be chown'd to
>  # the new user. Format is:
>  # login-tty  permdevice:[device]:...
> -/dev/ttyC0   0600
> /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0
> +/dev/ttyC0   0600
> /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/drm0:/dev/drm1:/dev/drm2:/dev/drm3
>  # samples
>  #/dev/ttyC0  0600/dev/fd0

I will make that change in the next few days and report back.

Further info: Both the onboard vga and the radeon display port interface are
connected to the same monitor (Dell U2412M).  The machine is usually running
win8 w/ the monitor in display port mode.  When running OpenBSD, I have the
monitor in vga mode.

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

On 02/12/14 03:01, Jonathan Gray wrote:
> On Wed, Feb 12, 2014 at 02:37:30AM -0500, RD Thrush wrote:
>> On 02/11/14 19:45, Jonathan Gray wrote:
>>> On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote:
>>>> On 10 February 2014 13:11, RD Thrush  wrote:
>>>>> With a somewhat recent i7 desktop, using startx, X seems to run ok; 
>>>>> however, at 1024x768 rather than the expected 1920x1200 resolution. 
>>>>> ctl-alt-keypad+ or - have no effect on resolution.  ctl-alt-backspace  
>>>>> correctly reverts to text mode.  I then tried Xorg -configure to look for 
>>>>> hints to improve resolution; however, that resulted in a segfault almost 
>>>>> immediately.
>>>>>
>>>>
>>>> I'm pretty sure
>>>>
>>>> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
>>>>
>>>> is not supported in the sense of working as opposed to being
>>>> recognized. i.e. 1024x768 is likely as good as it gets until support
>>>> is added. Even 4400 is problematic at the moment.
>>>>
>>>> But I'm willing to be corrected by people more in the know. :-)
>>>
>>> Haswell graphics should work since a few months now.
>>
>> It does work; however, only @ vesa 1024x768 resolution.  That same hardware
>> yields 1920x1200 w/ win7.  Is 1024x768 the upper limit for -current w/ vga 
>> and
>> this graphics hardware?
> 
> 1024x768 is the mode chosen if the monitor does not send
> a mode when probed.
> 
> If you want to make all of this a lot easier to debug
> remove the radeon card.

This i7 only has onboard graphics.  The other i7 has both graphics hardware.  I
only brought it up to corroborate the resolution and segfault problems seen in
the initial report.

>>
>>
>>> X segfaulting at a low address normally means the framebuffer
>>> could not be mmap'd due to the /dev/drm* permissions not
>>> being set correctly.
>>
>> Here's what I have:
>> a8v2:home/rd 2181>ls -l /dev/drm*
>> crw---  1 root  wheel   87,   0 Jan 24 02:58 /dev/drm0
>> crw---  1 root  wheel   87,   1 Jan 24 02:58 /dev/drm1
>> crw---  1 root  wheel   87,   2 Jan 24 02:58 /dev/drm2
>> crw---  1 root  wheel   87,   3 Jan 24 02:58 /dev/drm3
>>
>> I didn't expect those perms to matter w/ Xorg -configure -keepPriv.  In any
>> case, I added /dev/drm[123] to /etc/fbtab as you suggested in the other post 
>> but
>> observed the same segfault.
> 
> Xorg -configure is known to be broken for quite a while
> http://lists.freedesktop.org/pipermail/xorg/2013-June/055813.html
> avoid it.

Amending the faq[1] might help avoid this unproductive path...

[1]<http://www.openbsd.org/faq/faq11.html#amd64i386example>

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

On 02/11/14 19:45, Jonathan Gray wrote:
> On Mon, Feb 10, 2014 at 01:20:46PM -0500, Kenneth Westerback wrote:
>> On 10 February 2014 13:11, RD Thrush  wrote:
>>> With a somewhat recent i7 desktop, using startx, X seems to run ok; 
>>> however, at 1024x768 rather than the expected 1920x1200 resolution. 
>>> ctl-alt-keypad+ or - have no effect on resolution.  ctl-alt-backspace  
>>> correctly reverts to text mode.  I then tried Xorg -configure to look for 
>>> hints to improve resolution; however, that resulted in a segfault almost 
>>> immediately.
>>>
>>
>> I'm pretty sure
>>
>> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
>>
>> is not supported in the sense of working as opposed to being
>> recognized. i.e. 1024x768 is likely as good as it gets until support
>> is added. Even 4400 is problematic at the moment.
>>
>> But I'm willing to be corrected by people more in the know. :-)
> 
> Haswell graphics should work since a few months now.

It does work; however, only @ vesa 1024x768 resolution.  That same hardware
yields 1920x1200 w/ win7.  Is 1024x768 the upper limit for -current w/ vga and
this graphics hardware?


> X segfaulting at a low address normally means the framebuffer
> could not be mmap'd due to the /dev/drm* permissions not
> being set correctly.

Here's what I have:
a8v2:home/rd 2181>ls -l /dev/drm*
crw---  1 root  wheel   87,   0 Jan 24 02:58 /dev/drm0
crw---  1 root  wheel   87,   1 Jan 24 02:58 /dev/drm1
crw---  1 root  wheel   87,   2 Jan 24 02:58 /dev/drm2
crw---  1 root  wheel   87,   3 Jan 24 02:58 /dev/drm3

I didn't expect those perms to matter w/ Xorg -configure -keepPriv.  In any
case, I added /dev/drm[123] to /etc/fbtab as you suggested in the other post but
observed the same segfault.

I had compiled xenocara w/ debug and included the gdb backtrace in the original
message[1].  How may I provide more info about this segfault?

[1]<http://marc.info/?l=openbsd-misc&m=139205596505418&w=2>

Re: Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

On 02/10/14 13:20, Kenneth Westerback wrote:
> On 10 February 2014 13:11, RD Thrush  wrote:
>> With a somewhat recent i7 desktop, using startx, X seems to run ok; however, 
>> at 1024x768 rather than the expected 1920x1200 resolution. ctl-alt-keypad+ 
>> or - have no effect on resolution.  ctl-alt-backspace  correctly reverts to 
>> text mode.  I then tried Xorg -configure to look for hints to improve 
>> resolution; however, that resulted in a segfault almost immediately.
>>
> 
> I'm pretty sure
> 
> vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
> 
> is not supported in the sense of working as opposed to being
> recognized. i.e. 1024x768 is likely as good as it gets until support
> is added. Even 4400 is problematic at the moment.
> 
> But I'm willing to be corrected by people more in the know. :-)
> 
>  Ken

Thanks for the feedback.  Apparently, Intel HD Graphics 4000 is similarly not 
yet supported...

An older (~Nov 2012) i7 system has similar behavior, ie. vesa @1024x768 and 
segfault w/ Xorg -configure.

I have appended dmesg, Xorg.0.log for segfault as well as for vesa startx.


 dmesg #
OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb  7 11:45:09 MST 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17051402240 (16261MB)
avail mem = 16589279232 (15820MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba40 (112 entries)
bios0: vendor American Megatrends Inc. version "1204" date 11/26/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 ASF! SSDT SSDT DMAR
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) [...]
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.43 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: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 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
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 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
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 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
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 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
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz, 3400.02 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

Xorg: Segmentation fault at address 0x28 w/ Intel HD Graphics 4600

[RD Thrush]

With a somewhat recent i7 desktop, using startx, X seems to run ok; however, at 
1024x768 rather than the expected 1920x1200 resolution. ctl-alt-keypad+ or - 
have no effect on resolution.  ctl-alt-backspace  correctly reverts to text 
mode.  I then tried Xorg -configure to look for hints to improve resolution; 
however, that resulted in a segfault almost immediately.

After the segfault, I built xenocara w/ DEBUG="-g" with -current xenocara src 
to gather more debug info.  I've appended the gdb backtrace from the segfault, 
dmesg, Xorg.0.log from startx as well as Xorg.0.log from the segfault.



## gdb bt ##
a8v2:home/rd 402>sudo gdb $(which Xorg) /var/crash/Xorg.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.5"...
Core was generated by `Xorg'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libpthread.so.18.0...done.
Loaded symbols for /usr/lib/libpthread.so.18.0
Loaded symbols for /usr/X11R6/bin/X
Symbols already loaded for /usr/lib/libpthread.so.18.0
Reading symbols from /usr/X11R6/lib/libpciaccess.so.2.0...done.
Loaded symbols for /usr/X11R6/lib/libpciaccess.so.2.0
Reading symbols from /usr/X11R6/lib/libdrm.so.4.1...done.
Loaded symbols for /usr/X11R6/lib/libdrm.so.4.1
Reading symbols from /usr/X11R6/lib/libpixman-1.so.32.4...done.
Loaded symbols for /usr/X11R6/lib/libpixman-1.so.32.4
Reading symbols from /usr/X11R6/lib/libpthread-stubs.so.2.0...done.
Loaded symbols for /usr/X11R6/lib/libpthread-stubs.so.2.0
Reading symbols from /usr/X11R6/lib/libXfont.so.11.0...done.
Loaded symbols for /usr/X11R6/lib/libXfont.so.11.0
Reading symbols from /usr/X11R6/lib/libfreetype.so.22.0...done.
Loaded symbols for /usr/X11R6/lib/libfreetype.so.22.0
Reading symbols from /usr/X11R6/lib/libfontenc.so.4.0...done.
Loaded symbols for /usr/X11R6/lib/libfontenc.so.4.0
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/X11R6/lib/libXau.so.10.0...done.
Loaded symbols for /usr/X11R6/lib/libXau.so.10.0
Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done.
Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0
Reading symbols from /usr/lib/libkvm.so.16.0...done.
Loaded symbols for /usr/lib/libkvm.so.16.0
Reading symbols from /usr/lib/libm.so.9.0...done.
Loaded symbols for /usr/lib/libm.so.9.0
Reading symbols from /usr/lib/libc.so.73.1...done.
Loaded symbols for /usr/lib/libc.so.73.1
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
Reading symbols from /usr/X11R6/lib/modules/drivers/apm_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/apm_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/ark_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/ark_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/ati_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/ati_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/chips_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/chips_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/cirrus_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/cirrus_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/dummy_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/dummy_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/glint_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/glint_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/i128_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/i128_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/intel_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/intel_drv.so
Reading symbols from /usr/X11R6/lib/libX11.so.16.0...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.16.0
Reading symbols from /usr/X11R6/lib/libxcb.so.3.0...done.
Loaded symbols for /usr/X11R6/lib/libxcb.so.3.0
Reading symbols from /usr/X11R6/lib/libdrm_intel.so.3.1...done.
Loaded symbols for /usr/X11R6/lib/libdrm_intel.so.3.1
Reading symbols from /usr/X11R6/lib/modules/drivers/mach64_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/mach64_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/mga_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/mga_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/neomagic_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/neomagic_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/nv_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/nv_drv.so
Reading symbols from /usr/X11R6/lib/modules/drivers/openchrome_drv.so...don

Re: How-to: dualboot Windows 8.1 and OpenBSD 5.4

[RD Thrush]

On 11/17/13 14:02, Nick Holland wrote:
> On 11/17/13 12:53, Wesley MOUEDINE ASSABY wrote:
>> Le 2013-11-17 20:27, dmitry.sensei a écrit :
>>> What about 1Tb disk? Is CHS mode correct for this disks?
>>
>> I done the test using Virtualization.
>> Not tried with a physical hard drive 1 TB.
> 
> The smallest common non-SSD laptop drive is probably around 500G now,
> and 1TB is routine on desktops.  At least some (many? most?) of these
> machines are now shipping with UEFI boot, and a lot of them will be
> pre-loaded with Windows, with minimal resources to reload Windows from
> scratch.
> 
> The target (and worst-case) audience is the person who bought a laptop
> or desktop pre-loaded with Windows 8, and wants to install OpenBSD with
> as little disruption to the existing system as possible.
> 
> I appreciate the efforts, but we need something more comprehensive.
> 
> Sounds like I need to go buy a modern Windows system. :-/

Although your FAQ warns about keeping the OpenBSD partition within the first
128G, this limit will be a showstopper for people unable to shrink the preloaded
windows partition below 128G.  I've appended a patch (with help from krw) that
helped me double the limit in July,2011 after the Extended partition support
changes[1] were added.

[1]

Index: biosvar.h
===
RCS file: /a8v/pub/cvsroot/OpenBSD/src/sys/arch/amd64/include/biosvar.h,v
retrieving revision 1.14
diff -u -p -w -b -u -r1.14 biosvar.h
--- biosvar.h   26 Apr 2011 17:33:17 -  1.14
+++ biosvar.h   27 Apr 2011 12:03:05 -
@@ -36,7 +36,7 @@
 #defineBOOTARG_OFF (NBPG*2)
 #defineBOOTARG_LEN (NBPG*1)
 #defineBOOTBIOS_ADDR   (0x7c00)
-#defineBOOTBIOS_MAXSEC ((1 << 28) - 1)
+#defineBOOTBIOS_MAXSEC ((1 << 29) - 1)

/* BIOS configure flags */
 #defineBIOSF_BIOS320x0001

Re: Intel i7-4770 + z87 chipset - drm error, re0 is missing lladdr, unknown + not configured

[RD Thrush]

On 10/10/13 17:48, RD Thrush wrote:
> I noticed some anomalies in the dmesg on this new system.
> 
> 1. error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before 
> writing to 10
> 
> 2. dhclient doesn't work with the onboard nic (possibly since the lladdr is 
> 0:0:0:0:0:0.
> 
> 3. (1) 'unknown' product(ppb0)
> 
> 4. (3) 'not configured' items (Intel 8 Series (xHCI|MEI|SMBus)
> 
> I've appended the dmesg, pcidump, biosdecode, dmidecode, and acpidump detail.
> 
> I'll be happy to gather more data, test patches, ...
> 
> TIA.

FWIW, I've collected some additional dmesg info from recent versions of freebsd 
and linux mint at the following links:

<http://arp.thrush.com/openbsd/z87-a/data/freebsd-10.0-alpha5/dmesg.serial-console>
<http://arp.thrush.com/openbsd/z87-a/data/mint15/dmesg>

freebsd seemed to have the same re0 problems originally noted although I didn't 
pursue it since it hung before giving a console prompt.

mint15 worked a little better but I don't know enough linux to get more than 
basic info. X info is at 
<http://arp.thrush.com/openbsd/z87-a/data/mint15/Xorg.0.log>

Re: Intel i7-4770 + z87 chipset - drm error, re0 is missing lladdr, unknown + not configured

[RD Thrush]

On 10/11/13 03:18, Jonathan Gray wrote:
> On Fri, Oct 11, 2013 at 02:39:30AM -0400, RD Thrush wrote:
>> On 10/11/13 01:05, Jonathan Gray wrote:
>>> On Thu, Oct 10, 2013 at 05:48:43PM -0400, RD Thrush wrote:
>>>> I noticed some anomalies in the dmesg on this new system.
>>>>
>>>> 1. error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register 
>>>> before writing to 10
>>>>
>>>> 2. dhclient doesn't work with the onboard nic (possibly since the lladdr 
>>>> is 0:0:0:0:0:0.
>>>
>>> There is no support for Realtek 8168G/8111G devices, here is a diff which
>>> apparently lacks some critical part required to make it work
>>> as it didn't work for the last person who tried it.
>>>
>>> Index: re.c
>>> ===
>>> RCS file: /cvs/src/sys/dev/ic/re.c,v
>>> retrieving revision 1.144
>>> diff -u -p -r1.144 re.c
>>> --- re.c5 Oct 2013 22:59:57 -   1.144
>>> +++ re.c9 Oct 2013 01:21:41 -
>>> @@ -223,6 +223,8 @@ static const struct re_revision {
>>> { RL_HWREV_8101,"RTL8101" },
>>> { RL_HWREV_8101E,   "RTL8101E" },
>>> { RL_HWREV_8102E,   "RTL8102E" },
>>> +   { RL_HWREV_8106E,   "RTL8106E" },
>>> +   { RL_HWREV_8106E_SPIN1, "RTL8106E" },
>>> { RL_HWREV_8401E,   "RTL8401E" },
>>> { RL_HWREV_8402,"RTL8402" },
>>> { RL_HWREV_8411,"RTL8411" },
>>> @@ -238,6 +240,10 @@ static const struct re_revision {
>>> { RL_HWREV_8168C_SPIN2, "RTL8168C/8111C" },
>>> { RL_HWREV_8168CP,  "RTL8168CP/8111CP" },
>>> { RL_HWREV_8168F,   "RTL8168F/8111F" },
>>> +   { RL_HWREV_8168G,   "RTL8168G/8111G" },
>>> +   { RL_HWREV_8168G_SPIN1, "RTL8168G/8111G" },
>>> +   { RL_HWREV_8168G_SPIN2, "RTL8168G/8111G" },
>>> +   { RL_HWREV_8168G_SPIN4, "RTL8168G/8111G" },
>>> { RL_HWREV_8105E,   "RTL8105E" },
>>> { RL_HWREV_8105E_SPIN1, "RTL8105E" },
>>> { RL_HWREV_8168D,   "RTL8168D/8111D" },
>>> @@ -846,6 +852,8 @@ re_attach(struct rl_softc *sc, const cha
>>> case RL_HWREV_8402:
>>> case RL_HWREV_8105E:
>>> case RL_HWREV_8105E_SPIN1:
>>> +   case RL_HWREV_8106E:
>>> +   case RL_HWREV_8106E_SPIN1:
>>> sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
>>> RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 |
>>> RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD |
>>> @@ -892,6 +900,15 @@ re_attach(struct rl_softc *sc, const cha
>>> RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
>>> RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_NOJUMBO;
>>> break;
>>> +   case RL_HWREV_8168G:
>>> +   case RL_HWREV_8168G_SPIN1:
>>> +   case RL_HWREV_8168G_SPIN2:
>>> +   case RL_HWREV_8168G_SPIN4:
>>> +   sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
>>> +   RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
>>> +   RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_NOJUMBO |
>>> +   RL_FLAG_EARLYOFF;
>>> +   break;
>>> case RL_HWREV_8169_8110SB:
>>> case RL_HWREV_8169_8110SBL:
>>> case RL_HWREV_8169_8110SCd:
>>> @@ -1974,6 +1991,7 @@ re_init(struct ifnet *ifp)
>>>  {
>>> struct rl_softc *sc = ifp->if_softc;
>>> u_int16_t   cfg;
>>> +   uint32_trxcfg;
>>> int s;
>>> union {
>>> u_int32_t align_dummy;
>>> @@ -2058,7 +2076,10 @@ re_init(struct ifnet *ifp)
>>>  
>>> CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16);
>>>  
>>> -   CSR_WRITE_4(sc, RL_RXCFG, RL_RXCFG_CONFIG);
>>> +   rxcfg = RL_RXCFG_CONFIG;
>>> +   if (sc->rl_flags & RL_FLAG_EARLYOFF)
>>> +   rxcfg |= RL_RXCFG_EARLYOFF;
>>> +   CSR_WRITE_4(sc, RL_RXCFG, rxcfg);
>>>  
>>> /* Program promiscuous mode and multicast filters. */
>>> re_iff(sc);
>>> Index: rtl81x9reg.h
>>> ===
>>> RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
>>> r

Re: Intel i7-4770 + z87 chipset - drm error, re0 is missing lladdr, unknown + not configured

[RD Thrush]

On 10/11/13 01:05, Jonathan Gray wrote:
> On Thu, Oct 10, 2013 at 05:48:43PM -0400, RD Thrush wrote:
>> I noticed some anomalies in the dmesg on this new system.
>>
>> 1. error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before 
>> writing to 10
>>
>> 2. dhclient doesn't work with the onboard nic (possibly since the lladdr is 
>> 0:0:0:0:0:0.
> 
> There is no support for Realtek 8168G/8111G devices, here is a diff which
> apparently lacks some critical part required to make it work
> as it didn't work for the last person who tried it.
> 
> Index: re.c
> ===
> RCS file: /cvs/src/sys/dev/ic/re.c,v
> retrieving revision 1.144
> diff -u -p -r1.144 re.c
> --- re.c  5 Oct 2013 22:59:57 -   1.144
> +++ re.c  9 Oct 2013 01:21:41 -
> @@ -223,6 +223,8 @@ static const struct re_revision {
>   { RL_HWREV_8101,"RTL8101" },
>   { RL_HWREV_8101E,   "RTL8101E" },
>   { RL_HWREV_8102E,   "RTL8102E" },
> + { RL_HWREV_8106E,   "RTL8106E" },
> + { RL_HWREV_8106E_SPIN1, "RTL8106E" },
>   { RL_HWREV_8401E,   "RTL8401E" },
>   { RL_HWREV_8402,"RTL8402" },
>   { RL_HWREV_8411,"RTL8411" },
> @@ -238,6 +240,10 @@ static const struct re_revision {
>   { RL_HWREV_8168C_SPIN2, "RTL8168C/8111C" },
>   { RL_HWREV_8168CP,  "RTL8168CP/8111CP" },
>   { RL_HWREV_8168F,   "RTL8168F/8111F" },
> + { RL_HWREV_8168G,   "RTL8168G/8111G" },
> + { RL_HWREV_8168G_SPIN1, "RTL8168G/8111G" },
> + { RL_HWREV_8168G_SPIN2, "RTL8168G/8111G" },
> + { RL_HWREV_8168G_SPIN4, "RTL8168G/8111G" },
>   { RL_HWREV_8105E,   "RTL8105E" },
>   { RL_HWREV_8105E_SPIN1, "RTL8105E" },
>   { RL_HWREV_8168D,   "RTL8168D/8111D" },
> @@ -846,6 +852,8 @@ re_attach(struct rl_softc *sc, const cha
>   case RL_HWREV_8402:
>   case RL_HWREV_8105E:
>   case RL_HWREV_8105E_SPIN1:
> + case RL_HWREV_8106E:
> + case RL_HWREV_8106E_SPIN1:
>   sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
>   RL_FLAG_PHYWAKE_PM | RL_FLAG_PAR | RL_FLAG_DESCV2 |
>   RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD |
> @@ -892,6 +900,15 @@ re_attach(struct rl_softc *sc, const cha
>   RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
>   RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_NOJUMBO;
>   break;
> + case RL_HWREV_8168G:
> + case RL_HWREV_8168G_SPIN1:
> + case RL_HWREV_8168G_SPIN2:
> + case RL_HWREV_8168G_SPIN4:
> + sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
> + RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
> + RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_NOJUMBO |
> + RL_FLAG_EARLYOFF;
> + break;
>   case RL_HWREV_8169_8110SB:
>   case RL_HWREV_8169_8110SBL:
>   case RL_HWREV_8169_8110SCd:
> @@ -1974,6 +1991,7 @@ re_init(struct ifnet *ifp)
>  {
>   struct rl_softc *sc = ifp->if_softc;
>   u_int16_t   cfg;
> + uint32_trxcfg;
>   int s;
>   union {
>   u_int32_t align_dummy;
> @@ -2058,7 +2076,10 @@ re_init(struct ifnet *ifp)
>  
>   CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16);
>  
> - CSR_WRITE_4(sc, RL_RXCFG, RL_RXCFG_CONFIG);
> + rxcfg = RL_RXCFG_CONFIG;
> + if (sc->rl_flags & RL_FLAG_EARLYOFF)
> + rxcfg |= RL_RXCFG_EARLYOFF;
> + CSR_WRITE_4(sc, RL_RXCFG, rxcfg);
>  
>   /* Program promiscuous mode and multicast filters. */
>   re_iff(sc);
> Index: rtl81x9reg.h
> ===
> RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
> retrieving revision 1.76
> diff -u -p -r1.76 rtl81x9reg.h
> --- rtl81x9reg.h  17 Mar 2013 20:47:23 -  1.76
> +++ rtl81x9reg.h  3 Aug 2013 13:54:57 -
> @@ -186,8 +186,14 @@
>  #define RL_HWREV_8105E   0x4080
>  #define RL_HWREV_8105E_SPIN1 0x40C0
>  #define RL_HWREV_84020x4400
> +#define RL_HWREV_8106E   0x4480
> +#define RL_HWREV_8106E_SPIN1 0x4490
>  #define RL_HWREV_8168F   0x4800
>  #define RL_HWREV_84110x4880
> +#define RL_HWREV_8168G   0x4c00
> +#define RL_HWREV_8168G_SPIN1 0x4c10
> +#define RL_HWREV_816

Re: Intel i7-4770 + z87 chipset - drm error, re0 is missing lladdr, unknown + not configured

[RD Thrush]

On 10/11/13 01:28, Jonathan Gray wrote:
> On Thu, Oct 10, 2013 at 05:48:43PM -0400, RD Thrush wrote:
>> I noticed some anomalies in the dmesg on this new system.
>>
>> 1. error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before 
>> writing to 10
> 
> That should be harmless, and will go away when we update to newer
> upstream i915 code that clears the error on driver init.
> 
>>
>> 2. dhclient doesn't work with the onboard nic (possibly since the lladdr is 
>> 0:0:0:0:0:0.
>>
>> 3. (1) 'unknown' product(ppb0)
>>
>> 4. (3) 'not configured' items (Intel 8 Series (xHCI|MEI|SMBus)
> 
> Index: ichiic.c
> ===
> RCS file: /cvs/src/sys/dev/pci/ichiic.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 ichiic.c
> --- ichiic.c  2 Mar 2013 06:56:16 -   1.30
> +++ ichiic.c  11 Oct 2013 05:12:13 -
> @@ -90,6 +90,7 @@ const struct pci_matchid ichiic_ids[] = 
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6300ESB_SMB },
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_SMB },
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_7SERIES_SMB },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_8SERIES_SMB },
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801AA_SMB },
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801AB_SMB },
>   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801BA_SMB },
> 

Thanks, this patch removed the SMBus unknown from the dmesg.  See my next post
for full dmesg.

Re: Intel i7-4770 + z87 chipset - drm error, re0 is missing lladdr, unknown + not configured

[RD Thrush]

On 10/10/13 19:31, Brett Mahar wrote:
> On Thu, 10 Oct 2013 17:48:43 -0400
> RD Thrush  wrote:
> 
> | I noticed some anomalies in the dmesg on this new system.
> | 
> ...
> | 
> | 2. dhclient doesn't work with the onboard nic (possibly since the lladdr is 
> 0:0:0:0:0:0.
> 
> You could check this by adding a random lladdr line to your /etc/hostname.re0
> 
> lladdr 22:a4:cf:85:64:b9
> up
> dhcp
> 
> and the running "sh /etc/netstart".

Thanks, (on the dhcpd hosts) I 'created' another dhcpd.conf stanza with a 
matching (new) lladdr and now dhcp succeeds.  arping seems to work but ping 
doesn't work and tcpdump -i re0 -envvv shows some bad checksums.  netstat -nr 
output *doesn'* show link#1 for the dhcp IP address(10.1.2.30).

Here's some further detail:

a8v2:build/packages 36#sh /etc/netstart re0
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPACK from 10.1.2.18 (00:02:b3:ca:06:00)
bound to 10.1.2.30 -- renewal in 302400 seconds.
a8v2:build/packages 37#tcpdump -i re0 -envvv
tcpdump: listening on re0, link-type EN10MB
tcpdump: WARNING: compensating for unaligned libpcap packets
00:07:12.995766 00:22:15:2c:7d:fc 00:30:18:a3:1b:48 0800 78: 10.1.2.30.46241 > 
10.1.2.13.3551: S [bad tcp cksum a37b!] 1450186406:1450186406(0) win 16384  (DF) (ttl 64, 
id 44914, len 64, bad cksum 0! differs by 7319)
00:07:13.342214 bc:ae:c5:86:d9:cb 33:33:00:00:00:0c 86dd 208: 
fe80::e074:611b:ae16:65aa.54842 > ff02::c.1900: udp 146 [hlim 1] (len 154)
tcpdump: WARNING: compensating for unaligned libpcap packets
00:07:16.343225 bc:ae:c5:86:d9:cb 33:33:00:00:00:0c 86dd 208: 
fe80::e074:611b:ae16:65aa.54842 > ff02::c.1900: udp 146 [hlim 1] (len 154)
00:07:18.005627 00:22:15:2c:7d:fc 00:30:18:a3:1b:48 0800 78: 10.1.2.30.7166 > 
10.1.2.13.3551: S [bad tcp cksum e7a1!] 1750099443:1750099443(0)
 win 16384  (DF) (ttl 64, id 31832, len 64, bad cksum 0! differs by a633)
00:07:19.343500 bc:ae:c5:86:d9:cb 33:33:00:00:00:0c 86dd 208: 
fe80::e074:611b:ae16:65aa.54842 > ff02::c.1900: udp 146 [hlim 1] (len 154)
00:07:20.980721 30:85:a9:9a:6d:f0 ff:ff:ff:ff:ff:ff 0800 144: 10.1.2.40.17500 > 
255.255.255.255.17500: udp 102 (ttl 128, id 3544, len 130)
00:07:20.993563 30:85:a9:9a:6d:f0 ff:ff:ff:ff:ff:ff 0800 144: 10.1.2.40.17500 > 
255.255.255.255.17500: udp 102 (ttl 128, id 3545, len 130)
00:07:20.993822 30:85:a9:9a:6d:f0 ff:ff:ff:ff:ff:ff 0800 144: 10.1.2.40.17500 > 
10.1.2.255.17500: udp 102 (ttl 128, id 12521, len 130)
00:07:23.344174 bc:ae:c5:86:d9:cb 33:33:00:00:00:0c 86dd 208: 
fe80::e074:611b:ae16:65aa.54842 > ff02::c.1900: udp 146 [hlim 1] (len 154)
00:07:24.441081 bc:ae:c5:86:d9:cb ff:ff:ff:ff:ff:ff 0800 153: 10.1.2.35.17500 > 
255.255.255.255.17500: udp 111 (ttl 128, id 4141, len 139)
00:07:24.446438 bc:ae:c5:86:d9:cb ff:ff:ff:ff:ff:ff 0800 153: 10.1.2.35.17500 > 
10.1.2.255.17500: udp 111 (ttl 128, id 4142, len 139)
00:07:26.061193 00:0d:a2:01:7e:88 01:00:5e:7f:ff:fa 0800 304: 10.1.2.11.50001 > 
239.255.255.250.1900: udp 262 (DF) [ttl 1] (id 0, len 290)
00:07:26.061389 00:1f:33:eb:05:e9 01:00:5e:7f:ff:fa 0800 304: 10.1.2.15.50001 > 
239.255.255.250.1900: udp 262 (DF) [ttl 1] (id 0, len 290)
00:07:26.061527 00:1f:33:ea:36:d1 01:00:5e:7f:ff:fa 0800 304: 10.1.2.12.50001 > 
239.255.255.250.1900: udp 262 (DF) [ttl 1] (id 0, len 290)
00:07:26.345178 bc:ae:c5:86:d9:cb 33:33:00:00:00:0c 86dd 208: 
fe80::e074:611b:ae16:65aa.54842 > ff02::c.1900: udp 146 [hlim 1] (len 154)
^C
15 packets received by filter
0 packets dropped by kernel
a8v2:build/packages 38#ifconfig re0 hwfeatures
re0: flags=8843 mtu 1500

hwfeatures=8037 
hardmtu 7422
lladdr 00:22:15:2c:7d:fc
priority: 0
groups: int egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 10.1.2.30 netmask 0xff00 broadcast 10.1.2.255
a8v2:build/packages 39#netstat -nr -finet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default10.1.2.1   UGS0   24 - 8 re0
10.1.2/24  link#1 UC100 - 4 re0
10.1.2.1   00:00:24:c9:29:14  UHLc   1   12 - 4 re0
10.1.2.10  00:e0:4c:77:6d:ab  UHLc   06 - 4 re0
10.1.2.11  00:0d:a2:01:7e:88  UHLc   04 - 4 re0
10.1.2.12  00:1f:33:ea:36:d1  UHLc   06 - 4 re0
10.1.2.13  00:30:18:a3:1b:48  UHLc   0  240 - 4 re0
10.1.2.15  00:1f:33:eb:05:e9  UHLc   06 - 4 re0
10.1.2.18  00:02:b3:ca:06:00  UHLc   2   42 - 4 re0
10.1.2.31  00:1b:21:2e:39:c4  UHLc   0   16 - 4 re0
10.1.2.33  00:22:15:2c:7d:0b  UHLc   01 - 4 re0
10.1.2.255 link#1 UHLc   2  121 - 

Re: Help troubleshooting ehci_idone hang.

[RD Thrush]

On 09/12/13 10:34, Martin Pieuchot wrote:
> On 12/09/13(Thu) 08:16, RD Thrush wrote:
>> On 09/12/13 05:15, Martin Pieuchot wrote:
>>> [...]
>>>
>>> Could you try the diff below on the v1 machine and tell me if it helps?
>>
>> Thanks, I don't think it helped...
> 
> By looking at your new log, I believe it did ;)
> 
>> After booting the new kernel, upon first use of the kvm switch, the serial
>> console began filling with diagnostics which (to my untrained eye) looked
>> similar to the pre-patch session. v1-2.  Since I was unable to remotely ssh, 
>> I
>> interrupted ddb and set ehcidebug=1 but was unable to remotely ssh.  
>> ehcidebug=0
>> allowed remote ssh and normal operations resumed.
>>
>> <http://arp.thrush.com/openbsd/ehci_idone/v1/v1-3> has the associated serial
>> console.
>>
>> Let me know if I can provide further info.
> 
> Could you reproduce once again this manipulation with the diff below
> applied on top of the previous one?

<http://arp.thrush.com/openbsd/ehci_idone/v1/v1-4> has the results after adding
your diff.

I'm assuming the continual diagnostic output is expected with ehcidebug=5.
Interrupting ddb, setting ehcidebug=1 and continuing ddb still hits my panic
hack; however, I'll assume that's due to the crudeness of my hack.  I did
subsequently reboot with the same custom kernel w/ ehcidebug=0 and didn't hit
the panic hack.

What's the next step?


>>>> WRT to the other machine, x4, I installed the patch and have not yet had a
>>>> problem.  However, with ehcidebug=5, the following 2 line message is issued
>>>> about once per second:
>>>> ehci_intrlist_timeout
>>>> ehci_check_intr: ex=0x80238c00
>>>
>>> That's expected, thanks for confirming the problem cannot be reproduced
>>> with this diff with an ATI controller.
>>
>> Since the problem has been intermittent since Nov 2012, I'm not sure enough
>> time/kvm usage has occurred for certainty about that fix.
> 
> Since this diff is a backport of what has been done in FreeBSD and I
> already had a similar report from another developer with the same
> controller, I'm quite confident.
> 
>> I will run a custom MP kernel with your pci/ehci_pci.c patch on the x4 
>> machine
>> whenever I install a new snapshot and let you know if I notice the 
>> ehci_idone issue.
> 
> Please let me know.
> 
> Index: uhidev.c
> ===
> RCS file: /home/ncvs/src/sys/dev/usb/uhidev.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 uhidev.c
> --- uhidev.c  7 May 2013 08:44:38 -   1.44
> +++ uhidev.c  12 Sep 2013 14:25:52 -
> @@ -393,7 +393,7 @@ uhidev_intr(struct usbd_xfer *xfer, void
>   }
>  #endif
>  
> - if (status == USBD_CANCELLED)
> + if (status == USBD_CANCELLED || status == USBD_IOERROR)
>   return;
>  
>   if (status != USBD_NORMAL_COMPLETION) {

Re: Help troubleshooting ehci_idone hang.

[RD Thrush]

On 09/12/13 05:15, Martin Pieuchot wrote:
> On 11/09/13(Wed) 11:03, RD Thrush wrote:
>> On 09/10/13 07:56, Martin Pieuchot wrote:
>>> On 10/09/13(Tue) 07:15, RD Thrush wrote:
>>>> On 09/10/13 04:42, Martin Pieuchot wrote:
>>>>> [...]
>>>>>
>>>>> Thanks for this detailed bug report.
>>>>>
>>>>> You're saying that you have 2 amd64 systems with the same problem but
>>>>> I see only the dmesg for one machine, does the other has the same ehci
>>>>> controller?
>>>>
>>>> Apparently one is ATI and the other Intel.  
>>>> <http://arp.thrush.com/openbsd/ehci_idone/v1/> has two console captures, 
>>>> "v1.1" and "v1.2", for the other machine after an ehci_idone hang (I 
>>>> hadn't made the panic patch yet).  I was able to generate a ddb interrupt 
>>>> to stop the spew and gather some additional ddb info.  The forementioned 
>>>> directory also has acpidump, pcidump, biosdecode, and dmidecode previously 
>>>> collected from the same kernel.
>>>>
>>>> If you want/need further info about the 'v1' machine, let me know and I'll 
>>>> boot OpenBSD and get the info.
>>>
>>> It would be nice if you could reproduce the manipulation you did with
>>> the other machine and set ehcidebug to 5 before switching your kvm.
>>
>> With ehcidebug=5 on the v1 machine, switching the kvm resulted in a continual
>> ddb loop,  I wasn't able to generate a ddb interrupt via the serial console;
>> however, the pc keyboard was able to drop into ddb where I collected some
>> additional info.
>>
>> 'boot sync' resulted in the panic I'd patched (earlier in thread) to stop the
>> initial hang.  I had to do a hard reset to regain control.
>>
>> <http://arp.thrush.com/openbsd/ehci_idone/v1/v1-2> has the capture of the 
>> serial
>> console for that session.
> 
> Could you try the diff below on the v1 machine and tell me if it helps?

Thanks, I don't think it helped...

After booting the new kernel, upon first use of the kvm switch, the serial
console began filling with diagnostics which (to my untrained eye) looked
similar to the pre-patch session. v1-2.  Since I was unable to remotely ssh, I
interrupted ddb and set ehcidebug=1 but was unable to remotely ssh.  ehcidebug=0
allowed remote ssh and normal operations resumed.

<http://arp.thrush.com/openbsd/ehci_idone/v1/v1-3> has the associated serial
console.

Let me know if I can provide further info.

>> WRT to the other machine, x4, I installed the patch and have not yet had a
>> problem.  However, with ehcidebug=5, the following 2 line message is issued
>> about once per second:
>> ehci_intrlist_timeout
>> ehci_check_intr: ex=0x80238c00
> 
> That's expected, thanks for confirming the problem cannot be reproduced
> with this diff with an ATI controller.

Since the problem has been intermittent since Nov 2012, I'm not sure enough
time/kvm usage has occurred for certainty about that fix.

I will run a custom MP kernel with your pci/ehci_pci.c patch on the x4 machine
whenever I install a new snapshot and let you know if I notice the ehci_idone 
issue.


> Index: usbdi.c
> ===
> RCS file: /home/ncvs/src/sys/dev/usb/usbdi.c,v
> retrieving revision 1.58
> diff -u -p -r1.58 usbdi.c
> --- usbdi.c   6 Sep 2013 08:29:58 -   1.58
> +++ usbdi.c   12 Sep 2013 08:47:09 -
> @@ -810,6 +810,8 @@ usb_transfer_complete(struct usbd_xfer *
>   if (!repeat) {
>   /* XXX should we stop the queue on all errors? */
>   if ((xfer->status == USBD_CANCELLED ||
> +  xfer->status == USBD_IOERROR ||
> +  xfer->status == USBD_STALLED ||
>xfer->status == USBD_TIMEOUT) &&
>   pipe->iface != NULL)/* not control pipe */
>   pipe->running = 0;

Re: Help troubleshooting ehci_idone hang.

[RD Thrush]

On 09/10/13 07:56, Martin Pieuchot wrote:
> On 10/09/13(Tue) 07:15, RD Thrush wrote:
>> On 09/10/13 04:42, Martin Pieuchot wrote:
>>> [...]
>>>
>>> Thanks for this detailed bug report.
>>>
>>> You're saying that you have 2 amd64 systems with the same problem but
>>> I see only the dmesg for one machine, does the other has the same ehci
>>> controller?
>>
>> Apparently one is ATI and the other Intel.  
>> <http://arp.thrush.com/openbsd/ehci_idone/v1/> has two console captures, 
>> "v1.1" and "v1.2", for the other machine after an ehci_idone hang (I hadn't 
>> made the panic patch yet).  I was able to generate a ddb interrupt to stop 
>> the spew and gather some additional ddb info.  The forementioned directory 
>> also has acpidump, pcidump, biosdecode, and dmidecode previously collected 
>> from the same kernel.
>>
>> If you want/need further info about the 'v1' machine, let me know and I'll 
>> boot OpenBSD and get the info.
> 
> It would be nice if you could reproduce the manipulation you did with
> the other machine and set ehcidebug to 5 before switching your kvm.

With ehcidebug=5 on the v1 machine, switching the kvm resulted in a continual
ddb loop,  I wasn't able to generate a ddb interrupt via the serial console;
however, the pc keyboard was able to drop into ddb where I collected some
additional info.

'boot sync' resulted in the panic I'd patched (earlier in thread) to stop the
initial hang.  I had to do a hard reset to regain control.

<http://arp.thrush.com/openbsd/ehci_idone/v1/v1-2> has the capture of the serial
console for that session.


WRT to the other machine, x4, I installed the patch and have not yet had a
problem.  However, with ehcidebug=5, the following 2 line message is issued
about once per second:
ehci_intrlist_timeout
ehci_check_intr: ex=0x80238c00

That periodic message did not occur with the v1 machine.

Sorry for the delay in reporting...

Re: Help troubleshooting ehci_idone hang.

[RD Thrush]

On 09/10/13 07:56, Martin Pieuchot wrote:
> On 10/09/13(Tue) 07:15, RD Thrush wrote:
>> On 09/10/13 04:42, Martin Pieuchot wrote:
>>> [...]
>>>
>>> Thanks for this detailed bug report.
>>>
>>> You're saying that you have 2 amd64 systems with the same problem but
>>> I see only the dmesg for one machine, does the other has the same ehci
>>> controller?
>>
>> Apparently one is ATI and the other Intel.  
>> <http://arp.thrush.com/openbsd/ehci_idone/v1/> has two console captures, 
>> "v1.1" and "v1.2", for the other machine after an ehci_idone hang (I hadn't 
>> made the panic patch yet).  I was able to generate a ddb interrupt to stop 
>> the spew and gather some additional ddb info.  The forementioned directory 
>> also has acpidump, pcidump, biosdecode, and dmidecode previously collected 
>> from the same kernel.
>>
>> If you want/need further info about the 'v1' machine, let me know and I'll 
>> boot OpenBSD and get the info.
> 
> It would be nice if you could reproduce the manipulation you did with
> the other machine and set ehcidebug to 5 before switching your kvm.
> 
>>> The problem you are seeing is related to the way ehci transfers are
>>> aborted.  The abortion process is subtly broken.
>>>
>>> For the archives what happens in your case is that the timeout for
>>> one of the transfers fires and enqueue an abort task (ehci_timeout
>>> in your log).  This abort task get scheduled tries to deactivate
>>> the qTDs, asks for an Interrupt on Async Advance Doorbell and goes
>>> to sleep (ehci_sync_hc in your log).
>>> Then the interrupt happens (ehci_intr1: door bell), wakeups the
>>> task and goes into the softinterrupt path to process the finished
>>> transfers.  Here the driver discovers that the transfer that timed
>>> out is finished (whoa!) and tries to handles it.  But since this 
>>> transfer has been marked as TIMEOUT (ehci_idone: aborted in your
>>> log), it does nothing and bails.  
>>>
>>> Apparently the abort task never get rescheduled and your transfer
>>> is never removed from the list, certainly because the hardware 
>>> keeps interrupting your systems, so you're livelock ;)
>>>
>>> But all of that happens because a timeout fires for one of your
>>> transfers, apparently some ATI controllers needs one more quirk,
>>> as your problem looks like a dropped interrupt.  Does the diff
>>> below helps?
>>
>> Thank you very much for the detailed analysis and patch.  I'll build a 
>> -current kernel and try it.
>>
>> Would there be a complementary patch for the (above) Intel ehci controller?
> 
> I'm not even sure this will avoid your problem, a proper fix would be to
> stop trying to deactivate the transfer descriptors, as it obviously
> doesn't work, and just remove them from the list.  Does anybody want to
> take the time to do that? :)
> 
> Otherwise you can just buy a non crappy kvm ;)

Does anyone have suggestions for a non-crappy kvm?

For the record, this crappy kvm is a Trendnet TK-407.

Re: Help troubleshooting ehci_idone hang.

[RD Thrush]

On 09/10/13 04:42, Martin Pieuchot wrote:
> Hi Bob,
> 
> On 07/09/13(Sat) 08:14, RD Thrush wrote:
>> Since appx. November, 2012, I've had 2 amd64 systems hang while
>> spewing "ehci_idone: ex=0x80.. is done!" messages to the
>> serial console.  The hangs are intermittent.  The system is
>> unresponsive to the keyboard and doesn't respond to network ping.  A
>> hardware reset is necessary to regain control.
>>
>> In order to help troubleshoot, I patched /usr/src/sys/dev/usb/ehci.c
>> to panic when the forementioned message had occurred 9 times and then
>> built a custom kernel with EHCI_DEBUG defined.  In the past day, the
>> new panic has occurred on the same machine with both an mp and sp
>> kernel and I have collected basic ddb information as well as crash
>> dumps.
>>
>> Will the ddb results from my patch [below] help troubleshoot the hang?
>> If so, the largish console logs, usbdevs, pcidump and acpidump are
>> located at <http://arp.thrush.com/openbsd/ehci_idone/x4/>.
>>
>> NB: ehcidebug=0 in the sp session, while ehcidebug=3 or 2 in the mp session.
>> Setting ehcidebug=3 seemed to hang but I was able to interrupt ddb, set
>> ehcidebug=2 and continue the ddb session.
>>
>> I appreciate any help diagnosing this problem.
> 
> Thanks for this detailed bug report.
> 
> You're saying that you have 2 amd64 systems with the same problem but
> I see only the dmesg for one machine, does the other has the same ehci
> controller?

Apparently one is ATI and the other Intel.  
<http://arp.thrush.com/openbsd/ehci_idone/v1/> has two console captures, "v1.1" 
and "v1.2", for the other machine after an ehci_idone hang (I hadn't made the 
panic patch yet).  I was able to generate a ddb interrupt to stop the spew and 
gather some additional ddb info.  The forementioned directory also has 
acpidump, pcidump, biosdecode, and dmidecode previously collected from the same 
kernel.

If you want/need further info about the 'v1' machine, let me know and I'll boot 
OpenBSD and get the info.


x4:
x2:x4/ehci_idone 1481>egrep 'ehci[0-9]' console.mp | grep -w at
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00ehci0: offs=32
usb0 at ehci0: USB revision 2.0
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00ehci1: offs=32
usb1 at ehci1: USB revision 2.0

v1:
x2:v1/ehci_idone 1479>egrep 'ehci[0-9]' v1.1 | grep -w at
ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 23
usb0 at ehci0: USB revision 2.0
ehci1 at pci0 dev 29 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 23
usb1 at ehci1: USB revision 2.0


> The problem you are seeing is related to the way ehci transfers are
> aborted.  The abortion process is subtly broken.
> 
> For the archives what happens in your case is that the timeout for
> one of the transfers fires and enqueue an abort task (ehci_timeout
> in your log).  This abort task get scheduled tries to deactivate
> the qTDs, asks for an Interrupt on Async Advance Doorbell and goes
> to sleep (ehci_sync_hc in your log).
> Then the interrupt happens (ehci_intr1: door bell), wakeups the
> task and goes into the softinterrupt path to process the finished
> transfers.  Here the driver discovers that the transfer that timed
> out is finished (whoa!) and tries to handles it.  But since this 
> transfer has been marked as TIMEOUT (ehci_idone: aborted in your
> log), it does nothing and bails.  
> 
> Apparently the abort task never get rescheduled and your transfer
> is never removed from the list, certainly because the hardware 
> keeps interrupting your systems, so you're livelock ;)
> 
> But all of that happens because a timeout fires for one of your
> transfers, apparently some ATI controllers needs one more quirk,
> as your problem looks like a dropped interrupt.  Does the diff
> below helps?

Thank you very much for the detailed analysis and patch.  I'll build a -current 
kernel and try it.

Would there be a complementary patch for the (above) Intel ehci controller?


> Index: pci/ehci_pci.c
> ===
> RCS file: /home/ncvs/src/sys/dev/pci/ehci_pci.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 ehci_pci.c
> --- pci/ehci_pci.c15 Apr 2013 09:23:01 -  1.26
> +++ pci/ehci_pci.c10 Sep 2013 08:19:28 -
> @@ -204,10 +204,16 @@ ehci_pci_attach(struct device *parent, s
>   else
>   snprintf(sc->sc.sc_vendor, sizeof(sc->sc.sc_vendor),
>   "vendor 0x%04x", PCI_VENDOR(pa->pa_id));
> - 
> +
>   /* Enab

Help troubleshooting ehci_idone hang.

[RD Thrush]

Since appx. November, 2012, I've had 2 amd64 systems hang while
spewing "ehci_idone: ex=0x80.. is done!" messages to the
serial console.  The hangs are intermittent.  The system is
unresponsive to the keyboard and doesn't respond to network ping.  A
hardware reset is necessary to regain control.

In order to help troubleshoot, I patched /usr/src/sys/dev/usb/ehci.c
to panic when the forementioned message had occurred 9 times and then
built a custom kernel with EHCI_DEBUG defined.  In the past day, the
new panic has occurred on the same machine with both an mp and sp
kernel and I have collected basic ddb information as well as crash
dumps.

Will the ddb results from my patch [below] help troubleshoot the hang?
If so, the largish console logs, usbdevs, pcidump and acpidump are
located at .

NB: ehcidebug=0 in the sp session, while ehcidebug=3 or 2 in the mp session.
Setting ehcidebug=3 seemed to hang but I was able to interrupt ddb, set
ehcidebug=2 and continue the ddb session.

I appreciate any help diagnosing this problem.

Thanks, Bob


Index: dev/usb/ehci.c
===
RCS file: /pub2/cvsroot/OpenBSD/src/sys/dev/usb/ehci.c,v
retrieving revision 1.134
diff -u -p -w -b -u -r1.134 ehci.c
--- dev/usb/ehci.c  12 Jun 2013 11:42:01 -  1.134
+++ dev/usb/ehci.c  12 Jun 2013 12:47:18 -
@@ -81,6 +81,8 @@ struct cfdriver ehci_cd = {
 #define DPRINTF(x) do { if (ehcidebug) printf x; } while(0)
 #define DPRINTFN(n,x)  do { if (ehcidebug>(n)) printf x; } while (0)
 int ehcidebug = 0;
+int ehcicount = 0;
+int ehcicount_max = 10; /* panic - use ddb to gather more info before 
restarting */
 #define bitmask_snprintf(q,f,b,l) snprintf((b), (l), "%b", (q), (f))
 #else
 #define DPRINTF(x)
@@ -808,12 +810,15 @@ ehci_idone(struct ehci_xfer *ex)
{
int s = splhigh();
if (ex->isdone) {
+   if ( ++ehcicount >= ehcicount_max ) {
+   panic("ehci_idone: ex is done!\n");
+   }
splx(s);
 #ifdef EHCI_DEBUG
-   printf("ehci_idone: ex is done!\n   ");
+   printf("ehci_idone: ex is done!ehcicount=%d\n   ", 
ehcicount);
ehci_dump_exfer(ex);
 #else
-   printf("ehci_idone: ex=%p is done!\n", ex);
+   printf("ehci_idone: ex=%p is done!ehcicount=%d\n", ex, 
ehcicount);
 #endif
return;
}

Unexpected results from boot(8) "machine memory" configuration

[RD Thrush]

I expected "machine memory =1G" to reduce the memory size of this system from 
8GB to 1GB.  After the first invocation, free memory is reduced to ~6GB.  The 
second invocation results in the expected ~1GB free memory.

My intention is to limit the size of a subsequent crash dump.  I'm surprised it 
took two invocations to get the expected results.

Thanks in advance for helping me better understand this issue.


syncing disks... done
rebooting...
>> OpenBSD/amd64 BOOT 3.23
boot> machine memory
Region 0: type 1 at 0x0 for 630KB
Region 1: type 2 at 0x9d800 for 10KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 3135984KB
Region 4: type 4 at 0xbf77c000 for 288KB
Region 5: type 3 at 0xbf7c4000 for 32KB
Region 6: type 2 at 0xbf7cc000 for 16KB
Region 7: type 4 at 0xbf7d for 16KB
Region 8: type 2 at 0xbf7d4000 for 2496KB
Region 9: type 4 at 0xbfa44000 for 28KB
Region 10: type 2 at 0xbfa4b000 for 160KB
Region 11: type 4 at 0xbfa73000 for 2060KB
Region 12: type 1 at 0xbfc76000 for 2600KB
Region 13: type 1 at 0x11000 for 4964348KB
Region 14: type 2 at 0xe000 for 262144KB
Region 15: type 2 at 0xfec0 for 4KB
Region 16: type 2 at 0xfec1 for 4KB
Region 17: type 2 at 0xfed0 for 4KB
Region 18: type 2 at 0xfed61000 for 64KB
Region 19: type 2 at 0xfed8 for 64KB
Region 20: type 2 at 0xff00 for 16384KB
Low ram: 630KB  High ram: 3135984KB
Total free memory: 8103562KB
boot> machine memory =1G
Region 0: type 1 at 0x0 for 630KB
Region 1: type 2 at 0x9d800 for 10KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 1047552KB
Region 4: type 4 at 0xbf77c000 for 288KB
Region 5: type 3 at 0xbf7c4000 for 32KB
Region 6: type 2 at 0xbf7cc000 for 16KB
Region 7: type 4 at 0xbf7d for 16KB
Region 8: type 2 at 0xbf7d4000 for 2496KB
Region 9: type 4 at 0xbfa44000 for 28KB
Region 10: type 2 at 0xbfa4b000 for 160KB
Region 11: type 4 at 0xbfa73000 for 2060KB
Region 12: type 1 at 0x11000 for 4964348KB
Region 13: type 2 at 0xe000 for 262144KB
Region 14: type 2 at 0xfec0 for 4KB
Region 15: type 2 at 0xfec1 for 4KB
Region 16: type 2 at 0xfed0 for 4KB
Region 17: type 2 at 0xfed61000 for 64KB
Region 18: type 2 at 0xfed8 for 64KB
Region 19: type 2 at 0xff00 for 16384KB
Low ram: 630KB  High ram: 3135984KB
Total free memory: 6012530KB
boot> machine memory =1G
Region 0: type 1 at 0x0 for 630KB
Region 1: type 2 at 0x9d800 for 10KB
Region 2: type 2 at 0xe for 128KB
Region 3: type 1 at 0x10 for 1047552KB
Region 4: type 4 at 0xbf77c000 for 288KB
Region 5: type 3 at 0xbf7c4000 for 32KB
Region 6: type 2 at 0xbf7cc000 for 16KB
Region 7: type 4 at 0xbf7d for 16KB
Region 8: type 2 at 0xbf7d4000 for 2496KB
Region 9: type 4 at 0xbfa44000 for 28KB
Region 10: type 2 at 0xbfa4b000 for 160KB
Region 11: type 4 at 0xbfa73000 for 2060KB
Region 12: type 2 at 0xe000 for 262144KB
Region 13: type 2 at 0xfec0 for 4KB
Region 14: type 2 at 0xfec1 for 4KB
Region 15: type 2 at 0xfed0 for 4KB
Region 16: type 2 at 0xfed61000 for 64KB
Region 17: type 2 at 0xfed8 for 64KB
Region 18: type 2 at 0xff00 for 16384KB
Low ram: 630KB  High ram: 3135984KB
Total free memory: 1048182KB
boot> boot
booting hd0a:/bsd: 6503036+1639852+1076056+0+623264 [80+552312+368725]=0xe453c0
entry point at 0x10001e0 [7205c766, 3404, 24448b12, b958a304]
[ using 921888 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.4-current (GENERIC.MP) #44: Mon Aug 19 17:02:07 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1056964608 (1008MB)
avail mem = 1020780544 (973MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb0c0 (17 entries)
bios0: vendor American Megatrends Inc. version "P1.60" date 05/29/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) [...]
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.45 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC
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: smt 0, core 0, packag

sppp_clear_ip_addresses() patch (was Re: splassert: assertwaitok: want -1 have 1 - possibly pppoe related)

[RD Thrush]

On 06/27/12 10:59, RD Thrush wrote:
> On 06/26/12 12:36, Matthew Dempsky wrote:
>> This looks similar to the pppoe(4) bug that stsp fixed last year:
>> http://marc.info/?l=openbsd-tech&m=130288210121749&w=2
>>
>> Seems to me like sppp_clear_ip_addresses() needs the same workq
>> treatment that sppp_set_ip_addresses() received.
> 
> Thanks for the heads up.  I made the attached patch and have been running with
> it for the past 3 hours.  So far, it has successfully gone through 7 
> disconnects
> without the stack trace diagnostic.  I'll report more later unless breakage 
> occurs.

Status update:

While running the patch, my DSL continued to fail in the same way for another 
day or so until full service was regained.  During that time, it handled 30+ 
disconnections without triggering the stack trace diagnostic.  I'm confident 
the patch fixed my problem and may be considered for the tree.

Thanks, Bob

I've appended the patch inline or [1] if tbird mangles it.
[1]<http://arp.thrush.com/openbsd/pppoe/sys_net_if_spppsubr_c.diff>


Give sppp_clear_ip_addresses() the same workq treatment
that sppp_set_ip_addresses() received in cvs r1.85 by stsp.

Index: sys/net/if_spppsubr.c
===
RCS file: /a8v/pub2/cvsroot/OpenBSD/src/sys/net/if_spppsubr.c,v
retrieving revision 1.96
diff -u -p -u -p -r1.96 if_spppsubr.c
--- sys/net/if_spppsubr.c   28 Jan 2012 12:14:45 -  1.96
+++ sys/net/if_spppsubr.c   27 Jun 2012 11:35:01 -
@@ -398,7 +398,7 @@ HIDE void sppp_qflush(struct ifqueue *if
 int sppp_update_gw_walker(struct radix_node *rn, void *arg, u_int);
 void sppp_update_gw(struct ifnet *ifp);
 HIDE void sppp_set_ip_addrs(void *, void *);
-HIDE void sppp_clear_ip_addrs(struct sppp *sp);
+HIDE void sppp_clear_ip_addrs(void *, void *);
 HIDE void sppp_set_phase(struct sppp *sp);
 
 /* our control protocol descriptors */
@@ -3014,6 +3014,10 @@ struct sppp_set_ip_addrs_args {
u_int32_t hisaddr;
 };
 
+struct sppp_clear_ip_addrs_args {
+   struct sppp *sp;
+};
+
 HIDE void
 sppp_ipcp_tlu(struct sppp *sp)
 {
@@ -3035,6 +3039,7 @@ sppp_ipcp_tlu(struct sppp *sp)
(sp->ipcp.flags & IPCP_HISADDR_SEEN))
args->hisaddr = sp->ipcp.req_hisaddr;
 
+   printf("%s: workq_add_task(sppp_set_ip_addrs)\n", ifp->if_xname); /* 
XXX */
if (workq_add_task(NULL, 0, sppp_set_ip_addrs, args, NULL)) {
free(args, M_TEMP);
printf("%s: workq_add_task failed, cannot set "
@@ -3096,9 +3101,23 @@ sppp_ipcp_tls(struct sppp *sp)
 HIDE void
 sppp_ipcp_tlf(struct sppp *sp)
 {
+   struct ifnet *ifp = &sp->pp_if;
+   struct sppp_clear_ip_addrs_args *args;
+
+   args = malloc(sizeof(*args), M_TEMP, M_NOWAIT);
+   if (args == NULL)
+   return;
+
+   args->sp = sp;
+
if (sp->ipcp.flags & (IPCP_MYADDR_DYN|IPCP_HISADDR_DYN))
/* Some address was dynamic, clear it again. */
-   sppp_clear_ip_addrs(sp);
+   printf("%s: workq_add_task(sppp_clear_ip_addrs)\n", 
ifp->if_xname); /* XXX */
+   if (workq_add_task(NULL, 0, sppp_clear_ip_addrs, args, NULL)) {
+   free(args, M_TEMP);
+   printf("%s: workq_add_task failed, cannot clear "
+   "addresses\n", ifp->if_xname);
+   }
 
/* we no longer need LCP */
sp->lcp.protos &= ~(1 << IDX_IPCP);
@@ -4755,21 +4774,33 @@ sppp_set_ip_addrs(void *arg1, void *arg2
return;
}
sppp_update_gw(ifp);
+   log(LOG_DEBUG, SPP_FMT "sppp_set_ip_addrs succeeded\n", 
SPP_ARGS(ifp)); /* XXX */
}
splx(s);
 }
 
 /*
- * Clear IP addresses.  Must be called at splnet.
+ * Work queue task clearing addresses from process context.
+ * Clear IP addresses.
  */
 HIDE void
-sppp_clear_ip_addrs(struct sppp *sp)
+sppp_clear_ip_addrs(void *arg1, void *arg2)
 {
+   struct sppp_clear_ip_addrs_args *args = arg1;
+   struct sppp *sp = args->sp;
struct ifnet *ifp = &sp->pp_if;
+   int debug = ifp->if_flags & IFF_DEBUG;
struct ifaddr *ifa;
struct sockaddr_in *si;
struct sockaddr_in *dest;
 
+   int s;
+   
+   /* Arguments are now on local stack so free temporary storage. */
+   free(args, M_TEMP);
+
+   s = splsoftnet();
+
u_int32_t remote;
if (sp->ipcp.flags & IPCP_HISADDR_DYN)
remote = sp->ipcp.saved_hisaddr;
@@ -4792,6 +4823,7 @@ sppp_clear_ip_addrs(struct sppp *sp)
}
 
if (ifa && si) {
+   int error;
struct sockaddr_in new_sin = *si;
 
in_ifscrub(ifp, ifatoia(ifa

Hang: radeondrm0: wait for fifo failed status

[RD Thrush]

Since the bug tracker is broken, I'm sending sendbug info to misc and bugs...


>Synopsis:   The system hung hard while using xenocara>
>Category:   kernel
System  : OpenBSD 5.0
Details : OpenBSD 5.0-beta (GENERIC.MP) #34: Tue Jul 19 20:07:26 
MDT 2011


dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Hard hang while using xenocara.  The keyboard was unusable, ie. no LED 
response.
The mouse cursor was hung.  Pings were working.  I was unable to enter 
the serial
ddb from the pc keyboard but was able to enter ddb via the serail 
console.
I have appended the results of that session.  boot crash from ddb hung 
so there
is no crash dump.

>How-To-Repeat:
Dunno. This was the first time.
>Fix:
Let me know if I can collect additional info, install patches,...

## ddb transcript #
radeondrm0: Can't use AGP base @0xe400, won't fit
pms0: enable error
pms0: disable error
radeondrm0: wait for fifo failed status : 0x80036100 0x
 [ ... repeated 700+ times ... ]
radeondrm0: wait for fifo failed status : 0x80036100 0x
Stopped at  Debugger+0x5:   leave
ddb{0}> trace
Debugger() at Debugger+0x5
comintr() at comintr+0x268
Xintr_ioapic_edge4() at Xintr_ioapic_edge4+0xe8
--- interrupt ---
Bad frame pointer: 0x8000222c1be0
end trace frame: 0x8000222c1be0, count: -3
bus_space_read_4+0xe:
ddb{0}> show registers
ds0x1af8
es0x56a0acpi_pdirpa+0x12a8
fs0x9dc0acpi_pdirpa+0x59c8
gs0xc9c9acpi_pdirpa+0x85d1
rdi0
rsi0x3f8
rbp   0x8000222c1a88
rbx 0xf9
rdx0x3f8
rcx   0x80a07660cpu_info_primary
rax0
r80x80d5cf30x86_soft_intrs+0x50
r9   0x1
r100
r11   0x80122b40radeondrm_ioctl
r12   0x8018c110
r13   0x8018c000
r14   0x80141740
r150x3f8
rip   0x8042f1d5Debugger+0x5
cs   0x8
rflags0x3202mp_pdirpa+0x111b
rsp   0x8000222c1a88
ss  0x10
Debugger+0x5:   leave
ddb{0}> ps
   PID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 25731  20688  20688   1000  7   0bash
 20688   3993  20688   1000  30x80  piperdbash
  3993  17217  17217   1000  30x80  selectsshd
 17217  32747  17217  0  30x80  poll  sshd
 25024  32087  15285   1000  30x80  nanosleep sleep
 11026   1062  21129   1000  30x80  nanosleep sleep
  4217  29418   4217   1000  30x80  selectslogin
  9783  14293   9783   1000  30x80  selectslogin
 17994  24869  17994   1000  30x80  selectslogin
 29979527  29979   1000  30x80  selectssh
  5020527   5020   1000  30x80  selectssh
  7559527   7559   1000  30x80  selectssh
 25477  25271  25477   1000  30x80  selectslogin
  4668  19880   4668   1000  30x80  selectslogin
 20352  27243  20352   1000  30x80  selectslogin
 29519  15814  29519   1000  30x80  selectslogin
  8557  22473   8557   1000  30x80  selectslogin
  2920   3160   2920   1000  30x80  selectslogin
  1781   8995   1781   1000  30x80  selectslogin
 12814   4935  12814   1000  30x80  ttyoutslogin
 26260  14222  26260   1000  30x80  selectslogin
  6618  29077   6618   1000  30x80  selectslogin
  9028  22188   9028   1000  30x80  selectxemacs-21.4.22
 30905  14379  23803   1000  30x80  poll  chrome
  7690  17753   7690   1000  30x80  selectslogin
  4659  14379  23803   1000  30x80  poll  chrome
 12517   9809  12517   1000  30x80  selectslogin
 16199  12363  16199   1000  30x80  selectslogin
 16001  16255  16001   1000  30x80  selectslogin
 10869436  10869   1000  30x80  selectslogin
  1118  14793   1118   1000  30x80  selectslogin
 20722  23803  23803   1000  30x80  selectssh
 14379  30683  23803   1000  30x80  poll  chrome
  2999  30683  23803   1000  30x80  poll  chrome
  9388  1  23803   1000  30x80  poll  korgac
 19014527  19014   1000  30x8

sendbug/gnats down?

[RD Thrush]

I used sendbug to send a problem report[1] yesterday and haven't yet received an 
ack or seen the echo on bugs@.  Is something in the sendbug/gnats framework 
down? (FWIW, the gnats mail was accepted at shear.ucar.edu).


I send a note[2] to bugs@ this morning with sendmail details as well as most of 
the problem report.


[1] "panic: malloc: out of space in kmem_map & dump panic: Non dma-reachable 
buffer at curaddr"

[2]

Re: amd64/i386 kernel freezes on Asus M4A785TD-V EVO mobo

[RD Thrush]

On 03/14/11 21:06, Scott McEachern wrote:

I bought some new hardware the other day, including an Asus M4A785TD-V EVO
motherboard and an AMD Phenom II X6 1100T CPU.

The problem is that the kernel freezes when booting any of: bsd.rd, for either
amd64 or i386, -current or 4.8-stable; any GENERIC kernel for amd64/i386
-current or 4.8-stable on an installed system. (partial dmesgs below).

I have a spare P4 and can easily swap the HDD between it and the new box, so I
can install i386 or amd64 on it, and drop the drive into the new box to test.

Although I haven't a clue what most of the BIOS knobs actually do, I've tried
fiddling with every setting I can, and I always get the same freeze. The knobs
I've played with include:

- ACPI SRAT table enabled/disabled
- Plug and Play OS No/Yes
- Suspend mode Auto/S1 (POS) only/S3 only
- ACPI 2.0 support enabled/disabled

If anyone has any suggestions, I'd love to hear them. I'm dying to get my OS of
choice working on this machine!

Since I have a spare box and can swap HDDs easily, I'm more than willing to work
with anyone to test code in amd64 or i386-land in 4.9-current. I'm ready to
freak out that my brand-new workstation won't run OpenBSD. :(

Below are (probably too many) hand-typed dmesgs in the hope that together they
might help someone deduce what the problem is.

FWIW, I've just tried today's amd64-current snapshot (March 14) and I get the
same results as with the March 2 snap shown below.


I recently built a similar system and installed both i386 and amd64 -current 
systems without any noticeable drama.  I've appended the dmesg from both arch's 
for your reference.


Are you running with  the latest bios?


## amd64 ##
OpenBSD 4.9-current (GENERIC.MP) #832: Mon Mar 14 12:02:17 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3488153600 (3326MB)
avail mem = 3381272576 (3224MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (65 entries)
bios0: vendor American Megatrends Inc. version "0306" date 11/10/2010
bios0: ASUSTeK Computer INC. M4A88T-V EVO/USB3
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE7(S4) PCE9(S4) RLAN(S4) 
PCEA(S4) SBAZ(S4) PS2M(S4) PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) 
USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4)

acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) II X6 1055T Processor, 2812.88 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
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 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) II X6 1055T Processor, 2812.55 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache

cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Phenom(tm) II X6 1055T Processor, 2812.55 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache

cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Phenom(tm) II X6 1055T Processor, 2812.55 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache

cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu4 at mainbus0: apid 4 (application processor)
cpu4: AMD Phenom(tm) II X6 1055T Processor, 2812.55 MHz
cpu4: 
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
cpu4: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512

Re: Performance degradation w/ -current - GENERIC.MP {amd64,i386}

[RD Thrush]

>>>>> "a" == Ariane van der Steldt  writes:
a> On Mon, Apr 20, 2009 at 01:57:55PM -0400, RD Thrush wrote:
>> I've recently noticed reduced performance when building ports for
>> amd64 and i386 platforms on multiprocessor boxes.  I found the problem
>> was associated with running a 'nice'd dnetc [1] process on each
>> processor.  Without the 'nice'd processes, performance improves
>> dramatically.
>> 
>> In a test case, elapsed time increased 25X (from ~24 seconds to more
>> than 650 seconds) in one case and 12X (from ~30 seconds to more than
>> 350 seconds) in another case.
>> 
>> Since I received the 4.5 CD on Saturday (thanks for another very cool
>> release!), I used the bsd.mp kernels from that release and found the
>> problem with reduced performance has occurred since the 4.5 release.
>> 
>> The problem can be reproduced by busying each core w/ a 'nice'd
>> process.  Then, 'make clean;time make fake' in $PORTSDIR/devel/libtool
>> illustrates the problem.

a> Using a make and recording the time used is useless: the most important
a> numbers (user and sys) are only recorded for the initial 'make' program,
a> not the programs it starts.

  I didn't know that time(1) didn't accumulate user and sys.  Thanks
  for that.

a> You may want to redo the test with a program that doesn't spawn other
a> processes, like gzipping a large file.

  Ok, I've since updated both build boxes with the 20090419 snap and
  have used a simpler test case of gzcat comp45.tgz | wc.  Without the
  pipe, I was unable to stimulate the condition that resulted in the
  performance degradation.

  The new testing adds more wrinkles...  The i386 and amd64 platforms
  behave differently than expected, ie. I was expecting both platforms
  to show the dramatic degradation noticed with the "make" test.
  However, only the 2-core i386 showed significant degradation.  The
  4-core amd64 platform showed much less degradation with -current.

  In the following mini-analysis, time(1) is used as the measuring
  stick.  "4.5" refers to the 4.5 release as found on the official CD.
  "snap" refers to the 20090419 -current snapshot.  "baseline" means
  no niced processes.  "niced busy" means one busy process per core.
  "x4" refers to an AMD Phenom 9550 quad-core processor on an ASUS
  M3A78-EM motherboard.  "v1" refers to an AMD Athlon X2 dual-core
  processor on an ASUS M2N-E motherboard.  dmesgs are appended for
  both x4 and v1 running the forementioned "snap".  dmesgs for the
  "4.5" cases are in my previous message.

  "baseline" shows no significant difference between "4.5" and "snap"
  on either the v1 or x4 platforms.

  "niced busy" on x4 with "4.5" shows little significant difference
  with the "baseline" (If anything, the numbers are unexpectedly
  slightly better).  The additional niced processes apparently don't
  offer enough perturbation perhaps due to 4 cores available instead
  of 2 with v1.

  "niced busy" on x4 with "snap" shows more than 3 seconds increase in
  real time.  This is much less dramatic than the same test case with
  v1.

  "niced busy" on v1 with "4.5" shows appx. 4 second increase in real
  (elapsed) time while the user and system time are appx. the same.
  The additional niced processes probably prevent overlapping the
  gzcat and wc processes thus resulting in the increased elapsed time.

  "niced busy" on v1 with "snap" shows more than 150 seconds increase
  in real time.  Interestingly enough, the user and system time are
  more variable and less than the "baseline" results.  I can't explain
  the results of this test.

  I've appended the gory details which include "dnetc" results as
  described in my previous message.  The "dnetc" results are similar
  to "niced busy" and are only included for completeness.

>> FWIW, I have a soekris 5501 that does *not* have the problem which may
>> indicate the issue is not in the uniprocessor environment.
>> 
>> Is this new 'nice' behavior expected?  Or, the side-effect of some
>> other updates to the multiprocessor environment?  Hopefully,
>> performance can be restored to that of the 4.5 release.

a> A lot of cpu affinity changes have gone into the kernel.

  That sounds like fertile ground to explain the observations.

a> Please note that, while a niced process may only eat left-over processor
a> time (with a lower bound), the niced process will still take away
a> responsiveness from the system: it will finish its timeslice and th

Performance degradation w/ -current - GENERIC.MP {amd64,i386}

[RD Thrush]

I've recently noticed reduced performance when building ports for
amd64 and i386 platforms on multiprocessor boxes.  I found the problem
was associated with running a 'nice'd dnetc [1] process on each
processor.  Without the 'nice'd processes, performance improves
dramatically.

In a test case, elapsed time increased 25X (from ~24 seconds to more
than 650 seconds) in one case and 12X (from ~30 seconds to more than
350 seconds) in another case.

Since I received the 4.5 CD on Saturday (thanks for another very cool
release!), I used the bsd.mp kernels from that release and found the
problem with reduced performance has occurred since the 4.5 release.

The problem can be reproduced by busying each core w/ a 'nice'd
process.  Then, 'make clean;time make fake' in $PORTSDIR/devel/libtool
illustrates the problem.

FWIW, I have a soekris 5501 that does *not* have the problem which may
indicate the issue is not in the uniprocessor environment.

Is this new 'nice' behavior expected?  Or, the side-effect of some
other updates to the multiprocessor environment?  Hopefully,
performance can be restored to that of the 4.5 release.

I've appended a list of the 'time make fake' results for the release
and snapshot bsd.mp kernels for both an amd quad-core (amd64 platform)
and an amd dual-core (i386 platform).  The busy source and associated
dmesgs are at the end.

[1] 

##
amd64 quad-core
4.5 bsd.mp - baseline (ie. neither busy nor dnetc running)
24.69 real 8.58 user16.09 sys
4.5 bsd.mp - dnetc
22.06 real 7.69 user 9.32 sys
22.10 real 7.94 user 8.79 sys
4.5 bsd.mp - busy
24.46 real 7.42 user 8.85 sys
21.82 real 7.56 user 8.84 sys
22.04 real 7.61 user 8.86 sys
21.97 real 7.83 user 8.60 sys
21.79 real 7.85 user 8.47 sys

20090415 bsd.mp - baseline
25.74 real 8.29 user17.63 sys
25.75 real 8.28 user18.31 sys
20090415 bsd.mp - dnetc
   667.76 real 5.30 user 4.08 sys
20090415 bsd.mp - busy
   670.28 real 4.92 user 4.92 sys
   652.32 real 6.03 user 7.11 sys
   659.84 real 5.72 user 6.44 sys

##
i386 dual-core
4.5 bsd.mp - baseline
30.14 real11.38 user14.26 sys
27.80 real11.52 user13.90 sys
4.5 bsd.mp - dnetc
27.37 real11.07 user 9.06 sys
4.5 bsd.mp - busy - nice
27.30 real11.23 user 8.66 sys
27.29 real11.34 user 8.67 sys

20090415 bsd.mp - baseline
28.85 real11.74 user15.55 sys
28.81 real11.33 user16.08 sys
20090415 bsd.mp - dnetc
   527.43 real 6.70 user 0.84 sys
20090415 bsd.mp - busy
   380.40 real 7.14 user 1.01 sys
   367.23 real 7.22 user 0.75 sys


##
a8v:Projects/busy 4024>cat busy.c
int main (char **argv, int argc)
{
   for ( ;; ) ;
   return;
}
##
a8v:Projects/busy 4025>cat Do_busy
#!/bin/sh

if [ "X$1" != "X" ]; then
  NICE=nice
fi
CPUS=$(sysctl -n hw.ncpu)
TIME=/usr/bin/time
BUSY=./busy
CNT=0
echo Busying $CPUS processors
while :
do
  CNT=$((CNT + 1))
  $NICE $TIME -l $BUSY &
  if [ $CNT = $CPUS ]; then
exit
  fi
done


##
amd64 quad-core 4.5 release
##
booting hd1a:/bsd.45.mp: 4803420+967047+840784+0+620768 
[80+437952+277736]=0xb957d8
entry point at 0x1001e0 [7205c766, 3404, 24448b12, e0c0a304]
Ignoring 512MB above 4GB
[ using 716536 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-2009 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.5 (GENERIC.MP) #2133: Sat Feb 28 15:02:16 MST 2009
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3488088064 (3326MB)
avail mem = 3372306432 (3216MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (72 entries)
bios0: vendor American Megatrends Inc. version "1502" date 02/11/2009
bios0: ASUSTeK Computer INC. M3A78-EM
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC MCFG OEMB HPET
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) RLAN(S4) 
PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4) 
UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (b

Re: missing sendbug reports

[RD Thrush]

Bernd Ahlers wrote:
> RD Thrush [Wed, Jan 28, 2009 at 03:36:42AM -0500] wrote:
>> I've noticed the last three sendbug reports have gone missing, ie. no
>> ack was received nor was the report logged in the OpenBSD bug tracking
>> database.
>>
>> sendbug(1) mails the report to gn...@openbsd.org.  The highest
>> priority MX for openbsd.org is shear.ucar.edu which received each
>> report correctly (see appended sendmail maillog).  What happened to
>> these reports?
>>
>> FWIW, I've put the local copies of the associated bug reports at
>> <ftp://www.thrush.com/missing_sendbug/>.
>>
>>
>> Jan  7 20:57:56 tarpit2 sm-mta[15010]: n081vooO026259: 
>> to=, ctladdr= (1000/1000), 
>> delay=00:00:06, xdelay=00:00:06, mailer=esmtp, pri=103138, 
>> relay=shear.ucar.edu. [192.43.244.163], dsn=2.0.0, stat=Sent (n081vqc6004643 
>> Message accepted for delivery)
>> Jan  8 03:58:33 tarpit2 sm-mta[28912]: n088wPOH021430: 
>> to=, ctladdr= (1000/1000), 
>> delay=00:00:08, xdelay=00:00:08, mailer=esmtp, pri=168379, 
>> relay=shear.ucar.edu. [192.43.244.163], dsn=2.0.0, stat=Sent (n088wQpt006093 
>> Message accepted for delivery)
>> Jan 25 09:59:23 tarpit2 sm-mta[12177]: n0PExEXq003418: 
>> to=, ctladdr= (1000/1000), 
>> delay=00:00:08, xdelay=00:00:08, mailer=esmtp, pri=123437, 
>> relay=shear.ucar.edu. [192.43.244.163], dsn=2.0.0, stat=Sent (n0PExGrW005223 
>> Message accepted for delivery)
>>
> Same here.
> 
> If you query the pr database at http://www.openbsd.org/query-pr.html you
> see that some prs are pending. Those are the ones that don't show up on
> b...@openbsd.org, I think.
> 
> I don't know what's wrong with them.
> 
> Bernd

Thanks for noticing the pending category.  Since
src/usr.bin/sendbug/sendbug.c rev. 1.59, the following fields appear to
be missing:
Category
Class
Organization
Originator
Priority
Release
Severity
Submitter-Id

The missing fields apparently result in the report being categorized as
Pending and not being ack'd to the originator.  I didn't notice the
missing fields when making the report.

Per Ray's advice, I reverted sendbug.c to rev. 1.58 and see that those
fields are again available in the mail template.

How does one update the status of the associated problem reports?

I would like to change the following fields in pending/{6036,6037,6057}:
Category:   kernel
Severity:   critical
Priority:   high
Originator: RD Thrush
Organization:   net
Submitter-Id:   net

missing sendbug reports

[RD Thrush]

I've noticed the last three sendbug reports have gone missing, ie. no
ack was received nor was the report logged in the OpenBSD bug tracking
database.

sendbug(1) mails the report to gn...@openbsd.org.  The highest
priority MX for openbsd.org is shear.ucar.edu which received each
report correctly (see appended sendmail maillog).  What happened to
these reports?

FWIW, I've put the local copies of the associated bug reports at
.


Jan  7 20:57:56 tarpit2 sm-mta[15010]: n081vooO026259: to=, 
ctladdr= (1000/1000), delay=00:00:06, xdelay=00:00:06, 
mailer=esmtp, pri=103138, relay=shear.ucar.edu. [192.43.244.163], dsn=2.0.0, 
stat=Sent (n081vqc6004643 Message accepted for delivery)
Jan  8 03:58:33 tarpit2 sm-mta[28912]: n088wPOH021430: to=, 
ctladdr= (1000/1000), delay=00:00:08, xdelay=00:00:08, 
mailer=esmtp, pri=168379, relay=shear.ucar.edu. [192.43.244.163], dsn=2.0.0, 
stat=Sent (n088wQpt006093 Message accepted for delivery)
Jan 25 09:59:23 tarpit2 sm-mta[12177]: n0PExEXq003418: to=, 
ctladdr= (1000/1000), delay=00:00:08, xdelay=00:00:08, 
mailer=esmtp, pri=123437, relay=shear.ucar.edu. [192.43.244.163], dsn=2.0.0, 
stat=Sent (n0PExGrW005223 Message accepted for delivery)

Re: amd64 -current kernel hang

[RD Thrush]

>>>>> "rd" == RD Thrush <[EMAIL PROTECTED]> writes:
rd> I have experienced kernel hangs w/ -current snapshots on Athlon 64 X2
rd> and Sempron boxes.  Both GENERIC and GENERIC.MP snapshots exhibit the
rd> hang.  Once hung, the boxes don't respond to pings; however, keyboard
rd> LEDs toggle as expected and I can enter ddb from the keyboard.
rd> kernel/5777 [1] has the full problem report including dmesgs and ddb
rd> logs.  The hang is reproducible by building the eclipse-sdk port.

rd> This problem has developed fairly recently (within the past month or
rd> so).

rd> A similar box (w/ Opteron 165) runs -current i386 GENERIC.MP snapshots
rd> and is able to do the same port builds without hanging.  It seems the
rd> forementioned kernel hang doesn't affect the i386 variant.

rd> I would be happy to provide additional information that would help
rd> analyze and resolve the problem.


rd> [1] 
<http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&textonly=yes&numbers=5777>


I've now had the kernel hang occur on 3 different amd64 boxes.  (no
ping response.  top freezes.  Only kb LEDs work.  ddb can be entered
from the keyboard.)

Unfortunately, this last hang occured on a box without a serial port
so I have no ddb info to add to the above problem report.  I do have
crash dumps from this last hang.

The hang is reproducible by building the eclipse-sdk port on -current.
It does appear to require enough memory load to swap.  On this last
box, it wouldn't hang until I artificially added another 750MB load
(see below).

>From the associated ddb ps listings (several sessions), I see several
processes WAITing on flt_noram[135].  Amongst those sessions, javadoc
usually shows up WAITing on flt_noram5.  I have no idea whether that
is relevant to the hang but it does seem to form a pattern.

I'd appreciate help to further analyze the problem report and correct
the problem.

FWIW, it seems odd that no other reports of (or replies about)
this problem have occurred.  Are my 3 boxes the only ones that hang?

Here's the simpleminded memory loader:
perl -e '$n=1024*1024;for($i=0;$i<750;$i++) { $mem[$i]="z" x $n; }; <>;'

As previously mentioned, kernel/5777 contains the full report
including dmesgs.  I've appended the 3 dmesgs here as well.

### X2 #
OpenBSD 4.3-current (GENERIC.MP) #1589: Sat Mar 22 02:24:49 MDT 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1060524032 (1011MB)
avail mem = 1029472256 (981MB)
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: 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.89 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
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 processor)
cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2002.56 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
ioapic0 at mainbus0 apid 2 pa 0xfec0, version 3, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
cpu0: Cool'n'Quiet K8 2002 MHz: speeds: 2000 1800 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0 "VIA K8HTB Host" rev 0x00
pchb1 at pci0 dev 0 function 1 "VIA K8HTB Host" rev 0x00
pchb2 at pci0 dev 0 function 2 "VIA K8HTB Host" rev 0x00
pchb3 at pci0 dev 0 function 3 "VIA K8HTB Host" rev 0x00
pchb4 at pci0 dev 0 function 4 "VIA K8HTB Host" rev 0x00
pchb5 at pci0 dev 0 function 7 "VIA K8HTB Host" rev 0x00
ppb0 at pci0 dev 1 function 0 "VIA K8HTB AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 

amd64 -current kernel hang

[RD Thrush]

I have experienced kernel hangs w/ -current snapshots on Athlon 64 X2
and Sempron boxes.  Both GENERIC and GENERIC.MP snapshots exhibit the
hang.  Once hung, the boxes don't respond to pings; however, keyboard
LEDs toggle as expected and I can enter ddb from the keyboard.
kernel/5777 [1] has the full problem report including dmesgs and ddb
logs.  The hang is reproducible by building the eclipse-sdk port.

This problem has developed fairly recently (within the past month or
so).

A similar box (w/ Opteron 165) runs -current i386 GENERIC.MP snapshots
and is able to do the same port builds without hanging.  It seems the
forementioned kernel hang doesn't affect the i386 variant.

I would be happy to provide additional information that would help
analyze and resolve the problem.


[1]