Re: Problems installing 6.5 on Supermicro X11SDV-8C-TP8 motherboard - can't see/find network interfaces
On 2019-05-19 04:33, Hrvoje Popovski wrote: > On 19.5.2019. 3:08, Don Jackson wrote: >> I recently acquired a Supermicro 1019D-FRN8TP server with a X11SDV-8C-TP8 >> motherboard. > > try to install latest snapshot. After installation execute > sendbug -P > 1019D-FRN8TP.txt and send that output to b...@openbsd.org > with hardware description and links to that motherboard. Excellent advice! I installed OpenBSD 6.5-current (GENERIC.MP) #35: Sat May 18 11:40:36 MDT 2019, and it found all 8 interfaces, and the NVMe drive as well, complete victory! I sent the resulting dmesg to that mailing list. Thank you for suggesting I try current…
Problems installing 6.5 on Supermicro X11SDV-8C-TP8 motherboard - can't see/find network interfaces
I recently acquired a Supermicro 1019D-FRN8TP server with a X11SDV-8C-TP8 motherboard. When i attempt to install 6.5, (via PXE or USB), none of the network interfaces are detected. A dmesg appears below, followed by a dmesg and ifconfig -a from successful attempt installing FreeBSD 12.0 Any advice/recommendations about how I can get OpenBSD to see the network interfaces? I’m hoping there is a BIOS setting that will help, but haven’t found it yet….. In addition, I haven’t been able to get OpenBSD to see the M.2 nvme drive in this chassis, so installed a SATA SSD for now….Any way to get OpenBSD to see/use/boot from the M.2 nvme drive? = OpenBSD 6.5 dmesg: = OpenBSD 6.5 (RAMDISK_CD) #3: Sat Apr 13 14:55:38 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 68336508928 (65170MB) avail mem = 66261471232 (63191MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6de8d000 (62 entries) bios0: vendor American Megatrends Inc. version "1.1" date 01/19/2019 bios0: King Star Computer, inc. X11SDV-8C-TP8F acpi0 at bios0: rev 2, can't enable ACPI cpu0 at mainbus0: (uniprocessor) cpu0: Intel(R) Xeon(R) D-2146NT CPU @ 2.30GHz, 2295.15 MHz, 06-55-04 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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE pci0 at mainbus0 bus 0 0:4:0: mem address conflict 0x3831c000/0x4000 0:4:1: mem address conflict 0x38318000/0x4000 0:4:2: mem address conflict 0x38314000/0x4000 0:4:3: mem address conflict 0x3831/0x4000 0:4:4: mem address conflict 0x3830c000/0x4000 0:4:5: mem address conflict 0x38308000/0x4000 0:4:6: mem address conflict 0x38304000/0x4000 0:4:7: mem address conflict 0x3830/0x4000 0:20:2: mem address conflict 0x38323000/0x1000 0:22:0: mem address conflict 0x38322000/0x1000 0:22:1: mem address conflict 0x38321000/0x1000 0:22:4: mem address conflict 0x3832/0x1000 0:31:5: mem address conflict 0xfe01/0x1000 pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x2020 rev 0x04 vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 0 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 1 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 2 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 3 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 4 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 5 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 6 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 7 not configured vendor "Intel", unknown product 0x2024 (class system subclass miscellaneous, rev 0x04) at pci0 dev 5 function 0 not configured vendor "Intel", unknown product 0x2025 (class system subclass miscellaneous, rev 0x04) at pci0 dev 5 function 2 not configured vendor "Intel", unknown product 0x2026 (class system subclass interrupt, rev 0x04) at pci0 dev 5 function 4 not configured vendor "Intel", unknown product 0x2014 (class system subclass miscellaneous, rev 0x04) at pci0 dev 8 function 0 not configured vendor "Intel", unknown product 0x2015 (class DASP subclass Time and Frequency, rev 0x04) at pci0 dev 8 function 1 not configured vendor "Intel", unknown product 0x2016 (class system subclass miscellaneous, rev 0x04) at pci0 dev 8 function 2 not configured "Intel C620 MROM" rev 0x04 at pci0 dev 17 function 0 not configured vendor "Intel", unknown product 0xa1ed (class undefined unknown subclass 0x00, rev 0x04) at pci0 dev 17 function 1 not configured ahci0 at pci0 dev 17 function 5 "Intel C620 AHCI" rev 0x04: irq 11, AHCI 1.3.1 ahci0: port 2: 6.0Gb/s scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5001b44e1c7b8a66 sd0: 915715MB, 512 bytes/sector, 1875385008 sectors, thin xhci0 at pci0 dev 20 function 0 "Intel C620 xHCI" rev 0x04: irq 11, xHCI 1.0 usb0 at xhci0: USB revision 3.0
Questions about monitoring LAN traffic with openbsd/pf/pflog/pflow
I’m attempting to monitor traffic on my LAN, I have inserted a non-aggregating network tap between my firewall (not openbsd) and my enet switch. I wired the two monitor ports of the network tap to two ethernet interfaces (em2 and em3) on an openbsd machine (running 5.3 at present), em0 on this machine is the regular network port. I’m attempting to configure pf etc. in order to facilitate monitoring and analyzing the traffic on my lan. I started with just the em2 interface and associated tap output, which monitors traffic from my LAN to the firewall. AFAICT, the interfaces I use for this monitoring need to be “UP” and in “PROMISC” (promiscuous) mode, correct? So far, the only way I know I can do that is by adding the interface to a bridge. Is there another/better way? So, I have: ifconfig em2 up ifconfig bridge0 add em2 ifconfig bridge0 rule pass in on em2 tag tap_b ifconfig bridge0 up I’d like to configure pf as follows: Log all traffic on em2/bridge0 to (ideally a specific) pflog interface Also “log” flows on em2/bridge0 to (ideally a specific) pflow interface Leave em0 alone (in its default state), and don’t “duplicate” logging of packets received on this interface to pflog/pflow interfaces above. And after that, basically replicate the em2/bridge0 logging with similar logging for em3/bridge1, to distinct pflog/pflow interfaces. Here is my current pf.conf, it doesn’t do what I want above, but this is only thing I have gotten to work at all: set state-defaults pflow set skip on lo pass log on bridge0 block # block stateless traffic pass# establish keep-state block in on ! lo0 proto tcp to port 6000:6010 Is there a better way to log packets received on the bridge than by “pass” ing them? I tried to tag the packets coming in from em2 in the bridge config, but haven’t yet figured out how to use that tag to help me log. With the above, and with ifconfig pflow0 flowsrc 192.168.128.61 flowdst 192.168.128.61:1234 pflowproto 9 I’ve gotten some flow data to show up and I’ve used nfsen to look at it. I’d greatly appreciate any advice/pointers on how I can do what I describe above. I’ve spent many hours trying different things, reading man pages, and books (The Book of PF, Network Flow Analysis, etc) Don
Re: Questions about monitoring LAN traffic with openbsd/pf/pflog/pflow
On Mar 20, 2014, at 2:14 PM, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 20-03-2014 17:12, Don Jackson escreveu: I’m attempting to monitor traffic on my LAN, I have inserted a non-aggregating network tap between my firewall (not openbsd) and my enet switch. I wired the two monitor ports of the network tap to two ethernet interfaces (em2 and em3) on an openbsd machine (running 5.3 at present), em0 on this machine is the regular network port. I’m attempting to configure pf etc. in order to facilitate monitoring and analyzing the traffic on my lan. I started with just the em2 interface and associated tap output, which monitors traffic from my LAN to the firewall. AFAICT, the interfaces I use for this monitoring need to be “UP” and in “PROMISC” (promiscuous) mode, correct? So far, the only way I know I can do that is by adding the interface to a bridge. Is there another/better way? You could implement some sort of daemon that puts the interfaces in promiscuous mode using the pcap library. Or running a tmux+tcpdump. A bridge can also work, but it introduces complexity, especially when filtering the packets. Based on further experiments motivated by your suggestions, I have concluded that I’ve been using the wrong tool(s) for the job. Since I’m using the OpenBSD box to just read all packets on an interface, I shouldn’t be using pf/pflog/pflow at all, I should just focus on apps like tcpdump that open the interface directly, and read what they want. Some network monitoring packages (i.e. argus) seem to have their own tcpdump-like apps for reading network interfaces. If the box in question was the router/firewall, then obviously I could/should use pf/pflog/pflow to extract the info passing through/by that I would want to monitor. Thank you for kludging me in the right direction. Don
Re: OpenBSD pxe automated install
On Aug 12, 2013, at 11:37 PM, Loïc BLOT loic.b...@unix-experience.fr wrote: 3. What i want is something like this: https://wiki.debian.org/DebianInstaller/Preseed or this https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5 /html/Installation_Guide/ch-kickstart2.html Then i ask @misc to know if an existing process exists, but now i think this doesn't exist and i must create a special bsd.rd PXE to do this (and share it to OpenBSD community, it will be great for deploy OpenBSD on several machines without doing anything. Using the initial version of ânbender.com/install.netboot/install.html I have/had a completely automated OpenBSD install. I pxeboot this modified bsd.rd, and it discovers/downloads special installer support via DHCP/etc. Later, Nick did this: redux - fully automated OpenBSD installation - hiqu.biz We failed to get any sort of buy in to this approach into the main distribution⦠Don
Re: OpenBSD pxe automated install
On Aug 13, 2013, at 9:48 AM, Marian Hettwer m...@kernel32.de wrote: I believe it's save to assume that a DHCP server is around, since this one is needed anyways to pxeboot the box. So after the boot of our netboot.rd kernel, we need to figure out which interface was used for pxe config and then do a dhclient on this interface. I thought Nick's work did much/all of this. If we got an IP address, dhcp should probably give extra options, like the config server url where we then can find and download the additional configs. We could and probably should use DHCP options, since as stated above, dhcp servers are available for the pxeboot anyways. Nick's work definitely did this. Should we take this discussion off the list now? If so, who would like to be part of the next emails? I'd guess Loic, me, phessler (?), Nick Bender (?) and I will also add a colleague some might know (Uwe Stuehler uwe@). I would like to be included in any further discussion either at this email address or don dot jackson at gmail Here are two additional links that provide historical context, and links to past work: https://groups.google.com/d/topic/mailing.openbsd.tech/X01IcFJ0MVU/discussion https://groups.google.com/d/topic/mailing.openbsd.tech/h1-jrS36lqo/discussion And lastly, IMHO, optionally, it would be nice if the eventual solution was capable of being pxebooted via iPXE - open source boot firmware [start] At present, I have not been able to get bsd.rd or any sort of OpenBSD installer to run via ipxe Best regards, Don
Troubles compiling 4.8-stable userland on amd64
Hello,
In general, I run/track stable. I periodically rebuild the OS from source.
I've done this successfully probably about 50 times over the past N years.
I have a set of shell scripts I use to set up the various directories, pull
from CVS, build kernel, build userland, build release, etc, so my actions are
consistent.
I recently built a new 4.8 amd64 machine, from the images on the cdrom.
Then I pulled down the stable sources (4 patches since release), and rebuild
the kernel, installed new kernel, and rebooted.
dmesg | head
OpenBSD 4.8-stable (GENERIC.MP) #0: Sun Nov 21 17:12:18 PST 2010
d...@obsdbuildamd.siptone.net:/home2/4.8/amd64/src/sys/arch/amd64/compile
/GENERIC.MP
Then I attempted to build userland. After running for 60-90 minutes, the
build dies as shown in the messages below.
I have re-checked/re-traced my steps here 2-3 times, including starting all
over from scratch. Still, I can't see what I am doing wrong.
I did find something about changes to libstdc++-v3 at this link:
http://www.openbsd.org/faq/current.html#20100923
But I am attempting to build stable, not current.
I would definitely be grateful for any advice.
I must be doing something wrong, but so far I just can't figure out what.
Don
=== libstdc++-v3
c++ -O2 -pipe -g -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../libstdc++-v3/
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/libsupc++
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc/gcc/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../libiberty/include -I.
-frandom-seed=RepeatabilityConsideredGood -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/libsupc++
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc/gcc/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../libiberty/include -I.
-frandom-seed=RepeatabilityConsideredGood -fno-implicit-templates
-ffunction-sections -fdata-sections -Wno-deprecated -fno-implicit-templates
-ffunction-sections -fdata-sections -Wno-deprecated -idirafter
//usr/include/g++ -nostdinc -idirafter //usr/include -c
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc -o bitmap_allocator.o
In file included from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:37,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
//usr/include/g++/cstddef:50:28: error: bits/c++config.h: No such file or
directory
In file included from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:43,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
concurrence.h:41:24: error: bits/gthr.h: No such file or directory
In file included from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:37,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
//usr/include/g++/cstddef:53: error: expected constructor, destructor, or type
conversion before '(' token
//usr/include/g++/cstddef:58: error: '_GLIBCXX_END_NAMESPACE' does not name a
type
In file included from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:38,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/bits
/functexcept.h:93: error: '_GLIBCXX_END_NAMESPACE' does not name a type
In file included from //usr/include/g++/utility:66,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:39,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/bits
/stl_relops.h:136: error: '_GLIBCXX_END_NAMESPACE' does not name a type
In file included from //usr/include/g++/utility:67,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:39,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
Re: Troubles compiling 4.8-stable userland on amd64
On Nov 23, 2010, at 3:06 PM, Stuart Henderson wrote:
looks like you are setting DESTDIR during build. unfortunately DESTDIR
builds
got broken with the move to GCC 4 and aren't supported during the build
phase
any more.
http://marc.info/?l=openbsd-techm=128072148432121w=2
the patches in the previous message in the thread do work (you must build
and install gcc with the patch *before* doing the DESTDIR build), but
you're
creating maintenance problems that way.
the simplest way to do what you're trying to do now is probably to unpack
OS tgz sets to some other directory and build in a chroot jail (watch out
for mount options nodev/nosuid).
but the simplest way overall is to do the build without setting DESTDIR.
I'm willing to try not using DESTDIR.
But the FAQ clearly states to set it:
Make sure all the appropriate directories are created.
# cd /usr/src/etc env DESTDIR=/ make distrib-dirs
http://www.openbsd.org/faq/faq5.html#BldUserland
I will try this without setting DESTDIR.
On 2010-11-23, Don Jackson don.jack...@gmail.com wrote:
Hello,
In general, I run/track stable. I periodically rebuild the OS from
source.
I've done this successfully probably about 50 times over the past N years.
I have a set of shell scripts I use to set up the various directories,
pull
from CVS, build kernel, build userland, build release, etc, so my actions
are
consistent.
I recently built a new 4.8 amd64 machine, from the images on the cdrom.
Then I pulled down the stable sources (4 patches since release), and
rebuild
the kernel, installed new kernel, and rebooted.
dmesg | head
OpenBSD 4.8-stable (GENERIC.MP) #0: Sun Nov 21 17:12:18 PST 2010
d...@obsdbuildamd.siptone.net:/home2/4.8/amd64/src/sys/arch/amd64/compile
/GENERIC.MP
Then I attempted to build userland. After running for 60-90 minutes, the
build dies as shown in the messages below.
I have re-checked/re-traced my steps here 2-3 times, including starting
all
over from scratch. Still, I can't see what I am doing wrong.
I did find something about changes to libstdc++-v3 at this link:
http://www.openbsd.org/faq/current.html#20100923
But I am attempting to build stable, not current.
I would definitely be grateful for any advice.
I must be doing something wrong, but so far I just can't figure out what.
Don
=== libstdc++-v3
c++ -O2 -pipe -g -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../libstdc++-v3/
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/libsupc++
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc/gcc/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../libiberty/include -I.
-frandom-seed=RepeatabilityConsideredGood -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/libsupc++
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/gcc/gcc/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include
-I/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../libiberty/include -I.
-frandom-seed=RepeatabilityConsideredGood -fno-implicit-templates
-ffunction-sections -fdata-sections -Wno-deprecated
-fno-implicit-templates
-ffunction-sections -fdata-sections -Wno-deprecated -idirafter
//usr/include/g++ -nostdinc -idirafter //usr/include -c
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc -o bitmap_allocator.o
In file included from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:37,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
//usr/include/g++/cstddef:50:28: error: bits/c++config.h: No such file or
directory
In file included from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:43,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
concurrence.h:41:24: error: bits/gthr.h: No such file or directory
In file included from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/include/ext/
bitmap_allocator.h:37,
from
/home2/4.8/amd64/src/gnu/lib/libstdc++-v3/../../gcc/libstdc++-v3/src/bitmap_a
llocator.cc:30:
//usr/include/g++/cstddef:53: error: expected constructor, destructor, or
type
conversion before '(' token
//usr/include/g++/cstddef:58: error: '_GLIBCXX_END_NAMESPACE' does
Re: Troubles compiling 4.8-stable userland on amd64
OK, removing DESTDIR from my build-userland shell script fixed the problem.
To be specific, the FAQ says:
Make sure all the appropriate directories are created.
# cd /usr/src/etc env DESTDIR=/ make distrib-dirs
And here is what I had in my build script (ksh):
cd ${BSDSRCDIR}/etc
export DESTDIR=/
make distrib-dirs
And up until now, that has always worked for me. But now it doesn't, so based
on Stuart's advice, I removed the
export DESTDIR=/
Is the FAQ incorrect, or was my translation of the FAQ into a ksh script
incorrect, which then failed when DESTDIR suppport during userland builds
changed?
Thank you so much for pointing out a workaround to my problem, I've been stuck
on this for days!
Don
On Nov 23, 2010, at 9:32 PM, Don Jackson wrote:
On Nov 23, 2010, at 3:06 PM, Stuart Henderson wrote:
looks like you are setting DESTDIR during build. unfortunately DESTDIR
builds
got broken with the move to GCC 4 and aren't supported during the build
phase
any more.
http://marc.info/?l=openbsd-techm=128072148432121w=2
the patches in the previous message in the thread do work (you must build
and install gcc with the patch *before* doing the DESTDIR build), but
you're
creating maintenance problems that way.
the simplest way to do what you're trying to do now is probably to unpack
OS tgz sets to some other directory and build in a chroot jail (watch out
for mount options nodev/nosuid).
but the simplest way overall is to do the build without setting DESTDIR.
I'm willing to try not using DESTDIR.
But the FAQ clearly states to set it:
Make sure all the appropriate directories are created.
# cd /usr/src/etc env DESTDIR=/ make distrib-dirs
http://www.openbsd.org/faq/faq5.html#BldUserland
I will try this without setting DESTDIR.
suggestion for a new/additional OpenBSD release media option
Hello, I happily and dutifully purchase each CD-ROM release. Many of us receive these CDs prior to the official release date. It is my understanding/experience that many of the binary packages are not available on the CD, and I must wait for them to be released, and then copy them down to my local install server. If early access to the new release is an intended benefit of the CDs, (which it may not be, I don't know), then I for one, am not able to realize this benefit, because I need a lot of packages that are not included on the CD. I then contribute to server overload right after the release date, to ftp all these packages. Here is an idea for an additional release media product: DVD-ROM, including complete release and packages for i386 and amd64, and source I would happily pay more for this product than I currently do for the CDs. Possibly the reduction from 3 CDs to 1 DVD might reduce packaging and might be considered more green. Having all the packages would keep people like me from having to download these packages over the Internet, saving bandwidth charges for those hosting public access. Just a suggestion. Regards Don
Re: suggestion for a new/additional OpenBSD release media option
Here is an idea for an additional release media product: DVD-ROM, including complete release and packages for i386 and amd64, and source This will be a lot more work for me to make. Understood, and maybe this is reason enough to not do this. I would happily pay more for this product than I currently do for the CDs. And others might not. I don't know if it will offset. I am not proposing that you stop the traditional CDROM. Clearly, if it is lot of work for you to produce the DVD, and the resulting DVD revenue is not enough, then this is a bad idea, and a poor use of your time. I have also not yet invested the time into making 4 architectures boot off 2 media. For me, the ability to boot of the install media is not a requirement. I do all my installs via pxeboot. If there were enough room on the DVD, you could also provide the CDROM ISOs. If a user REALLY needed bootable media, they could burn the ISOs to CDROMs, and do that. Again, these are only suggestions. You understand your user/customer base infinitely better than I do. Obviously it is your decision what products you choose to offer.
Re: How do I enable bsd.mp kernel in 4.4/i386?
On May 3, 2009, at 9:15 AM, Thomas Pfaff wrote: On Sun, 3 May 2009 08:45:55 -0700 J.C. Roberts list-...@designtools.org wrote: Thirdly, it should be removed. The new installer destined for 4.6 already does the right thing, so the i386\amd64 specific etc/ boot.conf hack is redundant and leads to confusion. Hmm, how should I specify that I want to use com0 as console then? Agreed, boot.conf is VERY useful. Another important use is to reboot into another temporary kernel. I use this to boot into a YAIFO-like installer, so I can easily re- install a running machine from the network without having to much with BIOS setting for pxeboot, etc. And if this process fails for some reason (before you reformat your disks :-) ), it is good to have the regular kernels sitting around for recovery purposes. Don
Re: apache-based mp3 managers for openbsd
It isn't apache, but Stuart Henderson recently posted a port of the SlimDevices/Logitech SqueezeCenter to the ports mailing list. SqueezeCenter is a very nice MP3 manager On Dec 10, 2008, at 9:38 AM, Vivek Ayer wrote: Hey guys, Just wondering if openbsd had a program to manage mp3s via apache in their package collection or ports. I've heard good things about Zina and Ampache, but neither of them are available in the packages collection. Could you all recommend some programs, preferably LAMP-based? Thanks, Vivek
Re: PF and the old SIP issue
On Nov 19, 2008, at 6:39 PM, Girish Venkatachalam wrote: Slightly off topic but since many people do not like the horrible Asterisk code and design ( no offense meant) and of course the sucky GPL license, whatever is happening on a BSD licensed Asterisk implementation? I mean an EPABX in software? That will be really cool. Is someone working on it? It will be great if an OpenBSD style Asterisk clone is developed. ;) Have you looked at FreeSwitch? http://www.freeswitch.org/ It would sure be nice if someone would create an OpenBSD port of FreeSwitch. In other SIP news, I posted a port of Kamailio/OpenSER to the ports mailing list yesterday
question about useradd command on 4.4
My system installation script (similar to install.site, run right after the system was installed, and before first boot) attempts to configure a user account using sometime pretty much like this: /usr/sbin/useradd -mv -b /home -c name of user -u 2002 -g wheel -s /bin/ksh -p 'encrypted-password' foo When I did this, it created the user, but did not add the user to the group wheel. Based on the man page, I was expecting the -g option to do so: useradd -D [-b base-dir] [-e expiry-time] [-f inactive-time] [-g gid | name | =uid] [-k skel-dir] [-L login-class] [-r low..high] [-s shell] useradd [-mov] [-b base-dir] [-c comment] [-d home-dir] [-e expiry-time] [-f inactive-time] [-G secondary-group[,group,...]] [-g gid | name | =uid] [-k skel-dir] [-L login-class] [-p password] [-r low..high] [-s shell] [-u uid] user -g gid | groupname | =uid sets the default group for new users. But it didn't, the user was created with gid 0. When I changed the above command to use -G instead of -g, it worked. Why? Am I just not understanding the documentation for useradd?
Re: Experiences running named and rndc on 4.4 vs 4.3 - Solved/Explained
Yes, you are exactly right. My OS install script renames the existing /var/named/etc directory, and creates a new one pulled from version control, and in so doing, does not restore the correct ownership of the etc directory. So later on, during the execution of /etc/rc, the rndc.key file gets created with the wrong ownership, which led to the problem I reported. Because the rndc.key was generated later in this process, I did not think I had an ownership issue with it, but clearly the problem is the ownership of the parent directory. Thank you for your insight into my problem, I will make sure my install scripts do a better job of maintaining the ownership/permissions... Don On Wed, Nov 12, 2008 at 6:17 AM, Woodchuck [EMAIL PROTECTED] wrote: On Tue, 11 Nov 2008, Don Jackson wrote: Today I began testing named on a freshly installed OpenBSD 4.4 amd64 machine, using my old named.conf file from 4.3 (which was still running named version 9.4.2) When the machine first boots after the install, /etc/rc determines there is no rndc.key, and generates one: rndc-confgen: generating new shared secret... done. starting named Here are the owner, group, and file modes of the two different copies of rndc.key that are generated: # ls -lAF /etc/rndc.key /var/named/etc/rndc.key -rw--- 1 root wheel 77 Nov 11 12:24 /etc/rndc.key -rw-r- 1 root wheel 77 Nov 11 12:24 /var/named/etc/rndc.key named only cares about the rndc.key in /var/named/etc Right. But later, rndc will use the /etc version. So you need both, and the permissions you show are sane ones. Looking at the logs: /var/log/daemon, one can see: Nov 11 12:24:10 svn01 named[142]: none:0: open: /etc/rndc.key: permission denied Nov 11 12:24:10 svn01 named[142]: couldn't add command channel 127.0.0.1#953: permission denied Here is my workaround: # chown root:named /var/named/etc/rndc.key # ls -lAF /var/named/etc/rndc.key -rw-r- 1 root named 77 Nov 11 12:24 /var/named/etc/rndc.key Should /etc/rc set the group ownership of /var/named/etc/rndc.key? Comments? I think rndc.key should pick up the named group from the ownerships and permissions on /var/named/etc. /var/named/etc should be owned by root.named and have permissions 750. I bet your /var/named/etc is owned by root.wheel. Dave
Experiences running named and rndc on 4.4 vs 4.3
Today I began testing named on a freshly installed OpenBSD 4.4 amd64 machine, using my old named.conf file from 4.3 (which was still running named version 9.4.2) When the machine first boots after the install, /etc/rc determines there is no rndc.key, and generates one: rndc-confgen: generating new shared secret... done. starting named Here are the owner, group, and file modes of the two different copies of rndc.key that are generated: # ls -lAF /etc/rndc.key /var/named/etc/rndc.key -rw--- 1 root wheel 77 Nov 11 12:24 /etc/rndc.key -rw-r- 1 root wheel 77 Nov 11 12:24 /var/named/etc/rndc.key named only cares about the rndc.key in /var/named/etc Looking at the logs: /var/log/daemon, one can see: Nov 11 12:24:10 svn01 named[142]: none:0: open: /etc/rndc.key: permission denied Nov 11 12:24:10 svn01 named[142]: couldn't add command channel 127.0.0.1#953: permission denied Here is my workaround: # chown root:named /var/named/etc/rndc.key # ls -lAF /var/named/etc/rndc.key -rw-r- 1 root named 77 Nov 11 12:24 /var/named/etc/rndc.key Should /etc/rc set the group ownership of /var/named/etc/rndc.key? Comments?
Re: Serial ATA RAID ctrl on PCI
On Oct 28, 2008, at 5:46 AM, Claudio Jeker wrote: Have a look at the man -k RAID output. Especially arc(4) and ami(4) are great SATA RAID controllers on OpenBSD. Does OpenBSD's arc(4) driver support any method to report RAID status and/or failures? If not, then how is an admin supposed to understand the health of arc supported RAID array?
Re: Serial ATA RAID ctrl on PCI
On Oct 28, 2008, at 3:47 PM, Robert Franklin wrote: Did you read the man page for arc(4)? It says right there. I did, and I'm not seeing anything. It does talk about this: -a alarm-function Control the RAID card's alarm functionality, if supported. alarm-function may be one of: disable Disable the alarm on the RAID controller. enable Enable the alarm on the RAID controller. get Retrieve the current alarm state (enabled or disabled). silence | quiet Silence the alarm if it is currently beeping. The alarm-function may be specified as given above, or by the first letter only (e.g. -a e). But this all seems related to turning on/off the beeper, rather than giving me some textual indication of the health of the raid system. If my server is in a colo miles away, the alarm buzzer is not going to be particularly useful to me. Compare this to the ami driver, which states: Logical disk status is exposed under the hw.sensors sysctl(8) and can be monitored using sensorsd(8). For example: $ sysctl hw.sensors.ami0 hw.sensors.ami0.drive0=online (sd0), OK hw.sensors.ami0.drive1=degraded (sd1), WARNING hw.sensors.ami0.drive2=failed (sd2), CRITICAL This exactly the kind of thing I am asking if arc supports, and if it doesn't (which is what I suspect), then IMHO, OpenBSD's support for Areca cards is not as awesome as its support for LSI Megaraid boards On Tue, Oct 28, 2008 at 4:24 PM, Don Jackson [EMAIL PROTECTED] wrote: On Oct 28, 2008, at 5:46 AM, Claudio Jeker wrote: Have a look at the man -k RAID output. Especially arc(4) and ami(4) are great SATA RAID controllers on OpenBSD. Does OpenBSD's arc(4) driver support any method to report RAID status and/or failures? If not, then how is an admin supposed to understand the health of arc supported RAID array?
Re: firNAS (flexible, inexpensive, reliable Network Area Storage)
On Oct 17, 2008, at 3:55 PM, Anathae Townsend wrote: I've looked at a local retailer of computer equipment (they have good prices) and noticed that the least expensive of the four drive NAS appliances without drives was around $470 cdn. I pieced together a mother board, processor, memory, CF card, CF to IDE adapter, and case that would accept four SATA drives and was around $150 less expensive. Consumer NAS devices. don't look so good with that. Also, from what I hear, the consumer NAS devices typically have barely enough power to do simple SaMBa serving. How this is on topic for OpenBSD is OpenBSD seems like a good choice to use as the OS layer of the NAS. NFS, httpd (with ssl), ftp, sftp are included in the base install. Alternate Network File Systems are about the only thing that would have to be added, other than configuration settings and a management interface. The final two are what I would be developing, and adding to a package or some other release bundle. I'm sure you could do this with OpenBSD, and it would have some advantages. Make sure you have read and internalized http://www.openbsd.org/faq/faq14.html#LargeDrive before you start. You might want to take a look at the FreeNAS project, at www.freenas.org, which is based on FreeBSD. They have built a popular software NAS appliance. Your instincts to not use a consumer NAS appliance are right on, IMHO. I had a very bad experience with an InfrantNAS, when the motherboard itself began to fail, and wasn't able to extract a replacement from the mfg without buying a completely new unit. Never again! Although I use (and love) OpenBSD for lots of different kinds of servers, I have decided not to use OpenBSD for my NAS. My needs involve software-based RAID for many terrabyte+ sized drives, and for that I've found that ZFS with RAIDZ2 is truly amazing. The best existing implementation of ZFS is under Solaris10, so that is what I am using for now. ZFS has been added to FreeBSD, but I am going to wait a few releases to see how that implementation shakes out before trusting it with my data.
Re: DHCPD on 4.3 not passing options
One extreme workaround is to use the OpenBSD port of ISC dhcpd 3.1.0
(in the 4.3 ports repository )
If you do, you can declare custom option values symbolically, like this:
option openbsd-install-script code 225 = text ;
and then later:
option openbsd-install-script
http://www/config/custom-install.sh;;
You also need to make sure that your dhcp client is requesting the
option values you care about, see /etc/dhclient.conf
In a recent email to [EMAIL PROTECTED], Nick Bender stated:
Note that if you use the stock dhcpd you need to be running a version
built
after 10-sep-2008 as there was a bug in dhcpd which caused unreliable
handling
of dhcp option numbers greater than 63.
So this might be related to your problem as well.
On Oct 9, 2008, at 11:38 AM, Beto wrote:
Hi,
I got a new machine to become my new server, so I installed OpenBSD
4.3
stable and all services thar run on the old machine.
The older one runs OpenBSD 4.2 stable upgraded from OpenBSD 4.1
stable,
everything works fine including dhcpd that pass some special options
that
says to System Imager Client which server to search for.
On the new machine with the same configuration file, it does not
work. The
System Imager clients did not get the values, I think it is not
passed. All
the default information are passed.
I recompiled again my userland to try to solve this, but it not works.
Below my configuration file:
# $OpenBSD: dhcpd.conf,v 1.1 1998/08/19 04:25:45 form Exp $
#
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.
#
option domain-name ncd.org.br;
option impress-servers 192.168.1.252;
option time-servers 192.168.1.254;
default-lease-time 86400;
max-lease-time 9;
subnet 192.168.1.0 netmask 255.255.255.0 {
deny unknown-clients;
option domain-name-servers 192.168.1.254, 172.20.2.31,
172.20.2.126, 172.20.2.10;
server-identifier 192.168.1.252;
option routers 192.168.1.254;
# Servidor System Imager
option option-100 192.168.1.252;
option option-140 192.168.1.252;
option option-144 n;
next-server 192.168.1.252;
filename pxelinux.bin;
range 192.168.1.1 192.168.1.24;
range 192.168.1.251 192.168.1.251;
#Clientes
host ncd01 { hardware ethernet 00:0B:E0:J6:1C:FE;
fixed-address 192.168.1.1;
option host-name ncd01;}
.
.
.
(Other clients)
}
Any idea , how to solve this?
Thanks in advance.
SUMMARY: How to add new modules to httpd?
mod_proxy_html was the module I was trying to build, and it turns out that it requires Apache2. So I ended up installing Apache2 from the OpenBSD port, as well as libtools, and libxml. I then was able to use apxs2 to compile mod_proxy_html.c into the required .so, and loaded it into Apache2 with no problem. Thanks to Cezary Morga for pointing out the blog post http://laxmangunjikar.wordpress.com/2008/01/05/installing-mod_proxy_html/? which helped me to understand the apxs utility, and its use to simplify creating shared libraries for Apache. So, for future reference, if you are attempting to compile/load a module into httpd, use apxs to build the shared library. If you need Apache2, build that port, and load the libtools package, and use apxs2 to build your shared lib. Best regards, Don On Mon, Sep 22, 2008 at 4:20 PM, Don Jackson [EMAIL PROTECTED] wrote: I have some corrections and clarifications I need to make to this query: 1) The primary module I am trying to use/load is mod_proxy_html, which in turn requires mod_proxy_http (among others) 2) for a while I forgot I needed to turn off the chroot feature, now that I have, it looks like the LoadFile of libxml works, eg: LoadFile /usr/local/lib/libxml2.so.9.7 Yields no error messages on startup, so that is a big improvement! 3) In looking around the source code for httpd, I see that in ./src/usr.sbin/httpd/src/modules/proxy I see that proxy_http.c is in there, so does that mean that mod_proxy_http is already included in httpd? If so, it seems that the only remaining module I would need is mod_proxy_html. Do I need to recompile httpd to get this this into the build? (if so, how?) Or can I create a .so and just load it? Thanks again, Don On Mon, Sep 22, 2008 at 3:35 PM, Don Jackson [EMAIL PROTECTED] wrote: Hello, I'd like to use an Apache module, mod_proxy_http to build a reverse-proxy, see: http://www.apachetutor.org/admin/reverseproxies This module requires the inclusion of several others, eg: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule headers_modulemodules/mod_headers.so LoadFile /usr/lib/libxml2.so LoadModule proxy_html_module modules/mod_proxy_html.so I'm running OpenBSD 4.3 stable on amd64. It looks like the OpenBSD stock httpd inclues mod_proxy and mod_headers, but not mod_proxy_http, or mod_proxy_html, and although libxml2 seems to be available as a package, httpd compains when one tries to LoadFile it as above. Despite looking thru the FAQ and a few other places, I'm not finding the documentation I would need to figure out how to add the modules above. Do I need to recompile httpd after adding new modules into the tree? Any advice or pointers to documentation on this would be greatly appreciated! Thanks, Don
How to add new modules to httpd?
Hello, I'd like to use an Apache module, mod_proxy_http to build a reverse-proxy, see: http://www.apachetutor.org/admin/reverseproxies This module requires the inclusion of several others, eg: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule headers_modulemodules/mod_headers.so LoadFile /usr/lib/libxml2.so LoadModule proxy_html_module modules/mod_proxy_html.so I'm running OpenBSD 4.3 stable on amd64. It looks like the OpenBSD stock httpd inclues mod_proxy and mod_headers, but not mod_proxy_http, or mod_proxy_html, and although libxml2 seems to be available as a package, httpd compains when one tries to LoadFile it as above. Despite looking thru the FAQ and a few other places, I'm not finding the documentation I would need to figure out how to add the modules above. Do I need to recompile httpd after adding new modules into the tree? Any advice or pointers to documentation on this would be greatly appreciated! Thanks, Don
Re: How to add new modules to httpd?
I have some corrections and clarifications I need to make to this query: 1) The primary module I am trying to use/load is mod_proxy_html, which in turn requires mod_proxy_http (among others) 2) for a while I forgot I needed to turn off the chroot feature, now that I have, it looks like the LoadFile of libxml works, eg: LoadFile /usr/local/lib/libxml2.so.9.7 Yields no error messages on startup, so that is a big improvement! 3) In looking around the source code for httpd, I see that in ./src/usr.sbin/httpd/src/modules/proxy I see that proxy_http.c is in there, so does that mean that mod_proxy_http is already included in httpd? If so, it seems that the only remaining module I would need is mod_proxy_html. Do I need to recompile httpd to get this this into the build? (if so, how?) Or can I create a .so and just load it? Thanks again, Don On Mon, Sep 22, 2008 at 3:35 PM, Don Jackson [EMAIL PROTECTED] wrote: Hello, I'd like to use an Apache module, mod_proxy_http to build a reverse-proxy, see: http://www.apachetutor.org/admin/reverseproxies This module requires the inclusion of several others, eg: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule headers_modulemodules/mod_headers.so LoadFile /usr/lib/libxml2.so LoadModule proxy_html_module modules/mod_proxy_html.so I'm running OpenBSD 4.3 stable on amd64. It looks like the OpenBSD stock httpd inclues mod_proxy and mod_headers, but not mod_proxy_http, or mod_proxy_html, and although libxml2 seems to be available as a package, httpd compains when one tries to LoadFile it as above. Despite looking thru the FAQ and a few other places, I'm not finding the documentation I would need to figure out how to add the modules above. Do I need to recompile httpd after adding new modules into the tree? Any advice or pointers to documentation on this would be greatly appreciated! Thanks, Don
Panic booting 4.3/amd64 after install
I just installed 4.3 on a machine, a clean install (not an upgrade). Here is what happens when I attempt to boot after the install finishes, any advice? booting hd0a:/bsd: 4411696+1062081+747032+0+557080 [80+389616+243431]=0xb12c40 entry point at 0x1001e0 [7205c766, 3404, 24448b12, 9ba0a304]??[ using 633896 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2008 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.3 (GENERIC) #1368: Wed Mar 12 11:05:31 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 2147020800 (2047MB) avail mem = 2073399296 (1977MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf9830 (63 entries) bios0: vendor American Megatrends Inc.V2.05 version 080010 date 05/23/2006 bios0: TYAN S2881 Thunder K8SR Mainboard acpi0 at bios0: rev 0 acpi0: tables DSDT FACP OEMB ASF! acpi0: wakeup devices PCI1(S4) USB0(S4) USB1(S4) PS2K(S1) PS2M(S1) UAR1(S1) UAR2(S1) GOLA(S4) GLAN(S4) GOLB(S4) SMBC(S4) AC97(S4) MODM(S4) PWRB(S1) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PCI1) acpiprt2 at acpi0: bus 2 (GOLA) acpiprt3 at acpi0: bus 1 (GOLB) acpicpu0 at acpi0: PSS index.buf out of bounds: 255/21 1337 Called: \_SB_.PCI0.SBRG.CGLD arg0: 0x80008020 cnt:01 stk:00 objref: 0x8004a908 index: [\_SB_.PCI0.SBRG.LDN_] 0x8004a908 cnt:01 stk:00 field: bitpos=0038 bitlen=0008 ref1:4ac08 ref2:4ab08 [IndexField] [\_SB_.PCI0.SBRG.INDX] 0x8004ac08 cnt:19 stk:00 field: bitpos= bitlen=0008 ref1:4ae08 ref2:0 [Field] [\_SB_.PCI0.SBRG.IOID] 0x8004ae08 cnt:03 stk:00 opregion: 01,002e,2 [\_SB_.PCI0.SBRG.DATA] 0x8004ab08 cnt:19 stk:00 field: bitpos=0008 bitlen=0008 ref1:4ae08 ref2:0 [Field] [\_SB_.PCI0.SBRG.IOID] 0x8004ae08 cnt:03 stk:00 opregion: 01,002e,2 1105 Called: \_SB_.PCI0.SBRG.ENFG arg0: 0x80008520 cnt:01 stk:00 objref: 0x8004b288 index: [\_SB_.PCI0.SBRG.CGLD] 0x8004b288 cnt:01 stk:00 method: 01 1146 Called: \_SB_.PCI0.SBRG.UHID arg0: 0x80008320 cnt:01 stk:00 integer: 1 0b0e Called: \_SB_.PCI0.SBRG.UAR2._HID panic: aml_die aml_derefvalue:1407 Stopped at Debugger+0x5: leave Debugger() at Debugger+0x5 panic() at panic+0x12a _aml_die() at _aml_die+0xdc aml_derefvalue() at aml_derefvalue+0x271 aml_evalterm() at aml_evalterm+0x32 aml_parseterm() at aml_parseterm+0x4d aml_parseref() at aml_parseref+0x2b9 aml_parseop() at aml_parseop+0xf9 aml_parseterm() at aml_parseterm+0x3f aml_callmethod() at aml_callmethod+0x3a end trace frame: 0x80c18310, count: 0 RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger() at Debugger+0x5 panic() at panic+0x12a _aml_die() at _aml_die+0xdc aml_derefvalue() at aml_derefvalue+0x271 aml_evalterm() at aml_evalterm+0x32 aml_parseterm() at aml_parseterm+0x4d aml_parseref() at aml_parseref+0x2b9 aml_parseop() at aml_parseop+0xf9 aml_parseterm() at aml_parseterm+0x3f aml_callmethod() at aml_callmethod+0x3a aml_evalmethod() at aml_evalmethod+0x59 aml_derefvalue() at aml_derefvalue+0x7e aml_derefvalue() at aml_derefvalue+0x11c aml_derefvalue() at aml_derefvalue+0x11c aml_evalterm() at aml_evalterm+0x32 aml_parseterm() at aml_parseterm+0x4d aml_parseref() at aml_parseref+0x127 aml_parseop() at aml_parseop+0xf9 aml_parseterm() at aml_parseterm+0x3f aml_callmethod() at aml_callmethod+0x3a aml_evalmethod() at aml_evalmethod+0x59 aml_derefvalue() at aml_derefvalue+0x7e aml_derefvalue() at aml_derefvalue+0x11c aml_evalterm() at aml_evalterm+0x32 aml_parseterm() at aml_parseterm+0x4d aml_parseif() at aml_parseif+0xa3 aml_parseop() at aml_parseop+0xf9 aml_parseterm() at aml_parseterm+0x3f aml_callmethod() at aml_callmethod+0x3a aml_evalmethod() at aml_evalmethod+0x59 aml_derefvalue() at aml_derefvalue+0x7e aml_derefvalue() at aml_derefvalue+0x11c aml_evalterm() at aml_evalterm+0x32 aml_parseterm() at aml_parseterm+0x4d aml_parseref() at aml_parseref+0x2b9 aml_parseop() at aml_parseop+0xf9 aml_parseterm() at aml_parseterm+0x3f aml_callmethod() at aml_callmethod+0x3a aml_evalmethod() at aml_evalmethod+0x59 aml_evalnode() at aml_evalnode+0xe0 acpi_foundhid() at acpi_foundhid+0x29 aml_find_node() at aml_find_node+0x88 aml_find_node() at aml_find_node+0x7d aml_find_node() at aml_find_node+0x7d aml_find_node() at aml_find_node+0x7d aml_find_node() at aml_find_node+0x7d acpi_attach() at acpi_attach+0x4cc config_attach() at config_attach+0x11b bios_attach() at bios_attach+0xf3 config_attach() at config_attach+0x11b mainbus_attach() at mainbus_attach+0x5a config_attach() at config_attach+0x11b cpu_configure() at cpu_configure+0x1c main() at main+0x3b2 end trace frame: 0x0, count: -54 ddb ps PID PPID PGRPUID S FLAGS WAIT
problems building xenocara in 4.2 stable inside lndir'ed shadow directory when actual source is read only?
Hello, I try to keep one tree of stable source (on a NAS), and build releases for various architectures from that source tree. I've learned the hard way that the best(only) way to build a release is to create a shadow directory for the src using lndir, which makes symlinks to the target files in a new shadow directory tree. This works well for me. I then tried to build xenocara (installed as /usr/src/xenocara ), and ran into problems. On the first machine, I had the stable cvs update of the xenocara tree. I created the shadow directory tree, cd'ed into it, and did the makes per the FAQ. It worked fine. Then I build an X release, again using the instructions in the FAQ, so far so good. Then I copied the original xenocara source tree to my NAS. On a machine with a different architecture (i386 vs amd64), I then NFS mounted the xenocara source tree, and made another shadow source tree (using lndir) but this time the target files being shadowed where on the NAS, not a local disk). When I went to build xenocara, make bootstrap make obj worked OK, but make build failed, when it went into ./utils/macros it needed to write a file that was actually a symlink to my read-only source tree, and the make died. So, I believe there is a problem in the xenocara build process. In order to work around this problem, I copied my xenocara src tree to the local machine, and again built a shadow directory to it. This build works, because root can write to the local source directory, although IMHO, it really shouldn't need to. Don
Re: More questions on building a release with a read only source tree
On Mon, Feb 25, 2008 at 5:35 AM, Travers Buda [EMAIL PROTECTED] wrote:
Why on earth are you bothering with this? Please don't tell me
it's for security, because that would be inane.
I have a heterogeneous collection of machines on which I run OpenBSD,
both amd64 and i386.
I have separate build machines for each architecture.
I would vastly prefer to download the source once, put it on a local
NAS, and have each build machine build the release it needs.
In my experience, this doesn't work at all if the build processes
writes into the src tree itself, and historically I have had to keep a
virgin source tree, and copy to each build machine, which takes a
long time, and it is really kind of a pain to maintain the consistency
of 3 copies.
While choosing to avoid the use of the (inflammatory) word inane, I
find it curious that in following the proscribed procedure for
building a release, I have ALREADY built a new kernel for this
architecture (which is basically the first step before building
userland,
and then onto the release itself), (and in my case, I have already
built both the GENERIC and GENERIC.MP kernels), that the Makefile.inc
in /usr/src/etc/etc.amd64 goes ahead and does:
# $OpenBSD: Makefile.inc,v 1.7 2006/07/27 02:53:55 deraadt Exp $
.ifdef DESTDIR
snap_md: bsd bsd.mp bootblocks distrib
cp ${.CURDIR}/../sys/arch/amd64/compile/GENERIC/bsd \
${DESTDIR}/snapshot/bsd
cp ${.CURDIR}/../sys/arch/amd64/compile/GENERIC.MP/bsd \
${DESTDIR}/snapshot/bsd.mp
bsd:
cd ${.CURDIR}/../sys/arch/amd64/conf config GENERIC
cd ${.CURDIR}/../sys/arch/amd64/compile/GENERIC \
${MAKE} clean ${MAKE} depend exec ${MAKE}
bsd.mp:
cd ${.CURDIR}/../sys/arch/amd64/conf config GENERIC.MP
cd ${.CURDIR}/../sys/arch/amd64/compile/GENERIC.MP \
${MAKE} clean ${MAKE} depend exec ${MAKE}
bootblocks:
cp ${DESTDIR}/usr/mdec/pxeboot ${DESTDIR}/snapshot
cp ${DESTDIR}/usr/mdec/cdboot ${DESTDIR}/snapshot
cp ${DESTDIR}/usr/mdec/cdbr ${DESTDIR}/snapshot
.PHONY: bsd bsd.mp bootblocks
.endif # DESTDIR check
(I discovered this makefile AFTER I had sent my email last night)
Anyway, it looks like one possible solution to my question would be to
modify this file so that
the bsd and bsd.mp targets are either no-ops, or perform their make in
the previously generated kernel build directories,
and then to change the snap_md target to copy the resulting bsd files
out of these build directories, and not from the middle
of the source tree. Of course, I'll have to do this again for the the
comparable i386 Makefile.inc. It would be preferable if the makefile
would check an environment variable for the location of where it
should actually compile things (outside of the src tree!)
and do it there. If unset, the Makefile could continue to pollute the
source tree with its builds, if that is what you want.
Questions:
Is there any other way (a better way?) to do what I am looking for?
What other compiles does make release perform that involve writing
into the source tree?
Thanks!
Don
* Don Jackson [EMAIL PROTECTED] [2008-02-24 23:27:31]:
The FAQ describes two ways to build the kernel (
http://www.openbsd.org/faq/faq5.html#BldKernel ),
# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean make depend make
or
Variation on above process: Read-only source tree
Sometimes, you may wish to ensure your /usr/src/sys directory
remains untouched. This can be done by using the following process:
$ cd /somewhere
$ cp /usr/src/sys/arch/i386/conf/GENERIC .
$ config -s /usr/src/sys -b . GENERIC
$ make clean make depend make
I would like make release to use the read only source tree variant
above, how can I accomplish this?
Right now, I see make release do:
cd /home/4.2/src/etc/../sys/arch/amd64/conf config GENERIC
Which is going to attempt to build the GENERIC kernel right there in
my source tree.
Also, I am having some other weird problem, due to the following logic
in the Makefile.amd64 which contains:
# source tree is located via $S relative to the compilation directory
.ifndef S
S!= cd ../../../..; pwd
.endif
AMD64= $S/arch/amd64
For some reason the above is setting my AMD64 to some weird path that
is not correct on my system, namely:
cd /home/4.2/src/etc/../sys/arch/amd64/conf config GENERIC
GENERIC:13: cannot open ../../../../arch/amd64/conf/files.amd64
for reading: No such file or directory
*** Error code 1
Stop in /home/4.2/src/etc (line 11 of etc.amd64/Makefile.inc).
What is the point of the above, and how can I get the path correct for
this build?
Thanks,
Don
kernel naming proposal
OpenBSD kernel support on some architectures (I'm familiar with i386 and amd64) includes both a uniprocessor and multiprocessor version of the kernel. Currently the uniprocessor kernel is named bsd and the multiprocessor kernel is named bsd.mp It seems to me that /bsd is currently overloaded to mean the default kernel to run and the uniprocessor version of the kernel. I propose that by default, the uniprocessor version of the kernel be named bsd.up, and that the install process arrange to have /bsd link to /bsd.up by default. Users who wanted to run the mp kernel could arrange to change this link in their install process (eg their install.site script) I'm know a hard link would work fine, but a symbolic link (if that would work, I don't know) would be more convenient for some of us, when we build new versions of GENERIC and GENERIC.MP, the install process for each of these would just replace /bsd.up and /bsd.mp respectively, and a symbolic link from /bsd to our chosen version of the kernel would remain. Thank you in advance for considering this proposal. Best regards, Don
Re: More questions on building a release with a read only source tree
On Mon, Feb 25, 2008 at 7:31 AM, Marco Peereboom [EMAIL PROTECTED] wrote: You want to read lndir(1). This is extremely helpful advice, thank you! I used lndir to create an architecture specific copy of my source tree, and successfully built a release within it. So, this is one way to do what I requested, and is a successful workaround. After I built my release, I checked the arch specific src tree for files that were not symbolic links, using: find . -type f -print All resulting found files were in the ./sys/arch/`machine`/compile directory tree. This leads me to believe that only the compile directory needs to be written to by the make release process. I find it inconsistent and less than optimal that the build of userland pretty much requires the use of a seperate obj directory BSDOBJDIR, the src tree is defined in BSDSRCDIR, and the release and dest directories required by make release are defined as RELEASEDIR and DESTDIR, and all these directories can be defined in distinct separate areas, but that the compile directory used by make release cannot be similarly defined in an alternate location than its default location within BSDSRCDIR. So, I have a gentle request/proposal that the compile directory used by the make release process be specified in some new environment variable (BSDCOMPILEDIR ?), if defined, that location is used as the base for compiling GENERIC, GENERIC.MP, etc, and if undefined, the existing default behavior would be followed. I can imagine that the lndir solution works great (and maybe better) for a certain class of developers/builders/users (maybe people that are constantly building versions of CURRENT?), but I believe that the class of OpenBSD users that follow STABLE and need to support multiple architectures would benefit from this seemingly small and straightforward change to the make release process. The lndir solution works, but is not perfect (just read about some of the caveats in the lndir man page) when things start to diverge between the two subtrees. My proposal above would eliminate the issues created by having link trees back to the virgin source. Best regards, Don Jackson On Sun, Feb 24, 2008 at 11:27:31PM -0800, Don Jackson wrote: The FAQ describes two ways to build the kernel ( http://www.openbsd.org/faq/faq5.html#BldKernel ), # cd /usr/src/sys/arch/i386/conf # config GENERIC # cd ../compile/GENERIC # make clean make depend make or Variation on above process: Read-only source tree Sometimes, you may wish to ensure your /usr/src/sys directory remains untouched. This can be done by using the following process: $ cd /somewhere $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean make depend make I would like make release to use the read only source tree variant above, how can I accomplish this? Right now, I see make release do: cd /home/4.2/src/etc/../sys/arch/amd64/conf config GENERIC Which is going to attempt to build the GENERIC kernel right there in my source tree. Also, I am having some other weird problem, due to the following logic in the Makefile.amd64 which contains: # source tree is located via $S relative to the compilation directory .ifndef S S!= cd ../../../..; pwd .endif AMD64= $S/arch/amd64 For some reason the above is setting my AMD64 to some weird path that is not correct on my system, namely: cd /home/4.2/src/etc/../sys/arch/amd64/conf config GENERIC GENERIC:13: cannot open ../../../../arch/amd64/conf/files.amd64 for reading: No such file or directory *** Error code 1 Stop in /home/4.2/src/etc (line 11 of etc.amd64/Makefile.inc). What is the point of the above, and how can I get the path correct for this build? Thanks, Don
Re: kernel naming proposal
The issue is that when building and installing new kernels (eg, when a new security patch is released), it is not totally obvious to the (automated) build script what the file /bsd really is, is it the uniprocessor kernel, or a link to the multiprocessor kernel? If the latter, than blindly copying the new uniprocessor kenel to /bsd is probably not what you want to do. With my proposal, new kernels can be safely copied to /, since they have unique and distinct names. NB, I am NOT proposing different default behavior for installs. The uniprocessor kernel would be the one installed by default, the difference is that it would be named distinctly, and that /bsd would be some sort of link to the uniprocessor kernel. People can choose to install or not install the bsd.mp kernel, just as they do today, those who do can chose (or not) to change the link from /bsd to /bsd.mp . The only cost I currently see for my proposal is the cost of a link in /. At present, I see very little cost to my proposal, and reasonable benefit to some class of users. Perhaps someone on this list will come up with a really good reason why this a bad idea, but I haven't heard that reason yet. Best regards, Don On Mon, Feb 25, 2008 at 10:48 AM, Jay Hart [EMAIL PROTECTED] wrote: While I have no stake in this issue, I think as a user /bsd and /bsd.mp are fine. As a new user, I have to determine what the diff is between /bsd and /bsd.mp now, and if it was changed to /bsd.up and /bsd.mp, I'd still have to determine which was which. Am I missing something? Jay OpenBSD kernel support on some architectures (I'm familiar with i386 and amd64) includes both a uniprocessor and multiprocessor version of the kernel. Currently the uniprocessor kernel is named bsd and the multiprocessor kernel is named bsd.mp It seems to me that /bsd is currently overloaded to mean the default kernel to run and the uniprocessor version of the kernel. I propose that by default, the uniprocessor version of the kernel be named bsd.up, and that the install process arrange to have /bsd link to /bsd.up by default. Users who wanted to run the mp kernel could arrange to change this link in their install process (eg their install.site script) I'm know a hard link would work fine, but a symbolic link (if that would work, I don't know) would be more convenient for some of us, when we build new versions of GENERIC and GENERIC.MP, the install process for each of these would just replace /bsd.up and /bsd.mp respectively, and a symbolic link from /bsd to our chosen version of the kernel would remain. Thank you in advance for considering this proposal. Best regards, Don
Re: kernel naming proposal
Matt and Paul, Thank you for the information about boot.conf, using that will enable me to keep the uniprocessor and multiprocessor versions of the kernel distinct. I think I was led astray initially by this comment in Section 8.12 in the FAQ: A separate SMP kernel, bsd.mp, is provided with the install file sets, which can be selected at install time. It is suggested that you test booting this kernel before renaming it to bsd to make it your default kernel. See: http://www.openbsd.org/faq/faq8.html#SMP Perhaps the FAQ should be modified to tell people to change boot.conf instead of renaming the kernel files, to prevent others from overloading /bsd and the default kernel. Thanks for your help! Don On Mon, Feb 25, 2008 at 11:25 AM, Matthew Dempsky [EMAIL PROTECTED] wrote: On 2/25/08, Don Jackson [EMAIL PROTECTED] wrote: Users who wanted to run the mp kernel could arrange to change this link in their install process (eg their install.site script) Or you can just run echo set image bsd.mp /etc/boot.conf after installation.
Serial console questions on i386 and amd64
I use serial consoles on all my OpenBSD servers for remote serial access to the machines, both during initial install via pxeboot, and later on in regular use after the install. I'm currently running either 4.2 or 4.1 on all my machines. The FAQ states: Only the first serial port (com0) is supported for console on amd64 and i386 http://www.openbsd.org/faq/faq7.html#SerCon Why is this the case? Why does OpenBSD care which serial port I use? Will it simply not work if I specify set tty com1 in /etc/boot.conf ? I ask because my servers of choice are made by Rackable Systems, and their default configuration is to route the serial port known to as com1 to a special RJ-45 connector, that also supports BIOS redirection, and even serial access to power cycle the machine. Having my OpenBSD servers use that for the console would be ideal. FYI, my Solaris10/x86 servers happily use that port for the console, and there is no need to turn off Continue Console Redirection after POST, as also recommend in the OpenBSD FAQ: Some BIOSs have an option to Continue Console Redirection after POST (Power On Self Test), this should be set to OFF, so the boot loader and the kernel can handle their own console. I'd very much appreciate any insight into these questions. Best regards, Don
pxeboot and tftpd questions
I try and always install my new OpenBSD (i386 and amd64) machines using pxeboot.
I have the basic process down cold, but I am looking for a bit more
flexibility, hence these questions.
In my environment, I have a mix of i386 and amd64 machines, and it is
conceivable that I would want to install different versions of OpenBSD
on new installs.
On my dhcpd server, I might have something like this:
host obbamd42 {
hardware ethernet 00:e0:81:45:df:d4;
fixed-address 1.2.3.4;
filename pxeboot-amd64-4.2;
}
If I take care to specify the correct filename here, dhcpd will return
the correct pxeboot file for the OS version and architecture of the
machine in questions, so far so good!
The question/problem is how can I specify a different bsd.rd file for
different installs?
The filename to be booted is obtained by requesting /etc/boot.conf
from the tftpd server, so if I could return a different boot.conf file
for different requests, I could change the
boot line to make sure the correct boot file is then requested.
On the tftp server, in /var/tftpboot, I have an etc directory,
containing a boot.conf file, which looks something like:
# cat boot.conf
set tty com0
stty com0 9600
boot bsd.rd
I'd like for the file to boot to vary depending on which machine is
asking. How can I do that?
One way I can imagine is to modify the pxeboot file to request
different boot.conf files,
for example,
pxeboot-amd64-4.2 requests /etc/boot-4.2-amd.conf
pxeboot-i386-4.1 requests/etc/boot-4.1-i386.conf
etc. Or, maybe even more flexibly, the pxeboot program would
determine the MAC address of the machine on which it is running, and
request a specific boot.conf file, eg
/etc/boot-00e08145dfd4.conf
And ideally, if it couldn't find a file like this on the tftpd server,
it would then just request the normal boot.conf file (to preserve
existing behavior)
I've begun looking through the source code for pxeboot, and I haven't
yet found where it requests the boot.conf file.
Can anyone out there point me to the right file in the source tree to
do what I want?
Or, I am always open to other ideas as to how I can accomplish my goals here.
If there were a cgi option to tftpd where one could compute the
response to a request dynamically, that would be another way to go.
I'd appreciate any tips/pointers/advice.
Best regards,
Don
More questions on building a release with a read only source tree
The FAQ describes two ways to build the kernel ( http://www.openbsd.org/faq/faq5.html#BldKernel ), # cd /usr/src/sys/arch/i386/conf # config GENERIC # cd ../compile/GENERIC # make clean make depend make or Variation on above process: Read-only source tree Sometimes, you may wish to ensure your /usr/src/sys directory remains untouched. This can be done by using the following process: $ cd /somewhere $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean make depend make I would like make release to use the read only source tree variant above, how can I accomplish this? Right now, I see make release do: cd /home/4.2/src/etc/../sys/arch/amd64/conf config GENERIC Which is going to attempt to build the GENERIC kernel right there in my source tree. Also, I am having some other weird problem, due to the following logic in the Makefile.amd64 which contains: # source tree is located via $S relative to the compilation directory .ifndef S S!= cd ../../../..; pwd .endif AMD64= $S/arch/amd64 For some reason the above is setting my AMD64 to some weird path that is not correct on my system, namely: cd /home/4.2/src/etc/../sys/arch/amd64/conf config GENERIC GENERIC:13: cannot open ../../../../arch/amd64/conf/files.amd64 for reading: No such file or directory *** Error code 1 Stop in /home/4.2/src/etc (line 11 of etc.amd64/Makefile.inc). What is the point of the above, and how can I get the path correct for this build? Thanks, Don
Re: Performance problem with CF card on AMD CS5536 IDE
Here are some results using the Lexar Professional UDMA 300x CF drives. My favorite CF-IDE and CF-SATA converters are from Addonics http://www.addonics.com/products/flash_memory_reader/adidecf.asp Here are some typical boot messages from one of my servers with the Lexar/Addonics combo: wd0 at pciide1 channel 1 drive 0: LEXAR ATA FLASH CARD wd0: 1-sector PIO, LBA, 7631MB, 15630048 sectors wd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 2 I ran the same commands that others in this thread tried, here are my results: # dd if=/dev/zero of=nulls bs=65536 count=1600 1600+0 records in 1600+0 records out 104857600 bytes transferred in 65.142 secs (1609668 bytes/sec) # dd if=nulls of=/dev/null bs=65536 1600+0 records in 1600+0 records out 104857600 bytes transferred in 21.049 secs (4981460 bytes/sec) # dd if=nulls of=/dev/null bs=65536 1600+0 records in 1600+0 records out 104857600 bytes transferred in 0.051 secs (2036109439 bytes/sec) # dd if=nulls of=/dev/null bs=65536 1600+0 records in 1600+0 records out 104857600 bytes transferred in 0.051 secs (2044286745 bytes/sec) # uname -a OpenBSD svn01.clark-communications.com 4.2 GENERIC#0 amd64 # sysctl hw hw.machine=amd64 hw.model=Dual Core AMD Opteron(tm) Processor 275 HE hw.ncpu=1 hw.byteorder=1234 hw.physmem=4226789376 hw.usermem=4226785280 hw.pagesize=4096 hw.disknames=cd0,wd0,sd0 hw.diskcount=3 hw.sensors.admcts0.temp0=37.00 degC (Internal) hw.sensors.admcts0.temp1=46.00 degC (External) hw.sensors.admcts0.temp2=-90.00 degC (External) hw.sensors.admcts0.fan2=2647 RPM hw.sensors.admcts0.volt0=3.30 VDC (Vbat) hw.sensors.admcts0.volt1=3.32 VDC (3.3 V standby) hw.sensors.admcts0.volt2=3.30 VDC (3.3 V main) hw.sensors.admcts0.volt3=5.41 VDC (5 V) hw.sensors.admcts0.volt4=1.17 VDC (Vccp) hw.sensors.admcts0.volt5=12.06 VDC (12 V) hw.sensors.admcts0.volt6=-0.60 VDC (-12 V) hw.sensors.arc0.drive0=online (sd0), OK hw.cpuspeed=2205 hw.vendor=RIOWORKS hw.product=HDAMA hw.serialno=0123456789
How can I get alarms about my arc/Areca raid controller?
Hello, I have an Opteron machine running OpenBSD 4.2/amd64 I have an Areca ARC-1110 RAID controller in this machine. I'd like to be able to query or get notified of alarms on the raid controller, how can I do that? I can do: # bioctl -v -q sd0 sd0: Areca, ARC-1110-VOL#00, R001, serial 000591171972 # bioctl -a get arc0 alarm is currently enabled But if I try # bioctl -v -a silence arc0 bioctl: BIOCALARM: Input/output error What do I need to do to obtain the alarm state, and reset it if necessary? Thanks Here is my dmesg: # dmesg OpenBSD 4.2-stable (GENERIC) #0: Wed Oct 24 12:44:40 PDT 2007 [EMAIL PROTECTED] :/home/4.2/src/sys/arch/amd64/compile/GENERIC real mem = 4226789376 (4030MB) avail mem = 4093644800 (3904MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.34 @ 0xfbf7c000 (33 entries) bios0: vendor Phoenix Technologies Ltd. version V1.11 date 05/10/2006 bios0: RIOWORKS HDAMA acpi at mainbus0 not configured cpu0 at mainbus0: (uniprocessor) cpu0: Dual Core AMD Opteron(tm) Processor 275 HE, 2205.29 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: AMD erratum 89 present, BIOS upgrade may be required pci0 at mainbus0 bus 0: configuration mode 1 ppb0 at pci0 dev 6 function 0 AMD 8111 PCI-PCI rev 0x07 pci1 at ppb0 bus 1 ohci0 at pci1 dev 0 function 0 AMD 8111 USB rev 0x0b: irq 11, version 1.0, legacy support ohci1 at pci1 dev 0 function 1 AMD 8111 USB rev 0x0b: irq 11, version 1.0, legacy support vga1 at pci1 dev 6 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pciide0 at pci1 dev 7 function 0 CMD Technology SiI3114 SATA rev 0x02: DMA pciide0: using irq 5 for native-PCI interrupt usb0 at ohci0: USB revision 1.0 uhub0 at usb0: AMD OHCI root hub, rev 1.00/1.00, addr 1 usb1 at ohci1: USB revision 1.0 uhub1 at usb1: AMD OHCI root hub, rev 1.00/1.00, addr 1 pcib0 at pci0 dev 7 function 0 AMD 8111 LPC rev 0x05 pciide1 at pci0 dev 7 function 1 AMD 8111 IDE rev 0x03: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide1 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TEAC, CD-224E-N, 1.AA SCSI0 5/cdrom removable cd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 2 wd0 at pciide1 channel 1 drive 0: LEXAR ATA FLASH CARD wd0: 1-sector PIO, LBA, 7631MB, 15630048 sectors wd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 2 amdiic0 at pci0 dev 7 function 2 AMD 8111 SMBus rev 0x02: SCI iic0 at amdiic0 amdpm0 at pci0 dev 7 function 3 AMD 8111 Power rev 0x05: rng active iic1 at amdpm0 admcts0 at iic1 addr 0x2c ppb1 at pci0 dev 10 function 0 AMD 8131 PCIX rev 0x13 pci2 at ppb1 bus 2 bge0 at pci2 dev 3 function 0 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): irq 11, address 00:50:45:5f:13:ce brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci2 dev 3 function 1 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): irq 5, address 00:50:45:5f:13:cf brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 10 function 1 not configured ppb2 at pci0 dev 11 function 0 AMD 8131 PCIX rev 0x13 pci3 at ppb2 bus 3 ppb3 at pci3 dev 1 function 0 Intel IOP331 PCIX-PCIX rev 0x0a pci4 at ppb3 bus 4 arc0 at pci4 dev 14 function 0 Areca ARC-1110 rev 0x00: irq 11 arc0: 4 SATA Ports, 256MB SDRAM, FW Version: V1.43 2007-4-17 scsibus1 at arc0: 16 targets sd0 at scsibus1 targ 0 lun 0: Areca, ARC-1110-VOL#00, R001 SCSI3 0/direct fixed sd0: 476837MB, 56514 cyl, 36 head, 480 sec, 512 bytes/sec, 976562176 sec total AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 11 function 1 not configured pchb0 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb1 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb2 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb3 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console 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 lpt0 at isa0 port 0x378/4 irq 7 dkcsum: wd0 matches BIOS drive 0x80 dkcsum: sd0 matches BIOS drive 0x81 root on wd0a swap on wd0b dump on wd0b
Questions about bioctl and arc/Areca
Hello, I am have an Opteron machine running OpenBSD 4.2/amd64. This machine has an Areca AC-1110 raid controller. Among other things, I would like to either query or ideally be notified if the controller goes into alarm. How can I do that? I can do: # bioctl -v -q sd0 sd0: Areca, ARC-1110-VOL#00, R001, serial 000591171972 and # bioctl -a get arc0 alarm is currently enabled
Where/how can I set the flags for savecore during boot?
I'm running OpenBSD 4.2/amd64 on an Opteron machine.
I boot off of wd0, which is a flash disk.
I also have sd0, which I use for more frequently writable partitons (swap,
var, tmp, etc) (sdo is really a set of raid disks managed by an areca disk
controller)
Here is my /etc/fstab:
# more /etc/fstab
/dev/wd0a / ffs rw 1 1
/dev/wd0g /home ffs rw,nodev,nosuid 1 2
/dev/sd0f /home2 ffs rw,nodev,nosuid 1 2
/dev/sd0d /tmp ffs rw,nodev,nosuid 1 2
/dev/wd0e /usr ffs rw,nodev 1 2
/dev/sd0e /var ffs rw,nodev,nosuid 1 2
/dev/sd0b none swap sw 0 0
Note wd0b is not specified, and sd0b is.
When I boot the machine, I see:
root on wd0a swap on wd0b dump on wd0b
I guess the kernel devaults to wd0b for swap and dump?
Anyway, the next log line is:
swapctl: adding /dev/sd0b as swap device at priority 0
So that seems good, it is picking up the real swap space out of /etc/fstab
(after the machine boots, I run:
# swapctl -l
Device 512-blocks UsedAvail Capacity Priority
/dev/sd0b 84019320 8401932 0%0
so that seems consistent that the kernel is using sd0b for swap)
But later in the boot messages I see:
savecore: /dev/wd0b: Device not configured
Presumably this is because
rc.conf has:
savecore_flags= # -z to compress
and /etc/rc has:
if [ -d /var/crash ]; then
savecore ${savecore_flags} /var/crash
fi
So, how can fix it so savecore executes successfully in the rc script?
After the machine booted, I tried running
# savecore /dev/sd0b
savecore: /dev/wd0b: Device not configured
thinking that if I just specified the actual swap partition it would work,
but clearly it didn't.
How can I configure savecore to use the real swap partition on this system?
Don
Re: About Xen: maybe a reiterative question but ..
Just a bit more follow up on this topic: Kirk Ismay wrote: I don't think it would be appropriate to have Xen included with the stock OpenBSD kernel/distribution, due to both the security issues, and license issues (Xen is GPL). It may be better for the project to have Xen available as a port, Yes, I agree. Best not to burden the current OS ports with Xen support, but it would be great to have ports like i386-xen and/or amd64-xen available as well. It is not at all clear to me that the existance of a Xen port of OpenBSD would detract from the security or performance of the non-Xen ports of OpenBSD. You may recall I mentioned the Amazon EC2 compute cloud Xen-based service. Yesterday, Red Hat announced support for RH Enterprise Linux on Amazon's EC2: http://aws.typepad.com/aws/2007/11/red-hat-enterpr.html http://www.redhat.com/solutions/cloud/?intcmp=7016000HCbi This is interesting, RH is providing a consistent platform for premise-based, hosted, or cloud-based deployment of applications. I maintain that it would be a good thing if OpenBSD developers had similar deployment options. As a minor note, I also found this article to be in interesting introduction to Xen: http://www.acmqueue.org/modules.php?name=Contentpa=printer_friendlypid=443page=1 Best regards, Don On 10/25/07, Don Jackson [EMAIL PROTECTED] wrote: I wanted to add my 2 cents to this thread. Ignoring the debate/flamage on this thread regarding the security merits/risks of virtualization, I beleive there are a number of us who would like the option to run OpenBSD as a guest under various virtual machine frameworks. Even if it is less secure than dedicating a machine to the problem at hand. Like it or not, Xen is a very popular VM environment. (Granted, this may change if Citrix makes changes that people can't live with) One of the most interesting services supporting Xen is the Amazon EC2 service, where you can buy time on their cloud to run VMs. I'd like to be able to build/define/buy AMIs that are based on OpenBSD, and run them on the EC2 cloud. If my application ever needs dedicated hardware, I'll move to that, and I'd remove the VM layer, and I'd gain more security, and more performance. http://www.amazon.com/gp/browse.html?node=201590011 Today, one has no choice but to run Linux-based AMIs on EC2. It would be great if people could define and build OpenBSD 'software appliances' that could be deployed both standalone and virtualized. The ability to participate in VM ecosystems like EC2 would benefit the broader OpenBSD initative. So, if the changes to OpenBSD to support running under VM frameworks can be made without reducing the security/stability/performance of OpenBSD when it is NOT running under VM, and if these changes can be made with licensing terms that are consistent with the OpenBSD license (and acceptable to Theo), then I would really like to see this happen. Don
Issues with pkg_add wget on 4.2
In my install42.site file, I add several packages to a machine that I'll want later. In this case, I execute pkg_add wget, and here is the result: Installing package: wget ldconfig: /var/run/ld.so.hints: No such file or directory libiconv-1.9.2p3: complete Can't install gettext-0.14.6p0: lib not found expat.8.0 Dependencies for gettext-0.14.6p0 resolve to: libiconv-1.9.2p3 Full dependency tree is libiconv-1.9.2p3 Can't install wget-1.10.2p0: can't resolve gettext-0.14.6p0 Any ideas for a fix? Don
Re: About Xen: maybe a reiterative question but ..
I wanted to add my 2 cents to this thread. Ignoring the debate/flamage on this thread regarding the security merits/risks of virtualization, I beleive there are a number of us who would like the option to run OpenBSD as a guest under various virtual machine frameworks. Even if it is less secure than dedicating a machine to the problem at hand. Like it or not, Xen is a very popular VM environment. (Granted, this may change if Citrix makes changes that people can't live with) One of the most interesting services supporting Xen is the Amazon EC2 service, where you can buy time on their cloud to run VMs. I'd like to be able to build/define/buy AMIs that are based on OpenBSD, and run them on the EC2 cloud. If my application ever needs dedicated hardware, I'll move to that, and I'd remove the VM layer, and I'd gain more security, and more performance. http://www.amazon.com/gp/browse.html?node=201590011 Today, one has no choice but to run Linux-based AMIs on EC2. It would be great if people could define and build OpenBSD 'software appliances' that could be deployed both standalone and virtualized. The ability to participate in VM ecosystems like EC2 would benefit the broader OpenBSD initative. So, if the changes to OpenBSD to support running under VM frameworks can be made without reducing the security/stability/performance of OpenBSD when it is NOT running under VM, and if these changes can be made with licensing terms that are consistent with the OpenBSD license (and acceptable to Theo), then I would really like to see this happen. Don
SUMMARY: Still unable to get Cyclades Z serial ports working with OpenBSD
Hello, The OpenBSD web site states that Cyclades-Z series multiport serial cards are supported via the cz driver: Serial Ports Cyclades-Z series multiport serial boards (cz) (G) I am running OpenBSD 4.1 stable, on i386. I installed a Cyclades Ze PCI card, and hooked it up to the external 1U box. When my machine boots, I see: Cyclades Cyclom-Z rev 0x01 at pci1 dev 9 function 0 not configured Marco Hyman helpfully explained this because the driver is not part of the GENERIC kernel. So, I built a new kernel with cz support, and booted that, here is what the new boot looks like: Sep 4 21:15:18 log01 /bsd: cz0 at pci1 dev 9 function 0 Cyclades Cyclom-Z rev 0x01cz0: Cyclades-Ze, no channels at tached, firmware 3.3.1 Sep 4 21:15:18 log01 /bsd: cz0: polling mode, 20 ms interval (2 ticks) But I don't see any /dev/ttyZ?? ports. Marco explained I should make the correct devices, his research showed: The cz driver is in /sys/dev/pci/cz.c which hasn't been changed since 2003. Looking at that file I see that the cdev_decl uses the name cztty. Looking as /sys/arch/i386/conf.c I see cdev_tty_init(NCZ,cztty), /* 71: Cyclades-Z serial port */ in the cdevsw table. mknod(8) with character major device 71 will build your devices (on i386). You'll have to look at the conf.c for your architecture if it is not i386. /sys/dev/pci/cz.c says minor devices are 0-127 for the tty ports and 128-255 for the dialout (cua*) ports. Of course the actual number of ports depends upon what autoconf finds. So I wrote a script to generate the proper devices: mknod ttyZ00 c 71 0 mknod ttyZ15 c 71 15 mknod cuaZ00 c 71 128 ... mknod cuaZ16 c 71 143 So I did this, here is the result: # ls -l /dev/ttyZ?? /dev/cuaZ?? crw-r--r-- 1 root wheel 71, 128 Sep 25 12:40 /dev/cuaZ00 crw-r--r-- 1 root wheel 71, 129 Sep 25 12:40 /dev/cuaZ01 crw-r--r-- 1 root wheel 71, 130 Sep 25 12:40 /dev/cuaZ02 crw-r--r-- 1 root wheel 71, 131 Sep 25 12:40 /dev/cuaZ03 crw-r--r-- 1 root wheel 71, 132 Sep 25 12:40 /dev/cuaZ04 crw-r--r-- 1 root wheel 71, 133 Sep 25 12:40 /dev/cuaZ05 crw-r--r-- 1 root wheel 71, 134 Sep 25 12:40 /dev/cuaZ06 crw-r--r-- 1 root wheel 71, 135 Sep 25 12:40 /dev/cuaZ07 crw-r--r-- 1 root wheel 71, 136 Sep 25 12:40 /dev/cuaZ08 crw-r--r-- 1 root wheel 71, 137 Sep 25 12:40 /dev/cuaZ09 crw-r--r-- 1 root wheel 71, 138 Sep 25 12:40 /dev/cuaZ10 crw-r--r-- 1 root wheel 71, 139 Sep 25 12:40 /dev/cuaZ11 crw-r--r-- 1 root wheel 71, 140 Sep 25 12:40 /dev/cuaZ12 crw-r--r-- 1 root wheel 71, 141 Sep 25 12:40 /dev/cuaZ13 crw-r--r-- 1 root wheel 71, 142 Sep 25 12:40 /dev/cuaZ14 crw-r--r-- 1 root wheel 71, 143 Sep 25 12:40 /dev/cuaZ15 crw-r--r-- 1 root wheel 71, 0 Sep 25 12:40 /dev/ttyZ00 crw-r--r-- 1 root wheel 71, 1 Sep 25 12:41 /dev/ttyZ01 crw-r--r-- 1 root wheel 71, 2 Sep 25 12:40 /dev/ttyZ02 crw-r--r-- 1 root wheel 71, 3 Sep 25 12:40 /dev/ttyZ03 crw-r--r-- 1 root wheel 71, 4 Sep 25 12:40 /dev/ttyZ04 crw-r--r-- 1 root wheel 71, 5 Sep 25 12:40 /dev/ttyZ05 crw-r--r-- 1 root wheel 71, 6 Sep 25 12:40 /dev/ttyZ06 crw-r--r-- 1 root wheel 71, 7 Sep 25 12:40 /dev/ttyZ07 crw-r--r-- 1 root wheel 71, 8 Sep 25 12:40 /dev/ttyZ08 crw-r--r-- 1 root wheel 71, 9 Sep 25 12:40 /dev/ttyZ09 crw-r--r-- 1 root wheel 71, 10 Sep 25 12:40 /dev/ttyZ10 crw-r--r-- 1 root wheel 71, 11 Sep 25 12:40 /dev/ttyZ11 crw-r--r-- 1 root wheel 71, 12 Sep 25 12:40 /dev/ttyZ12 crw-r--r-- 1 root wheel 71, 13 Sep 25 12:40 /dev/ttyZ13 crw-r--r-- 1 root wheel 71, 14 Sep 25 12:40 /dev/ttyZ14 crw-r--r-- 1 root wheel 71, 15 Sep 25 12:40 /dev/ttyZ15 I attempted to use tip on these serial ports: I attempted to test by adding ttyZ00|Test port:\ :dv=/dev/ttyZ00:tc=direct:tc=unixhost: to /etc/remote, which I tried: # tip ttyZ00 /dev/ttyZ00: Device not configured link down I then emailed one of the authors of the cz driver, who stated: Sorry, I'm not an OpenBSD user or developer, so I can't really be of any help. I guess OpenBSD simply ported my code from NetBSD. So I've given up on getting this to work under OpenBSD. Is there another high density serial port solution that is supported by OpenBSD? Don
Re: How do I configure Cyclades Z serial ports with OpenBSD?
OK, thanks for the pointers! I rebuilt the kernel, uncommenting the cz driver. Installed the new kernel on that machine, rebooted. Now I get: Sep 4 21:15:18 log01 /bsd: cz0 at pci1 dev 9 function 0 Cyclades Cyclom-Z rev 0x01cz0: Cyclades-Ze, no channels at tached, firmware 3.3.1 Sep 4 21:15:18 log01 /bsd: cz0: polling mode, 20 ms interval (2 ticks) But I don't see any /dev/ttyZ?? ports. What do I do next? Thanks! Don On 9/2/07, Martin Reindl [EMAIL PROTECTED] wrote: Don Jackson [EMAIL PROTECTED] wrote: Hello, I am running OpenBSD 4.1 stable. I installed a Cyclades Ze PCI card, and hooked it up to the external 1U box. When my machine boots, I see: Cyclades Cyclom-Z rev 0x01 at pci1 dev 9 function 0 not configured So the OS/driver does see the card. How do I get from where I am to functioning /dev/ttyZ?? ports? Thank you in advance for any advice or pointers you can give me. Don Have a look at the cz(4) driver, you need to comment it out in GENERIC (preferably in -current).
Re: How to use (compact) flash cards with OpenBSD
I have gotten past all the problems I discussed in my original message to this list. On the AMD/Tyan motherboard with the Addonics CF to SATA converter, what I did was purchase a Lexar Professional UDMA 300X CF card. This card is faster, and provides the UDMA interface that the motherboard and the OS likes to use. I changed the cabling so that the flash card was the first disk (wd0 to OpenBSD), and I moved the SATA hard drive to wd1. For this first attempt, I put swap, /tmp, and /var onto partitions on wd1. wd0 (the flash), has /, /usr, and /home I was able to cleanly install OpenBSD and boot into it. It appears to work fine. I do get an error from savecore that wants to use wd0b, and I'll have to tweak that. On an older i386 machine, I used another CF (actually it provides a PCMCIA) to IDE adaptor made by http://www.prestico.com/prod-cardmaster.htm I used the Sandisk drive I wrote about previously. The sandisk CF card does not support UDMA. Again, made the CF card be wd0, and the hard drive be wd1, the partitions were as described above. Again, no problems installing OpenBSD, and running it. Thanks to Nick Holland for suggesting making the flash card be wd0, and inspiring me to go try and find a UDMA CF card. And appologies to Nick and everyone for the poorly worded subject line on my original message. Don On 7/30/07, Don Jackson [EMAIL PROTECTED] wrote: I have a Tyan S2881 Thunder K8SR motherboard (Opteron), and wd0 is a SATA hard disk (Western Digital), but I want to boot and run off a flash card. I have an Addonics SATA to CF adaptor, Model ADSACF) http://www.addonics.com/products/flash_memory_reader/adsacf.asp The OpenBSD 4.1 installer (booted via PXEboot) seems to have a LOT of trouble with the flash drive (recognized as WD1). How can I make OpenBSD happy with this drive? The actual CF card is a SanDisk Ultra II 8Gb. I had zero problems installing and using a similar SanDisk card in a Soekris 4801, so I know that it must be possible to make this work. How do I make OpenBSD happy with the flash disk? Do I need special BIOS settings? I had very similar problems with another IDE - Flash adaptor in a Pentium machine. Here is the log from the installer: Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.1-stable (RAMDISK_CD) #1: Sun May 27 13:25:48 PDT 2007 [EMAIL PROTECTED]:/home/openbsd/4.1/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Dual Core AMD Opteron(tm) Processor 270 (AuthenticAMD 686-class, 1024KB L2 cache) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3 cpu0: AMD erratum 89 present, BIOS upgrade may be required real mem = 2146988032 (2096668K) avail mem = 1953828864 (1908036K) using 4278 buffers containing 107474944 bytes (104956K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+ BIOS, date 05/23/06, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.3 @ 0xf9830 (63 entries) bios0: TYAN S2881 Thunder K8SR Mainboard apm0 at bios0: Power Management spec V1.2 apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4d30/208 (11 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x746b pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x4800 0xcc800/0x1800 0xce000/0x1800 0xcf800/0x1000 acpi at mainbus0 not configured cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) ppb0 at pci0 dev 6 function 0 AMD 8111 PCI-PCI rev 0x07 pci1 at ppb0 bus 3 ohci0 at pci1 dev 0 function 0 AMD 8111 USB rev 0x0b: irq 9, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1 at pci1 dev 0 function 1 AMD 8111 USB rev 0x0b: irq 9, version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pciide0 at pci1 dev 5 function 0 CMD Technology SiI3114 SATA rev 0x02: DMA pciide0: using irq 10 for native-PCI interrupt pciide0: port 0: device present, speed: 1.5Gb/s wd0 at pciide0 channel 0 drive 0: WDC WD2500YS-01SHB0 wd0: 16-sector PIO, LBA48, 239372MB, 490234752 sectors wd0(pciide0:0:0): using BIOS timings, Ultra-DMA mode 6 pciide0: port 1: device present, speed: 1.5Gb/s wd1 at pciide0 channel 1 drive 0: SanDisk SDCFH-8192 wd1: 4-sector PIO, LBA, 7815MB, 16007040 sectors wd1(pciide0:1:0): using BIOS timings, DMA mode 2 vga1 at pci1 dev 6 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) pcib0 at pci0
How do I configure Cyclades Z serial ports with OpenBSD?
Hello, I am running OpenBSD 4.1 stable. I installed a Cyclades Ze PCI card, and hooked it up to the external 1U box. When my machine boots, I see: Cyclades Cyclom-Z rev 0x01 at pci1 dev 9 function 0 not configured So the OS/driver does see the card. How do I get from where I am to functioning /dev/ttyZ?? ports? Thank you in advance for any advice or pointers you can give me. Don
How to use (compact) flash cards with OpenBSD
I have a Tyan S2881 Thunder K8SR motherboard (Opteron), and wd0 is a SATA hard disk (Western Digital), but I want to boot and run off a flash card. I have an Addonics SATA to CF adaptor, Model ADSACF) http://www.addonics.com/products/flash_memory_reader/adsacf.asp The OpenBSD 4.1 installer (booted via PXEboot) seems to have a LOT of trouble with the flash drive (recognized as WD1). How can I make OpenBSD happy with this drive? The actual CF card is a SanDisk Ultra II 8Gb. I had zero problems installing and using a similar SanDisk card in a Soekris 4801, so I know that it must be possible to make this work. How do I make OpenBSD happy with the flash disk? Do I need special BIOS settings? I had very similar problems with another IDE - Flash adaptor in a Pentium machine. Here is the log from the installer: Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.1-stable (RAMDISK_CD) #1: Sun May 27 13:25:48 PDT 2007 [EMAIL PROTECTED]:/home/openbsd/4.1/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Dual Core AMD Opteron(tm) Processor 270 (AuthenticAMD 686-class, 1024KB L2 cache) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3 cpu0: AMD erratum 89 present, BIOS upgrade may be required real mem = 2146988032 (2096668K) avail mem = 1953828864 (1908036K) using 4278 buffers containing 107474944 bytes (104956K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+ BIOS, date 05/23/06, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.3 @ 0xf9830 (63 entries) bios0: TYAN S2881 Thunder K8SR Mainboard apm0 at bios0: Power Management spec V1.2 apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4d30/208 (11 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x746b pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x4800 0xcc800/0x1800 0xce000/0x1800 0xcf800/0x1000 acpi at mainbus0 not configured cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) ppb0 at pci0 dev 6 function 0 AMD 8111 PCI-PCI rev 0x07 pci1 at ppb0 bus 3 ohci0 at pci1 dev 0 function 0 AMD 8111 USB rev 0x0b: irq 9, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1 at pci1 dev 0 function 1 AMD 8111 USB rev 0x0b: irq 9, version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pciide0 at pci1 dev 5 function 0 CMD Technology SiI3114 SATA rev 0x02: DMA pciide0: using irq 10 for native-PCI interrupt pciide0: port 0: device present, speed: 1.5Gb/s wd0 at pciide0 channel 0 drive 0: WDC WD2500YS-01SHB0 wd0: 16-sector PIO, LBA48, 239372MB, 490234752 sectors wd0(pciide0:0:0): using BIOS timings, Ultra-DMA mode 6 pciide0: port 1: device present, speed: 1.5Gb/s wd1 at pciide0 channel 1 drive 0: SanDisk SDCFH-8192 wd1: 4-sector PIO, LBA, 7815MB, 16007040 sectors wd1(pciide0:1:0): using BIOS timings, DMA mode 2 vga1 at pci1 dev 6 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) pcib0 at pci0 dev 7 function 0 AMD 8111 LPC rev 0x05 pciide1 at pci0 dev 7 function 1 AMD 8111 IDE rev 0x03: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide1: channel 0 disabled (no drives) pciide1: channel 1 disabled (no drives) AMD 8111 SMBus rev 0x02 at pci0 dev 7 function 2 not configured AMD 8111 Power rev 0x05 at pci0 dev 7 function 3 not configured ppb1 at pci0 dev 10 function 0 AMD 8131 PCIX rev 0x12 pci2 at ppb1 bus 2 bge0 at pci2 dev 9 function 0 Broadcom BCM5704C rev 0x03, BCM5704 A3 (0x2003): irq 5, address 00:e0:81:45:de:28 brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci2 dev 9 function 1 Broadcom BCM5704C rev 0x03, BCM5704 A3 (0x2003): irq 10, address 00:e0:81:45:de:29 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 10 function 1 not configured ppb2 at pci0 dev 11 function 0 AMD 8131 PCIX rev 0x12 pci3 at ppb2 bus 1 AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 11 function 1 not configured pchb0 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb1 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb2 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb3 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 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 npx0
How can I build a release without writing into the /usr/src tree?
Hello, I try to studiously follow the STABLE branch. I carefully follow the directions in the FAQ. When I build my new kernel, I use the alternate instructions: Variation on above process: Read-only source tree Sometimes, you may wish to ensure your /usr/src/sys directory remains untouched. This can be done by using the following process: $ cd /somewhere $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean make depend make ... lots of output ... After building my new kernel, I reboot, build userland, reboot, and then go to build a release. In the build process for a release ( make release ), at some point, here is what happens: cd /home/openbsd/4.1/src/etc/../sys/arch/amd64/conf config GENERIC config: cannot create ../compile/GENERIC: Permission denied *** Error code 2 Stop in /home/openbsd/4.1/src/etc (line 11 of etc.amd64/Makefile.inc). (FYI, /usr/src - /home/openbsd/4.1/src ) Looks like make release is trying to build a new kernel in my /usr/src tree. 1) Is there a way to get make release to NOT build a new kernel inside my source tree? 2) Actually, I have already built a GENERIC kernel anyway, it would be very nice if make release would be able to figure that out, and just use the already built GENERIC kernel. I understand it will still need to build bsd.mp, bsd.rd, etc., but hopefully it would build those outside the source tree also. Don
How can I build a release without writing into the /usr/src tree?
Hello, I try to studiously follow the STABLE branch. I carefully follow the directions in the FAQ. When I build my new kernel, I use the alternate instructions: Variation on above process: Read-only source tree Sometimes, you may wish to ensure your /usr/src/sys directory remains untouched. This can be done by using the following process: $ cd /somewhere $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean make depend make ... lots of output ... After building my new kernel, I reboot, build userland, reboot, and then go to build a release. In the build process for a release ( make release ), at some point, here is what happens: cd /home/openbsd/4.1/src/etc/../sys/arch/amd64/conf config GENERIC config: cannot create ../compile/GENERIC: Permission denied *** Error code 2 Stop in /home/openbsd/4.1/src/etc (line 11 of etc.amd64/Makefile.inc). (FYI, /usr/src - /home/openbsd/4.1/src ) Looks like make release is trying to build a new kernel in my /usr/src tree. 1) Is there a way to get make release to NOT build a new kernel inside my source tree? 2) Actually, I have already built a GENERIC kernel anyway, it would be very nice if make release would be able to figure that out, and just use the already built GENERIC kernel. I understand it will still need to build bsd.mp, bsd.rd, etc., but hopefully it would build those outside the source tree also. Don
