configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
... using the GENERIC kernel ... I'll answer because I floated a poorly framed question like this one earlier. The second part of my answer is probably more useful. 1) A lot of thought and planning goes into the GENERIC kernel and the final arrangement is a source of pride. So if it's matter of trusting the code then it is still possible, if you have the time, resources or skill, to do your own code audit and still have a GENERIC kernel. Staying with the GENERIC configuration allows your feedback regarding kernel function to contribute to the activities and functions being focused on in the project. Deviating from the GENERIC configuration means that the trouble of sorting out your problems from those of the GENERIC configuration is too much trouble, and you are on your own. However ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. See the section kernel modification in config(8) for more info: http://www.openbsd.org/cgi-bin/man.cgi?query=config Regards, -Lars
Re: amd64 -current kernel hang
rd == RD Thrush [EMAIL PROTECTED] writes:
rd I have experienced kernel hangs w/ -current snapshots on Athlon 64 X2
rd and Sempron boxes. Both GENERIC and GENERIC.MP snapshots exhibit the
rd hang. Once hung, the boxes don't respond to pings; however, keyboard
rd LEDs toggle as expected and I can enter ddb from the keyboard.
rd kernel/5777 [1] has the full problem report including dmesgs and ddb
rd logs. The hang is reproducible by building the eclipse-sdk port.
rd This problem has developed fairly recently (within the past month or
rd so).
rd A similar box (w/ Opteron 165) runs -current i386 GENERIC.MP snapshots
rd and is able to do the same port builds without hanging. It seems the
rd forementioned kernel hang doesn't affect the i386 variant.
rd I would be happy to provide additional information that would help
rd analyze and resolve the problem.
rd [1]
http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yestextonly=yesnumbers=5777
I've now had the kernel hang occur on 3 different amd64 boxes. (no
ping response. top freezes. Only kb LEDs work. ddb can be entered
from the keyboard.)
Unfortunately, this last hang occured on a box without a serial port
so I have no ddb info to add to the above problem report. I do have
crash dumps from this last hang.
The hang is reproducible by building the eclipse-sdk port on -current.
It does appear to require enough memory load to swap. On this last
box, it wouldn't hang until I artificially added another 750MB load
(see below).
From the associated ddb ps listings (several sessions), I see several
processes WAITing on flt_noram[135]. Amongst those sessions, javadoc
usually shows up WAITing on flt_noram5. I have no idea whether that
is relevant to the hang but it does seem to form a pattern.
I'd appreciate help to further analyze the problem report and correct
the problem.
FWIW, it seems odd that no other reports of (or replies about)
this problem have occurred. Are my 3 boxes the only ones that hang?
Here's the simpleminded memory loader:
perl -e '$n=1024*1024;for($i=0;$i750;$i++) { $mem[$i]=z x $n; }; ;'
As previously mentioned, kernel/5777 contains the full report
including dmesgs. I've appended the 3 dmesgs here as well.
### X2 #
OpenBSD 4.3-current (GENERIC.MP) #1589: Sat Mar 22 02:24:49 MDT 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1060524032 (1011MB)
avail mem = 1029472256 (981MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0530 (67 entries)
bios0: vendor American Megatrends Inc. version 0221 date 12/06/2005
bios0: ASUSTeK Computer Inc. A8V
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC OEMB
acpi0: wakeup devices PCI0(S4) PS2K(S4) PS2M(S4) UAR1(S4) AC97(S4) USB1(S4)
USB2(S4) USB3(S4) USB4(S4) EHCI(S4) PWRB(S4) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2002.89 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2002.56 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
ioapic0 at mainbus0 apid 2 pa 0xfec0, version 3, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
cpu0: Cool'n'Quiet K8 2002 MHz: speeds: 2000 1800 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0 VIA K8HTB Host rev 0x00
pchb1 at pci0 dev 0 function 1 VIA K8HTB Host rev 0x00
pchb2 at pci0 dev 0 function 2 VIA K8HTB Host rev 0x00
pchb3 at pci0 dev 0 function 3 VIA K8HTB Host rev 0x00
pchb4 at pci0 dev 0 function 4 VIA K8HTB Host rev 0x00
pchb5 at pci0 dev 0 function 7 VIA K8HTB Host rev 0x00
ppb0 at pci0 dev 1 function 0 VIA K8HTB AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 ATI Radeon 9200 PRO rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
agp at vga1 not configured
ATI Radeon 9200 PRO Sec rev 0x01 at pci1 dev 0 function 1 not configured
skc0 at pci0 dev 10 function 0
Re: OT: Wireframe Puffy 3D model for Lego's
On Sun, Mar 9, 2008 at 11:56 PM, Daniel Ouellet [EMAIL PROTECTED] wrote: Daniel Anderson wrote: If nobody responds to this with a quality file, I will gladly make a 2D version of it as an SVG for you and all of us. I will wait a few days, may be someone might have something or not. I can't say yet. No reply other then yours yet. Anything would be mostly appreciated by my Sun and it would be much welcome. I always told my Sun that you need not to have a weak heart to be on this list, but great reply always come in time when needed and available. My Sun asked me if an MLCad was available. I asked him, what's MLCad? He spend hours explaining to me how this works and it's special for Lego's and help a lots for it. So, we spend good times having fun. I sure don't expect to have such a file as it would the up most gift to get, but anything to start with that provide some perspective would sure be welcome and I guess in time, he may finish the MLCad and make it available with the Lego kit too. (; This is obviously way remote form OpenBSD, other then just Puffy, so I don't want to take any ore time for anyone. Just if you have something I would welcome getting it, or being pointed in the right direction. It's hard to work from the image itself. In any case, your offer is very much appreciated and I thank you too. Best, Daniel Has he replied to this? I haven't been able to contact him off list, the mail keeps failing. TIA!
Re: OpenBSD Memory Sniffer Protection
No I thought I was already registered to misc when I sent that and then noticed that it didn't post. So I registered thinking that first message would never post and sent another. Steve Shockley [EMAIL PROTECTED] wrote:Your message at 9:00 wasn't enough, so you sent another one at 9:22? If someone can kick your machine, your choice of OS doesn't matter. - Looking for last minute shopping deals? Find them fast with Yahoo! Search.
About Squid port for OpenBSD 4.2
Hi,
i'm trying to recompile SQUID 2.6-STABLE13 port for OpenBSD 4.2
with LDAP auth helpers and ldap_group helpers support and get errors
during the compilation. This is what i modified in the Makefile:
...
CONFIGURE_ARGS+=--datadir=${PREFIX}/share/squid \
--enable-auth=basic digest \
--enable-arp-acl \
--enable-basic-auth-helpers=NCSA YP LDAP \
--enable-digest-auth-helpers=password \
--enable-external-acl-helpers=ip_user unix_group
ldap_group \
--enable-removal-policies=lru heap \
--enable-ssl \
--enable-storeio=ufs diskd null \
--localstatedir=${SQUIDDIR}
...
i precise that i have installed openldap-client package before to get
the ldap libraries and this is what i get when building Squid:
# make
Making all in LDAP
if cc -DHAVE_CONFIG_H -I.
-I/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP
-I../../../include
-I/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/include -O2
-pipe -MT squid_ldap_auth.o -MD -MP -MF .deps/squid_ldap_auth.Tpo -c
-o squid_ldap_auth.o
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c;
then mv -f .deps/squid_ldap_auth.Tpo .deps/squid_ldap_auth.Po; else
rm -f .deps/squid_ldap_auth.Tpo; exit 1; fi
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:121:18:
lber.h: No such file or directory
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:122:18:
ldap.h: No such file or directory
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:135:
error: `LDAP_SCOPE_SUBTREE' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:139:
error: `LDAP_DEREF_NEVER' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:145:
error: `LDAP_NO_LIMIT' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:152:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:206:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_errno':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: (Each undeclared identifier is reported only once
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: for each function it appears in.)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:211:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_set_aliasderef':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:213:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:213:
error: `deref' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:216:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_set_referrals':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:218:
error: `referrals' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:219:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:219:
error: `LDAP_OPT_REFERRALS' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:224:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_set_timelimit':
Re: OpenBSD Memory Sniffer Protection
Michael Seney [EMAIL PROTECTED] writes: No I thought I was already registered to misc when I sent that and then noticed that it didn't post. So I registered thinking that first message would never post and sent another. What you're describing is most likely just normal greylisting behavior. If your IP address (or that of your outgoing SMTP box) hasn't sent mail to the server that hosts misc@ for a while, there will be an initial delay equal to minwait plus whatever random factors determine sender's retry interval. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 11:00:01AM +0200, Lars Nood??n wrote: ... using the GENERIC kernel ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. Doug.
Re: RAMdisk, not for boot, how?
On Fri, Mar 28, 2008 at 01:21:55PM +1100, Rod Whitworth wrote: On Fri, 28 Mar 2008 02:51:33 +0100, chefren wrote: On 3/28/08 1:20 AM, Rod Whitworth wrote: The CF wearout meme needs to die. Specs, it's all about specs, it seems a fact to me that standard CF cards, as used in camera's, often without any technical specification other than size, cannot be written as often as ordinary harddisks. [snip brand examples] I have lost cout of failed HDDs around here and never lost a byte on CF. There are nearly as many CFs here as HDDs now and if you have a look at new laptops you'll see more and more SSHD and hybrids every time a new model comes out. Practically speaking if you buy a decent brand of CF or spend the extra on an industrial model you can expect years of service out of it. I'm sure that Bamboo Charlie makes cheapies in CF as well as mobos and other junk, don't buy from him I have my old IBM ValuePoint 486 that has a bios that really only likes drives under 512 MB. It has worked with one 8 GB drive, but not another seemingly identical WD 8 GB drive, yet alone a new-off-the-shelf 80 GB PATA drive. The IBM bios has no adjustability (as does the Award bios), but instead just displays the size of the hard drive found. If it displays a size, it will boot from it, if not, it declares a hardware error and won't boot from anything. I wonder if a 512 MB CF card in a PATA-CF adapter would be a solution in this case. The box would likely do remote-logging anyway. Does a CF card in a PATA-CF adapter look just like a HD, bootable and all, to old BIOS? Doug.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 12:58:40PM -0400, Douglas A. Tutty wrote: On Sat, Mar 29, 2008 at 11:00:01AM +0200, Lars Nood??n wrote: ... using the GENERIC kernel ... 2) One thing that may not be visible enough is that config(8) can be used to modify kernel parameters without needing to recompile. That gives you a fair amount of customization without deviating from the GENERIC configuration. It is possible to make modifications to the currently running kernel as well as to save these changes in the form of a new kernel binary so that the changes stay even after system restarts. One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Guest_tcecrystaldemon, verify your e-mail with IMVU and get 500 credits!
Hi tcecrystaldemon, Click here to verify your email address with IMVU!If you did not sign up for IMVU, ignore this email. We will not continue tosend mail to unverified addresses.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Jacob Meuser wrote: if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. That's for him to decide, not you. It's his machine, and it might be a fairly good one at that, despite being small or old. If you do not know the answer to the question, it is acceptable to be quiet. My machines have more than enough RAM, but what he brings up is an interesting question: does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? I'll have to schedule time to try two kernels, one with more deactivated, and compare their resource usage. The deactivation via config(8) definitely speeds up the boot process significantly on the slow units. Regards, -Lars
Re: About Squid port for OpenBSD 4.2
Hi,
I guess you didn't install openldap-client package?
Rosen
ComC(te wrote:
Hi,
i'm trying to recompile SQUID 2.6-STABLE13 port for OpenBSD 4.2
with LDAP auth helpers and ldap_group helpers support and get errors
during the compilation. This is what i modified in the Makefile:
...
CONFIGURE_ARGS+=--datadir=${PREFIX}/share/squid \
--enable-auth=basic digest \
--enable-arp-acl \
--enable-basic-auth-helpers=NCSA YP LDAP \
--enable-digest-auth-helpers=password \
--enable-external-acl-helpers=ip_user unix_group
ldap_group \
--enable-removal-policies=lru heap \
--enable-ssl \
--enable-storeio=ufs diskd null \
--localstatedir=${SQUIDDIR}
...
i precise that i have installed openldap-client package before to get
the ldap libraries and this is what i get when building Squid:
# make
Making all in LDAP
if cc -DHAVE_CONFIG_H -I.
-I/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP
-I../../../include
-I/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/include -O2
-pipe -MT squid_ldap_auth.o -MD -MP -MF .deps/squid_ldap_auth.Tpo -c
-o squid_ldap_auth.o
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c;
then mv -f .deps/squid_ldap_auth.Tpo .deps/squid_ldap_auth.Po; else
rm -f .deps/squid_ldap_auth.Tpo; exit 1; fi
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:121:18:
lber.h: No such file or directory
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:122:18:
ldap.h: No such file or directory
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:135:
error: `LDAP_SCOPE_SUBTREE' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:139:
error: `LDAP_DEREF_NEVER' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:145:
error: `LDAP_NO_LIMIT' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:152:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:206:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_errno':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: (Each undeclared identifier is reported only once
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: for each function it appears in.)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:211:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_set_aliasderef':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:213:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:213:
error: `deref' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:216:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_set_referrals':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:218:
error: `referrals' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:219:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:219:
error: `LDAP_OPT_REFERRALS' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:224:
error: syntax error before '*' token
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 09:52:48PM +0200, Lars Nood?n wrote: Jacob Meuser wrote: if your machine is low enough on ram that you would even consider recompiling a kernel, just to save ram, it's time to retire the machine. That's for him to decide, not you. well no fucking shit, Lars. it was a suggestion. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: RAMdisk, not for boot, how?
On 2008-03-29, Douglas A. Tutty [EMAIL PROTECTED] wrote: I have my old IBM ValuePoint 486 that has a bios that really only likes drives under 512 MB. It has worked with one 8 GB drive, but not another seemingly identical WD 8 GB drive, yet alone a new-off-the-shelf 80 GB PATA drive. The IBM bios has no adjustability (as does the Award bios), but instead just displays the size of the hard drive found. If it displays a size, it will boot from it, if not, it declares a hardware error and won't boot from anything. I wonder if a 512 MB CF card in a PATA-CF adapter would be a solution in this case. The box would likely do remote-logging anyway. Does a CF card in a PATA-CF adapter look just like a HD, bootable and all, to old BIOS? Yes, totally. I think this has a fairly good chance of success. Only thing I've found that refuses to boot from CF in a converter so far is my X40 (if anyone has any tips on that, please send them my way :-)
AUDIO-VIZUELNA METODA UCENJA ENGLESKOG JEZIKA na 10 CD-a
- This mail is a HTML mail. Not all elements could be shown in plain text mode. - AUDIO-VIZUELNA METODA UCENJA ENGLESKOG JEZIKA na 10 CD-a Multilingua Press-England Detaljnije informacije na www.engleski.9f.com Srdacan pozdrav :Saska Radic ::tel.0649588214: :::e-mail: [EMAIL PROTECTED]
Re: RAMdisk, not for boot, how?
On Sat, 29 Mar 2008 13:29:41 -0400, Douglas A. Tutty wrote: I have my old IBM ValuePoint 486 that has a bios that really only likes drives under 512 MB. It has worked with one 8 GB drive, but not another seemingly identical WD 8 GB drive, yet alone a new-off-the-shelf 80 GB PATA drive. The IBM bios has no adjustability (as does the Award bios), but instead just displays the size of the hard drive found. If it displays a size, it will boot from it, if not, it declares a hardware error and won't boot from anything. I wonder if a 512 MB CF card in a PATA-CF adapter would be a solution in this case. The box would likely do remote-logging anyway. Does a CF card in a PATA-CF adapter look just like a HD, bootable and all, to old BIOS? The one I use does. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sat, Mar 29, 2008 at 08:54:05PM +, Jacob Meuser wrote: well no fucking shit, Lars. Now that's something I'd rather not do... :) it was a suggestion.
Ethernet on ASUS EEE PC?
As opposed to previous mention that the Ethernet interface is correctly identified on a 28 Jan -current snapshot: http://marc.info/?l=openbsd-miscm=120177549104133w=2 ...the behaviour I'm seeing from the 25 Mar snapshot is similar to the following: http://marc.info/?l=openbsd-miscm=120185685618399w=2 http://marc.info/?l=openbsd-miscm=119802047918588w=2 Perhap different hardware revisions are being employed by ASUS. I'm using a EEE PC 4G Surf. My dmesg follows. Any suggestions or requests are welcomed. Jim ==8 OpenBSD 4.3-current (GENERIC) #723: Mon Mar 24 18:23:49 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(R) M processor 900MHz (GenuineIntel 686-class) 631 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF real mem = 2138140672 (2039MB) avail mem = 2059415552 (1964MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 01/04/08, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xf06c0 (37 entries) bios0: vendor American Megatrends Inc. version 0703 date 01/04/2008 bios0: ASUSTeK Computer INC. 701 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 3.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf76b0/176 (9 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801FB LPC rev 0x00) pcibios0: PCI bus #5 is the last bus bios0: ROM list: 0xc/0xf800! 0xcf800/0x1000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82915GM Host rev 0x04 vga1 at pci0 dev 2 function 0 Intel 82915GM Video rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) agp0 at vga1: aperture at 0xd000, size 0x1000 Intel 82915GM Video rev 0x04 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801FB HD Audio rev 0x04: irq 5 azalia0: codec[s]: Realtek/0x0662 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801FB PCIE rev 0x04: irq 5 pci1 at ppb0 bus 4 ppb1 at pci0 dev 28 function 1 Intel 82801FB PCIE rev 0x04: irq 11 pci2 at ppb1 bus 3 Attansic Technology L2 rev 0xa0 at pci2 dev 0 function 0 not configured ppb2 at pci0 dev 28 function 2 Intel 82801FB PCIE rev 0x04: irq 10 pci3 at ppb2 bus 1 uhci0 at pci0 dev 29 function 0 Intel 82801FB USB rev 0x04: irq 7 uhci1 at pci0 dev 29 function 1 Intel 82801FB USB rev 0x04: irq 3 uhci2 at pci0 dev 29 function 2 Intel 82801FB USB rev 0x04: irq 10 uhci3 at pci0 dev 29 function 3 Intel 82801FB USB rev 0x04: irq 5 ppb3 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xd4 pci4 at ppb3 bus 5 ichpcib0 at pci0 dev 31 function 0 Intel 82801FBM LPC rev 0x04: PM disabled pciide0 at pci0 dev 31 function 2 Intel 82801FBM SATA rev 0x04: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 1 drive 0: SILICONMOTION SM223AC wd0: 1-sector PIO, LBA, 3815MB, 7815024 sectors wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 ichiic0 at pci0 dev 31 function 3 Intel 82801FB SMBus rev 0x04: irq 3 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 biomask e7fd netmask e7fd ttymask mtrr: Pentium Pro MTRR support umass0 at uhub2 port 1 configuration 1 interface 0 ENE UB6225 rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets sd0 at scsibus0 targ 1 lun 0: USB2.0, CardReader SD0, 0100 SCSI0 0/direct removable sd0: drive offline softraid0 at root root on wd0a swap on wd0b dump on wd0b WARNING: / was not properly unmounted uhub4 at uhub0 port 2 Prolific Technology Inc. USB Embedded Hub rev 2.00/1.00 addr 2 umass1 at uhub4 port 1 configuration 1 interface 0 Prolific Technology Inc. USB Mass Storage Device rev 2.00/1.00 addr 3 umass1: using ATAPI over Bulk-Only scsibus1 at umass1: 2 targets sd1 at scsibus1 targ 1 lun 0: Corsair, Flash Voyager, 1.00 SCSI0 0/direct removable sd1: 978MB, 124 cyl, 255 head, 63 sec, 512 bytes/sec, 2002944 sec total sd1 detached scsibus1 detached umass1 detached uhub4 detached uhub4 at uhub0 port 2 Prolific Technology
Any Audigy users here?
I'm unable to have sound on both outputs available in Audigy. Perhaps any Audigy owner could make a tip, how can I achieve that (if that's possible at all, using current audio driver)? OpenBSD 4.2 -- pozdrawiam / regards Zbigniew Baniewski
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. WELL...there MIGHT be a small savings in data structures not allocated for drivers, but that would most likely only be the case if you had such a device in the machine, but deactivated the driver. (i.e., em(4) (the driver) might allocate a RAM buffer for each em(4) card in the machine, but only for the cards in the machine...disable the driver, you don't allocate the buffers, but you can't use the card). Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. That would be a funky kind of relinking, or a bunch of loadable modules, ala Windows or Linux, which is why Windows and Linux needs so much less RAM than OpenBSD. Oh..wait... ;) Removing drivers for reduced memory is really a for advanced users only task, and you VERY QUICKLY run into diminishing returns. One problem is you almost certainly need another computer -- if you have 16M RAM, you want to whittle down the kernel a lot...but $DEITY help you if you need to build that new kernel on that machine, since just sitting at the shell prompt will have you into swap. HOWEVER, by the time you get to 32M, I doubt you will appreciate the time and effort required to build and reboot off a new kernel (even if compiled on another machine). You just won't be adding much functionality to the machine -- there won't be something major you will suddenly be able to do that you couldn't do before. Nick.
Re: Any Audigy users here?
Zbigniew Baniewski wrote: I'm unable to have sound on both outputs available in Audigy. Perhaps any Audigy owner could make a tip, how can I achieve that (if that's possible at all, using current audio driver)? OpenBSD 4.2 The question is which Audigy? Creative makes wide variety of cards sold under that name and even the known one are sometime sold with different chip version (usually undocumented when they switch a chip). I do have Audigy SE sitting around that somebody gave me when he upgraded gaming rig. That is one of the cheapest and most widely sold cards sold in U. S. to kids who are playing video games. I actually waisted some time playing with it (not very mature thing to do). I have tried both OpenBSD 4.2 i386 and amd 64 and I could send you dmesg as a proof that the damn thing doesn't work. I didn't try it on 4.3beta. I did manage card to work with OSS driver compiled from ports on FreeBSD. However the card is not supported by even the newest FreeBSD kernel driver hnd. OSS of course is not ported for OpenBSD because until recently was closed source binary only package. OSS is now released under BSD license. We had a discussion about OSS sometimes ago and I didn't notice big enthusiasm by developers to port or incorporate parts of OSS into OpenBSD. Now if you have time on your hands you might try to extract some drivers from OSS play with them on OpenBSD. I am sure if you come up with something good the developers will find a way to incorporate into current. Kind Regards, Predrag Punosevac
