Re: signing release files
On Mon, Jun 16, 2014 at 05:47:03PM -0400, Nick Holland wrote: [diff to easily allow different keys] I think focus has been lost. What's the point of signing releases? To say This came from the OpenBSD project. Why? To make sure your release is a pure, untampered with version. Signed releases is not a goal, the goal is an install that is trusted by the installer (you). Signed releases are a way to help reach that goal. Don't forget that. IF your release is from the OpenBSD project, the signing should work fine. If your release is from some other souce...I WANT an alert saying This is not signed by OpenBSD! I don't want to squish the alert. It isn't there to hit a checkbox Code signed by someone. If your use is such that you DO want to certify that YOU created the files in question, that's great, ok, you have got a great mini-fork -- you can easily build your own release with your own keys and manage them appropriately, but a knob to get around the very point of release file signing is not really what I want to see. Nick. The problem is political. Does OpenBSD make life easier for people who want to customize release build/installation by default or these people should maintain their diffs separately. Technically, how does verification of siteXX.tgz work? IIUC it does not. I don't see what's the problem to provide one variable. Why are there MD* variables and override functions one could use but are not used by default (override/add into install.md)? j.
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On Mon, Jun 16, 2014 at 11:07:39PM +0100, Kevin Chadwick wrote: previously on this list Mikolaj Kucharski contributed: by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you I cannot find how to enable 'the old pic controller' in libvirt with qemu-kvm. Do you know by any chance how to enable it? I believe he means disabling mpbios at OpenBSD's boot or in boot.conf means KVM will automatically fall back. Virtual hosting companies like arpnetworks generally ask you to do this for OpenBSD. boot -c disable mpbios Ah, I got confused. Yes, I'm aware of this, as I've seen this on the list archives mentioned few times. I actually tested this, and I don't see any difference. See at my below tests: OpenBSD i386/virtio (default) [test12] # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 3635.270 secs (1181471 bytes/sec) 60m35.50s real 0m1.24s user54m15.15s system OpenBSD i386/virtio (disable mpbios) [test13] # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 3628.306 secs (1183739 bytes/sec) 60m28.49s real 0m1.33s user54m8.30s system On the archives I have seen recommendation to disable mpbios while machine is slow in general, however I am experiencing only slow disk I/O. I thought my problem is unrelated to mpbios. With qemu-kvm from RHEL7 on bsd.sp there is no mpbios mentioned in dmesg(8) (I didn't test bsd.mp). See dmesg output at the bottom of this email. Also starting OpenBSD with mpbios disabled via boot_config(8) ends up with: --- dmesg.txt Sat Jun 14 15:49:02 2014 +++ disable-mpbios.txt Tue Jun 17 08:15:34 2014 @@ -4,6 +4,11 @@ cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) +User Kernel Config +UKC disable mpbios +368 mpbios0 disabled +UKC quit +Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root @@ -22,7 +27,7 @@ ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 -bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800! +bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800 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 @@ -32,11 +37,11 @@ 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 0x1c 0f=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x1d 0f=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4d 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 +iic0: addr 0x1c 0f=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x1d 0f=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4d 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00: Virtio Network Device vio0 at virtio0: address 52:54:00:12:34:70 virtio0: apic 0 int 11 Full, default dmesg: OpenBSD 5.5-current (GENERIC) #162: Tue Jun 10 21:17:31 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: QEMU Virtual CPU version 1.5.3 (AuthenticAMD 686-class, 512KB L2 cache) 2.61 GHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xfc672, SMBIOS rev. 2.4 @ 0xfdde0 (10 entries) bios0: vendor Bochs version Bochs date 01/01/2011 bios0: Red Hat KVM acpi0 at bios0: rev 0 acpi0: sleep
_XData32() crash: long* vs int* on amd64 (LP64)
Hi,
I use xsel (from ports) pretty often, and every so often it
crashes:
$ gdb `which xsel` xsel.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 `xsel'.
Program terminated with signal 11, Segmentation fault.
Loaded symbols ...
[...]
#0 0x05adb1e28f40 in _XData32 () from /usr/X11R6/lib/libX11.so.16.0
(gdb) bt
#0 0x05adb1e28f40 in _XData32 () from /usr/X11R6/lib/libX11.so.16.0
#1 0x05adb1e05629 in XChangeProperty () from /usr/X11R6/lib/libX11.so.16.0
#2 0x05aba4a03d75 in change_property (display=0x5adb3b07000,
requestor=20978267, property=482, target=4, format=32, mode=0,
data=0x5ada9647fc0 3\001, nelements=9, selection=1, time=3242522763,
mparent=0x0) at /usr/build/ports/pobj/xsel-1.2.0/xsel-1.2.0/xsel.c:1177
#3 0x05aba4a042f9 in handle_targets (display=0x5adb3b07000,
requestor=20978267, property=482, selection=1, time=3242522763,
mparent=0x0) at /usr/build/ports/pobj/xsel-1.2.0/xsel-1.2.0/xsel.c:1307
#4 0x05aba4a04b48 in handle_selection_request (event=
{type = 30, xany = {type = 30, serial = 22, send_event = 0,
display = 0x5adb3b07000, window = 18874369}, xkey = {type = 30, serial
= 22, send_event = 0, display = 0x5adb3b07000, window = 18874369, root
= 20978267, subwindow = 1, time = 311, x = 482, y = 0, x_root =
-1052444533, y_root = 0, state = 0, keycode = 0, same_screen = 0},
xbutton = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, window = 18874369, root = 20978267, subwindow = 1, time
= 311, x = 482, y = 0, x_root = -1052444533, y_root = 0, state = 0,
button = 0, same_screen = 0}, xmotion = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, window = 18874369, root =
20978267, subwindow = 1, time = 311, x = 482, y = 0, x_root =
-1052444533, y_root = 0, state = 0, is_hint = 0 '\0', same_screen =
0}, xcrossing = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, window = 18874369, root = 20978267, subwindow = 1, time
= 311, x = 482, y = 0, x_root = -1052444533, y_root = 0, mode = 0,
detail = 0, same_screen = 0, focus = 0, state = 0}, xfocus = {type =
30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, mode = 20978267, detail = 0}, xexpose = {type = 30, serial =
22, send_event = 0, display = 0x5adb3b07000, window = 18874369, x =
20978267, y = 0, width = 1, height = 0, count = 311}, xgraphicsexpose
= {type = 30, serial = 22, send_event = 0, display = 0x5adb3b07000,
drawable = 18874369, x = 20978267, y = 0, width = 1, height = 0, count
= 311, major_code = 0, minor_code = 482}, xnoexpose = {type = 30,
serial = 22, send_event = 0, display = 0x5adb3b07000, drawable =
18874369, major_code = 20978267, minor_code = 0}, xvisibility = {type
= 30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, state = 20978267}, xcreatewindow = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, parent = 18874369, window =
20978267, x = 1, y = 0, width = 311, height = 0, border_width = 482,
override_redirect = 0}, xdestroywindow = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, event = 18874369, window =
20978267}, xunmap = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, event = 18874369, window = 20978267, from_configure =
1}, xmap = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, event = 18874369, window = 20978267, override_redirect
= 1}, xmaprequest = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, parent = 18874369, window = 20978267}, xreparent =
{type = 30, serial = 22, send_event = 0, display = 0x5adb3b07000,
event = 18874369, window = 20978267, parent = 1, x = 311, y = 0,
override_redirect = 482}, xconfigure = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, event = 18874369, window =
20978267, x = 1, y = 0, width = 311, height = 0, border_width = 482,
above = 3242522763, override_redirect = 0}, xgravity = {type = 30,
serial = 22, send_event = 0, display = 0x5adb3b07000, event =
18874369, window = 20978267, x = 1, y = 0}, xresizerequest = {type =
30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, width = 20978267, height = 0}, xconfigurerequest = {type =
30, serial = 22, send_event = 0, display = 0x5adb3b07000, parent =
18874369, window = 20978267, x = 1, y = 0, width = 311, height = 0,
border_width = 482, above = 3242522763, detail = 0, value_mask = 0},
xcirculate = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, event = 18874369, window = 20978267, place = 1},
xcirculaterequest = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, parent = 18874369,
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On 06/17/14 10:56, Mikolaj Kucharski wrote: On Mon, Jun 16, 2014 at 11:07:39PM +0100, Kevin Chadwick wrote: previously on this list Mikolaj Kucharski contributed: by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you I cannot find how to enable 'the old pic controller' in libvirt with qemu-kvm. Do you know by any chance how to enable it? I believe he means disabling mpbios at OpenBSD's boot or in boot.conf means KVM will automatically fall back. Virtual hosting companies like arpnetworks generally ask you to do this for OpenBSD. boot -c disable mpbios Ah, I got confused. Yes, I'm aware of this, as I've seen this on the list archives mentioned few times. I actually tested this, and I don't see any difference. See at my below tests: OpenBSD i386/virtio (default) [test12] # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 3635.270 secs (1181471 bytes/sec) 60m35.50s real 0m1.24s user54m15.15s system OpenBSD i386/virtio (disable mpbios) [test13] # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 3628.306 secs (1183739 bytes/sec) 60m28.49s real 0m1.33s user54m8.30s system On the archives I have seen recommendation to disable mpbios while machine is slow in general, however I am experiencing only slow disk I/O. I thought my problem is unrelated to mpbios. With qemu-kvm from RHEL7 on bsd.sp there is no mpbios mentioned in dmesg(8) (I didn't test bsd.mp). See dmesg output at the bottom of this email. Also starting OpenBSD with mpbios disabled via boot_config(8) ends up with: --- dmesg.txt Sat Jun 14 15:49:02 2014 +++ disable-mpbios.txt Tue Jun 17 08:15:34 2014 @@ -4,6 +4,11 @@ cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) +User Kernel Config +UKC disable mpbios +368 mpbios0 disabled +UKC quit +Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root @@ -22,7 +27,7 @@ ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 -bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800! +bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800 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 @@ -32,11 +37,11 @@ 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 0x1c 0f=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x1d 0f=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4d 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 -iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 +iic0: addr 0x1c 0f=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x1d 0f=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4d 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 +iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=8fc5 01=8fc5 02=8fc5 03=8fc5 04=8fc5 05=8fc5 06=8fc5 07=8fc5 virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00: Virtio Network Device vio0 at virtio0: address 52:54:00:12:34:70 virtio0: apic 0 int 11 Full, default dmesg: OpenBSD 5.5-current (GENERIC) #162: Tue Jun 10 21:17:31 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: QEMU Virtual CPU version 1.5.3 (AuthenticAMD 686-class, 512KB L2 cache) 2.61 GHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xfc672, SMBIOS rev. 2.4 @ 0xfdde0 (10 entries) bios0: vendor Bochs version Bochs date 01/01/2011 bios0:
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On 17/06/14 4:56 AM, Mikolaj Kucharski wrote: On Mon, Jun 16, 2014 at 11:07:39PM +0100, Kevin Chadwick wrote: previously on this list Mikolaj Kucharski contributed: by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you I cannot find how to enable 'the old pic controller' in libvirt with qemu-kvm. Do you know by any chance how to enable it? I believe he means disabling mpbios at OpenBSD's boot or in boot.conf means KVM will automatically fall back. Virtual hosting companies like arpnetworks generally ask you to do this for OpenBSD. boot -c disable mpbios Ah, I got confused. Yes, I'm aware of this, as I've seen this on the list archives mentioned few times. I actually tested this, and I don't see any difference. See at my below tests: Because ACPI is in use which takes higher precedence over MP BIOS. You have to disable acpimadt. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: signing release files
On 06/17/14 02:40, Jiri B wrote: On Mon, Jun 16, 2014 at 05:47:03PM -0400, Nick Holland wrote: [diff to easily allow different keys] I think focus has been lost. What's the point of signing releases? To say This came from the OpenBSD project. Why? To make sure your release is a pure, untampered with version. Signed releases is not a goal, the goal is an install that is trusted by the installer (you). Signed releases are a way to help reach that goal. Don't forget that. IF your release is from the OpenBSD project, the signing should work fine. If your release is from some other souce...I WANT an alert saying This is not signed by OpenBSD! I don't want to squish the alert. It isn't there to hit a checkbox Code signed by someone. If your use is such that you DO want to certify that YOU created the files in question, that's great, ok, you have got a great mini-fork -- you can easily build your own release with your own keys and manage them appropriately, but a knob to get around the very point of release file signing is not really what I want to see. Nick. The problem is political. Does OpenBSD make life easier for people who want to customize release build/installation by default or these people should maintain their diffs separately. OpenBSD is quite different from many open source projects, where they have a fear of offending any one person or group, and thus end up with three different packet filters, several different packing management systems, etc. Internally, one of the biggest insults in the project is to call a suggestion a usless knob, and great pride is taken in deleting code and options that just shouldn't be there. I think this falls under that category. Technically, how does verification of siteXX.tgz work? IIUC it does not. It works exactly as intended: your siteXX.tgz file is something YOU generated, OpenBSD has no idea what's in it. If you can't trust your siteXX.tgz file and how it gets from you to you, you have much bigger problems that signing isn't going to fix. Again, you are confusing the goal with the tool used to help achieve the goal. signing is NOT the goal. I've had this discussion often. It often goes like this: We want to implement two factor authentication (followed by a description that is much more based on convenience than security) me: Two factor authentication should not be the goal, it should be the means to the goal: security. You are subverting the security of TFA Oh, I know. (followed by a return to the subverted two-factor authentication system again) me: You are undoing the benefits of two-factor authentication But two-factor is good! (at which point, I think about driving a truck for a living) I don't see what's the problem to provide one variable. much the same reason why we don't have a magic switch to disable stack smash protection or W^X protection. The point of the signing is simple and limited. Having worked with some systems which offer the kind of feature you request and speaking only for myself, I'm happy with this. Why are there MD* variables and override functions one could use but are not used by default (override/add into install.md)? because they add features /the developers desire/ without disabling security? Nick.
Re: openbsd live-cd?
On Mon, Jun 16, 2014 at 03:47:14PM -0400, Brian McCafferty wrote: Install it to a usb stick. And then try to not get banned from the store you're trying the new hardware in for uploading malware (apparently that's what the dmesg scolling by looks like to the untrained eye :P), even if you got the managers permission first.
Re: signing release files
On 17 June 2014 07:37, Nick Holland n...@holland-consulting.net wrote: On 06/17/14 02:40, Jiri B wrote: On Mon, Jun 16, 2014 at 05:47:03PM -0400, Nick Holland wrote: [diff to easily allow different keys] I think focus has been lost. What's the point of signing releases? To say This came from the OpenBSD project. Why? To make sure your release is a pure, untampered with version. Signed releases is not a goal, the goal is an install that is trusted by the installer (you). Signed releases are a way to help reach that goal. Don't forget that. IF your release is from the OpenBSD project, the signing should work fine. If your release is from some other souce...I WANT an alert saying This is not signed by OpenBSD! I don't want to squish the alert. It isn't there to hit a checkbox Code signed by someone. If your use is such that you DO want to certify that YOU created the files in question, that's great, ok, you have got a great mini-fork -- you can easily build your own release with your own keys and manage them appropriately, but a knob to get around the very point of release file signing is not really what I want to see. Nick. The problem is political. Does OpenBSD make life easier for people who want to customize release build/installation by default or these people should maintain their diffs separately. OpenBSD is quite different from many open source projects, where they have a fear of offending any one person or group, and thus end up with three different packet filters, several different packing management systems, etc. Internally, one of the biggest insults in the project is to call a suggestion a usless knob, and great pride is taken in deleting code and options that just shouldn't be there. I think this falls under that category. Technically, how does verification of siteXX.tgz work? IIUC it does not. It works exactly as intended: your siteXX.tgz file is something YOU generated, OpenBSD has no idea what's in it. If you can't trust your siteXX.tgz file and how it gets from you to you, you have much bigger problems that signing isn't going to fix. Again, you are confusing the goal with the tool used to help achieve the goal. signing is NOT the goal. I've had this discussion often. It often goes like this: We want to implement two factor authentication (followed by a description that is much more based on convenience than security) me: Two factor authentication should not be the goal, it should be the means to the goal: security. You are subverting the security of TFA Oh, I know. (followed by a return to the subverted two-factor authentication system again) me: You are undoing the benefits of two-factor authentication But two-factor is good! (at which point, I think about driving a truck for a living) I don't see what's the problem to provide one variable. much the same reason why we don't have a magic switch to disable stack smash protection or W^X protection. The point of the signing is simple and limited. Having worked with some systems which offer the kind of feature you request and speaking only for myself, I'm happy with this. Why are there MD* variables and override functions one could use but are not used by default (override/add into install.md)? because they add features /the developers desire/ without disabling security? Nick. Nick once more hits the nail on the head. Driving it fully into the wood one can only hope. As, to the best of my recollection, the originator of the MD* variables I can say that they were intended - nay, forced upon us - to support differences between the needs of different architectures. Not to provide knobs to allow site customization. The ideal would be to completely eliminate them and the install.md files. Ken
Re: openbsd live-cd?
On 06/17/14 15:27, Jean-Philippe Ouellet wrote: On Mon, Jun 16, 2014 at 03:47:14PM -0400, Brian McCafferty wrote: Install it to a usb stick. And then try to not get banned from the store you're trying the new hardware in for uploading malware (apparently that's what the dmesg scolling by looks like to the untrained eye :P), even if you got the managers permission first. Malware? Sue.
Re: openbsd live-cd?
On Mon, Jun 16, 2014 at 9:45 PM, Martijn van Duren martijn...@gmail.com wrote: On 06/16/14 21:38, Gustav Fransson Nyvell wrote: On 06/16/14 21:35, Thuban wrote: Hi, I would like to try openBSD before installing it on my laptop to check if things works correctly (X server as example). Do you know any liveCD or any methode to try openBSD on some hardware before installing? Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc] You'll be testing OpenBSD if you boot install55.iso. I didn't know install55.iso comes with a fully functioning Xorg. :) You might want to try http://liveusb-openbsd.sourceforge.net/. I've only used it to bootstrap my netbook once, so no guarantees about the validity or quality from my end, but it might be what you're looking for. FuguIta is nice too: http://fuguita.ddo.jp/openbsd/index.php?FuguIta
problem with IPSec between OpenBSD 5.5 and Cisco 2901
Hi,
I'm trying to establish an IPSec tunnel between an OpenBSD 5.5 (amd64)
box and a Cisco 2901, the whole day, but doesn't seem to
get it to work. I think I have something wrong with the
crypto transforms for phase two, since this NO_PROPOSAL_CHOSEN
I get in the logs, which I think is in phase two.
Network looks similar to this one:
Host behind OBSD (192.168.13.12/24)
|
|
OBSD (XXX.191.219.14)
|
|
Internet
|
|
NAT FW (XXX.217.33.11)
|
|
Internal Network
|
|
Cisco 2901 (192.168.14.126)
|
|
Host behind Cisco (192.168.13.19/24)
Yes, they have both the same network behind each VPN Endpoints.
Something, more or less the same we have up and running between
two Cisco 2901.
OpenBSD configuration:
rem_gw=XXX.217.33.11
bb_gw=XXX.191.219.14
ike active esp from { 192.168.13.12 } to { 192.168.13.19 } \
local $bb_gw peer $rem_gw \
main auth hmac-sha1 enc aes-128 group modp1024 \
quick auth hmac-md5 enc 3des group none \
psk SuperTopSecret
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key SuperTopSecret address XXX.191.219.14 no-xauth
crypto isakmp keepalive 30 5
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto map TO_BB 1 ipsec-isakmp
set peer XXX.191.219.14
set transform-set ESP-3DES-MD5
match address 101
interface GigabitEthernet0/1
description outside-interface
ip address 192.168.14.126 255.255.255.0
duplex auto
speed auto
crypto map TO_BB
access-list 101 permit ip host 192.168.13.12 host 192.168.13.19
I think from the logs, see below, Phase one gets established, but then
it runs into trouble with Phase 2, at least how I would interpret the logs:
On the Cisco, status looks like:
# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.14.126 XXX.191.219.14 QM_IDLE 1442 ACTIVE
IPv6 Crypto ISAKMP SA
#show crypto ipsec sa
interface: GigabitEthernet0/1
Crypto map tag: TO_BBN, local addr 192.168.14.126
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.13.12/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (192.168.13.19/255.255.255.255/0/0)
current_peer XXX.191.219.14 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 192.168.14.126, remote crypto endpt.: XXX.191.219.14
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
On the OpenBSD box it looks like:
ipsecctl -s all
FLOWS:
No flows
SAD:
No entries
isakmpd with isakmpd -d -D A=75 -K,
after loading the configuration, trying to connect to the remote
endpoint:
171646.650413 Timr 10 timer_handle_expirations: event ui_conn_reinit(0x0)
171646.650515 Misc 30 connection_reinit: reinitializing connection list
171646.650592 Timr 10 timer_add_event: event connection_checker(0x20f87dac0)
added last, expiration in 0s
171646.650722 Misc 60 connection_record_passive: passive connection
from-192.168.13.12-to-192.168.13.19 added
171646.650811 Timr 10 timer_handle_expirations: event
connection_checker(0x20f87dac0)
171646.650884 Timr 10 timer_add_event: event connection_checker(0x20f87dac0)
added last, expiration in 60s
171646.650943 Sdep 70 pf_key_v2_connection_check: SA for
from-192.168.13.12-to-192.168.13.19 missing
171646.651021 Trpt 70 transport_setup: added 0x2018f7680 to transport list
171646.651092 Trpt 70 transport_setup: added 0x2018f7280 to transport list
171646.651150 Trpt 70 transport_setup: virtual transport 0x2018f7b00
171646.651227 Timr 10 timer_add_event: event exchange_free_aux(0x2018f6e00)
added last, expiration in 120s
171646.651288 Cryp 60 hash_get: requested algorithm 1
171646.651356 Exch 10 exchange_establish_p1: 0x2018f6e00
peer-XXX.217.33.11-local-XXX.191.219.14
phase1-peer-XXX.217.33.11-local-XXX.191.219.14 policy initiator phase 1 doi 1
exchange 2 step 0
171646.651429 Exch 10 exchange_establish_p1: icookie 7128cf36d74c89f1 rcookie
171646.651492 Exch 10 exchange_establish_p1: msgid
171646.651554 SA 70 sa_enter: SA 0x2018f6800 added to SA list
171646.651606 SA 60 sa_create: sa 0x2018f6800 phase 1 added to exchange
0x2018f6e00 (peer-XXX.217.33.11-local-XXX.191.219.14)
171646.651704 Misc 70 attribute_set_constant: no PRF in the
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On Tue, Jun 17, 2014 at 05:10:51AM -0400, Brad Smith wrote: On 17/06/14 4:56 AM, Mikolaj Kucharski wrote: On Mon, Jun 16, 2014 at 11:07:39PM +0100, Kevin Chadwick wrote: previously on this list Mikolaj Kucharski contributed: by disabling mpbios on OpenBSD and falling back to the old pic controller, in this case you I cannot find how to enable 'the old pic controller' in libvirt with qemu-kvm. Do you know by any chance how to enable it? I believe he means disabling mpbios at OpenBSD's boot or in boot.conf means KVM will automatically fall back. Virtual hosting companies like arpnetworks generally ask you to do this for OpenBSD. boot -c disable mpbios Ah, I got confused. Yes, I'm aware of this, as I've seen this on the list archives mentioned few times. I actually tested this, and I don't see any difference. See at my below tests: Because ACPI is in use which takes higher precedence over MP BIOS. You have to disable acpimadt. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Randomly disabling parts of the kernel is likely to cause other problems. -ml
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
Mike, On Tue, Jun 17, 2014 at 10:30:23AM -0700, Mike Larkin wrote: On Tue, Jun 17, 2014 at 05:10:51AM -0400, Brad Smith wrote: Because ACPI is in use which takes higher precedence over MP BIOS. You have to disable acpimadt. Randomly disabling parts of the kernel is likely to cause other problems. I agree, but disabling mpbios and acpimadt makes a huge difference for me on qemu-kvm-1.5.3-60.el7.x86_64: OpenBSD i386/virtio (bsd.sp disable mpbios and acpimadt) # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 18.524 secs (231854084 bytes/sec) 0m18.52s real 0m0.24s user 0m14.48s system It takes now 18 seconds to run above dd(1), when previously it took 60 mintues. Thanks Christiano and Brad for the tips. Do you guys think it's worth opening bug report with RedHat to get them look into this, or is the problem more on OpenBSD side? Ideally I would like to run unmodified OpenBSD kernel on my VMs. $ diff -I'^iic0' dmesg.txt disable-mpbios-and-acpimadt.txt --- dmesg.txt Sat Jun 14 15:49:02 2014 +++ disable-mpbios-and-acpimadt.txt Tue Jun 17 13:30:46 2014 @@ -4,6 +4,13 @@ cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) +User Kernel Config +UKC disable mpbios +368 mpbios0 disabled +UKC disable acpimadt +501 acpimadt0 disabled +UKC quit +Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root @@ -15,22 +22,20 @@ acpi0: tables DSDT FACP SSDT APIC RSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits -acpimadt0 at acpi0 addr 0xfee0: PC-AT compat -cpu0 at mainbus0: apid 0 (boot processor) -mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges -cpu0: apic clock running at 999MHz -ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 +mpbios at bios0 function 0x0 not configured bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800! +cpu0 at mainbus0: (uniprocessor) +mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges 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) 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 +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 9 iic0 at piixpm0 iic0: addr 0x1c 0f=00 words 00=d4d0 01=d4d0 02=d4d0 03=d4d0 04=d4d0 05=d4d0 06=d4d0 07=d4d0 iic0: addr 0x1d 0f=00 words 00=d4d0 01=d4d0 02=d4d0 03=d4d0 04=d4d0 05=d4d0 06=d4d0 07=d4d0 @@ -39,13 +44,13 @@ iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00: Virtio Network Device vio0 at virtio0: address 52:54:00:12:34:70 -virtio0: apic 0 int 11 +virtio0: irq 11 virtio1 at pci0 dev 4 function 0 Qumranet Virtio Storage rev 0x00: Virtio Block Device vioblk0 at virtio1 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: VirtIO, Block Device, SCSI3 0/direct fixed sd0: 102400MB, 512 bytes/sector, 209715200 sectors -virtio1: apic 0 int 11 +virtio1: irq 11 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo -- best regards q#
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On Tue, Jun 17, 2014 at 07:47:32PM +0100, Mikolaj Kucharski wrote: Mike, On Tue, Jun 17, 2014 at 10:30:23AM -0700, Mike Larkin wrote: On Tue, Jun 17, 2014 at 05:10:51AM -0400, Brad Smith wrote: Because ACPI is in use which takes higher precedence over MP BIOS. You have to disable acpimadt. Randomly disabling parts of the kernel is likely to cause other problems. I agree, but disabling mpbios and acpimadt makes a huge difference for me on qemu-kvm-1.5.3-60.el7.x86_64: Please don't bother filing any bug reports for a system where you've done this. -ml OpenBSD i386/virtio (bsd.sp disable mpbios and acpimadt) # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 18.524 secs (231854084 bytes/sec) 0m18.52s real 0m0.24s user 0m14.48s system It takes now 18 seconds to run above dd(1), when previously it took 60 mintues. Thanks Christiano and Brad for the tips. Do you guys think it's worth opening bug report with RedHat to get them look into this, or is the problem more on OpenBSD side? Ideally I would like to run unmodified OpenBSD kernel on my VMs. $ diff -I'^iic0' dmesg.txt disable-mpbios-and-acpimadt.txt --- dmesg.txt Sat Jun 14 15:49:02 2014 +++ disable-mpbios-and-acpimadt.txt Tue Jun 17 13:30:46 2014 @@ -4,6 +4,13 @@ cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) +User Kernel Config +UKC disable mpbios +368 mpbios0 disabled +UKC disable acpimadt +501 acpimadt0 disabled +UKC quit +Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root @@ -15,22 +22,20 @@ acpi0: tables DSDT FACP SSDT APIC RSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits -acpimadt0 at acpi0 addr 0xfee0: PC-AT compat -cpu0 at mainbus0: apid 0 (boot processor) -mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges -cpu0: apic clock running at 999MHz -ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 +mpbios at bios0 function 0x0 not configured bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800! +cpu0 at mainbus0: (uniprocessor) +mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges 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) 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 +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 9 iic0 at piixpm0 iic0: addr 0x1c 0f=00 words 00=d4d0 01=d4d0 02=d4d0 03=d4d0 04=d4d0 05=d4d0 06=d4d0 07=d4d0 iic0: addr 0x1d 0f=00 words 00=d4d0 01=d4d0 02=d4d0 03=d4d0 04=d4d0 05=d4d0 06=d4d0 07=d4d0 @@ -39,13 +44,13 @@ iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00: Virtio Network Device vio0 at virtio0: address 52:54:00:12:34:70 -virtio0: apic 0 int 11 +virtio0: irq 11 virtio1 at pci0 dev 4 function 0 Qumranet Virtio Storage rev 0x00: Virtio Block Device vioblk0 at virtio1 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: VirtIO, Block Device, SCSI3 0/direct fixed sd0: 102400MB, 512 bytes/sector, 209715200 sectors -virtio1: apic 0 int 11 +virtio1: irq 11 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo -- best regards q#
Re: Very slow I/O under OpenBSD i386 on qemu-kvm from RHEL7rc
On 17 June 2014 20:47, Mikolaj Kucharski miko...@kucharski.name wrote: Mike, On Tue, Jun 17, 2014 at 10:30:23AM -0700, Mike Larkin wrote: On Tue, Jun 17, 2014 at 05:10:51AM -0400, Brad Smith wrote: Because ACPI is in use which takes higher precedence over MP BIOS. You have to disable acpimadt. Randomly disabling parts of the kernel is likely to cause other problems. I agree, but disabling mpbios and acpimadt makes a huge difference for me on qemu-kvm-1.5.3-60.el7.x86_64: OpenBSD i386/virtio (bsd.sp disable mpbios and acpimadt) # time dd if=/dev/zero of=/tmp/TEST bs=4096 count=1024x1024 1048576+0 records in 1048576+0 records out 4294967296 bytes transferred in 18.524 secs (231854084 bytes/sec) 0m18.52s real 0m0.24s user 0m14.48s system It takes now 18 seconds to run above dd(1), when previously it took 60 mintues. Thanks Christiano and Brad for the tips. Do you guys think it's worth opening bug report with RedHat to get them look into this, or is the problem more on OpenBSD side? Ideally I would like to run unmodified OpenBSD kernel on my VMs. One solution is to rewrite the OpenBSD i386 interrupt handling code on the apic case to use software masking, like amd64 and the i386 pic code. $ diff -I'^iic0' dmesg.txt disable-mpbios-and-acpimadt.txt --- dmesg.txt Sat Jun 14 15:49:02 2014 +++ disable-mpbios-and-acpimadt.txt Tue Jun 17 13:30:46 2014 @@ -4,6 +4,13 @@ cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,LONG,SSE3,CX16,LAHF,ABM,SSE4A,PERF real mem = 536367104 (511MB) avail mem = 515158016 (491MB) +User Kernel Config +UKC disable mpbios +368 mpbios0 disabled +UKC disable acpimadt +501 acpimadt0 disabled +UKC quit +Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root @@ -15,22 +22,20 @@ acpi0: tables DSDT FACP SSDT APIC RSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits -acpimadt0 at acpi0 addr 0xfee0: PC-AT compat -cpu0 at mainbus0: apid 0 (boot processor) -mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges -cpu0: apic clock running at 999MHz -ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 +mpbios at bios0 function 0x0 not configured bios0: ROM list: 0xc/0x1000! 0xc1000/0xa00 0xc2000/0x2400 0xed800/0x2800! +cpu0 at mainbus0: (uniprocessor) +mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges 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) 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 +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 9 iic0 at piixpm0 iic0: addr 0x1c 0f=00 words 00=d4d0 01=d4d0 02=d4d0 03=d4d0 04=d4d0 05=d4d0 06=d4d0 07=d4d0 iic0: addr 0x1d 0f=00 words 00=d4d0 01=d4d0 02=d4d0 03=d4d0 04=d4d0 05=d4d0 06=d4d0 07=d4d0 @@ -39,13 +44,13 @@ iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 3e=d1 48=d1 4a=d1 4e=d1 fc=d1 fe=d1 words 00=9d87 01=9d87 02=9d87 03=9d87 04=9d87 05=9d87 06=9d87 07=9d87 virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00: Virtio Network Device vio0 at virtio0: address 52:54:00:12:34:70 -virtio0: apic 0 int 11 +virtio0: irq 11 virtio1 at pci0 dev 4 function 0 Qumranet Virtio Storage rev 0x00: Virtio Block Device vioblk0 at virtio1 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: VirtIO, Block Device, SCSI3 0/direct fixed sd0: 102400MB, 512 bytes/sector, 209715200 sectors -virtio1: apic 0 int 11 +virtio1: irq 11 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo -- best regards q#
Ethernet configuration problem
Hello, I am currently trying to install OpenBSD 5.5 on a usb stick, and didn't manage to connect to the internet (to download file sets). Neither dhcp works. I tried to configure the interface manually, but the ethernet interface seems to still be sleeping. I used this command : ifconfig jme0 inet 192.168.1.68 255.255.255.0 192.168.1.255 If it can help, here is an extract from the `dmesg` command (written by hand, sorry) jme0 at pci3 dev 0 function 0 JMicron JMC250 rev 0x05; msi, address 00:90:f5:bc:7b:56 jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev.1 The command ifconfig detect 2 interfaces : jme0 and vlan0 (wifi I guess?) Do you have any suggestion to make this ethernet working? All my apologize for my bad english and beginner questions. Regards, -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub KeyID : 0x54CD2F2F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Ethernet port on Lenovo G480
Hello list, that's me again. I have a Lenovo G480 but neither ethernet nor internal wifi are working as expected. could you please give me a hand to solve this issue? OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014 dera...@amd64.openbsd.org:/ usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80clock_battery real mem = 4138713088 (3946MB) avail mem = 4019929088 (3833MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6fd0 (59 entries) bios0: vendor LENOVO version 5ECN95WW(V9.00) date 12/19/2012 bios0: LENOVO 20150 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC UEFI ASF! HPET APIC MCFG SSDT BOOT SSDT SSDT ASPT DBGP FPDT MSDM SSDT SSDT acpi0: wakeup devices P0P1(S0) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S0) PXSX(S3) PXSX(S3) PXSX(S3) PXSX(S3) PXSX(S3) RP05(S0) PXSX(S3) RP06(S0) PXSX(S3) RP07(S0) PXSX(S3) [...] 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) Pentium(R) CPU B980 @ 2.40GHz, 2394.96 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Pentium(R) CPU B980 @ 2.40GHz, 2394.57 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpitz0 at acpi0: critical temperature is 127 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT1 model PABAS0241231 serial 41167 type Li-Ion oem LENOVO acpiac0 at acpi0: AC unit online acpibtn2 at acpi0: LID0 acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ acpivideo2 at acpi0: GFX0 acpivout0 at acpivideo2: DD02 cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 2000 rev 0x09 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1366x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 7 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 0 int 16 ehci0: timed out waiting for BIOS usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: msi azalia0: codecs: Conexant/0x506e, Intel/0x2806, using Conexant/0x506e audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi pci1 at ppb0 bus 1 Attansic Technology AR8162 rev 0x10 at pci1 dev 0 function 0 not configured ppb1 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi pci2 at ppb1 bus 2 Atheros AR9485 rev 0x01 at pci2 dev 0 function 0 not configured ehci1 at pci0 dev 29 function 0 Intel 7 Series USB rev 0x04: apic 0 int 23 ehci1: timed out waiting for BIOS usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 Intel HM76 LPC rev 0x04 pciide0 at pci0 dev 31 function 2 Intel 7 Series SATA rev 0x04: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using apic 0 int 19 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: Hitachi HTS722012K9A300 wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors atapiscsi0 at pciide0 channel 0 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0:
Re: Ethernet port on Lenovo G480
On 06/17/14 21:49, Leonardo Santagostini wrote: Hello list, that's me again. I have a Lenovo G480 but neither ethernet nor internal wifi are working as expected. could you please give me a hand to solve this issue? OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014 dera...@amd64.openbsd.org:/ snipped ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi pci1 at ppb0 bus 1 Attansic Technology AR8162 rev 0x10 at pci1 dev 0 function 0 not configured ppb1 at pci0 dev 28 function 1 Intel 7 Series PCIE rev 0xc4: msi pci2 at ppb1 bus 2 Atheros AR9485 rev 0x01 at pci2 dev 0 function 0 not configured snipped run0 at uhub3 port 4 Linksys Linksys WUSB600N Wireless-N USB Network Adapter with Dual-Band ver. 2 rev 2.00/1.01 addr 3 run0: MAC/BBP RT3572 (rev 0x0223), RF RT3052 (MIMO 2T2R), address 98:fc:11:e0:59:0a snipped neither your ethernet (Attansic Technology AR8162) nor wifi (Atheros AR9485) are currently supported - some attempts have been made to get the AR9485 working [1] [1]http://marc.info/?t=13995899051 Atheros - are not a good vendor - they do not provide documentation for the developers to work from. Looks like you'll be stuck with run0 USB wireless adapter for the moment. Fred
Re: _XData32() crash: long* vs int* on amd64 (LP64)
I think the issue is that xsel.c allocates int nr_bytes; in
change_property(), and then passes it to XChangeProperty with
format==32. However, XChangeProperty() documents that format==32
specifically means a pointer to long (even on LP64 platforms).
I suspect changing int nr_bytes to long nr_bytes should fix the bug.
On Tue, Jun 17, 2014 at 1:56 AM, patrick keshishian pkesh...@gmail.com wrote:
Hi,
I use xsel (from ports) pretty often, and every so often it
crashes:
$ gdb `which xsel` xsel.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 `xsel'.
Program terminated with signal 11, Segmentation fault.
Loaded symbols ...
[...]
#0 0x05adb1e28f40 in _XData32 () from /usr/X11R6/lib/libX11.so.16.0
(gdb) bt
#0 0x05adb1e28f40 in _XData32 () from /usr/X11R6/lib/libX11.so.16.0
#1 0x05adb1e05629 in XChangeProperty () from
/usr/X11R6/lib/libX11.so.16.0
#2 0x05aba4a03d75 in change_property (display=0x5adb3b07000,
requestor=20978267, property=482, target=4, format=32, mode=0,
data=0x5ada9647fc0 3\001, nelements=9, selection=1, time=3242522763,
mparent=0x0) at /usr/build/ports/pobj/xsel-1.2.0/xsel-1.2.0/xsel.c:1177
#3 0x05aba4a042f9 in handle_targets (display=0x5adb3b07000,
requestor=20978267, property=482, selection=1, time=3242522763,
mparent=0x0) at /usr/build/ports/pobj/xsel-1.2.0/xsel-1.2.0/xsel.c:1307
#4 0x05aba4a04b48 in handle_selection_request (event=
{type = 30, xany = {type = 30, serial = 22, send_event = 0,
display = 0x5adb3b07000, window = 18874369}, xkey = {type = 30, serial
= 22, send_event = 0, display = 0x5adb3b07000, window = 18874369, root
= 20978267, subwindow = 1, time = 311, x = 482, y = 0, x_root =
-1052444533, y_root = 0, state = 0, keycode = 0, same_screen = 0},
xbutton = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, window = 18874369, root = 20978267, subwindow = 1, time
= 311, x = 482, y = 0, x_root = -1052444533, y_root = 0, state = 0,
button = 0, same_screen = 0}, xmotion = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, window = 18874369, root =
20978267, subwindow = 1, time = 311, x = 482, y = 0, x_root =
-1052444533, y_root = 0, state = 0, is_hint = 0 '\0', same_screen =
0}, xcrossing = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, window = 18874369, root = 20978267, subwindow = 1, time
= 311, x = 482, y = 0, x_root = -1052444533, y_root = 0, mode = 0,
detail = 0, same_screen = 0, focus = 0, state = 0}, xfocus = {type =
30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, mode = 20978267, detail = 0}, xexpose = {type = 30, serial =
22, send_event = 0, display = 0x5adb3b07000, window = 18874369, x =
20978267, y = 0, width = 1, height = 0, count = 311}, xgraphicsexpose
= {type = 30, serial = 22, send_event = 0, display = 0x5adb3b07000,
drawable = 18874369, x = 20978267, y = 0, width = 1, height = 0, count
= 311, major_code = 0, minor_code = 482}, xnoexpose = {type = 30,
serial = 22, send_event = 0, display = 0x5adb3b07000, drawable =
18874369, major_code = 20978267, minor_code = 0}, xvisibility = {type
= 30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, state = 20978267}, xcreatewindow = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, parent = 18874369, window =
20978267, x = 1, y = 0, width = 311, height = 0, border_width = 482,
override_redirect = 0}, xdestroywindow = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, event = 18874369, window =
20978267}, xunmap = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, event = 18874369, window = 20978267, from_configure =
1}, xmap = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, event = 18874369, window = 20978267, override_redirect
= 1}, xmaprequest = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, parent = 18874369, window = 20978267}, xreparent =
{type = 30, serial = 22, send_event = 0, display = 0x5adb3b07000,
event = 18874369, window = 20978267, parent = 1, x = 311, y = 0,
override_redirect = 482}, xconfigure = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, event = 18874369, window =
20978267, x = 1, y = 0, width = 311, height = 0, border_width = 482,
above = 3242522763, override_redirect = 0}, xgravity = {type = 30,
serial = 22, send_event = 0, display = 0x5adb3b07000, event =
18874369, window = 20978267, x = 1, y = 0}, xresizerequest = {type =
30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, width = 20978267,
Re: _XData32() crash: long* vs int* on amd64 (LP64)
Oh, and I think the (int *) cast here should be changed to (long *):
retval = wait_incr_selection (selection, event.xselection,
*(int *)value);
Can anyone confirm if xsel works on big-endian LP64 platforms? I'd
suspect the above expression would render it rather useless if it's
actually supposed to be (long *)...
On Tue, Jun 17, 2014 at 9:55 PM, Matthew Dempsky matt...@dempsky.org wrote:
I think the issue is that xsel.c allocates int nr_bytes; in
change_property(), and then passes it to XChangeProperty with
format==32. However, XChangeProperty() documents that format==32
specifically means a pointer to long (even on LP64 platforms).
I suspect changing int nr_bytes to long nr_bytes should fix the bug.
On Tue, Jun 17, 2014 at 1:56 AM, patrick keshishian pkesh...@gmail.com
wrote:
Hi,
I use xsel (from ports) pretty often, and every so often it
crashes:
$ gdb `which xsel` xsel.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 `xsel'.
Program terminated with signal 11, Segmentation fault.
Loaded symbols ...
[...]
#0 0x05adb1e28f40 in _XData32 () from /usr/X11R6/lib/libX11.so.16.0
(gdb) bt
#0 0x05adb1e28f40 in _XData32 () from /usr/X11R6/lib/libX11.so.16.0
#1 0x05adb1e05629 in XChangeProperty () from
/usr/X11R6/lib/libX11.so.16.0
#2 0x05aba4a03d75 in change_property (display=0x5adb3b07000,
requestor=20978267, property=482, target=4, format=32, mode=0,
data=0x5ada9647fc0 3\001, nelements=9, selection=1, time=3242522763,
mparent=0x0) at /usr/build/ports/pobj/xsel-1.2.0/xsel-1.2.0/xsel.c:1177
#3 0x05aba4a042f9 in handle_targets (display=0x5adb3b07000,
requestor=20978267, property=482, selection=1, time=3242522763,
mparent=0x0) at /usr/build/ports/pobj/xsel-1.2.0/xsel-1.2.0/xsel.c:1307
#4 0x05aba4a04b48 in handle_selection_request (event=
{type = 30, xany = {type = 30, serial = 22, send_event = 0,
display = 0x5adb3b07000, window = 18874369}, xkey = {type = 30, serial
= 22, send_event = 0, display = 0x5adb3b07000, window = 18874369, root
= 20978267, subwindow = 1, time = 311, x = 482, y = 0, x_root =
-1052444533, y_root = 0, state = 0, keycode = 0, same_screen = 0},
xbutton = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, window = 18874369, root = 20978267, subwindow = 1, time
= 311, x = 482, y = 0, x_root = -1052444533, y_root = 0, state = 0,
button = 0, same_screen = 0}, xmotion = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, window = 18874369, root =
20978267, subwindow = 1, time = 311, x = 482, y = 0, x_root =
-1052444533, y_root = 0, state = 0, is_hint = 0 '\0', same_screen =
0}, xcrossing = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, window = 18874369, root = 20978267, subwindow = 1, time
= 311, x = 482, y = 0, x_root = -1052444533, y_root = 0, mode = 0,
detail = 0, same_screen = 0, focus = 0, state = 0}, xfocus = {type =
30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, mode = 20978267, detail = 0}, xexpose = {type = 30, serial =
22, send_event = 0, display = 0x5adb3b07000, window = 18874369, x =
20978267, y = 0, width = 1, height = 0, count = 311}, xgraphicsexpose
= {type = 30, serial = 22, send_event = 0, display = 0x5adb3b07000,
drawable = 18874369, x = 20978267, y = 0, width = 1, height = 0, count
= 311, major_code = 0, minor_code = 482}, xnoexpose = {type = 30,
serial = 22, send_event = 0, display = 0x5adb3b07000, drawable =
18874369, major_code = 20978267, minor_code = 0}, xvisibility = {type
= 30, serial = 22, send_event = 0, display = 0x5adb3b07000, window =
18874369, state = 20978267}, xcreatewindow = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, parent = 18874369, window =
20978267, x = 1, y = 0, width = 311, height = 0, border_width = 482,
override_redirect = 0}, xdestroywindow = {type = 30, serial = 22,
send_event = 0, display = 0x5adb3b07000, event = 18874369, window =
20978267}, xunmap = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, event = 18874369, window = 20978267, from_configure =
1}, xmap = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, event = 18874369, window = 20978267, override_redirect
= 1}, xmaprequest = {type = 30, serial = 22, send_event = 0, display =
0x5adb3b07000, parent = 18874369, window = 20978267}, xreparent =
{type = 30, serial = 22, send_event = 0, display = 0x5adb3b07000,
event = 18874369, window = 20978267, parent = 1, x = 311, y = 0,
override_redirect = 482}, xconfigure = {type = 30,
Re: Porting a driver from NetBSD
Not sure if it's related to the arch (amd64), but have a variant compared to what the author of this thread posted. ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR4W, address 00:1b:9e:3a:bb:18 Prior to the Jun12 snap there were 5 lines of ath0 output, varying between reboots and including 'hal status 0'. From the Jun12 snap on, it changed to 3 lines which don't seem to change. ath0: unable to reset hardware; hal status 4294934528 ath0: unable to reset hardware; hal status 4294967295 ath0: unable to reset hardware; hal status 4294967295 Never tried to install multiple BSD flavors to one disk, but have a free 50G slot to install NetBSD if that helps. Full dmesg follows. Cheers - Z OpenBSD 5.5-current (GENERIC.MP) #215: Tue Jun 17 10:35:36 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4142333952 (3950MB) avail mem = 4023287808 (3836MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0170 (26 entries) bios0: vendor TOSHIBA version V2.30 date 01/15/2010 bios0: TOSHIBA Satellite A215 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP TCPA SLIC SSDT APIC MCFG HPET ASF! acpi0: wakeup devices PB2_(S4) PB3_(S4) PB4_(S4) PB5_(S3) PB6_(S0) BB4_(S4) BB5_(S4) OHC1(S4) OHC2(S4) OHC3(S4) OHC4(S4) OHC5(S4) EHCI(S4) P2P_(S5) AUDO(S4) MODM(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 Turion(tm) 64 X2 Mobile Technology TL-56, 1795.77 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,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP 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 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Turion(tm) 64 X2 Mobile Technology TL-56, 1795.50 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,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP 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 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-26 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PB2_) acpiprt2 at acpi0: bus -1 (PB3_) acpiprt3 at acpi0: bus -1 (PB4_) acpiprt4 at acpi0: bus 8 (PB5_) acpiprt5 at acpi0: bus 14 (PB6_) acpiprt6 at acpi0: bus 20 (PB7_) acpiprt7 at acpi0: bus -1 (BB4_) acpiprt8 at acpi0: bus 8 (BB5_) acpiprt9 at acpi0: bus 26 (P2P_) acpiprt10 at acpi0: bus 1 (AGP_) acpiec0 at acpi0 acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PWRB acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model PA3457U serial 3658Q type Li-Ion oem TOSHIBA acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ cpu0: PowerNow! K8 1795 MHz: speeds: 1800 1600 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 ATI RS690 Host rev 0x00 ppb0 at pci0 dev 1 function 0 ATI RS690 PCIE rev 0x00 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 5 function 0 ATI Radeon X1250 IGP rev 0x00 drm0 at radeondrm0 radeondrm0: msi ppb1 at pci0 dev 5 function 0 ATI RS690 PCIE rev 0x00: msi pci2 at ppb1 bus 8 ppb2 at pci0 dev 6 function 0 ATI RS690 PCIE rev 0x00: msi pci3 at ppb2 bus 14 re0 at pci3 dev 0 function 0 Realtek 8101E rev 0x01: RTL8101E (0x3400), msi, address 00:1b:38:1b:d2:ff rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1 ppb3 at pci0 dev 7 function 0 ATI RS690 PCIE rev 0x00: msi pci4 at ppb3 bus 20 ath0 at pci4 dev 0 function 0 Atheros AR5424 rev 0x01: apic 2 int 19 ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR4W, address 00:1b:9e:3a:bb:18 ahci0 at pci0 dev 18 function 0 ATI SB600 SATA rev 0x00: apic 2 int 22, AHCI 1.1 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: ATA, FUJITSU MHX2250B, 0040 SCSI3 0/direct fixed naa.50e0408826f2 sd0: 238475MB, 512 bytes/sector, 488397168 sectors ohci0 at pci0 dev 19 function 0 ATI SB600 USB rev 0x00: apic 2 int 16, version 1.0, legacy support ohci1 at pci0 dev 19 function 1 ATI SB600 USB rev 0x00: apic 2 int 17, version 1.0, legacy support ohci2 at pci0 dev 19 function 2 ATI SB600 USB rev 0x00: apic 2 int 18, version 1.0, legacy support ohci3 at pci0 dev 19 function 3 ATI SB600 USB rev 0x00: apic 2 int 17, version 1.0, legacy support ohci4 at
