Re: amd64 vmm(4) virtual machine "powers off" instead of rebooting when started with "-B disk"
> It has been this way since day-1 of -B -- unclear if you want to call > it expected, feature or bug :-) Ah, thanks! No need to dive into it then, and hopefully this thread will pop up in searches for others running into the same phenomenon. :) Regards, Jurjen Op do 29 dec. 2022 om 16:01 schreef Philipp Buehler : > > Am 29.12.2022 15:40 schrieb Jurjen Oskam: > > From the host dmesg I noticed the following line: > > It has been this way since day-1 of -B -- unclear if you want to call > it expected, feature or bug :-) > > Noticed this early on the vagrant+packer works.. -B is adhoc and > thus vmd is not aware of it after the process ends.. > > > -- > pb
amd64 vmm(4) virtual machine "powers off" instead of rebooting when started with "-B disk"
Hi,
Today I first started to use vmm(4) virtual machines (on amd64 7.2 with all
syspatches applied, dmesg of the host is below). From what I've seen so far
I'm quite happy with it, it's very elegant and straightforward how all the
components work together.
One thing I noticed is that when a VM is started with "-B disk" (or "boot
device disk" in vm.conf), trying to reboot the VM from inside it results in
it shutting down instead:
syncing disks... done
vmmci0: powerdown
rebooting...
[EOT]
superbsd#
At this point, the VM no longer shows in vmctl status (if started without
an entry in vm.conf) or with status "stopped" (if started from an entry in
vm.conf).
When I leave out the "-B disk" (or vm.conf equivalent), it works as
expected:
minecraft$ syncing disks... done
vmmci0: powerdown
rebooting...
Using drive 0, partition 3.
Loading..
probing: pc0 com0 mem[638K 3838M 4352M a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.55
The simplest way to reproduce is with just a switch definition in vm.conf:
superbsd# cat /etc/vm.conf
switch "uplink" {
interface veb0
}
superbsd#
... and starting the VM like this:
superbsd# vmctl start -c -n uplink -B disk -d /vm/minecraft/disk0.qcow2 -m
8G minecraft
When starting the VM with the exact same command but leaving out "-B disk"
the VM can be rebooted.
I don't know whether this is expected, and if not how this can be solved.
>From the host dmesg I noticed the following line:
cpu0: using VERW MDS workaround (except on vmm entry)
... but I don't know to what extent this is relevant.
Is there something I can do to investigate what the problem is, to send (if
relevant) a report to bugs@?
Regards,
Jurjen
OpenBSD 7.2 (GENERIC.MP) #4: Mon Dec 12 06:06:42 MST 2022
r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 68592119808 (65414MB)
avail mem = 66495918080 (63415MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (42 entries)
bios0: vendor American Megatrends Inc. version "2.3" date 06/04/2021
bios0: Supermicro Super Server
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT
BGRT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP01(S4) RP02(S4) RP03(S4)
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) BR1A(S4) BR1B(S4) BR2A(S4)
BR2B(S4) BR2C(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1900.03 MHz, 06-56-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 9MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1900.02 MHz, 06-56-03
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 9MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1900.02 MHz, 06-56-03
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 9MB 64b/line 12-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0:
Could "re0: watchdog timeout" be caused by pf queues?
Hi, On my home router, since a year or two I've occasionally seen watchdog timeouts on re0 (which is connected with 1Gbps to a Cisco switch): re0: watchdog timeout They weren't frequent, but when they occurred it was always under high-ish throughput (300-400 Mbps). Yesterday however, one particular download from a machine on the LAN was able to consistently and repeatedly trigger a watchdog timeout. Starting the download resulted in a watchdog timeout within a second or two. It only stopped when I configured the downloading program to limit itself to ~40 Mbps or so. This was surprising, since I regularly can download stuff at 300-400Mbps. I've been trying things like switching gige master/slave mode and enabling/ disabling ethernet flow control. While this was all nicely shown in the output of ifconfig, it did not make any difference in symptoms. Is such a watchdog timeout always caused by the NIC, or could it also be caused by things like VLANs or an incorrect queue configuration? In other words, is it useful to try different configurations or is this a clear indication the the NIC itself is on its way out? Output of ifconfig and dmesg follows: lo0: flags=8049 mtu 32768 index 4 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 re0: flags=8843 mtu 1500 lladdr 80:ee:73:a6:be:cf index 1 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 192.168.178.253 netmask 0xff00 broadcast 192.168.178.255 inet6 fe80::82ee:73ff:fea6:becf%re0 prefixlen 64 scopeid 0x1 inet6 2a03:10c3:391a:e0:: prefixlen 64 re1: flags=808843 mtu 1500 lladdr 80:ee:73:a6:be:ce index 2 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 83.86.199.249 netmask 0xfe00 broadcast 83.86.199.255 enc0: flags=0<> index 3 priority 0 llprio 3 groups: enc status: active gif0: flags=8051 mtu 1476 index 5 priority 0 llprio 3 encap: txprio payload rxprio payload groups: gif egress tunnel: inet 83.86.199.249 -> 185.216.160.152 ttl 128 nodf ecn inet6 fe80::82ee:73ff:fea6:becf%gif0 -> prefixlen 64 scopeid 0x5 inet6 2a03:10c3:10:391a::2 -> 2a03:10c3:10:391a::1 prefixlen 128 gre0: flags=8051 rdomain 1 mtu 1476 index 6 priority 0 llprio 6 encap: vnetid none txprio payload rxprio packet groups: gre tunnel: inet 83.86.199.249 -> 185.216.160.152 ttl 128 nodf ecn rdomain 0 inet 10.0.0.1 --> 0.0.0.0 netmask 0xff00 vlan2: flags=8843 mtu 1500 lladdr 80:ee:73:a6:be:cf index 7 priority 0 llprio 3 encap: vnetid 2 parent re0 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 192.168.179.253 netmask 0xff00 broadcast 192.168.179.255 vlan3: flags=8843 mtu 1500 lladdr 80:ee:73:a6:be:cf index 8 priority 0 llprio 3 encap: vnetid 3 parent re0 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 10.0.0.253 netmask 0xff00 broadcast 10.0.0.255 vlan4: flags=8843 mtu 1500 lladdr 80:ee:73:a6:be:cf index 9 priority 0 llprio 3 encap: vnetid 4 parent re0 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 10.1.0.253 netmask 0xff00 broadcast 10.1.0.255 vlan5: flags=8843 mtu 1500 lladdr 80:ee:73:a6:be:cf index 10 priority 0 llprio 3 encap: vnetid 5 parent re0 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 172.16.0.253 netmask 0xff00 broadcast 172.16.0.255 vlan9: flags=8843 rdomain 1 mtu 1500 lladdr 80:ee:73:a6:be:cf index 11 priority 0 llprio 3 encap: vnetid 9 parent re0 txprio packet rxprio outer groups: vlan media: Ethernet autoselect (1000baseT full-duplex,master) status: active inet 185.216.161.105 netmask 0xfff8 broadcast 185.216.161.111 lo1: flags=8008 rdomain 1 mtu 32768 index 12 priority 0 llprio 3 groups: lo pflog0: flags=141 mtu 33136 index 13 priority 0 llprio 3 groups: pflog OpenBSD 6.8 (GENERIC.MP) #1: Tue Nov 3 09:06:04 MST 2020 r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8456675328 (8064MB) avail mem = 8185331712 (7806MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec1e0 (77 entries) bios0:
Re: uvn_flush: WARNING: changes to page may be lost
On Thu, Nov 12, 2020 at 08:24:51PM +0100, Paul de Weerd wrote: > | > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. > | > > uvn_flush: WARNING: changes to page may be lost! > From the reply Mark sent me on June 9th[1]: > > > What you're seeing is what happens when a program writes to a file by > > using mmap(2) and there is no disk space available when the kernel > > finally decides to write out the modified memory to disk. > > There's plenty of space available in RAM, so you can create a file > that's bigger than the amount of space available on disk. Then > trying to write it to disk will fail with the error you got. Thanks, it makes sense that mmap() would be involved. Since I've only read the books and haven't actually written anything that uses mmap() I was under the impression that you can't use mmap() and friends to extend or create a file; the filesystem needs to have a file at least as big as the area you're mapping. So (just to understand what's going for my own curiosity) what are the ways you can end up in a situation where the kernel wants to write out mmapped data to disk, but there's no space in the filesystem to store that data? My first guess would be mmap()ing a sparse file. My second guess would be something where the file size was changed after the mapping was created, but before the data was written back. Probably a scenario where the msync(2) manpage warns for: "Filesystem operations on a file that is mapped for shared modifications are unpredictable except after an msync()." Thanks for pointing me in this direction, it resulted in an interesting half hour of reading web pages about mmap on several OSes. :) Regards, Jurjen Oskam
Re: uvn_flush: WARNING: changes to page may be lost
On Wed, Nov 11, 2020 at 05:54:36AM -0700, Todd C. Miller wrote: > On Wed, 11 Nov 2020 10:20:41 +0100, Jan Stary wrote: > > uvn_flush: obj=0x0, offset=0x7c2. error during pageout. > > uvn_flush: WARNING: changes to page may be lost! > This happens when /usr/libexec/reorder_kernel runs and your /usr > is full. If you have upgraded the system multiple times there is I ran into this earlier this year, and tried to figure out how a filesystem becoming full could result in kernel messages such as this. As there are no softupdates involved, I would have expected the kernel only to return a message about /usr being 100% full, and the (user space) kernel relinking to simply fail. I wasn't able to figure out what was going on. Is the relinking special in some way? Or is it possible that other situations where a filesystem fills up can result in messages like this? (Not counting situations where softupdates are enabled) Regards, Jurjen Oskam
Re: msyscall error during boot
On Thu, Jul 09, 2020 at 06:38:01AM +, mabi wrote: > I just upgraded one of my vmd virtual machine from OpenBSD 6.6 to 6.7 using > sysupgrade and noticed a new msyscall error message I have never seen before > during reboot as you can see below: > > ... > preserving editor files. > starting network daemons: sshd smtpd httpd. > starting package daemons: dovecot postgresql php72_fpm netsnmpd. > msyscall a35ee0ce000 a3000 error > msyscall a35187dd000 a5000 error > starting local daemons: cron. > Thu Jul 9 08:07:15 CEST 2020 > > Any ideas where this could come from? and if it is bad? Did you update your packages? I ran into the same issue when I forgot to update the packages after upgrading the system. Regards, Jurjen
Re: [smartmontools] OpenBSD testers required
On Fri, Jun 05, 2020 at 10:52:38AM +0200, Marek Benc wrote: > There's been some changes in the OpenBSD port of smartmontools, > tools for working with S.M.A.R.T diagnostic of hard drives and SSDs, > the platform-specific code was modernized, so it would be quite useful > if people could test these changes out to make sure they work on all > systems, I tested them on a macppc system with an ATA drive. > > The developer doesn't currently have access to a physical system > with OpenBSD running on it, so they wrote the changes in a virtual > machine. > > You can find the changes here: > https://github.com/smartmontools/smartmontools/pull/56 > Seems to work fine here: calvin$ uname -a OpenBSD calvin.int.osk.am 6.7 GENERIC.MP#2 amd64 calvin$ sysctl hw | egrep '(model|vendor|product|version)' hw.model=Intel(R) Pentium(R) CPU G3450 @ 3.40GHz hw.vendor=Shuttle Inc. hw.product=DS81L hw.version=V1.0 calvin$ doas ./smartctl -a -d ata /dev/rsd0c smartctl 7.2 (build date Jun 6 2020) [OpenBSD 6.7 amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Samsung based SSDs Device Model: Samsung SSD 840 EVO 120GB Serial Number:S1D5NSBDB26732X LU WWN Device Id: 5 002538 8a00f2d01 Firmware Version: EXT0DB6Q User Capacity:120,034,123,776 bytes [120 GB] Sector Size: 512 bytes logical/physical Rotation Rate:Solid State Device TRIM Command: Available Device is:In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is:Sat Jun 6 10:41:51 2020 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection:( 4200) seconds. Offline data collection capabilities:(0x53) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. No Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 2) minutes. Extended self-test routine recommended polling time:( 70) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010Pre-fail Always - 0 9 Power_On_Hours 0x0032 087 087 000Old_age Always - 64013 12 Power_Cycle_Count 0x0032 099 099 000Old_age Always - 545 177 Wear_Leveling_Count 0x0013 098 098 000Pre-fail Always - 24 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010Pre-fail Always - 0 187 Uncorrectable_Error_Cnt 0x0032 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 067 053 000Old_age Always - 33 195 ECC_Error_Rate 0x001a 200 200 000Old_age Always - 0 199 CRC_Error_Count
Re: Offline autoinstall(install.conf)
On Tue, Jun 02, 2020 at 01:48:33PM +, RT wrote: > I have already gone through the autoinstall man page but I didn't understand > how to do that using local(offline without the TFTP server) file(do I need to > write rewrite the bsd.rd and include the install.conf file? from > https://marc.info/?l=openbsd-misc=141552533922277=2) As the ramdisk is embedded in bsd.rd, if you want to do a local autoinstall you need to create a bsd.rd file that contains a ramdisk with your install.conf in there, under the name /auto_install.conf (as described in autoinstall(8)). The link you gave describes a good method of doing that, and nowadays it's easier because rdsetroot is part of the base system so you don't even need to build it. Regards, Jurjen Oskam
Forgetting pkg_add -u after sysupgrade can cause ansible msyscall errors
Hi, For the sake of the archives and future search engine users, I'll share what can happen when you use sysupgrade to upgrade your OpenBSD host but then forget to run update your installed packages. (Yep, silly mistake, I know...) After upgrading my Ansible host to 6.7, I noticed that each ansible command outputted the following error, but it continued normally after that: msyscall 1ba41d145000 a5000 error The second word varied with each invocation, and I did not notice any other adverse effects on that box. The error occurred with all ansible commands, such as ansible, ansible-playbook and ansible-connection. I was >< this close to sending a help request to this list, but I realized I had not tried to see what would happen on a freshly installed 6.7 box. It was then that I noticed that the new box had ansible-2.9.7 and python-3.7.7, while the upgraded box had ansible-2.7.9 and python-3.6.8p0. This caused me to realize I had forgotten to update my packages after doing the sysupgrade... A quick "pkg_add -u" later and my problem was gone. D'oh! So, moral of the story: don't forget to update your packages after a sysupgrade. Regards, Jurjen Oskam
Re: OpenBSD VM on ESXi: uvn_flush: obj=0xfffffd813ee78298, offset=0x33f000. error during pageout.
On Thu, Oct 31, 2019 at 08:01:25AM -, Stuart Henderson wrote: > On 2019-10-30, Jurjen Oskam wrote: > > > > All snapshots I tried up to and including this point did not show the > > problem: > > OpenBSD 6.6-beta (GENERIC.MP) #202: Mon Aug 12 11:01:21 MDT 2019 > > > > All snapshots I tried starting from this point show the problem: > > OpenBSD 6.6-beta (GENERIC.MP) #207: Tue Aug 13 11:32:34 MDT 2019 > > > > > > Would it be helpful to start a binary search for the exact commit that > > introduced the problem? > > Yes, definitely! We usually do this with date-based cvs updates. > > > I've been looking at the commit history around > > that time but haven't been able to spot an obvious candidate; but that's > > probably because I'm not a programmer. > > Sometimes diffs are tested in snapshots before they're committed, > so you might need to look beyond the snapshot dates to find the > commit. This took a while. I was not able to isolate a commit, but I did find the variable that can reliably trigger the problem. It's a bit embarrasing to say that the trigger is a f*ckup at my end: in my template configuration for short-lived VMs, I accidentally configured /usr to be 1G. I'm aware this is too small, but I never noticed because it didn't seem to cause any problem for quite a few releases. I guess at some point the kernel grew a bit and then the problem started to occur during reorder_kernel. After configuring /usr to be created at 4G (and leaving everything else the same), the problem never occurred again. This does lead me to a question though. Is it expected that a (nearly) full filesystem can result in dmesg error messages such as these? (None of the filesystems on the system are mounted softdep) uvn_flush: obj=0xfd813ee78298, offset=0x33f. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x33f. error during pageout. uvn_flush: WARNING: changes to page may be lost! [ repeat last two lines many times ] uvn_flush: obj=0xfd813ee78298, offset=0x340. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x340. error during pageout. uvn_flush: WARNING: changes to page may be lost! [ repeat last two lines many times ] /dev/sd0a on / type ffs (local) /dev/sd0i on /home type ffs (local, nodev, nosuid) /dev/sd0d on /tmp type ffs (local, nodev, nosuid) /dev/sd0f on /usr type ffs (local, nodev) /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev, wxallowed) /dev/sd0e on /var type ffs (local, nodev, nosuid) Regards, Jurjen Oskam
Re: OpenBSD VM on ESXi: uvn_flush: obj=0xfffffd813ee78298, offset=0x33f000. error during pageout.
On Tue, Oct 29, 2019 at 01:25:10PM -0700, Mike Larkin wrote: > On Tue, Oct 29, 2019 at 09:16:42PM +0100, Jurjen Oskam wrote: [...] > > uvn_flush: obj=0xfd813ee78298, offset=0x33f. error during pageout. > > uvn_flush: WARNING: changes to page may be lost! > > uvn_flush: obj=0x0, offset=0x33f. error during pageout. > > uvn_flush: WARNING: changes to page may be lost! > > [ repeat last two lines many times ] [...] > > nvme0 at pci19 dev 0 function 0 "VMware NVMe" rev 0x00: apic 1 int 16, NVMe > > 1.0 > > nvme0: VMware Virtual NVMe Disk, firmware 1.0, serial VMWare NVME- > > Why did you assign this non-default disk type to the guest VM? > > Try assigning mpi(4) (LSI Logic SAS) instead. I've been using that with my > ESXi 6.7U3 box here without problems for weeks. > > If that works, it's either an error in our nvme(4) driver or ESXi's emulation > of the NVMe hardware. I forgot to mention that I tried using different controller types, and nvme(4) happened to be the one I took the dmesg of. The ones I tried were LSI Logic SAS, LSI Logic Parallel and VMware Paravirtual (the latter after working around the lost first write problem). All showed the same symptom. I have been trying old snapshots (thanks to the snapshot archive at ftp.hostserver.de), and found the point where the problem started to occur: All snapshots I tried up to and including this point did not show the problem: OpenBSD 6.6-beta (GENERIC.MP) #202: Mon Aug 12 11:01:21 MDT 2019 All snapshots I tried starting from this point show the problem: OpenBSD 6.6-beta (GENERIC.MP) #207: Tue Aug 13 11:32:34 MDT 2019 Would it be helpful to start a binary search for the exact commit that introduced the problem? I've been looking at the commit history around that time but haven't been able to spot an obvious candidate; but that's probably because I'm not a programmer. Regards, Jurjen Oskam
OpenBSD VM on ESXi: uvn_flush: obj=0xfffffd813ee78298, offset=0x33f000. error during pageout.
0 "PNP0A05" at acpi0 not configured acpiac0 at acpi0: AC unit online cpu0: using VERW MDS workaround pvbus0 at mainbus0: VMware vmt0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02 pci2 at ppb1 bus 2 ppb2 at pci0 dev 21 function 0 "VMware PCIE" rev 0x01 pci3 at ppb2 bus 3 vmx0 at pci3 dev 0 function 0 "VMware VMXNET3" rev 0x01: apic 1 int 18, address 00:0c:29:fb:60:eb ppb3 at pci0 dev 21 function 1 "VMware PCIE" rev 0x01 pci4 at ppb3 bus 4 ppb4 at pci0 dev 21 function 2 "VMware PCIE" rev 0x01 pci5 at ppb4 bus 5 ppb5 at pci0 dev 21 function 3 "VMware PCIE" rev 0x01 pci6 at ppb5 bus 6 ppb6 at pci0 dev 21 function 4 "VMware PCIE" rev 0x01 pci7 at ppb6 bus 7 ppb7 at pci0 dev 21 function 5 "VMware PCIE" rev 0x01 pci8 at ppb7 bus 8 ppb8 at pci0 dev 21 function 6 "VMware PCIE" rev 0x01 pci9 at ppb8 bus 9 ppb9 at pci0 dev 21 function 7 "VMware PCIE" rev 0x01 pci10 at ppb9 bus 10 ppb10 at pci0 dev 22 function 0 "VMware PCIE" rev 0x01 pci11 at ppb10 bus 11 vmx1 at pci11 dev 0 function 0 "VMware VMXNET3" rev 0x01: apic 1 int 19, address 00:0c:29:fb:60:f5 ppb11 at pci0 dev 22 function 1 "VMware PCIE" rev 0x01 pci12 at ppb11 bus 12 ppb12 at pci0 dev 22 function 2 "VMware PCIE" rev 0x01 pci13 at ppb12 bus 13 ppb13 at pci0 dev 22 function 3 "VMware PCIE" rev 0x01 pci14 at ppb13 bus 14 ppb14 at pci0 dev 22 function 4 "VMware PCIE" rev 0x01 pci15 at ppb14 bus 15 ppb15 at pci0 dev 22 function 5 "VMware PCIE" rev 0x01 pci16 at ppb15 bus 16 ppb16 at pci0 dev 22 function 6 "VMware PCIE" rev 0x01 pci17 at ppb16 bus 17 ppb17 at pci0 dev 22 function 7 "VMware PCIE" rev 0x01 pci18 at ppb17 bus 18 ppb18 at pci0 dev 23 function 0 "VMware PCIE" rev 0x01 pci19 at ppb18 bus 19 nvme0 at pci19 dev 0 function 0 "VMware NVMe" rev 0x00: apic 1 int 16, NVMe 1.0 nvme0: VMware Virtual NVMe Disk, firmware 1.0, serial VMWare NVME- scsibus1 at nvme0: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: sd0: 30720MB, 512 bytes/sector, 62914560 sectors ppb19 at pci0 dev 23 function 1 "VMware PCIE" rev 0x01 pci20 at ppb19 bus 20 ppb20 at pci0 dev 23 function 2 "VMware PCIE" rev 0x01 pci21 at ppb20 bus 21 ppb21 at pci0 dev 23 function 3 "VMware PCIE" rev 0x01 pci22 at ppb21 bus 22 ppb22 at pci0 dev 23 function 4 "VMware PCIE" rev 0x01 pci23 at ppb22 bus 23 ppb23 at pci0 dev 23 function 5 "VMware PCIE" rev 0x01 pci24 at ppb23 bus 24 ppb24 at pci0 dev 23 function 6 "VMware PCIE" rev 0x01 pci25 at ppb24 bus 25 ppb25 at pci0 dev 23 function 7 "VMware PCIE" rev 0x01 pci26 at ppb25 bus 26 ppb26 at pci0 dev 24 function 0 "VMware PCIE" rev 0x01 pci27 at ppb26 bus 27 ppb27 at pci0 dev 24 function 1 "VMware PCIE" rev 0x01 pci28 at ppb27 bus 28 ppb28 at pci0 dev 24 function 2 "VMware PCIE" rev 0x01 pci29 at ppb28 bus 29 ppb29 at pci0 dev 24 function 3 "VMware PCIE" rev 0x01 pci30 at ppb29 bus 30 ppb30 at pci0 dev 24 function 4 "VMware PCIE" rev 0x01 pci31 at ppb30 bus 31 ppb31 at pci0 dev 24 function 5 "VMware PCIE" rev 0x01 pci32 at ppb31 bus 32 ppb32 at pci0 dev 24 function 6 "VMware PCIE" rev 0x01 pci33 at ppb32 bus 33 ppb33 at pci0 dev 24 function 7 "VMware PCIE" rev 0x01 pci34 at ppb33 bus 34 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (afa24b55e438df24.a) swap on sd0b dump on sd0b Regards, Jurjen Oskam
Re: L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?
Hi Philipp, Thank you - this was exactly what I was missing. I have now gotten it to work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1), which strongly suggests my Nexus 6P (all patched) doesn't implement hmac-sha2-256 correctly. The irony is that the manpage of isakmpd.policy explains all this excellently, but I didn't read it because I misunderstood what the manpage of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run at boot time via the isakmpd_flags variable in rc.conf.local(8). Note that it will probably need to be run with at least the -K option, to avoid keynote(4) policy checking." I read this as meaning that keynote policy checking is *always* unwanted when ipsecctl is used, and that you can avoid policy checking either by not having a policy file at all (in which case the -K option doesn't matter), or by using the -K option (in which case it's certain that policy checking never happens). But now I know better. :) Thanks, Jurjen 2017-03-20 9:33 GMT+01:00 Jurjen Oskam <jur...@osk.am>: > Hi Philipp, > > Thank you - this was exactly what I was missing. I have now gotten it to > work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1), > which strongly suggests my Nexus 6P (all patched) doesn't implement > hmac-sha2-256 correctly. > > The irony is that the manpage of isakmpd.policy explains all this > excellently, but I didn't read it because I misunderstood what the manpage > of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run > at boot time via the isakmpd_flags variable in rc.conf.local(8). Note that > it will probably need to be run with at least the -K option, to avoid > keynote(4) policy checking." I read this as meaning that keynote policy > checking is *always* unwanted when ipsecctl is used, and that you can avoid > policy checking either by not having a policy file at all (in which case > the -K option doesn't matter), or by using the -K option (in which case > it's certain that policy checking never happens). > > But now I know better. :) > > Thanks, > > Jurjen > > > 2017-03-20 6:08 GMT+01:00 Philipp Buehler 7...@posteo.net>: > >> Am 19.03.2017 15:36 schrieb Jurjen Oskam: >> >> So, to validate that I'm indeed hitting this bug (and also as a >>> workaround) >>> I tried to set up the OpenBSD side to not use SHA2. I haven't been able >>> to >>> get this running yet: isakmpd always seems to offer HMAC_SHA2_256. >>> >> >> It's not offering that - but accepting "better" Phase2 transforms. If >> isakmpd >> would start the negotiation, it'd propose HMAC_SHA. >> >> To keep out unwanted proposals, you need an isakmpd.policy. (hint: no -K) >> >> In my eyes this is 'bad behaviour' and tends to lead to situations where >> e.g. >> a remote end "upgrades" (and locks down) the transforms and thus rekeying >> started by isakmpd start to fail. >> >> HTH, >> -- >> pb
L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?
attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute AUTHENTICATION_ALGORITHM = HMAC_SHA payload: TRANSFORM len: 24 transform: 9 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 payload: TRANSFORM len: 24 transform: 10 ID: DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256 payload: TRANSFORM len: 24 transform: 11 ID: DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute AUTHENTICATION_ALGORITHM = HMAC_SHA payload: TRANSFORM len: 24 transform: 12 ID: DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 payload: NONCE len: 20 payload: ID len: 12 proto: 17 port: 0 type: IPV4_ADDR = 100.93.193.197 payload: ID len: 12 proto: 17 port: 1701 type: IPV4_ADDR = 83.86.243.18 [ttl 0] (id 1, len 492) 15:31:00.865689 5356F312.cm-6-7d.dynamic.ziggo.nl.ipsec-nat-t > static.kpn.net.ipsec-nat-t: [bad udp cksum 9d3a! -> 1d43] udpencap: isakmp v1.0 exchange QUICK_MODE cookie: 0f659aa030f4904d->64d8256cce1ec37b msgid: 8281d122 len: 148 payload: HASH len: 24 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0xacb10a8a payload: TRANSFORM len: 28 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute KEY_LENGTH = 256 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256 payload: NONCE len: 20 payload: ID len: 12 proto: 17 port: 0 type: IPV4_ADDR = 100.93.193.197 payload: ID len: 12 proto: 17 port: 1701 type: IPV4_ADDR = 83.86.243.18 [ttl 0] (id 1, len 180) ipsecctl shows that hmac-sha2-256 is indeed selected: # ipsecctl -s all FLOWS: flow esp in proto udp from 31.161.203.40 to 83.86.243.18 port l2tp peer 31.161.203.40 srcid 83.86.243.18/32 dstid 100.93.193.197/32 type use flow esp out proto udp from 83.86.243.18 port l2tp to 31.161.203.40 peer 31.161.203.40 srcid 83.86.243.18/32 dstid 100.93.193.197/32 type require SAD: esp transport from 83.86.243.18 to 31.161.203.40 spi 0x030ab16e auth hmac-sha2-256 enc aes-256 esp transport from 31.161.203.40 to 83.86.243.18 spi 0xa31bf5b1 auth hmac-sha2-256 enc aes-256 Using the FIFO based interface to isakmpd, I verified that HMAC_SHA is configured: # get "[Phase 2]:Connections" # get "[Phase 2]:Passive-Connections" from-re1=17-to-0.0.0.0/0=17:1701 # get "[from-re1=17-to-0.0.0.0/0=17:1701]:Configuration" phase2-from-re1=17-to-0.0.0.0/0=17:1701 # get "[phase2-from-re1=17-to-0.0.0.0/0=17:1701]:Suites" phase2-suite-from-re1=17-to-0.0.0.0/0=17:1701 # get "[phase2-suite-from-re1=17-to-0.0.0.0/0=17:1701]:Protocols" phase2-protocol-from-re1=17-to-0.0.0.0/0=17:1701 # get "[phase2-protocol-from-re1=17-to-0.0.0.0/0=17:1701]:PROTOCOL_ID" IPSEC_ESP # get "[phase2-protocol-from-re1=17-to-0.0.0.0/0=17:1701]:Transforms" phase2-transform-from-re1=17-to-0.0.0.0/0=17:1701-AES128-SHA-MODP_1024-TRANSPORT # get "[phase2-transform-from-re1=17-to-0.0.0.0/0=17:1701-AES128-SHA-MODP_1024-TRANSPORT]:AUTHENTICATION_ALGORITHM" HMAC_SHA # I'm likely to miss something obvious here. Why is isakmpd negotiating HMAC_SHA2_256 instead of HMAC_SHA, as it is configured to do? Any hints would be much appreciated. Thanks, Jurjen Oskam
Re: Cannot set stty parameters and read from /dev/ttyU0
Stuart Henderson stu at spacehopper.org writes: On 2014-01-10, Jurjen Oskam jurjen at osk.am wrote: Philip Guenther guenther at gmail.com writes: Oh, you're running 5.4-stable? I thought you were running -current and was worried there was another hang in there. I'm now 99% sure you're hitting the one I fixed back in October. I'm sorry, but I don't know which hang you fixed in October. With this information, do you think it's the same hang? It's this one, which is in 5.4-stable updated after 2013/11/12 http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/003_vnode.patch Hmm, I'm running -stable as provided by M:Tier, which should have that fix in it: OpenBSD 5.4 (GENERIC.MP) #1: Tue Nov 12 10:57:06 CET 2013 r...@binpatch-54-amd64.mtier.org:/home/jasper/binpatchng/work-binpatch54- amd64/src/sys/arch/amd64/compile/GENERIC.MP # pkg_info binpatch54-amd64-kernel-2.0 Binary Patch for 003_vnode.patch [...] It seems like this is a different issue then. What can I do to investigate this further? Regards, Jurjen Oskam
Re: Cannot set stty parameters and read from /dev/ttyU0
Philip Guenther guenther at gmail.com writes: On Thu, Jan 9, 2014 at 8:20 AM, Jurjen Oskam jurjen at osk.am wrote: OK, I've got it to work using a /dev/cua* device. I still have problems with processes not exiting though. Since this machine has real com ports, I also made a cable that is attached to cua01 (no USB involved). ... Then when I kill it, I get this: $ kill 13670 $ ps PID TT STAT TIME COMMAND 15727 p0 Is 0:00.01 -ksh (ksh) 13444 p0 S+ 0:00.02 kdump -l -T 26314 p1 Is 0:00.00 -ksh (ksh) 13670 p1 SE+ 0:00.01 (perl) 6996 p2 Ss 0:00.00 -ksh (ksh) 13352 p2 R+/10:00.00 ps What's the output of ps -Owchan,procflags,f for the process? $ ps -Owchan,procflags,f ps: procflags: keyword not found PID WCHAN F TT STAT TIME COMMAND 1579 pause 408e p0 Is 0:00.00 -ksh (ksh) 21410 ttyout 80006086 p0 IE+ 0:00.00 (perl) 8608 pause 408e p1 Ss 0:00.00 -ksh (ksh) 27149 - 4006 p1 R+/10:00.00 ps -Owchan (Running 5.4-stable, so that's why procflags isn't recognized. I'll try a snapshot to see what happens.) Regards, Jurjen Oskam
Re: Cannot set stty parameters and read from /dev/ttyU0
Philip Guenther guenther at gmail.com writes:
Oh, you're running 5.4-stable? I thought you were running -current
and was worried there was another hang in there. I'm now 99% sure
you're hitting the one I fixed back in October.
I did some more experimenting, and I found that the issue does not happen
when I leave out the crtscts option to stty.
With crtscts however, things get weird:
Opening and immediately closing cua01 is no problem:
open cua01
stty 9600 sane parenb -parodd crtscts cs7 igncr
close cua01 # device probably didn't send anything yet
exit# exits normally
Opening cua01 and closing it later *is* a problem:
open cua01
stty 9600 sane parenb -parodd crtscts cs7 igncr
sleep 15# to make sure the device on the other end has sent some data
close cua01 # HANGS, but is interruptible after which everything is nicely
cleaned up
exit# never reached
Interrupting a read from cua01 results in a process that can't exit:
open cua01
stty 9600 sane parenb -parodd crtscts cs7 igncr
while-loop {
read cua01 # blocks when the other end isn't sending anything; if the
process is interrupted now it won't ever exit;
cua01 is not released and only a reboot clears the process
}
close cua01 # HANGS, but is interruptible after which everything is nicely
cleaned up
exit# never reached
Again, if I leave out crtscts (and leave everything else the same),
everything works as expected: no hangs at all, and interrupting a read is no
problem.
I'm sorry, but I don't know which hang you fixed in October. With this
information, do you think it's the same hang?
Thanks,
Jurjen Oskam
Re: Cannot set stty parameters and read from /dev/ttyU0
Philip Guenther guenther at gmail.com writes:
This is where Remco's response comes into play. As described on the
tty(4)/cua(4) manpage, /dev/ttyU* blocks on open until the external
device signals that it's active via some hardware signal (DTR, iirc).
If you want to initiate an outgoing connection to a potentially
inactive device, use the matching /dev/cuaU* device.
OK, I've got it to work using a /dev/cua* device. I still have problems with
processes not exiting though. Since this machine has real com ports, I also
made a cable that is attached to cua01 (no USB involved).
This little Perl script shows the problem:
#!/usr/bin/perl -w
$|=1;
close(STDIN) or die;
open(STDIN,/dev/cua01);
system(/bin/stty 9600 sane parenb -parodd crtscts cs7 igncr);
system(/bin/stty);
while (my $line = ) {
print $line;
}
I run it using ktrace:
$ ktrace -i ./try.pl
speed 9600 baud;
lflags: echoe echoke echoctl
iflags: igncr
cflags: cs7 parenb crtscts
/XMX5XMXABCE35164
0-0:96.1.1(31333031333735352020202020202020)
1-0:1.8.1(02932.937*kWh)
[ ... output snipped ...]
It shows as follows in the output of ps:
$ ps
PID TT STAT TIME COMMAND
15727 p0 Ss 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
26314 p1 Ss 0:00.00 -ksh (ksh)
13670 p1 S+ 0:00.01 /usr/bin/perl -w ./try.pl
6996 p2 Ss 0:00.00 -ksh (ksh)
29731 p2 R+/10:00.00 ps
Then when I kill it, I get this:
$ kill 13670
$ ps
PID TT STAT TIME COMMAND
15727 p0 Is 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
26314 p1 Is 0:00.00 -ksh (ksh)
13670 p1 SE+ 0:00.01 (perl)
6996 p2 Ss 0:00.00 -ksh (ksh)
13352 p2 R+/10:00.00 ps
... and after a while, this:
$ ps
PID TT STAT TIME COMMAND
15727 p0 Is 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
26314 p1 Is 0:00.00 -ksh (ksh)
13670 p1 IE+ 0:00.01 (perl)
6996 p2 Ss 0:00.00 -ksh (ksh)
23612 p2 R+/10:00.00 ps
The terminal on which the Perl script was running didn't return the prompt.
The script was also no longer running, because it didn't display new data
coming from cua00 anymore.
The last few lines from ktrace.out are:
13670 perl 1389283736.782851 RET write 2
13670 perl 1389283736.782855 CALL read(0,0x10dbb9977000,0x2000)
13670 perl 1389283738.376985 PSIG SIGTERM SIG_DFL
The read normally blocks for 10 seconds, because that is the interval the
meter sends it data. The kill happened while this read was waiting for data.
I am now no longer able to terminate the process. Disconnecting its terminal
just gives:
$ ps
PID TT STAT TIME COMMAND
15727 p0 Is 0:00.01 -ksh (ksh)
13444 p0 S+ 0:00.02 kdump -l -T
13670 p1- IE 0:00.01 (perl)
6996 p2 Ss 0:00.00 -ksh (ksh)
32590 p2 R+/10:00.00 ps
Killing it with -9 also does not work.
cua01 is still busy though:
$ stty -f /dev/cua01
stty: /dev/cua01: Device busy
The only way to get rid of the process is to reboot the system.
Am I doing anything wrong here? I expected the process to just exit and
release cua01 after I killed it.
Regards,
Jurjen Oskam
Cannot set stty parameters and read from /dev/ttyU0
Hi everybody,
Earlier I had a Linux machine (well, a Raspberry Pi actually) which
I used to read out my energy meter. The energy meter was connected
to a USB port with a custom FTDI cable. The energy meter only
supports reading from it, writing to it is not possible.
On Linux, I set the necessary parameters on the USB tty as follows:
/bin/stty -F /dev/ttyUSB0 9600 sane evenp crtscts cs7 igncr
And after that, issuing cat /dev/ttyUSB0 resulted in the output
I'm interested in: the energy meter outputs its data every ten seconds.
Wrapping this in a Perl script was easy: just set issue the stty
command before invoking the Perl script, and in Perl I could just open
/dev/ttyUSB0 for reading and process the output line by line:
open(METER,/dev/ttyUSB0) or die;
while(METER) {
# do stuff
done
This worked fine.
I replaced the Raspberry Pi with a more powerful amd64 machine
(full dmesg below). The USB cable shows up as:
uftdi0 at uhub3 port 6 FTDI P1 Converter Cable rev 2.00/6.00 addr 3
ucom0 at uftdi0 portno 1
But now I can't figure out how to read from /dev/ttyU0.
The first problem I'm having is that the stty setting doesn't seem to
stick:
$ stty -f /dev/ttyU0
ispeed 0 baud; ospeed 9600 baud;
lflags: echoe echoke echoctl
cflags: cs8 -parenb
$ stty -f /dev/ttyU0 9600 sane parenb -parodd crtscts cs7 igncr
$
$ stty -f /dev/ttyU0
ispeed 0 baud; ospeed 9600 baud;
lflags: echoe echoke echoctl
cflags: cs8 -parenb
When I do a cat /dev/ttyU0 in one terminal, it just hangs without
displaying anything. If I execute stty -f /dev/ttyU0 in another terminal,
cat suddenly outputs a few lines of garbage and then exits.
When I again do a cat /dev/ttyU0 in one terminal, but then use stty in
another terminal to set the correct settings, the cat command starts
outputting the correct data: several lines of output every ten seconds.
After while, it stops though, and I can't interrupt the cat command
anymore. A stty in another terminal also hangs uninterruptibly. Even a
kill -9 and disconnecting the SSH session doesn't work:
joskam 21226 0.0 0.0 180 152 p0 D+ 3:56PM0:00.00 stty -f
/dev/ttyU0
joskam 22302 0.0 0.0 236 176 p1- IE 3:54PM0:00.00 (cat)
I did read the manual pages, but I probably overlooked something.
How can I set the correct parameters on /dev/ttyU0 and read from it?
Thank you,
Jurjen Oskam
Full dmesg:
OpenBSD 5.4 (GENERIC.MP) #1: Tue Nov 12 10:57:06 CET 2013
r...@binpatch-54-amd64.mtier.org:/home/jasper/binpatchng/work-binpatch54-
amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4204191744 (4009MB)
avail mem = 4084551680 (3895MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb420 (76 entries)
bios0: vendor American Megatrends Inc. version 2.04 date 04/16/2013
bios0: Shuttle Inc. DS61
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC HPET SSDT SSDT SSDT
acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz, 2893.81 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,
DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,
XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz, 2893.43 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,
DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,
XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus 3 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus 4 (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)
acpiec0 at acpi0: Failed to read resource settings
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: FN00
acpipwrres1 at acpi0: FN01
acpipwrres2 at acpi0: FN02
acpipwrres3 at acpi0: FN03
acpipwrres4 at acpi0: FN04
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0
Re: Cannot set stty parameters and read from /dev/ttyU0
Philip Guenther guenther at gmail.com writes: On Tue, Jan 7, 2014 at 8:23 AM, Theo de Raadt deraadt at cvs.openbsd.org wrote: What you need to instead is wrap all this in a way which keeps the tty open ( stty 9600 sane parenb -parodd crtscts cs7 igncr do your IO loop ) /dev/ttyU0 01 02 Something like that. I think the desired redirections on the subshell-close would make that last line: ) /dev/ttyU0 0 (open /dev/ttyU0 read-write as stdin, and then dup that to stdout) Thank you for the responses. I sort of figured out that the stty settings are set to default each time the device is opened, but now that's confirmed I ran into the problem that open() does not seem to be returning. I created the following simple shell script: #!/bin/sh ( stty 9600 sane parenb -parodd crtscts cs7 igncr while read line do echo $line done ) /dev/ttyU0 0 Running it results in no output at all, without the prompt coming back. Interrupting the process results in the following ktrace snippet: 486 sh 1389125130.342774 CALL open(0x208ee2c50,0x202O_RDWR|O_CREAT,0x1b6S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP |S_IROTH|S_IWOTH) 486 sh 1389125130.342776 NAMI /dev/ttyU0 486 sh 1389125151.417307 PSIG SIGINT caught handler=0x4214f0 mask=0 486 sh 1389125151.417312 RET open -1 errno 4 Interrupted system call Looking at the timestamps, the open() only returns when I Ctrl-C the process. The same happens with the following trivial Perl script: #!/usr/bin/perl -w $|=1; open(METER,/dev/ttyU0) or die; print opened terminal\n; close(METER); Running it produces no output without the prompt coming back, at least not until I Ctrl-C the Perl script: 15860 perl 1389125426.222462 CALL open(0x12f6694a1d70,0O_RDONLY) 15860 perl 1389125426.222465 NAMI /dev/ttyU0 15860 perl 1389125451.261414 PSIG SIGINT SIG_DFL Again, open() doesn't seem to return. Am I doing something wrong here? Regards, Jurjen Oskam
Re: dhclient, resolv.conf
On Sun, Oct 23, 2011 at 12:08:22AM +0200, Jan Stary wrote: On Oct 22 04:41:56, Philippe Meunier wrote: Kenneth R Westerback wrote: If you are using dhclient, then /etc/resolv.conf is not really a configuration file. Unless your machine runs its own DNS server. Just out of curiosity, what would be an example situation for using a machine that simultaneously (1) acts as a name-server for others (2) gets its network settings dynamicaly reconfigured An example would be an ISP that uses DHCP to maintain a DSL connection. Even with a static IP address, I *must* get it using a DHCP client and keep it running so the lease is properly renewed. If the lease isn't renewed on time, the connection just stops routing IP. Even with a static IP address. Since I run my own resolving DNS server, it was annoying that the DHCP server not only gave me my static IP address, but also the addresses of the ISP's resolving name servers. I just used chflags uchg /etc/resolv.conf, until I properly read the manual and discovered how I can use the supersede option in dhclient.conf: supersede domain-name-servers 192.168.1.1; supersede domain-name ; Regards, -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Seeking inexpensive RAID 1 hardware recommendation
On Mon, Nov 15, 2010 at 06:30:18PM +0100, m...@mdaniel.de wrote: I have a hard time finding a RAID1 capable controller that is well supported via bioctl, available, and not too expensive. Is there e.g. a nice mpi or mpii card that can be controlled via bioctl? The man page only mentions that some mpi cards offer Raid1. Of course it doesn't have to be a mpi card. The mpi man page mentions a HP card (EH417AA). Even though it's a HP branded card, you can go to lsi.com and download the most current firmware. I have four SATA drives attached in 2 RAID1 arrays, works extremely well. It wasn't hard to find over here, and not expensive. I just visited a reputable Web shop, searched for EH417AA and that was basically it. Regards, -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Auto Logout Idle Users
On Thu, Oct 14, 2010 at 06:17:23PM -0400, Brad Tilley wrote:
I thought about doing that too. I need to test it more to see what
happens when ksh is the shell and the user executes csh manually. I
suppose ksh will still honor TMOUT in that case.
TMOUT is at most a convenience, not a security measure:
$ TMOUT=600
$ readonly TMOUT
$ exec perl -e 'delete $ENV{TMOUT} ; exec /bin/ksh;'
$ echo $TMOUT
0
$
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.
mt_soname mbufs keep increasing steadily, where can I look?
11) pci3 at ppb2 bus 3 mskc0 at pci3 dev 0 function 0 Marvell Yukon 88E8056 rev 0x14, Yukon-2 EC Ultra rev. B0 (0x3): apic 4 int 16 (irq 11) msk0 at mskc0 port A: address 00:26:18:65:bc:ab eephy0 at msk0 phy 0: 88E1149 Gigabit PHY, rev. 1 ppb3 at pci0 dev 28 function 5 Intel 82801G PCIE rev 0x01: apic 4 int 17 (irq 10) pci4 at ppb3 bus 2 mskc1 at pci4 dev 0 function 0 Marvell Yukon 88E8056 rev 0x14, Yukon-2 EC Ultra rev. B0 (0x3): apic 4 int 17 (irq 10) msk1 at mskc1 port A: address 00:26:18:65:ba:d5 eephy1 at msk1 phy 0: 88E1149 Gigabit PHY, rev. 1 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 4 int 23 (irq 5) uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 4 int 19 (irq 7) ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 4 int 23 (irq 5) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci5 at ppb4 bus 1 rl0 at pci5 dev 0 function 0 Realtek 8139 rev 0x10: apic 4 int 21 (irq 10), address 00:e0:4d:52:a8:d1 rlphy0 at rl0 phy 0: RTL internal PHY ral0 at pci5 dev 1 function 0 Ralink RT2561S rev 0x00: apic 4 int 22 (irq 6), address 00:11:6b:3d:7f:6a ral0: MAC/BBP RT2561C, RF RT2527 re0 at pci5 dev 2 function 0 Realtek 8139 rev 0x20: RTL8139C+ (0x7480), apic 4 int 23 (irq 5), address 00:0a:fa:20:04:c8 rlphy1 at re0 phy 0: RTL internal PHY vga1 at pci5 dev 3 function 0 XGI Technology Volari Z7 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01 ichiic0 at pci0 dev 31 function 3 Intel 82801GB SMBus rev 0x01: apic 4 int 19 (irq 7) iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627DHG spdmem0 at iic0 addr 0x51: 1GB DDR2 SDRAM ECC PC2-6400CL5 spdmem1 at iic0 addr 0x53: 1GB DDR2 SDRAM ECC PC2-6400CL5 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25 lm2 at wbsio0 port 0x290/8: W83627DHG lm1 detached mtrr: Pentium Pro MTRR support softraid0 at root root on sd1a swap on sd1b dump on sd1b WARNING: / was not properly unmounted -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: TRIM support?
On Tue, Apr 20, 2010 at 11:03:30PM -0700, J.C. Roberts wrote: degrade. You might be better off in the long run using multiple rotating disks that are half as fast, and half the price, but won't degrade. It's my understanding that if you have a decent SSD, write response times can (under some workloads) degrade but never below the performance of even a very fast rotating disk. So, i've stopped worrying about things like TRIM and trying to avoid writes. I'll align my partitions, but apart from that I just enjoy the extremely low read response times, and my almost-always-quite-low write response times. :) -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: trouble showing a kernel dmesg
On Fri, Mar 26, 2010 at 06:36:37AM -0400, Nick Holland wrote: run bsd. You can't pull a dmesg out of a kernel that wasn't run (note that some machines don't clear their RAM between boots, so you can sometimes see multiple dmesgs if you have rebooted without powering down. Usual rule: if this would be convenient for you, it won't work, your machine will have cleared RAM before boot. :) Very true: my machine keeps the dmesg buffer intact when it's rebooted normally, but every now and then it just spontaneously and instantly reboots (I suspect the hardware) but you've guessed it: in that case the dmesg doesn't survive the reboot... -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Why does dhclient-script set a route to 127.0.0.1?
Hi there, I switched to a new DSL provider, and this provider assigns an IP address using DHCP. No problem, a hostname.msk1 with just dhcp in it works great. When digging a bit deeper (purely out of interest), I noticed that /sbin/dhclient-script explicitly does: route add $new_ip_address 127.0.0.1 /dev/null 21 ... when it gets a lease. This route is deleted when necessary. When I use hostname.if to statically assign an address to an interface, no route to 127.0.0.1 is created. I've looked around, but I'm afraid I don't understand why dhclient-script goes out of its way to set this route. Could someone point me in the right direction? I'd like to understand the effects of setting (or not setting) such a route... Regards, -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Hardware problem? amd64 system sometimes just resets with MP kernel, dmesg buffer doesn't survive.
: apic 4 int 16 (irq 11) pci3 at ppb2 bus 3 mskc0 at pci3 dev 0 function 0 Marvell Yukon 88E8056 rev 0x14, Yukon-2 EC Ultra rev. B0 (0x3): apic 4 int 16 (irq 11) msk0 at mskc0 port A: address 00:26:18:65:bc:ab eephy0 at msk0 phy 0: 88E1149 Gigabit PHY, rev. 1 ppb3 at pci0 dev 28 function 5 Intel 82801G PCIE rev 0x01: apic 4 int 17 (irq 10) pci4 at ppb3 bus 2 mskc1 at pci4 dev 0 function 0 Marvell Yukon 88E8056 rev 0x14, Yukon-2 EC Ultra rev. B0 (0x3): apic 4 int 17 (irq 10) msk1 at mskc1 port A: address 00:26:18:65:ba:d5 eephy1 at msk1 phy 0: 88E1149 Gigabit PHY, rev. 1 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 4 int 23 (irq 5) uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 4 int 19 (irq 7) ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 4 int 23 (irq 5) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci5 at ppb4 bus 1 rl0 at pci5 dev 0 function 0 Realtek 8139 rev 0x10: apic 4 int 21 (irq 6), address 00:e0:4d:52:a8:d1 rlphy0 at rl0 phy 0: RTL internal PHY ral0 at pci5 dev 1 function 0 Ralink RT2561S rev 0x00: apic 4 int 22 (irq 11), address 00:11:6b:3d:7f:6a ral0: MAC/BBP RT2561C, RF RT2527 vendor NetMos, unknown product 0x9865 (class communications subclass serial, rev 0x00) at pci5 dev 2 function 0 not configured vendor NetMos, unknown product 0x9865 (class communications subclass serial, rev 0x00) at pci5 dev 2 function 1 not configured vendor NetMos, unknown product 0x9865 (class communications subclass parallel, rev 0x00) at pci5 dev 2 function 2 not configured vga1 at pci5 dev 3 function 0 XGI Technology Volari Z7 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01 ichiic0 at pci0 dev 31 function 3 Intel 82801GB SMBus rev 0x01: apic 4 int 19 (irq 7) iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627DHG spdmem0 at iic0 addr 0x51: 1GB DDR2 SDRAM ECC PC2-6400CL5 spdmem1 at iic0 addr 0x53: 1GB DDR2 SDRAM ECC PC2-6400CL5 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25 lm2 at wbsio0 port 0x290/8: W83627DHG lm1 detached mtrr: Pentium Pro MTRR support softraid0 at root root on sd1a swap on sd1b dump on sd1b Thank you, -- Jurjen Oskam
Re: how to fresh raidframe install on an already raidframe system?
On Sun, Jan 03, 2010 at 12:03:00PM -0500, Kent Watsen wrote: [upgrading a system that uses RAIDframe] What do other people do? I'm now running a GENERIC kernel with an mpi RAID card, but I've used RAIDframe for several years. I had a disk die on me, and RAIDframe worked great. The disk suddenly seemed to disappear from the system, so any command sent to it resulted in a very noticeable timeout, during which process scheduling didn't function. After some time, RAIDframe marked the disk as failed and didn't issue any more I/O's to it and the system worked normally after that. (Note that this is one of the things you should take into account when using a watchdog: don't set its timeout too low.) Anyway, what I did was create several normal, non-RAID, partitions and one large RAID partition on each disk. On the normal partitions of each disk, I performed a normal OpenBSD install. Using that installation, I created two RAIDframe enabled kernels: one with and one without RAID autoconfig. I can then reboot into the non-autoconfig RAIDframe enabled kernel, manually configure the RAIDframe array, and then upgrade the OpenBSD installation within. Once happy, I can set the boot.conf of the two disks to the autoconfig RAIDframe enabled kernel, which will then load from one of the normal partitions, but once started will use the root filesystem in the RAID partition. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
bioctl's Device name inconsistent with dmesg device name: is that expected?
1 ppb4 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci5 at ppb4 bus 1 rl0 at pci5 dev 0 function 0 Realtek 8139 rev 0x10: apic 4 int 21 (irq 6), address 00:e0:4d:52:a8:d1 rlphy0 at rl0 phy 0: RTL internal PHY ral0 at pci5 dev 1 function 0 Ralink RT2561S rev 0x00: apic 4 int 22 (irq 11), address 00:11:6b:3d:7f:6a ral0: MAC/BBP RT2561C, RF RT2527 vendor NetMos, unknown product 0x9865 (class communications subclass serial, rev 0x00) at pci5 dev 2 function 0 not configured vendor NetMos, unknown product 0x9865 (class communications subclass serial, rev 0x00) at pci5 dev 2 function 1 not configured vendor NetMos, unknown product 0x9865 (class communications subclass parallel, rev 0x00) at pci5 dev 2 function 2 not configured vga1 at pci5 dev 3 function 0 XGI Technology Volari Z7 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01 ichiic0 at pci0 dev 31 function 3 Intel 82801GB SMBus rev 0x01: apic 4 int 19 (irq 7) iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627DHG spdmem0 at iic0 addr 0x51: 1GB DDR2 SDRAM ECC PC2-6400CL5 spdmem1 at iic0 addr 0x53: 1GB DDR2 SDRAM ECC PC2-6400CL5 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25 lm2 at wbsio0 port 0x290/8: W83627DHG lm1 detached mtrr: Pentium Pro MTRR support softraid0 at root root on sd1a swap on sd1b dump on sd1b Thanks, -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: bioctl's Device name inconsistent with dmesg device name: is that expected?
On Sun, Dec 06, 2009 at 10:11:56AM -0600, Marco Peereboom wrote: I did notice that bioctl has a different Device name for the volumes than the rest of the system. That sure isn't right. Can you submit a sendbug for this please? I don't have time to work on it right away so I need reminder :-) Sure, I've just sent in my report and it's now registered under number 6269. Thanks for the quick reply, and if there's something I can do just let me know. Regards, -- Jurjen Oskam
ahci0: unrecoverable errors (IS: 8000000IFS), disabling port.
82801BA Hub-to-PCI rev 0xe1 pci5 at ppb4 bus 1 rl0 at pci5 dev 0 function 0 Realtek 8139 rev 0x10: apic 4 int 21 (irq 6), address 00:e0:4d:52:a8:d1 rlphy0 at rl0 phy 0: RTL internal PHY ral0 at pci5 dev 1 function 0 Ralink RT2561S rev 0x00: apic 4 int 22 (irq 11), address 00:11:6b:3d:7f:6a ral0: MAC/BBP RT2561C, RF RT2527 vendor NetMos, unknown product 0x9865 (class communications subclass serial, rev 0x00) at pci5 dev 2 function 0 not configured vendor NetMos, unknown product 0x9865 (class communications subclass serial, rev 0x00) at pci5 dev 2 function 1 not configured vendor NetMos, unknown product 0x9865 (class communications subclass parallel, rev 0x00) at pci5 dev 2 function 2 not configured vga1 at pci5 dev 3 function 0 XGI Technology Volari Z7 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01 pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) ahci0 at pci0 dev 31 function 2 Intel 82801GR AHCI rev 0x01: apic 4 int 19 (irq 5), AHCI 1.1 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, OCZ-VERTEX, 1.41 SCSI3 0/direct fixed sd0: 30533MB, 512 bytes/sec, 62533296 sec total sd1 at scsibus0 targ 1 lun 0: ATA, OCZ-VERTEX, 1.41 SCSI3 0/direct fixed sd1: 30533MB, 512 bytes/sec, 62533296 sec total sd2 at scsibus0 targ 2 lun 0: ATA, Hitachi HDT72103, ST2O SCSI3 0/direct fixed sd2: 305245MB, 512 bytes/sec, 625142448 sec total sd3 at scsibus0 targ 3 lun 0: ATA, Hitachi HDT72103, ST2O SCSI3 0/direct fixed sd3: 305245MB, 512 bytes/sec, 625142448 sec total ichiic0 at pci0 dev 31 function 3 Intel 82801GB SMBus rev 0x01: apic 4 int 19 (irq 5) iic0 at ichiic0 lm1 at iic0 addr 0x2d: W83627DHG spdmem0 at iic0 addr 0x51: 1GB DDR2 SDRAM ECC PC2-6400CL5 spdmem1 at iic0 addr 0x53: 1GB DDR2 SDRAM ECC PC2-6400CL5 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25 lm2 at wbsio0 port 0x290/8: W83627DHG lm1 detached Kernelized RAIDframe activated mtrr: Pentium Pro MTRR support raid1 at root: (RAID Level 1) total number of sectors is 62524800 (30529 MB) as root raid0 at root: (RAID Level 1) total number of sectors is 563913472 (275348 MB) softraid0 at root root on raid1a WARNING: / was not properly unmounted swapmount: no device ahci0: unrecoverable errors (IS: 800IFS), disabling port. raid0: IO Error. Marking /dev/sd3l as failed. raid0: node (Rod) returned fail, rolling backward Unable to verify raid1 parity: can't read stripe. Could not verify parity. raid0: Error re-writing parity! ral0: Michael MIC failureClosing the opened device: /dev/sd3l About to (re-)open the device for rebuilding: /dev/sd3l RECON: Initiating in-place reconstruction on row 0 col 0 - spare at row 0 col 0. Quiescence reached... Thanks, -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Kernel log message without a \n
Hi, I've seen two or three of those messages in the last year, and I noticed a \n was missing: --- sys/net80211/ieee80211_crypto_tkip.cTue Apr 21 02:01:35 2009 +++ sys/net80211/ieee80211_crypto_tkip.c.newFri Oct 30 20:08:26 2009 @@ -508,7 +508,7 @@ if (ic-ic_flags IEEE80211_F_COUNTERM) return; /* countermeasures already active */ - log(LOG_WARNING, %s: Michael MIC failure, ic-ic_if.if_xname); + log(LOG_WARNING, %s: Michael MIC failure\n, ic-ic_if.if_xname); /* * NB. do not send Michael MIC Failure reports as recommended since -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: 200g harddisk after newfs = Available 174g?
On Wed, Oct 28, 2009 at 10:28:00AM +0100, Daniel Gracia Garallar wrote: Computer programmers, OS and all around computer chit-chat use the prefix 'giga' to refer 2^30 = 1,073,741,824 bytes. IEC recommends calling this GiB, but it's uncommon. Today, you could assume safely only manufacturers write Gb in the International System meaning; everybody else is refering to GiBs when talking about Gb. ... except when talking about computer networks: in that case everybody *does* use the SI-prefixes and 1 Gb/sec really is 10 bits/second, and not 1073741824 bits/second. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Memory on 4.5 again
at pciide1 channel 0 drive 0: WDC WD1200SD-01KCC0 wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 wd1 at pciide1 channel 1 drive 0: WDC WD1200SD-01KCC0 wd1: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5 ppb0 at pci0 dev 9 function 0 NVIDIA nForce4 PCI-PCI rev 0xa2 pci1 at ppb0 bus 5 ral0 at pci1 dev 6 function 0 Ralink RT2561S rev 0x00: irq 12, address 00:11:6b:3d:7f:6a ral0: MAC/BBP RT2561C, RF RT2527 rl0 at pci1 dev 7 function 0 Realtek 8139 rev 0x10: irq 10, address 00:e0:4d:52:a8:d1 rlphy0 at rl0 phy 0: RTL internal PHY vga1 at pci1 dev 8 function 0 S3 86C968-0 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) nfe0 at pci0 dev 10 function 0 NVIDIA CK804 LAN rev 0xa3: irq 7, address 00:13:d4:ae:99:b7 eephy0 at nfe0 phy 1: 88E Gigabit PHY, rev. 2 ppb1 at pci0 dev 11 function 0 NVIDIA nForce4 PCIE rev 0xa3 pci2 at ppb1 bus 4 ppb2 at pci0 dev 12 function 0 NVIDIA nForce4 PCIE rev 0xa3 pci3 at ppb2 bus 3 ppb3 at pci0 dev 13 function 0 NVIDIA nForce4 PCIE rev 0xa3 pci4 at ppb3 bus 2 ppb4 at pci0 dev 14 function 0 NVIDIA nForce4 PCIE rev 0xa3 pci5 at ppb4 bus 1 pchb0 at pci0 dev 24 function 0 AMD AMD64 0Fh HyperTransport rev 0x00 pchb1 at pci0 dev 24 function 1 AMD AMD64 0Fh Address Map rev 0x00 pchb2 at pci0 dev 24 function 2 AMD AMD64 0Fh DRAM Cfg rev 0x00 kate0 at pci0 dev 24 function 3 AMD AMD64 0Fh Misc Cfg rev 0x00 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 it0 at isa0 port 0x2e/2: IT8712F rev 7, EC port 0x290 Kernelized RAIDframe activated mtrr: Pentium Pro MTRR support raid1 at root: (RAID Level 1) total number of sectors is 228146560 (111399 MB) as root softraid0 at root softraid0: wd0h can not read metadata version 0, expected 3 softraid0: wd1h can not read metadata version 0, expected 3 root on raid1a swapmount: no device On 2009-08-07, Lars Kotthoff li...@larsko.org wrote: Hi all, after my post in June [1] I've removed the wireless card that seemed to be causing the memory problems and my system is more stable now. However, after about three weeks of uptime, memory starts running low again and the machine starts swapping constantly. netstat -m gives me 33805 mbufs in use: 33790 mbufs allocated to data 3 mbufs allocated to packet headers 12 mbufs allocated to socket names and addresses 6/94/6144 mbuf 2048 byte clusters in use (current/peak/max) 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) 0/8/6144 mbuf 9216 byte clusters in use (current/peak/max) 0/8/6144 mbuf 12288 byte clusters in use (current/peak/max) 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) 156296 Kbytes allocated to network (99% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines 150 MB for network seems a bit much to me, especially since I can literally watch that number grow. The system has 3 wired ethernet interfaces (2 of them in use), pflog0 and enc0. No other interfaces. Traffic levels are very moderate -- max 1 GB per day. Any ideas what's going on and what I could do about this? Thanks, Lars [1] http://www.nabble.com/Memory-problems-on-4.5-td23901874.html -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: mount point busy, can't find process holding it
On Wed, Jul 29, 2009 at 04:12:56PM +0200, frantisek holop wrote: hmm, on Wed, Jul 29, 2009 at 09:56:29AM -0400, Dan Harnett said that On Wed, Jul 29, 2009 at 06:06:16AM +0200, frantisek holop wrote: amaaq$ sudo fstat /adata USER CMD PID FD MOUNTINUM MODE R/WSZ|DV NAME You should use the '-f' option to fstat. $ sudo fstat -f /adata One possibility is shared libraries or objects. (ah, so happy to see my signature in almost every unix command :]) amaaq$ sudo fstat -f /adata USER CMD PID FD MOUNTINUM MODE R/WSZ|DV no luck Are you sure you haven't mounted anything else somewhere in the filesystem you're trying to unmount? You can't unmount a filesystem if a directory in that filesystem is used as a mount point for another filesystem. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: bash for root?
On Sun, Nov 30, 2008 at 11:11:53AM -0500, Nick Holland wrote: need or want to use bash on OpenBSD. The only good reason I've found to use bash on OpenBSD is to make it feel like some other OS, Another reason I've found is the option set -o pipefail, which is handy when you want the ERR trap to fire when any single command of a set of piped commands exits non-zero. (If there's a better way of doing things, I'd love to hear about it...) -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
ral0: ping: sendto: No buffer space available
MHz: speeds: 2000 1800 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 VIA K8HTB Host rev 0x01 agp at pchb0 not configured ppb0 at pci0 dev 1 function 0 VIA K8HTB AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 NVIDIA GeForce2 MX rev 0xa1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) skc0 at pci0 dev 10 function 0 Marvell Yukon 88E8001/8003/8010 rev 0x13, Yukon Lite rev. A3 (0x7): irq 10 sk0 at skc0 port A: address 00:11:2f:9c:09:6b eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5 ral0 at pci0 dev 11 function 0 Ralink RT2561S rev 0x00: irq 11, address 00:11:6b:3d:7f:6a ral0: MAC/BBP RT2561C, RF RT2527 rl0 at pci0 dev 12 function 0 Realtek 8139 rev 0x10: irq 10, address 00:e0:4d:52:a8:d1 rlphy0 at rl0 phy 0: RTL internal PHY pciide0 at pci0 dev 15 function 0 VIA VT6420 SATA rev 0x80: DMA pciide0: using irq 10 for native-PCI interrupt pciide1 at pci0 dev 15 function 1 VIA VT82C571 IDE rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide1 channel 0 drive 0: HDS728080PLAT20 wd0: 16-sector PIO, LBA48, 78533MB, 160836480 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6 wd1 at pciide1 channel 1 drive 0: HDS728080PLAT20 wd1: 16-sector PIO, LBA48, 78533MB, 160836480 sectors wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 6 uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x81: irq 11 uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81: irq 11 uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81: irq 10 uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81: irq 10 ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86: irq 5 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 VIA EHCI root hub rev 2.00/1.00 addr 1 viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 iic0 at viapm0 iic0: addr 0x4a 00=3f 01=03 02=7f 03=07 05=30 06=c0 07=90 08=3f 09=03 0a=7f 0b=07 0d=30 0e=c0 0f=90 10=3f 11=03 12=7f 13=07 15=30 16=c0 17=90 18=3f 19=03 1a=7f 1b=07 1d=30 1e=c0 1f=90 20=3f 21=03 22=7f 23=07 25=30 26=c0 27=90 28=3f 29=03 2a=7f 2b=07 2d=30 2e=c0 2f=90 30=3f 31=03 32=7f 33=07 35=30 36=c0 37=90 38=3f 39=03 3a=7f 3b=07 3d=30 3e=c0 3f=90 40=3f 41=03 42=7f 43=07 45=30 46=c0 47=90 48=3f 49=03 4a=7f 4b=07 4d=30 4e=c0 4f=90 50=3f 51=03 52=7f 53=07 55=30 56=c0 57=90 58=3f 59=03 5a=7f 5b=07 5d=30 5e=c0 5f=90 60=3f 61=03 62=7f 63=07 65=30 66=c0 67=90 68=3f 69=03 6a=7f 6b=07 6d=30 6e=c0 6f=90 70=3f 71=03 72=7f 73=07 75=30 76=c0 77=90 78=3f 79=03 7a=7f 7b=07 7d=30 7e=c0 7f=90 80=3f 81=03 82=7f 83=07 85=30 86=c0 87=90 88=3f 89=03 8a=7f 8b=07 8d=30 8e=c0 8f=90 90=3f 91=03 92=7f 93=07 95=30 96=c0 97=90 98=3f 99=03 9a=7f 9b=07 9d=30 9e=c0 9f=90 a0=3f a1=03 a2=7f a3=07 a5=30 a6=c0 a7=90 a8=3f a9=03 aa=7f ab=07 ad=30 ae=c0 af=90 b0=3f b1=03 b2=7f b3=07 b5=30 b6=c0 b7=90 b8=3f b9=03 ba=7f bb=07 bd=30 be=c0 bf=90 c0=3f c1=03 c2=7f c3=07 c5=30 c6=c0 c7=90 c8=3f c9=03 ca=7f cb=07 cd=30 ce=c0 cf=90 d0=3f d1=03 d2=7f d3=07 d5=30 d6=c0 d7=90 d8=3f d9=03 da=7f db=07 dd=30 de=c0 df=90 e0=3f e1=03 e2=7f e3=07 e5=30 e6=c0 e7=90 e8=3f e9=03 ea=7f eb=07 ed=30 ee=c0 ef=90 f0=3f f1=03 f2=7f f3=07 f5=30 f6=c0 f7=90 f8=3f f9=03 fa=7f fb=07 fd=30 fe=c0 ff=90 words 00=3fff 01=03ff 02=7fff 03=07ff 04=00ff 05=30ff 06=c0ff 07=90ff 08=3fff 09=03ff 0a=7fff 0b=07ff 0c=00ff 0d=30ff 0e=c0ff 0f=90ff spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM ECC PC3200CL3.0 pchb1 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb2 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb3 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb4 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 VIA UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 VIA UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 VIA UHCI root hub rev 1.00/1.00 addr 1 isa0 at mainbus0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83697HF rev 0x12 lm1 at wbsio0 port 0x290/8: W83697HF fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec Kernelized RAIDframe activated raid0 at root: (RAID Level 1) total number of sectors is 154534656 (75456 MB) as root softraid0 at root swapmount: no device -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Nintendo Wii seems to be unhappy with a ral in hostap mode
=7f 03=07 05=30 06=c0 07=90 08=3f 09=03 0a=7f 0b=07 0d=30 0e=c0 0f=90 10=3f 11=03 12=7f 13=07 15=30 16=c0 17=90 18=3f 19=03 1a=7f 1b=07 1d=30 1e=c0 1f=90 20=3f 21=03 22=7f 23=07 25=30 26=c0 27=90 28=3f 29=03 2a=7f 2b=07 2d=30 2e=c0 2f=90 30=3f 31=03 32=7f 33=07 35=30 36=c0 37=90 38=3f 39=03 3a=7f 3b=07 3d=30 3e=c0 3f=90 40=3f 41=03 42=7f 43=07 45=30 46=c0 47=90 48=3f 49=03 4a=7f 4b=07 4d=30 4e=c0 4f=90 50=3f 51=03 52=7f 53=07 55=30 56=c0 57=90 58=3f 59=03 5a=7f 5b=07 5d=30 5e=c0 5f=90 60=3f 61=03 62=7f 63=07 65=30 66=c0 67=90 68=3f 69=03 6a=7f 6b=07 6d=30 6e=c0 6f=90 70=3f 71=03 72=7f 73=07 75=30 76=c0 77=90 78=3f 79=03 7a=7f 7b=07 7d=30 7e=c0 7f=90 80=3f 81=03 82=7f 83=07 85=30 86=c0 87=90 88=3f 89=03 8a=7f 8b=07 8d=30 8e=c0 8f=90 90=3f 91=03 92=7f 93=07 95=30 96=c0 97=90 98=3f 99=03 9a=7f 9b=07 9d=30 9e=c0 9f=90 a0=3f a1=03 a2=7f a3=07 a5=30 a6=c0 a7=90 a8=3f a9=03 aa=7f ab=07 ad=30 ae=c0 af=90 b0=3f b1=03 b2=7f b3=07 b5=30 b6=c0 b7=90 b8=3f b9=03 ba=7f bb=07 bd=30 be=c0 bf=90 c0=3f c1=03 c2=7f c3=07 c5=30 c6=c0 c7=90 c8=3f c9=03 ca=7f cb=07 cd=30 ce=c0 cf=90 d0=3f d1=03 d2=7f d3=07 d5=30 d6=c0 d7=90 d8=3f d9=03 da=7f db=07 dd=30 de=c0 df=90 e0=3f e1=03 e2=7f e3=07 e5=30 e6=c0 e7=90 e8=3f e9=03 ea=7f eb=07 ed=30 ee=c0 ef=90 f0=3f f1=03 f2=7f f3=07 f5=30 f6=c0 f7=90 f8=3f f9=03 fa=7f fb=07 fd=30 fe=c0 ff=90 words 00=3fff 01=03ff 02=7fff 03=07ff 04=00ff 05=30ff 06=c0ff 07=90ff 08=3fff 09=03ff 0a=7fff 0b=07ff 0c=00ff 0d=30ff 0e=c0ff 0f=90ff spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM ECC PC3200CL3.0 pchb1 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb2 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb3 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb4 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 VIA UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 VIA UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 VIA UHCI root hub rev 1.00/1.00 addr 1 isa0 at mainbus0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83697HF rev 0x12 lm1 at wbsio0 port 0x290/8: W83697HF fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec Kernelized RAIDframe activated raid0 at root: (RAID Level 1) total number of sectors is 154534656 (75456 MB) as root softraid0 at root swapmount: no device -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
How to (help) diagnose a system hang?
=3f 89=03 8a=7f 8b=07 8d=30 8e=c0 8f=90 90=3f 91=03 92=7f 93=07 95=30 96=c0 97=90 98=3f 99=03 9a=7f 9b=07 9d=30 9e=c0 9f=90 a0=3f a1=03 a2=7f a3=07 a5=30 a6=c0 a7=90 a8=3f a9=03 aa=7f ab=07 ad=30 ae=c0 af=90 b0=3f b1=03 b2=7f b3=07 b5=30 b6=c0 b7=90 b8=3f b9=03 ba=7f bb=07 bd=30 be=c0 bf=90 c0=3f c1=03 c2=7f c3=07 c5=30 c6=c0 c7=90 c8=3f c9=03 ca=7f cb=07 cd=30 ce=c0 cf=90 d0=3f d1=03 d2=7f d3=07 d5=30 d6=c0 d7=90 d8=3f d9=03 da=7f db=07 dd=30 de=c0 df=90 e0=3f e1=03 e2=7f e3=07 e5=30 e6=c0 e7=90 e8=3f e9=03 ea=7f eb=07 ed=30 ee=c0 ef=90 f0=3f f1=03 f2=7f f3=07 f5=30 f6=c0 f7=90 f8=3f f9=03 fa=7f fb=07 fd=30 fe=c0 ff=90 words 00=3fff 01=03ff 02=7fff 03=07ff 04=00ff 05=30ff 06=c0ff 07=90ff 08=3fff 09=03ff 0a=7fff 0b=07ff 0c=00ff 0d=30ff 0e=c0ff 0f=90ff spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM ECC PC3200CL3.0 pchb1 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb2 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb3 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb4 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 VIA UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 VIA UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 VIA UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 VIA UHCI root hub rev 1.00/1.00 addr 1 isa0 at mainbus0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 wbsio0 at isa0 port 0x2e/2: W83697HF rev 0x12 lm1 at wbsio0 port 0x290/8: W83697HF fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec Kernelized RAIDframe activated raid0 at root: (RAID Level 1) total number of sectors is 154534656 (75456 MB) as root softraid0 at root swapmount: no device -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: ral(4) hostap plea
On Tue, May 06, 2008 at 11:05:35PM -0400, James Turner wrote: Some info, the ral(4) is a Gigabyte GN-WP01GS which is an RT2561S. My basic hostname.ral0 reads: inet 192.168.1.1 255.255.255.0 NONE media autoselect mode 11g mediaopt hostap nwid my_net nwkey secret chan 11. I'm also using ral in hostap mode, and it works perfectly. Contents of hostname.ral0: inet 192.168.2.1 255.255.255.0 NONE media autoselect mediaopt hostap nwid stupendous mode 11g (I don't use WEP.) The device itself: ral0 at pci0 dev 11 function 0 Ralink RT2561S rev 0x00: irq 11, address 00:11:6b:3d:7f:6a ral0: MAC/BBP RT2561C, RF RT2527 Try attaching (if you haven't already) a high quality external antenna. This made a world of difference in my case. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Environment variables
Hi there,
I'm seeing something I don't quite understand concerning environment
variables. (This is on an OpenBSD 4.2 amd64 system) I hope someone here
can explain.
Given the following C-program:
#include stdio.h
#include errno.h
#include stdlib.h
int main(int argc, char **argv)
{
char *var1 = FOO=TESTING;
int rc;
sleep(10);
rc = putenv(var1);
if (rc 0) {
printf(Error inserting %s in environ, errno = %d\n,
var1, errno);
return 1;
}
printf(%s inserted in environ\n, var1);
sleep(10);
return 0;
}
In another terminal, I start a while loop:
$ while true ; do ps -eww | grep F[O]O ; sleep 1 ; done
When I run this program using env -i ./a.out, the while loop
in the other terminal doesn't show any output at all. ps doesn't
seem to see FOO being put in the environment.
However, when I start the program using env -i FOO=BAR ./a.out, the
while loop in the other terminal shows this output, beginning right after
the start of the program:
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=BAR (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
20571 p2 I+ 0:00.00 FOO=TESTING (a.out)
So ps does show FOO, *and* it shows the value of FOO changing after
ten seconds.
I don't understand this behaviour. On another system (AIX), ps does pick
up newly set environment variables. Is this behaviour implementation
dependent?
Thanks,
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.
Re: Environment variables
On Fri, Apr 18, 2008 at 04:21:08PM +0200, Almir Karic wrote: On Fri, Apr 18, 2008 at 3:20 PM, Jurjen Oskam [EMAIL PROTECTED] wrote: So ps does show FOO, *and* it shows the value of FOO changing after ten seconds. what is so weird about it? you set your program an env var via env(1) for first ten seconds it has that env var, than the putenv(3) call happens and it changes the value of FOO. That in itself is not weird. What I meant was that if the variable isn't set at the start of the program, ps won't see it at all, not even after the program sets it. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Environment variables
On Fri, Apr 18, 2008 at 08:47:44PM +0300, Paul Irofti wrote:
int main(int argc, char **argv)
{
char *var1 = FOO=TESTING;
A bit OT but you should really alloc that or use a static.
I'm almost a complete C non-programmer; I've copy-pasted this program
from somewhere on the Web. You'll not be seeing me near any C code with
any significant value anytime soon. :)
But thanks for the tip.
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.
Re: USB speed (umass): what should I expect?
On Sat, Apr 12, 2008 at 12:04:10PM -0500, Dale Rahn wrote: I presume that /dev/sd0c or sdN[a-k] was used to access the USB device this goes thru the buffer cache which defeats the use of larger blocks under OpenBSD. To accurately compare the I/O speeds use /dev/rsd0c, the raw device. Please be accurate about what is being tested. Thanks, I'll apply the cluebat appropriately. Using rsdxx indeed results in similar results. Sorry for the noise. I've turned on softdep for the filesystems on the stick. This enormously sped up file creation/deletion: for example MAKEDEV all took 45 seconds without soft updates, and 2 seconds with soft updates. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
USB speed (umass): what should I expect?
function 3 not configured Ricoh 5C592 Memory Stick rev 0x11 at pci7 dev 0 function 4 not configured Ricoh 5C852 xD rev 0x11 at pci7 dev 0 function 5 not configured cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 22 device 0 cacheline 0x0, lattimer 0xb0 pcmcia0 at cardslot0 pcib0 at pci0 dev 31 function 0 Intel 82801HEM LPC rev 0x03 pciide0 at pci0 dev 31 function 1 Intel 82801HBM IDE rev 0x03: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: MATSHITA, DVD-RAM UJ-852, RB02 SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ahci0 at pci0 dev 31 function 2 Intel 82801HBM AHCI rev 0x03: irq 10, AHCI 1.1 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: ATA, ST910021AS, 4.06 SCSI3 0/direct fixed sd0: 95396MB, 12161 cyl, 255 head, 63 sec, 512 bytes/sec, 195371568 sec total ichiic0 at pci0 dev 31 function 3 Intel 82801H SMBus rev 0x03: irq 11 iic0 at ichiic0 usb2 at uhci0: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 Intel UHCI root hub rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 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 midi0 at pcppi0: PC speaker spkr0 at pcppi0 aps0 at isa0 port 0x1600/31 aps0: failed to initialise npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 biomask edfd netmask edfd ttymask mtrr: Pentium Pro MTRR support umass0 at uhub1 port 1 configuration 1 interface 0 OCZ Technology RALLY2 rev 2.00/11.00 addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets sd1 at scsibus2 targ 1 lun 0: OCZ, RALLY2, 1100 SCSI0 0/direct removable sd1: 7648MB, 974 cyl, 255 head, 63 sec, 512 bytes/sec, 15663104 sec total ugen0 at uhub2 port 2 STMicroelectronics Biometric Coprocessor rev 1.00/0.01 addr 2 softraid0 at root root on sd1a swap on sd1b dump on sd1b Thanks, -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Help with root partition on RaidFrame
On Tue, Jan 08, 2008 at 10:22:04PM -0800, William Sloan wrote: OpenBSD 4.2-stable (RAID) #3: Mon Jan 7 17:45:05 PST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/RAID cpu0: Geode(TM) Integrated Processor by National Semi (Geode by NSC [...] root on wd0a swap on wd0b dump on wd0b raid0: Component /dev/sd0a being configured at row: 0 col: 0 Row: 0 Column: 0 Num Rows: 1 Num Columns: 2 Version: 2 Serial Number: 123456 Mod Counter: 638 Clean: Yes Status: 0 raid0: Component /dev/sd1a being configured at row: 0 col: 1 Row: 0 Column: 1 Num Rows: 1 Num Columns: 2 Version: 2 Serial Number: 123456 Mod Counter: 638 Clean: Yes Status: 0 raid0 at root It looks like you're booting a kernel that was compiled without the RAID_AUTOCONFIG option set. The system boot script will automatically configure raid0 if the file /etc/raid0.conf (on wd0) exists, so that explains why raid0 gets configured after the location of the root filesystem is determined. Try recompiling a kernel with RAID_AUTOCONFIG set, and boot from that. Don't create an /etc/raid0.conf. Not in /etc on wd0, and not in /etc on raid0. Do create one on another location on wd0 though, it might come in handy later. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Instant reboot / Inappropriate ioctl when trying to access SMART statistics
Intel 82801HBM IDE rev 0x03: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: MATSHITA, DVD-RAM UJ-852, RB02 SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ahci0 at pci0 dev 31 function 2 Intel 82801HBM SATA rev 0x03: irq 10, AHCI 1.1 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: ATA, ST910021AS, 4.06 SCSI2 0/direct fixed sd0: 95396MB, 12161 cyl, 255 head, 63 sec, 512 bytes/sec, 195371568 sec total ichiic0 at pci0 dev 31 function 3 Intel 82801H SMBus rev 0x03: irq 11 iic0 at ichiic0 usb2 at uhci0: USB revision 1.0 uhub2 at usb2: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6: Intel UHCI root hub, rev 1.00/1.00, addr 1 isa0 at pcib0 isadma0 at isa0 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 midi0 at pcppi0: PC speaker spkr0 at pcppi0 aps0 at isa0 port 0x1600/31 ugen0 at uhub2 port 2 ugen0: STMicroelectronics Biometric Coprocessor, rev 1.00/0.01, addr 2 dkcsum: sd0 matches BIOS drive 0x80 root on sd0a swap on sd0b dump on sd0b umass0 at uhub1 port 2 configuration 1 interface 0 umass0: SanDisk Corporation Cruzer Mini, rev 2.00/0.10, addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets sd1 at scsibus2 targ 1 lun 0: SanDisk, Cruzer Mini, 0.1 SCSI2 0/direct removable sd1: 244MB, 31 cyl, 255 head, 63 sec, 512 bytes/sec, 501759 sec total -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: problems with ral0 and OBSD 4.0
On Wed, Sep 19, 2007 at 01:10:59PM +0200, Alessandro Roncari wrote: is there anybody who feels like giving a good advice regarding a wireless chipset to be used in hostap mode, well supported by obsd and spreading a good signal? I wouldn't want to make a 2nd mistake, so I think best thing is to trust somebody who's using himself the same hardware. I use a Ralink-based card with an external antenna, and it works absolutely great. I did experience problems with that card with a (probably) low quality antenna on a suboptimal location though, I got 30 pct packetloss and many duplicates. Using a high-quality, well-placed antenna I get a great signal using the exact same card. The only thing I do experience from time to time is a ral0: device timeout when sending lots of data to a client. I even got some sort of division by zero in the kernel once, halting the entire machine. This is on 4.1-STABLE. However, I saw that lots and lots of work was done on 802.11 code in 4.2, so I'll upgrade to that once my CD arrives and really stresstest it. Should I find anything, I'll try to properly diagnose it. Anyhow, this happens very rarely, and I'm quite happy with my ral card in hostap mode! ral0 at pci0 dev 11 function 0 Ralink RT2560 rev 0x01: irq 11, address 00:0c:f6:26:0d:b2 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Slow ral(4) 802.11b in hostap mode?
On Thu, Sep 20, 2007 at 12:07:02AM +0930, Damon McMahon wrote: I'm not sure how to troubleshoot this further, but any advice would be appreciated. As I've just mentioned, I experienced poor performance on a ral-based card in hostap mode, until I connected a high-quality antenna on a proper location. After that, it worked great. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: problems with ral0 and OBSD 4.0
On Wed, Sep 19, 2007 at 08:13:10PM +0200, Alessandro Roncari wrote: can I ask you, what mode are you using, 11b or 11g? and which channel? ral0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0c:f6:26:0d:b2 groups: wlan media: IEEE802.11 autoselect mode 11g hostap status: active ieee80211: nwid stupendous chan 1 bssid 00:0c:f6:26:0d:b2 100dBm inet 192.168.2.1 netmask 0xff00 broadcast 192.168.2.255 inet6 fe80::20c:f6ff:fe26:db2%ral0 prefixlen 64 scopeid 0x2 did you try different channels? I have a slightly different chipset, 2561s will try a different antenna though mine is a 9dBi and I thought it was enough That should be enough, since mine is 8dBi. :) If it's an omnidirectional anntenna: I understand that you don't get good reception when the antenna is placed on the third floor, and you're on the first floor directly underneath the antenna. Since my antenna is located at the top floor of my house, I just attached it horizontally to the ceiling. I don't know if my understanding is correct, but hey, it works. :) I think there is also like you say a problem of packet loss, because even when the signal is good, the internet connection is weak or drops. This is easily shown using ping, especially with the -f option. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: ral in hostap mode
On Wed, Jul 18, 2007 at 11:56:18AM -0600, Daniel Melameth wrote: [ral PCI card performed poorly in hostap mode; packet loss etc] Have you tried setting the channel and/or forcing the mode? I also have a ral-based AP and while it performs fairly well, its reliability and consistency does not appear to be as good as the wi-based APs. (Sorry for the late reply - I was away for a few weeks) Well, the problem was the antenna and/or the placement of the antenna. I used a separate antenna from the start, but for testing I tried another one in a different location (unreachable with the first antenna). This solved the problem entirely: even ping -f doesn't lose one single packet nor reports any duplicates, and that is with ping -f running for a good 30 seconds. There's one thing that I noticed though, the contents of hostname.ral0 are: inet 192.168.2.1 255.255.255.0 NONE media autoselect mediaopt hostap nwid stupendous mode 11g When I put a nwflag nobridge in there, it doesn't work. It complains about not being able to set the flag. (Sorry, I didn't copy-paste the error message). Only after the interface is placed in hostap mode, I can set the nobridge flag, both with ifconfig and netstart ral0. Does this sound familiar to anyone? Should I gather more data so I can create a proper report? -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: ral in hostap mode
On Wed, Jul 18, 2007 at 04:53:35PM +0300, Alexey Suslikov wrote: Jurjen Oskam wrote: At home, I have a wireless access point which is directly connected to rl1. To eliminate the access point, I put a wireless PCI card in the machine, ^^^ CAVEATS section in ral's man page. ... The ural driver supports automatic control of the transmit speed in BSS Since the CAVEATS sections explicitly mentions ural, I used a PCI card, not a USB one. Or does the caveat apply to PCI-cards as well? -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
ral in hostap mode
=c0 4f=90 50=3f 51=03 52=7f 53=07 55=30 56=c0 57=90 58=3f 59=03 5a=7f 5b=07 5d=30 5e=c0 5f=90 60=3f 61=03 62=7f 63=07 65=30 66=c0 67=90 68=3f 69=03 6a=7f 6b=07 6d=30 6e=c0 6f=90 70=3f 71=03 72=7f 73=07 75=30 76=c0 77=90 78=3f 79=03 7a=7f 7b=07 7d=30 7e=c0 7f=90 80=3f 81=03 82=7f 83=07 85=30 86=c0 87=90 88=3f 89=03 8a=7f 8b=07 8d=30 8e=c0 8f=90 90=3f 91=03 92=7f 93=07 95=30 96=c0 97=90 98=3f 99=03 9a=7f 9b=07 9d=30 9e=c0 9f=90 a0=3f a1=03 a2=7f a3=07 a5=30 a6=c0 a7=90 a8=3f a9=03 aa=7f ab=07 ad=30 ae=c0 af=90 b0=3f b1=03 b2=7f b3=07 b5=30 b6=c0 b7=90 b8=3f b9=03 ba=7f bb=07 bd=30 be=c0 bf=90 c0=3f c1=03 c2=7f c3=07 c5=30 c6=c0 c7=90 c8=3f c9=03 ca=7f cb=07 cd=30 ce=c0 cf=90 d0=3f d1=03 d2=7f d3=07 d5=30 d6=c0 d7=90 d8=3f d9=03 da=7f db=07 dd=30 de=c0 df=90 e0=3f e1=03 e2=7f e3=07 e5=30 e6=c0 e7=90 e8=3f e9=03 ea=7f eb=07 ed=30 ee=c0 ef=90 f0=3f f1=03 f2=7f f3=07 f5=30 f6=c0 f7=90 f8=3f f9=03 fa=7f fb=07 fd=30 fe=c0 ff=90 pchb1 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb2 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb3 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb4 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 isa0 at mainbus0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lm0 at isa0 port 0x290/8: W83697HF fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec Kernelized RAIDframe activated raid0 (root): (RAID Level 1) total number of sectors is 154534656 (75456 MB) as root dkcsum: wd0 matches BIOS drive 0x80 dkcsum: wd1 matches BIOS drive 0x81 swapmount: no device -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
tcpdump segfaults on enc0 interface
revision 1.0 uhub0 at usb0 uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81: irq 11 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81: irq 10 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81: irq 10 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 uhub3: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86: irq 5 usb4 at ehci0: USB revision 2.0 uhub4 at usb4 uhub4: VIA EHCI root hub, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 iic0 at viapm0 iic0: addr 0x4a 00=3f 01=03 02=7f 03=07 05=30 06=c0 07=90 08=3f 09=03 0a=7f 0b=07 0d=30 0e=c0 0f=90 10=3f 11=03 12=7f 13=07 15=30 16=c0 17=90 18=3f 19=03 1a=7f 1b=07 1d=30 1e=c0 1f=90 20=3f 21=03 22=7f 23=07 25=30 26=c0 27=90 28=3f 29=03 2a=7f 2b=07 2d=30 2e=c0 2f=90 30=3f 31=03 32=7f 33=07 35=30 36=c0 37=90 38=3f 39=03 3a=7f 3b=07 3d=30 3e=c0 3f=90 40=3f 41=03 42=7f 43=07 45=30 46=c0 47=90 48=3f 49=03 4a=7f 4b=07 4d=30 4e=c0 4f=90 50=3f 51=03 52=7f 53=07 55=30 56=c0 57=90 58=3f 59=03 5a=7f 5b=07 5d=30 5e=c0 5f=90 60=3f 61=03 62=7f 63=07 65=30 66=c0 67=90 68=3f 69=03 6a=7f 6b=07 6d=30 6e=c0 6f=90 70=3f 71=03 72=7f 73=07 75=30 76=c0 77=90 78=3f 79=03 7a=7f 7b=07 7d=30 7e=c0 7f=90 80=3f 81=03 82=7f 83=07 85=30 86=c0 87=90 88=3f 89=03 8a=7f 8b=07 8d=30 8e=c0 8f=90 90=3f 91=03 92=7f 93=07 95=30 96=c0 97=90 98=3f 99=03 9a=7f 9b=07 9d=30 9e=c0 9f=90 a0=3f a1=03 a2=7f a3=07 a5=30 a6=c0 a7=90 a8=3f a9=03 aa=7f ab=07 ad=30 ae=c0 af=90 b0=3f b1=03 b2=7f b3=07 b5=30 b6=c0 b7=90 b8=3f b9=03 ba=7f bb=07 bd=30 be=c0 bf=90 c0=3f c1=03 c2=7f c3=07 c5=30 c6=c0 c7=90 c8=3f c9=03 ca=7f cb=07 cd=30 ce=c0 cf=90 d0=3f d1=03 d2=7f d3=07 d5=30 d6=c0 d7=90 d8=3f d9=03 da=7f db=07 dd=30 de=c0 df=90 e0=3f e1=03 e2=7f e3=07 e5=30 e6=c0 e7=90 e8=3f e9=03 ea=7f eb=07 ed=30 ee=c0 ef=90 f0=3f f1=03 f2=7f f3=07 f5=30 f6=c0 f7=90 f8=3f f9=03 fa=7f fb=07 fd=30 fe=c0 ff=90 pchb1 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb2 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb3 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb4 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 isa0 at mainbus0 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 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lm0 at isa0 port 0x290/8: W83697HF fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec Kernelized RAIDframe activated raid0 (root): (RAID Level 1) total number of sectors is 154534656 (75456 MB) as root dkcsum: wd0 matches BIOS drive 0x80 dkcsum: wd1 matches BIOS drive 0x81 swapmount: no device -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: tcpdump segfaults on enc0 interface
On Mon, May 28, 2007 at 09:12:58AM +0100, Stuart Henderson wrote: the bug is probably in a protocol decoder, in which case you'd still be able to write the network data to disk; a copy of this may help someone locate the problem (tcpdump -ienc0 -w file) Thanks for your suggestions (also the one about -s 1500)! This is what I found: - When adding -s 1500 to the parameters, no segfault occurs. (Output at http://www.stupendous.org/enc0-s1500.log) - When running under gdb, I get the following: [snip (using args -npienc0)] 19:19:07.584092 (authentic,confidential): SPI 0x66436c81: 194.109.21.66.52091 192.168.2.12.8381: . 419725:420249(524) ack 1 win 46 nop,nop,timestamp 3760582140 454451604 (DF) [tos 0x8] (encap) 19:19:07.585631 (authentic,confidential): SPI 0x66436c81: 194.109.21.66.52091 192.168.2.12.8381: . 419201:419725(524) ack 1 win 46 nop,nop,timestamp 3760582140 454451604 (DF) [tos 0x8] (encap) 19:19:07.585825 (authentic,confidential): SPI 0x5d5feb70: 192.168.2.12.8381 194.109.21.66.52091: . ack 413437 win 15860 nop,nop,timestamp 454451604 3760582120 (DF) [tos 0x8] (encap) 19:19:07.587079 (authentic,confidential): SPI 0x66436c81: 194.109.21.66.52091 192.168.2.12.8381: . 420249:420773(524) ack 1 win 46 nop,nop,timestamp 3760582140 454451604 (DF) [tos 0x8] (encap) Program received signal SIGSEGV, Segmentation fault. 0x4227e809 in memcpy (dst0=0x4f052080, src0=0x42aaf003, length=0) at /usr/src/lib/libc/string/bcopy.c:115 115 TLOOP1(*--dst = *--src); (gdb) bt #0 0x4227e809 in memcpy (dst0=0x4f052080, src0=0x42aaf003, length=0) at /usr/src/lib/libc/string/bcopy.c:115 #1 0x00408259 in ip_print (bp=0x42aaefa4 [EMAIL PROTECTED]@, length=576) at /usr/src/usr.sbin/tcpdump/print-ip.c:382 #2 0x00408722 in ip_print (bp=0x14 Address 0x14 out of bounds, length=16384) at /usr/src/usr.sbin/tcpdump/print-ip.c:471 #3 0x0041d49c in enc_if_print (user=0x4f052080 [EMAIL PROTECTED]'@, h=0x4f052080, p=0x42aaef90 E\b\002T\030@) at /usr/src/usr.sbin/tcpdump/print-enc.c:99 #4 0x4c191d64 in pcap_read (p=0x49817200, cnt=-1, callback=0x41d3c0 enc_if_print, user=0x0) at /usr/src/lib/libpcap/pcap-bpf.c:154 #5 0x4c19257b in pcap_loop (p=0x49817200, cnt=-1, callback=0x41d3c0 enc_if_print, user=0x0) at /usr/src/lib/libpcap/pcap.c:76 #6 0x00403276 in main (argc=2, argv=0x41d3c0) at /usr/src/usr.sbin/tcpdump/tcpdump.c:485 (gdb) I made the resulting file of tcpdump -p -ienc0 -w enc0.dump available at http://www.stupendous.org/enc0.dump. Should I file a bugreport? -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Strange behavior with new suse dostro, vista and openbsd vpn tunel
On Fri, Mar 09, 2007 at 10:28:59AM +, Stuart Henderson wrote: On 2007/03/09 01:26, Claude Brassel wrote: I have try some new linux distro (opensuse 10.2, mandriva 2007) so if I try to join a host through the vpn it's working only for small packets in ex: the telnet login session work's great, but if I try some ls or everithing else that produce a big amount of lines the connection will timed out, I have no idea why. use flags s/sa keep state on all tcp PF rules. I have found that some Linux-distributions experience problems when their connectivity is routed through an OpenBSD box which has reassemble tcp enabled. I never investigated further though, I just stopped using reassemble tcp. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: SIP on OpenBSD
On Tue, Feb 13, 2007 at 11:09:06AM -, [EMAIL PROTECTED] wrote: I don't know for sure how you did it. Just install the asterisk package, which is made available by the ports team. and never had any single damn problem. I have and reviewed the specs of digium over and over again that zaptel is the device driver for the NIC card that talks to the kernel. Yes, and if you don't use that card, you don't need zaptel. If you don't use the card, you can still connect to any POTS system just fine using some other POTS - SIP interface. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: 'database filesystems' (was: backing up windows hosts to openbsd)
On Mon, Jan 08, 2007 at 10:43:42AM +, Brian Candler wrote: Consider a database application - mysql or oracle or whatever. At some point in time, it decides to write some updates to tables 1, 2 and 3, and index files X, Y and Z. [...] If you happen to take a snapshot of the filesystem at the point where some of these writes have been requested but others have not, then the image you restore will be in an inconsistent state. If that is the case, your database application isn't worth the diskspace it's occupying. (Assuming, of course, that the filesystem snapshot is atomic.) A good database application is specifically designed to handle this, and there are backup strategies which explicitly take advantage of this. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: Swedish speakers -- OpenBSD and IBM Tivoli TSM BA
On Thu, Oct 12, 2006 at 06:11:16PM +0200, ropers wrote: I find myself having to use the Tivoli Storage Manager Backup/Archive client (dsmc). As much as I would prefer a free solution, this is the only offsite backup supported in my organisaton and if I want to maintain an OpenBSD server, I will have to get OpenBSD to talk to the Tivoli server. There is no TSM client for OpenBSD. I wouldn't recommend running one under any emulation mode. Should you happen to run into problems, you're SOL because IBM will say that it's not supported and you can't fix it yourself since it's closed source. I think the most easy (and safe) solution is to install a TSM client on a supported platform on another machine. Use tar/dump/whatever on the OpenBSD machine, and store the resulting files on the machine with the TSM client on it. Regards, -- Jurjen Oskam
Re: Swedish speakers -- OpenBSD and IBM Tivoli TSM BA
On Thu, Oct 12, 2006 at 11:23:28PM +0200, ropers wrote: I also did touch /emul/linux/etc/mtab in the process, which I didn't see documented in this context, but an error message screamed about /etc/mtab missing, so there. While it might be way cool to get the thing to run, are you *really really sure* you want to do this? You're talking about the ability to backup *and restore* your data. It's not a good idea to hack something together that seems to work, and fails when you need it. I really recommend doing this with tried, understood and proven methods. What you're doing right now is building a house of cards. Regards, -- Jurjen Oskam
Re: annoying openbsd mutt package
On Mon, Oct 02, 2006 at 10:06:34PM -0300, Gustavo Rios wrote: I am using mutt with openbsd. I am getting annoyed by a message error i got just after i start it on command line: The message is the following: /var/mail/grios: No such file or directory (errno = 2) [...] I don't know what i am supposed to do to prevent it from happening. Read the mutt manpage, specifically the ENVIRONMENT section. -- Jurjen Oskam
Re: mbuf leak with rl
On Thu, Sep 14, 2006 at 10:38:35AM -0500, Karle, Chris wrote: Is anyone using a Realtek 8139 card with OpenBSD 3.9? I noticed that mbufs will slowly leak when using it. I noticed this after switching to 3.9. I I have 2 rl and 1 sk interface in my AMD64 machine, and this works fine. Home usage, so no heavy traffic, but uptimes of 50-60 days with no problems. $ dmesg | grep rl ; uptime ; netstat -m rl0 at pci0 dev 12 function 0 Realtek 8139 rev 0x10: irq 10, address 00:00:b4:93:54:c4 rlphy0 at rl0 phy 0: RTL internal PHY rl1 at pci0 dev 13 function 0 Realtek 8139 rev 0x10: irq 5, address 00:e0:4c:49:78:1d rlphy1 at rl1 phy 0: RTL internal PHY 7:59PM up 7 days, 7:22, 1 user, load averages: 0.45, 0.50, 0.47 264 mbufs in use: 256 mbufs allocated to data 2 mbufs allocated to packet headers 6 mbufs allocated to socket names and addresses 0/120/6144 mbuf clusters in use (current/peak/max) 344 Kbytes allocated to network (19% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: apmd -C in 3.9
On Wed, Apr 26, 2006 at 10:26:55PM +0200, Olivier Cherrier wrote: Or did I miss something and is apmd not supported on amd64? It is only in recent versions/snapshots. Ah thanks. Should have noticed, I only picked the OpenBSD Current selection of the amd64 manpages section of www.openbsd.org. When I select 3.8 amd64 it's indeed not there. My bad. But hey, it's a reason to upgrade to 4.0 when it's out. :) -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
3.9 release: nfe driver doesn't work with my motherboard
wsdisplay0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 it0 at isa0 port 0x290/8: IT87 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec uhub2 at uhub0 port 3 uhub2: Texas Instruments UT-USB41 hub, rev 1.10/1.10, addr 2 uhub2: 4 ports with 4 removable, self powered uhidev0 at uhub2 port 1 configuration 1 interface 0 uhidev0: Microsoft Microsoft Natural Keyboard Pro, rev 1.10/1.11, addr 3, iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub2 port 1 configuration 1 interface 1 uhidev1: Microsoft Microsoft Natural Keyboard Pro, rev 1.10/1.11, addr 3, iclass 3/0 uhidev1: 2 report ids uhid0 at uhidev1 reportid 1: input=2, output=0, feature=0 uhid1 at uhidev1 reportid 2: input=1, output=0, feature=0 uhidev2 at uhub2 port 2 configuration 1 interface 0 uhidev2: Logitech Optical USB Mouse, rev 2.00/3.40, addr 4, iclass 3/1 ums0 at uhidev2: 3 buttons and Z dir. wsmouse0 at ums0 mux 0 dkcsum: wd0 matches BIOS drive 0x81 dkcsum: wd1 matches BIOS drive 0x80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: 3.9 release: nfe driver doesn't work with my motherboard
On Sat, Apr 15, 2006 at 04:57:38PM +0200, Srebrenko Sehic wrote: That's weird, since nfe(4) worked fine in the X2100 Sun box I tested a while ago. That was pre-3.9. From X2100 dmesg: Now that you mention it, I did try a 3.8-current on that machine. nfe0 worked, but when booting back to Windows the card wouldn't work in Windows. It started working after I did something which I cannot remember, but a hard reset wasn't it. Could you try with an MP kernel? Hmm, that one doesn't even boot: lots of dmesg I couldn't capture wd0(pciide1:0:0): timeout type: ata c_bcount: 512 c_skip: 0 wd0(pciide1:0:0): timeout type: ata c_bcount: 512 c_skip: 0 I tried booting the i386 install CD, but that didn't boot either: lots of dmesg again bios0: ROM list: 0xc/0xee00! 0xd/0x4000! On Sun, Apr 16, 2006 at 01:03:22AM +1000, Jonathan Gray wrote: nfe0: tx v2 error 0x6004 nfe0: tx v2 error 0x6204 You're on 10baseT Ethernet right? Nope, a standard 10/100 switched Ethernet. I did dhclient -d nfe0 again just now, and now the first error was: nfe0: tx v2 error 0x6100 ... after which 0x6204 was again repeated for (almost) each DHCP query. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: why is there . [dot] in default PATH?
On Tue, Apr 04, 2006 at 09:15:58PM +0200, RedShift wrote: I cannot see how this would be exploitable. root doesn't have . in it's PATH. Other people were discussing cat and cta for example. For this to work, one would have to be able to write to the victim's home directory, $ cd /tmp $ ls-la $ cd ~ ksh: /home/joskam: not found $ cat ls-la #!/bin/sh rm -rf ~ $ HTH. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: openbsd and the money -solutions
On Fri, Mar 24, 2006 at 03:15:27PM -0800, Brian wrote: There is no reason to provide funding from a business standpoint. What does the business gain? Does having a business standpoint require shutting off all common sense? Everytime someone mentions things like business decision or business standpoint you're practically *guaranteed* to hear an extremely narrowminded and shortsighted argument. No corporation is gonna provide funding unless they get something out of it. The companies which integrated Sendmail all just had to spend a lot of money to issue an advisory about the latest vulnerability. They had to scramble to patch things on their version of Sendmail, or at least make sure that the Sendmail-supplied patches work well on their particular OS. As we all know, OpenSSH is used by many companies in many products. A high quality OpenSSH is in the interest of each and every company. A high quality OpenSSH *lowers* costs, both today (because it's freely available), and in the future because high quality means less bugs, wich means a significantly lowered chance of having to spend a lot money should a vulnerability be found. If it would no longer be possible (for whatever reason) to provide high quality software, costs for each company would go *up* much more than it would cost all of them together to make it possible for a project like OpenBSD to keep providing high quality OpenSSH software. -- Jurjen Oskam
Re: OpenBSD/Linux centralized authentication
On Sun, Mar 19, 2006 at 02:27:39PM -0800, Adam D. Morley wrote: MS AD provides MIT-ish KDC support, or so I hear. I've never used it from the UNIX side, but I do know that Windows clients will willingly talk to a UNIX KDC, and I'm told the reverse is true. Yes, you can authenticate against Active Directory using Kerberos. There are some minor caveats (mostly regarding encryption algorithms), but as far as the Unix-clients are concerned it's just Kerberos. I've got some AIX boxes authenticating against Active Directory, even password changing from the AIX side works. To get back to OpenBSD: this means that you can authenticate to Active Directory using Kerberos. Services for Unix aren't necessarily needed. -- Jurjen Oskam
Re: RAIDframe question
On Wed, Feb 01, 2006 at 01:19:58AM -0500, Peter wrote: raid0: Device already configured! ioctl (RAIDFRAME_CONFIGURE) failed Can anyone lend a hand in this important matter? Let me guess (since you didn't post any configuration): you enabled RAID-autoconfiguration by the kernel *and* you configure the same RAID-device during the boot sequence using raidctl? -- Jurjen Oskam
Re: One time passwords?
On Tue, Sep 27, 2005 at 11:36:22PM -0500, C. Bensend wrote: 1) Log into system via ssh skey, which is a one-time auth method 2) Type 'sudo farfegnugen blahblah yadda' 3) Log out You're assuming that the keys you press are transmitted unmodified to your server. Since the terminal is not under your control, there's no reason why it can't send, e.g., sudo rm -rf / all by itself after it sees you're logged in. And this is just one example. -- Jurjen Oskam
Re: [OT]: good home switch?
On Sun, Sep 04, 2005 at 02:00:48PM +0300, Antti Nykdnen wrote: the D-Link DES-1005D Switch 10/100 Mbit/s 5-port I've had one of these since 2002 or 2003 and it has worked solidly ever since. Of course, it'd be weird if such a simple device had any problems. I never buy D-Link again. My 8 port 100 Mbps el-cheapo D-link switch at home would lock itself up every two-three days or so under moderate traffic. At work, for a temporary little network, we bought two 8 port D-Link 1 Gbps switches. These also locked up, and this was with high-end hardware (IBM pSeries) attached to them. A not-too-expensive unmanaged 16 port 3Com switch works great. -- Jurjen Oskam
Re: Did anybody hear this??
On Mon, Jul 25, 2005 at 10:05:32PM -0700, Bruno Delbono wrote: how much truth is actually in this article??? It makes a lot of sense and is right on. What I take out of this article is that having one single firewall (can be any type: network, application etc.) at the perimeter doesn't stop hackers. It does look like the before situation in the article is one where there is only one firewall that separates the LAN from the Internet, and everything on the LAN is treated equally, workstations and servers alike. Generally, that is a bad situation. So, the advice to put different types of machines into different (protected) networks is good. Many people wouldn't go as far as entirely eliminating the outside firewall though; although he says that the desktops run secure OSes he also mentions Active Directory. Some would say those two terms don't go well together. :-) I don't see what really alarmed you? The author makes excellent points and I agree with the him. I also agree, except for the part of eliminating the externally facing firewall entirely. -- Jurjen Oskam
Re: Did anybody hear this??
On Tue, Jul 26, 2005 at 11:20:35AM -0500, Terry Tyson wrote: I only have one firewall but it is three legged, the DMZ box and the LAN are seperate. Is this what you mean by different (protected) networks? Everything depends on your particular situation and needs, but the general idea is that servers shouldn't be wide open to the clients. In your case, if that one firewall is compromised, all attached networks are exposed. This might or might not be something you should worry about. It all depends on your needs. -- Jurjen Oskam
Re: SATA
On Thu, Jun 16, 2005 at 10:10:18AM -0500, L. V. Lammert wrote: [ASUS boards with VIA chipsets] The only problem I have found is the sk0 driver appears to be unstable in some installations, requiring a separate NIC (could have be related to GB on 100BaseT, but it wasn't worth the time to troubleshoot). I've had this with OpenBSD 3.6 on an K8V-X. After upgrading to 3.7, sk0 works great. In 3.6, the PHY wasn't detected. On the few occasions that it was detected, the interface worked but it would lock up under moderate traffic requiring an ifconfig down/up (or detach, don't remember). But, with 3.7 it works great. (This all on a 100 Mbps switched LAN) -- Jurjen Oskam
Re: Good Multi-Platform Backup Solution...
On Sat, Jun 04, 2005 at 04:05:16PM +0200, Manon Goo wrote: You may want to look at TSM TSM doesn't support OpenBSD. You probably could get it to work using the Linux-emulation. However, I don't think it would be wise to trust your data to a program that isn't guaranteed to work on the desired platform, let alone *tested*. -- Jurjen Oskam
