Re: softdep issue in 5.3-current ?
On Fri, Jun 28, 2013 at 10:25 PM, Andreas Bartelt o...@bartula.de wrote: I also noticed that tar performance got much worse on current, and time for building release doubled somewhere around the first half of June. Hmm, please excuse my frustration, but I'm going to have to rant a moment. Gah! Build performance *was cut in half* and you didn't say anything until *at least two weeks later*!?!? No last known good date given for when things were fast. No date given for when you first noticed that it had slowed down. No definitive time measurements. No dmesg or information about the system involved (softdeps? NFS? hell, *architecture*?!?!) additional text deleted Folks, if you're following -current and see a support or performance regression, SAY SOMETHING. We test as much as we believe necessary and reasonable, which means that sometimes we miss cases that are actually show-stoppers and other times we're simply wrong. Delays in reporting just make it harder. Philip Guenther
Re: softdep issue in 5.3-current ?
On 06/29/13 08:15, Philip Guenther wrote: On Fri, Jun 28, 2013 at 10:25 PM, Andreas Bartelt o...@bartula.de wrote: I also noticed that tar performance got much worse on current, and time for building release doubled somewhere around the first half of June. Hmm, please excuse my frustration, but I'm going to have to rant a moment. Gah! Build performance *was cut in half* and you didn't say anything until *at least two weeks later*!?!? No last known good date given for when things were fast. No date given for when you first noticed that it had slowed down. No definitive time measurements. No dmesg or information about the system involved (softdeps? NFS? hell, *architecture*?!?!) additional text deleted Folks, if you're following -current and see a support or performance regression, SAY SOMETHING. We test as much as we believe necessary and reasonable, which means that sometimes we miss cases that are actually show-stoppers and other times we're simply wrong. Delays in reporting just make it harder. sorry, I'm quite busy atm. My last known good /bsd.mp kernel is from June 7: OpenBSD 5.3-current (GENERIC.MP) #0: Fri Jun 7 07:15:17 CEST 2013 I first noticed this problem a couple of days later. I usually build release via the following script (12 cores, hyperthreading deactivated): # cat buildsrc.sh #!/bin/sh cd /usr/src \ make obj \ cd etc \ env DESTDIR=/ make distrib-dirs \ cd /usr/src \ make -j12 build \ export DESTDIR=/usr/destdir; export RELEASEDIR=/usr/releasedir \ cd /usr/src/etc \ make -j12 release \ cd /usr/src/distrib/sets \ sh checkflist \ unset RELEASEDIR DESTDIR time ./buildsrc.sh took about 41 minutes at 5.3 release, then went down to 32 minutes at some point afterwards. At some point after June 7th, build time doubled to 64 minutes. As I already mentioned, tar got very slow. softdep is enabled on this box, kern.bufcachepercent=40, system is on a raid0 drive which spans over 2 ciss(4) HW raid1 drives. ciss(4) performance generally isn't optimal but I suppose this isn't directly related to the problem described above. # mount /dev/sd2a on / type ffs (local, noatime, softdep) /dev/sd2e on /usr type ffs (local, noatime, nodev, softdep) /dev/sd2d on /var type ffs (local, noatime, nodev, nosuid, softdep) # bioctl sd2 Volume Status Size Device softraid0 0 Online 599704600576 sd2 RAID0 0 Online 299852318720 0:0.0 noencl sd0d 1 Online 299852318720 0:1.0 noencl sd1d Best Regards Andreas OpenBSD 5.3-current (GENERIC.MP) #0: Thu Jun 27 22:50:00 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17152794624 (16358MB) avail mem = 16688459776 (15915MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf7fe000 (127 entries) bios0: vendor HP version P68 date 01/28/2011 bios0: HP ProLiant DL360 G7 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC SRAT BERT HEST DMAR SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2667.16 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 32 (application processor) cpu1: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2666.77 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 0, package 1 cpu2 at mainbus0: apid 16 (application processor) cpu2: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2666.77 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 8, package 0 cpu3 at mainbus0: apid 48 (application processor) cpu3: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2666.76 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,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 8, package 1 cpu4 at mainbus0: apid
Re: apropos
Hi Patric, patric conant wrote on Fri, Jun 28, 2013 at 01:32:20PM -0500: During the first Toronto hackathon, I focused on the SQLite database backend for mandocdb(8). Currently, mandocdb is still disabled in OpenBSD-current, but it is intended to become a drop-in replacement for the makewhatis(8) utility, providing enhanced search capabilities for the apropos(1) manual page search utility. This made jump up and down, as a UNIX user on many different platforms I'm ecstatic that such core system tools and utilities are being actively maintained and expanded. In OpenBSD, all elementary userland utilities are actively maintained, not just mandoc(1) and friends. Sure, they don't see large numbers of commits because they are not *that* broken any longer; but, for example, otto@ committed to cp.c 10 months ago, tedu@ committed to dd.c 3 weeks ago, guenther@ committed to ln.c 3 months ago and to ls.c 4 weeks ago, naddy@ committed to mkdir.c 2 months ago, deraadt@ committed to rm.c 2 months ago (no, Theo isn't shy of grunt work), and those are just samples from src/bin, i didn't even get started on src/usr.bin. To man.c, i committed five times during the last four years, and jca@, mikeb@ and deraadt@ helped there, too. Thanks to the Not maintained here, let's borrow it, effect, in a few years other systems I'm subjected to will likely have a apropos command that's seen some development since the '80s. That's not automatic, you may have to wait a few decades. Take mandoc(1) as an example. It was imported into OpenBSD in April 2009, systematic integration started in January 2010, the OpenBSD build switched to mandoc in April 2010, groff was disconnected from the build in October 2010. NetBSD and FreeBSD expressed interest to do the same in July 2009. A DragonFly guy popped up once around the same time, then vanished again. An IllumOS guy popped up once in 2011, then vanished again. I don't think i ever heard anything from any Linux distro or MacOS. No idea about any commercial UNIX. The current state is that NetBSD and FreeBSD have the code somewhere in their trees, maintaining it loosely but not using it very actively, certainly not using it as the default manual page formatter, and i don't see any indication that they might switch any time soon. Before any system can profit from the upcoming mandocdb(8), very solid mandoc(1) integration is certainly required, but that doesn't seem to happen anywhere but here, in OpenBSD. Heck, all the Solaris clones typically don't even have mdoc(7) yet, even though that first appeared in 4.4BSD in June 1993. So, you might have to either exercise quite some patience - or use OpenBSD... Besides, as espie@ said, the switch to mandocdb(8) is not trivial, i have to be *very* careful to not impact build and search performance. Yours, Ingo
Re: softdep issue in 5.3-current ?
On 29 June 2013 09:51, Andreas Bartelt o...@bartula.de wrote: snip time ./buildsrc.sh took about 41 minutes at 5.3 release, then went down to 32 minutes at some point afterwards. At some point after June 7th, build time doubled to 64 minutes. /snip Hi Andreas, story doesn't tell whether you have sysctl kern.pool_debug set to 0. Is it? In release it is, in current it is not. -- Sincerely, Ville Valkonen
Re: X or cwm got slower
On Tue, Jun 25, 2013 at 10:45:08AM -0700, Philip Guenther wrote: On Tue, Jun 25, 2013 at 10:24 AM, Callum Davies calrog...@gmail.com wrote: I'm also not an X hacker but nv should use EXA since ~2007? should? No, not if you believe nv(4). Can? It would seem so. Does by default, or at least if XAA isn't available? Doesn't seem so. Setting Option AccelMethod EXA might improve performance. Or it might crash and burn, given that it hasn't been the default and is therefore probably undertested. AFAICT, EXA is only implemented for G80 chipsets in the nv driver. Older cards have lost acceleration since the removing of XAA in X server 1.4 which was imported into Xenocara on june 7. -- Matthieu Herrb
routes stuck in bgpd after ifconfig destroy
Tested on 5.2 and current. routes get stuck in bgpd after ifconfig destroy. titan# cat /etc/bgpd.conf AS 65001 router-id 10.1.1.1 network inet connected network inet static titan# bgpctl show rib flags: * = Valid, = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI* 10.1.1.0/24 0.0.0.0100 0 i AI* 172.29.1.0/240.0.0.0100 0 i titan# ifconfig vlan102 create titan# ifconfig vlan102 vlandev em1 vlan 102 up titan# ifconfig vlan102 192.168.1.1/24 titan# route add 192.0.2.1/32 192.168.1.100 add host 192.0.2.1/32: gateway 192.168.1.100 titan# bgpctl show rib flags: * = Valid, = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI* 10.1.1.0/24 0.0.0.0100 0 i AI* 172.29.1.0/240.0.0.0100 0 i AI* 192.0.2.1/32 0.0.0.0100 0 i AI* 192.168.1.0/24 0.0.0.0100 0 i titan# ifconfig vlan102 destroy titan# bgpctl show rib flags: * = Valid, = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI* 10.1.1.0/24 0.0.0.0100 0 i AI* 172.29.1.0/240.0.0.0100 0 i AI* 192.0.2.1/32 0.0.0.0100 0 i titan# bgpctl show fib | grep 192.0.2.1 *S 8 192.0.2.1/32 192.168.1.100 titan# netstat -rn | grep 192.0.2.1 titan# /T
Re: Internet access on openvpn with PF and NAT
Hello mike You are blocking trafic after matching nat rule. Because you don't use quick keyword, your PF match the first rule, and next the second and next the third and to do third. In your firewall configuration you block nothing and you nat nothing. Better way is to write this: set skip on lo block in log pass out pass in quick on tun0 from 10.8.0.0/24 to any nat-to 37.x.x.x This allow outgoing traffic and incoming trafic from tun0 (+nat). Because PF is stateful, you don't have to allow return traffic from tun0 nated clients. If you want to allow some more incoming traffic, add new rules after the previous rules. -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr Le vendredi 28 juin 2013 à 23:50 -0500, Mike Parker a écrit : pf.conf set skip on lo pass in on tun0 from 10.8.0.0/24 to any nat-to 37.x.x.x block log pass block in on ! lo0 proto tcp to port 6000:6010 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: softdep issue in 5.3-current ?
On 06/29/13 11:18, Ville Valkonen wrote: On 29 June 2013 09:51, Andreas Bartelt o...@bartula.de wrote: snip time ./buildsrc.sh took about 41 minutes at 5.3 release, then went down to 32 minutes at some point afterwards. At some point after June 7th, build time doubled to 64 minutes. /snip Hi Andreas, story doesn't tell whether you have sysctl kern.pool_debug set to 0. Is it? In release it is, in current it is not. yep, forgot to mention this... kern.pool_debug was set to 0 during all these measurements. All measurements were done on current -- with 41 minutes at 5.3 release I actually meant the approximate time when 5.3 was released. The build time improvement to 32 minutes happened about mid-May, if I remember correctly. # cat /etc/sysctl.conf |grep -v ^# kern.pool_debug=0 kern.bufcachepercent=40 Best Regards Andreas
Re: apropos
On 2013-06-29 Sat 10:09 AM |, Ingo Schwarze wrote: In OpenBSD, all elementary userland utilities are actively maintained, Appreciated, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
Re: X or cwm got slower
On Jun 29 11:12:50, mhe...@gmail.com wrote: On Tue, Jun 25, 2013 at 10:45:08AM -0700, Philip Guenther wrote: On Tue, Jun 25, 2013 at 10:24 AM, Callum Davies calrog...@gmail.com wrote: I'm also not an X hacker but nv should use EXA since ~2007? should? No, not if you believe nv(4). Can? It would seem so. Does by default, or at least if XAA isn't available? Doesn't seem so. Setting Option AccelMethod EXA might improve performance. Or it might crash and burn, given that it hasn't been the default and is therefore probably undertested. AFAICT, EXA is only implemented for G80 chipsets in the nv driver. Older cards have lost acceleration since the removing of XAA in X server 1.4 which was imported into Xenocara on june 7. Thank you for the insight. Indeed, after beginning of June is about when I started noticing the slowness. As was already mentioned, just another reason to get rid of nvidia. Jan
Re: OpenSMTPD with RBLs and spamd
Cool. Best of luck. O.D. On 28. juni 2013 at 10:59 PM, Gilles Chehade gil...@poolp.org wrote: On Fri, Jun 28, 2013 at 03:35:52PM +, openda...@hushmail.com wrote: Hi, Hi, Anybody know when OpenSMTPD will work with RBLs and spamd? Filters is a work in progress, it may or may not be ready for 5.4 but it's a high priority task. When filter API is ready, it won't take long before rbl and similar filters get implemented. Just switched over from Postfix. Couldn't be happier. Glad to hear ;) -- Gilles Chehade https://www.poolp.org @poolpOrg
Re: OpenSMTPD and Rails: What to do with -i and -t?
Marvellous. Thanks a lot Gilles.
O.D.
On 28. juni 2013 at 11:05 PM, Gilles Chehade gil...@poolp.org wrote:
On Fri, Jun 28, 2013 at 03:51:34PM +, openda...@hushmail.com
wrote:
Hi,
Hi,
Rails' Action Mailer's default arguments for Sendmail are -i and
-t (http://guides.rubyonrails.org/action_mailer_basics.html):
config.action_mailer.sendmail_settings = { location:
/usr/sbin/sendmail, arguments: -i -t}
If I switch OpenSMTPD: config.action_mailer.sendmail_settings =
{ location: /usr/sbin/smtpctl } -- should I have to worry about
replacing -i and -t?
You shouldn't need to do that.
smtpctl(8) knows when it is invoked as sendmail and will work
just the
way you'd expect. All you have to do is setup the mailwrapper(8)
and you
can then let your ruby app config reference sendmail
--
Gilles Chehade
https://www.poolp.org
@poolpOrg
Re: iwn0 no link device timeout
I ran fw_update -v to no avail, it still can not connect, says no link
Re: iwn0 no link device timeout
Try from browser firmware.openbsd.org. 29.06.2013 22:35 полÑзоваÑÐµÐ»Ñ Sha'ul sh...@lavabit.com напиÑал: I ran fw_update -v to no avail, it still can not connect, says no link
panic: kernel diagnostic assertion on June 27th amd64 snap
hello, while updating my server today it panics on boot. I can work around the issue and get it up by doing bsd -c and then a 'disable viomb' Details follows and dmsg is attached. panic: kernel diagnostic assertion level = IPL_TTY || level = IPL_CLOCK || flags IPL_MPSAFE failed: file ../../../../arch/amd64/amd64/intr.c, line 359 Stopped at Debugger+0x5: leave Debugger() at Debugger+0x5 panic() at panic+0xe4 __assert() at __assert+0x21 intr_establish() at intr_establish+0x2dd pci_intr_establish() at pci_intr_establish+0xfd virtio_pci_attach() at virtio_pci_attach+0x1e8 config_attach() at config_attach+0x1d4 pci_probe_device() at pci_probe_device+0x3e2 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1d4 end trace frame: 0x81de6e30, count: 0 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger() at Debugger+0x5 panic() at panic+0xe4 __assert() at __assert+0x21 intr_establish() at intr_establish+0x2dd pci_intr_establish() at pci_intr_establish+0xfd virtio_pci_attach() at virtio_pci_attach+0x1e8 config_attach() at config_attach+0x1d4 pci_probe_device() at pci_probe_device+0x3e2 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1d4 mainbus_attach() at mainbus_attach+0x163 config_attach() at config_attach+0x1d4 cpu_configure() at cpu_configure+0x17 main() at main+0x3d5 end trace frame: 0x0, count: -14 ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7 0x200swapper ddb show registers ds0xec00acpi_pdirpa+0xa6a0 es0x6940acpi_pdirpa+0x23e0 fs0x6940acpi_pdirpa+0x23e0 gs 0 rdi 0x1 rsi 0x5 rbp 0x81de6930end+0xe5b50 rbx 0x8175ec00addrmask+0x2f60 rdx 0x8178471f_length_code+0xb1f rcx0 rax 0x1 r80x81de6850end+0xe5a70 r9 0 r10 0x r11 0x810fe2c0comcnputc r120x100 r13 0x81de6940end+0xe5b60 r14 0x814ee470virtio_pci_intr r15 0x81984de0i8259_pic rip 0x813a1225Debugger+0x5 cs 0x8 rflags 0x202 rsp 0x81de6930end+0xe5b50 ss 0x10 Debugger+0x5: leave ddb OpenBSD 5.3-current (GENERIC) #9: Thu Jun 27 16:28:53 MDT 2013 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 4278124544 (4079MB) avail mem = 4156547072 (3963MB) User Kernel Config UKC disable viomb 203 viomb* disabled UKC quit Continuing... mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfbd3f (10 entries) bios0: vendor QEMU version QEMU date 01/01/2007 acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 mpbios at bios0 not configured cpu0 at mainbus0: (uniprocessor) cpu0: QEMU Virtual CPU version 0.9.1, 2667.31 MHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,LONG,PERF cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped pci0 at mainbus0 bus 0 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 wd0 at pciide0 channel 0 drive 0: QEMU HARDDISK wd0: 16-sector PIO, LBA48, 122880MB, 251658240 sectors atapiscsi0 at pciide0 channel 0 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 0.9. ATAPI 5/cdrom removable wd0(pciide0:0:0): using PIO mode 0, DMA mode 2 cd0(pciide0:0:1): using PIO mode 0 atapiscsi1 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi1: 2 targets cd1 at scsibus1 targ 0 lun 0: QEMU, QEMU DVD-ROM, 0.9. ATAPI 5/cdrom removable cd1(pciide0:1:0): using PIO mode 0 uhci0 at pci0 dev 1 function 2 Intel 82371SB USB rev 0x01: irq 11 piixpm0 at pci0 dev 1 function 3 Intel 82371AB Power rev 0x03: irq 10 iic0 at piixpm0 iic0: addr 0x4c 48=00 words 00= 01= 02= 03= 04= 05= 06= 07= iic0: addr 0x4e 48=00 words
Re: iwn0 no link device timeout
I did pkg_add http://firmware.openbsd.org/firmware/snapshots/iwn-firmware-5.7.tgz and still no link, device timeout
Re: panic: kernel diagnostic assertion on June 27th amd64 snap
Johan Huldtgren johan+openbsd-ports at huldtgren.com writes: panic: kernel diagnostic assertion level = IPL_TTY || level = IPL_CLOCK || flags IPL_MPSAFE failed: file ../../../../arch/amd64/amd64/intr.c, line 359 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/intr.c.diff?r1=1.34;r2=1.35
Re: panic: kernel diagnostic assertion on June 27th amd64 snap
Alexey E. Suslikov alexey.suslikov at gmail.com writes: Johan Huldtgren johan+openbsd-ports at huldtgren.com writes: panic: kernel diagnostic assertion level = IPL_TTY || level = IPL_CLOCK || flags IPL_MPSAFE failed: file ../../../../arch/amd64/amd64/intr.c, line 359 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/intr.c.diff?r1=1.34;r2=1.35 Looking at viomb.c/viomb_attach reveals vsc-sc_ipl = IPL_VM; while above commit message says ... and nobody is supposed to establish interrupts at IPL_VM ...
Re: panic: kernel diagnostic assertion on June 27th amd64 snap
2013/6/29 Johan Huldtgren johan+openbsd-po...@huldtgren.com: hello, while updating my server today it panics on boot. I can work around the issue and get it up by doing bsd -c and then a 'disable viomb' I was just about to report similar symptoms. Likewise, system works ok with viomb disabled. Drop me a line if ddb output is essential, I will need to write it down manually. Dmesg from last working kernel: OpenBSD 5.3-current (GENERIC) #4: Sun Jun 23 18:37:55 CEST 2013 d...@frigg.0x29a.it:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 520085504 (495MB) avail mem = 498597888 (475MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfd9b0 (10 entries) bios0: vendor HAL 9000 version Bochs date 01/01/2011 bios0: e24cloud Bochs 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 acpihpet0 at acpi0: 1 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 mpbios0 at bios0: Intel MP Specification 1.4 cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 1.4.2, 1700.30 MHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,POPCNT,NXE,LONG,LAHF,CMPLEG,ABM,SSE4A cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: apic clock running at 1000MHz mpbios0: bus 0 is type PCI mpbios0: bus 1 is type ISA ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins pci0 at mainbus0 bus 0 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 atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: QEMU, QEMU DVD-ROM, 1.4. ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 disabled (no drives) 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 iic0: addr 0x4c 48=00 words 00= 01= 02= 03= 04= 05= 06= 07= iic0: addr 0x4e 48=00 words 00= 01= 02= 03= 04= 05= 06= 07= 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 Network rev 0x00: Virtio Network Device vio0 at virtio0: address 52:54:00:76:bb:38 virtio0: apic 0 int 11 virtio1 at pci0 dev 4 function 0 Qumranet Virtio Console rev 0x00: Virtio Console Device virtio1: no matching child driver; not configured virtio2 at pci0 dev 5 function 0 Qumranet Virtio Storage rev 0x00: Virtio Block Device vioblk0 at virtio2 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: VirtIO, Block Device, SCSI3 0/direct fixed sd0: 40960MB, 512 bytes/sector, 83886080 sectors virtio2: apic 0 int 10 virtio3 at pci0 dev 6 function 0 Qumranet Virtio Memory rev 0x00: Virtio Memory Balloon Device viomb0 at virtio3 virtio3: apic 0 int 10 Intel 6300ESB WDT rev 0x00 at pci0 dev 7 function 0 not configured isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 1: density unknown usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 nvram: invalid checksum mtrr: Pentium Pro MTRR support uhidev0 at uhub0 port 1 configuration 1 interface 0 QEMU QEMU USB Tablet rev 1.00/0.00 addr 2 uhidev0: iclass 3/0 uhid0 at uhidev0: input=6, output=0, feature=0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (d165180d79cfec23.a) swap on sd0b dump on sd0b clock: unknown CMOS layout
Re: iwn0 no link device timeout
I'm just returning to OpenBSD after a lng time solely on OS X. I picked up a ThinkPad X220 a couple of days ago and this is the first thing I'm trying to troubleshoot. I'll get a dmesg later but right now I need a nap. On Sat, Jun 29, 2013 at 12:18 PM, Sha'ul sh...@lavabit.com wrote: I did pkg_add http://firmware.openbsd.org/firmware/snapshots/iwn-firmware-5.7.tgz and still no link, device timeout
Re: iwn0 no link device timeout
After disabling wireless security I am still getting No link Doing a $ sudo ifconfig iwn0 scan it lists the networks around me, in /etc/hostname.iwn0 I have nwid xxx #wpakey 'xx' dhcp since security is disabled, I broadcast the SSID, and still no link, device timeout.
Re: iwn0 no link device timeout
Nevermind, I must have fat fingered something. iwn is working fine with 5.3 release on this X220, Centrino 6205. On Sat, Jun 29, 2013 at 2:41 PM, Sha'ul sh...@lavabit.com wrote: After disabling wireless security I am still getting No link Doing a $ sudo ifconfig iwn0 scan it lists the networks around me, in /etc/hostname.iwn0 I have nwid xxx #wpakey 'xx' dhcp since security is disabled, I broadcast the SSID, and still no link, device timeout.
