Re: core dump files in invalid format on 4.3 (x86)
What I have is application.core, but I cannot read this: /home/me/application.core is not a core dump: File format not recognized (gdb) quit did you check the core size to see if it didn't get truncated because of some ulimit ? Yes, the core file is definitely a lot smaller than what ulimit -c was set to. Furthermore the dump should have a header so that 'file' could determine the file type. Which is not the case.
Re: 4.6 arriving
On Fri, Oct 2, 2009 at 12:26 PM, patrick keshishian pkesh...@gmail.com wrote: On Fri, Oct 2, 2009 at 12:19 PM, Dave Anderson d...@daveanderson.com wrote: The CD set showed up in today's mail (near Boston, Mass.) Dave I received ship notice this morning. So, after all, Oct 1st (-ish) did end up to be the release date(?). arrived in burbank, ca (usa) today. thank you all! tiny little puffy shrine: http://sidster.com/gallery/misc/2009/obsd46-32-21-mugs.jpg
Re: core dump files in invalid format on 4.3 (x86)
iirc core dump format was changed to elf(5) sometime around when PIE was imported, you probably need older gdb On 20:38 Thu 08 Oct, openbsd.misc.tmp openbsd.misc.tmp wrote: Hi! I have an application that in very seldom cases causes core dumps on about a dotzen machines that are located on customers sites. What I have is application.core, but I cannot read this: # gdb -c /home/me/application.core /home/me/application GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd4.3...(no debugging symbols found) /home/me/application.core is not a core dump: File format not recognized (gdb) quit # file /home/me/application.core /home/me/application.core: data Anybody got an idea how this can happen? What can I do with the file I have? This happened more than once. Yet, all the .core files I was able to get were unusable to me. However, when I initiate a .core file by exiting the application intentionally with a signal, the resulting core files are OK. Thanks in advance! Regards, T.
Re: 4.6 arriving
On 09.10.2009, at 08:30, patrick keshishian wrote: arrived in burbank, ca (usa) today. thank you all! tiny little puffy shrine: http://sidster.com/gallery/misc/2009/obsd46-32-21-mugs.jpg Oh man, I'd LOVE to give the 2.1 version a boot opportunity on i386. Just for the sake of curiosity. Anyone offering a copy? My 4.6 arrived here too, Cologne/Bonn area in Germany. Funny fact: the shipping notification email arrived one day after the package has been handed over to me by the postman. Canadian mail seems to kick ass compared to E-Mail ;) I can only encourage those who are still undecided: buy, or at least donate!
Re: 4.6 arriving
On Fri, Oct 09, 2009 at 09:30:07AM +0200, Lukas Ratajski wrote: On 09.10.2009, at 08:30, patrick keshishian wrote: arrived in burbank, ca (usa) today. thank you all! tiny little puffy shrine: http://sidster.com/gallery/misc/2009/obsd46-32-21-mugs.jpg Oh man, I'd LOVE to give the 2.1 version a boot opportunity on i386. Just for the sake of curiosity. Anyone offering a copy? Yes, but it's a collectible at this point: https://https.openbsd.org/cgi-bin/order My 4.6 arrived here too, Cologne/Bonn area in Germany. Funny fact: the shipping notification email arrived one day after the package has been handed over to me by the postman. Canadian mail seems to kick ass compared to E-Mail ;) I can only encourage those who are still undecided: buy, or at least donate!
Chuva de preços...
Se nco conseguir visualizar esta newsletter p.f. clique aqui | Para remover o seu email da n/ base de dados clique aqui Clique na imagem para enviar Pedido de Orgamento Email enviado para: misc@openbsd.org O presente email destina-se znica e exclusivamente a informar clientes ou potenciais clientes brinde-companhia.com e nco deve ser considerado SPAM. Se inadvertidamente i receptor desta mensagem e nco pretende receber mais informagues clique aqui ou reenvie-nos este email com o assunto REMOVER. Deve efectuar o pedido de anulagco pelo enderego de email que se encontra na nossa base de dados, de outra forma ficaremos impossibilitados de o fazer. Este email esta em conformidade com o decreto/lei 67/98 de 26 Outubro, artigos 10 e 11 (Regulagco do tratamento automatizado de dados). [IMAGE]
Re: 4.6 arriving
From: Lukas Ratajski l.rataj...@h-s-l.de On 09.10.2009, at 08:30, patrick keshishian wrote: arrived in burbank, ca (usa) today. thank you all! tiny little puffy shrine: http://sidster.com/gallery/misc/2009/obsd46-32-21-mugs.jpg Oh man, I'd LOVE to give the 2.1 version a boot opportunity on i386. Just for the sake of curiosity. Anyone offering a copy? Given that 2.1 is just a *tiny* bit pricey, might I suggest : 1) http://ftp.eu.openbsd.org/pub/OpenBSD/2.1/i386/ 2) A donation PK
Re: 4.6 arriving
On 09.10.2009, at 10:52, Peter Kay - Syllopsium wrote: Given that 2.1 is just a *tiny* bit pricey, might I suggest : 1) http://ftp.eu.openbsd.org/pub/OpenBSD/2.1/i386/ Oh :) Thank you! 2) A donation I donate monthly, with a standing order.
Re: core dump files in invalid format on 4.3 (x86)
I really appreciate the help I'm getting here, so don't get me wrong, I really don't want to be negative with what you propose, but: /home/me/application.core is not a core dump: File format not recognized iirc core dump format was changed to elf(5) sometime around when PIE was imported, you probably need older gdb Is that really likely? I mean, all files (Kernels, gdb, .core file) derive from the same machine, a standard OpenBSD 4.3 installation. Why should an older gdb version help here?
Re: 4.6 arriving
On Fri, Oct 09, 2009 at 09:30:07AM +0200, Lukas Ratajski wrote: Oh man, I'd LOVE to give the 2.1 version a boot opportunity on i386. Just for the sake of curiosity. Anyone offering a copy? 2009/10/9 Bret S. Lambert bret.lamb...@gmail.com: Yes, but it's a collectible at this point: https://https.openbsd.org/cgi-bin/order Here it says that 2.1 and others are sold out: http://www.openbsd.org/items.html#21 Maybe that's just something that needs to be corrected on the website?
Re: 4.6 arriving
2009/10/9 Bret S. Lambert bret.lamb...@gmail.com: On Fri, Oct 09, 2009 at 09:30:07AM +0200, Lukas Ratajski wrote: Oh man, I'd LOVE to give the 2.1 version a boot opportunity on i386. Just for the sake of curiosity. Anyone offering a copy? Yes, but it's a collectible at this point: https://https.openbsd.org/cgi-bin/order Indeed. But 2.4 is the real collectible. :-) Best Martin
Re: 4.6 arriving
Got my copy on the 7th here in Utah. Just did my first new install. Have to say I think the new install process is really nice. I think OpenBSD might just be the fastest installing (new)OS out there, I didn't actually time it but it felt less than five minutes to up, configured and running (no_x11). Thank you to everyone that worked on this release. -- ESP
Re: ALIX and PC Engines CompactFlash
Hi Daniel Daniel Melameth [Thu, Oct 01, 2009 at 01:26:28PM -0600]: would you please share the RELEVANT PORTION OF YOUR DMESG for the card (and your opinions if you'd like)? I'm particularly interested in what's reported for x-sector PIO and related. It might be a bit late, but ... $ dmesg | grep wd wd0 at pciide0 channel 0 drive 0: CF 4GB wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 root on wd0a swap on wd0b dump on wd0b $ This is on 4.5. I use that card in my Alix-based firewall. So far I didn't have any problems with it. I hope that helps, Dominik -- Dominik Meister My public GnuPG key is available at http://www.meisternet.ch/gpg.txt [demime 1.01d removed an attachment of type application/pgp-signature]
ifstated delay after state transition
I'm seeing a 35-40 second delay in ifstated after a state transition
before jumping into the init {} sequence. In the log below, the
detection to isp2l2down occurs at 10:36:19 and the first init run occurs
at 10:36:58. Is that normal?
(OpenBSD 4.5-stable (GENERIC.MP) #7: Fri Jul 31 09:13:51 EDT 2009) Is
this normal?
/var/log/daemon:
Oct 9 10:33:24 fw1 ifstated[22548]: changing state to safereturn
Oct 9 10:36:19 fw1 ifstated[22548]: changing state to isp2l2down
Oct 9 10:36:58 fw1 ifstated[22548]: running pfctl -a outbound3 -F rules
Oct 9 10:36:58 fw1 ifstated[22548]: running date|mail -s 'FW1 says
Link2 is down' root
Oct 9 10:36:58 fw1 ifstated[22548]: running pfctl -a outbound3 -F rules
-f /etc/pf.isp2l2up.conf
Oct 9 10:36:58 fw1 ifstated[22548]: running date|mail -s 'FW1 says
Link2 is up' root
/etc/ifstated.conf:
isp1l1_up = '( ping -q -c 8 -w 2 -I 192.168.1.60 192.168.16.1
/dev/null every 60)'
isp2l1_up = '( ping -q -c 10 -w 1 192.168.8.254 /dev/null every 60
\
ping -q -c 10 -w 1 -I 192.168.8.228 192.168.32.20
/dev/null every 60)'
isp2l2_up = '( ping -q -c 10 -w 1 192.168.57.221 /dev/null every 60
\
ping -q -c 10 -w 1 -I 192.168.57.222 192.168.58.10
/dev/null every 60)'
state bothup {
init {
run route delete default 192.168.1.33
run route add default 192.168.8.254
run pfctl -a outbound3 -F rules -f
/etc/pf.isp2l2up.conf
run pfctl -a outbound -F rules -f /etc/pf.bothup.conf
run date|mail -s 'FW1 says both ISPs up' root
}
if ! $isp2l1_up
set-state isp2l1down
if ! $isp2l2_up
set-state isp2l2down
if ! $isp1l1_up
set-state isp1l1down
}
state safereturn {
if ! $isp2l1_up
set-state isp2l1down
if ! $isp2l2_up
set-state isp2l2down
if ! $isp1l1_up
set-state isp1l1down
}
state isp1l1down {
init {
run route delete default 192.168.1.33
run route add default 192.168.8.254
run pfctl -a outbound -F rules -f
/etc/pf.isp1l1down.conf
run date|mail -s 'FW1 says Isp1l1 is down' root
run pkill ftp-proxy
run sleep 5
run /usr/sbin/ftp-proxy -a 192.168.8.228
}
if $isp1l1_up {
run pkill ftp-proxy
run /usr/sbin/ftp-proxy -a 192.168.1.62
run /usr/sbin/ftp-proxy -b 192.168.1.43 -R 10.9.0.11 -p
21
set-state bothup
}
}
state isp2l1down {
init {
run route delete default 192.168.8.254
run route add default 192.168.1.33
run pfctl -a outbound -F rules -f
/etc/pf.isp2l1down.conf
run date|mail -s 'FW1 says FreedomNet Link1 is down'
root
}
if $isp2l1_up {
set-state bothup
}
}
state isp2l2down {
init {
run pfctl -a outbound3 -F rules
run date|mail -s 'FW1 says FreedomNet Link2 is down'
root
}
if $isp2l2_up {
run pfctl -a outbound3 -F rules -f
/etc/pf.isp2l2up.conf
run date|mail -s 'FW1 says FreedomNet Link2 is up'
root
set-state safereturn
}
if ! $isp2l1_up
set-state isp2l1down
}
-Steve S.
Re: ALIX and PC Engines CompactFlash
would you please share the RELEVANT PORTION OF YOUR DMESG for the card (and your opinions if you'd like)? I'm particularly interested in what's reported for x-sector PIO and related. It might be a bit late, but ... $ dmesg | grep wd wd0 at pciide0 channel 0 drive 0: CF 4GB wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 root on wd0a swap on wd0b dump on wd0b $ This is on 4.5. I use that card in my Alix-based firewall. So far I didn't have any problems with it. Some time ago, it was suggested that the 1-sector PIO is what's occasionaly slow about some of these cards (e.g. when untarring a big tgz during an install). Sadly, I have never seen any multi-sector PIO card. And obviuosly, I will be upgrading soon (ALICes, actually). Can people recommend some quality multi-sector PIO CF cards? Thanks Jan
no hostname in mails sent with smtpd in a crontab
Hello.
I'm on a OPENBSD_4_6. I use smtpd insted of sendmail. All works perfect
with it, except one point. When a mail is sent from a crontab, the mail
received has this in the header:
From: root (Cron Daemon)
I have no hostname, no domain, nothing. Just the user in the From part.
This case is only when a mail is sent from a crontab (crontab -e -u root). With
this line for example:
*/1 * * * * echo test
So, we wan't answer to this mail, or know who is the machine which send it.
However, in other informations in the header, we wan see the domain in
'Received' parts.
See my /etc/mail/smtpd.conf:
listen on sk0
hostname my.hostname.tld
map aliases { source db /etc/mail/aliases.db }
accept from all for local deliver to mbox
accept for all relay
See the end of /etc/mail/aliases
root: u...@myprovider.tld
And, other question... Why Cron Daemon AND root are printed in my From?
Thanks.
Regards,
--
Nicolas
Re: route-to/reply-to broken?
Hello, Stuart. On 8 October 2009 G. 15:03:13 Stuart Henderson wrote: On 2009-09-25, Vadim Zhukov persg...@gmail.com wrote: 2. Is it OK if I'll hack it to make possible even crazy rule like this: pass in on $if1 from $a to $b rdr-to $c \ route-to ($if3 $gt3) reply-to ($if2 $gt2) dup-to $if4 ... or it's not intended to be so, or it's in the work already? All I want is redirecting traffic smartly between to uplinks in different networks like: match in on lan to ! all-locals port domain \ route-to ($fast_if $fast_gw) pass in on lan to ! all-locals I think both of those syntaxes should be expected to work. There is a problem with syntax BTW: should it act on any match, as tag does, or just be saved for pass, as, say, rdr-to? I think the second is right one as it will make dup-to work for packets moving in both directions, not in one as route-to/reply-to/fastroute. On 2009-09-25, Vadim Zhukov persg...@gmail.com wrote: On 25 September 2009 11:49:48 Henning Brauer wrote: On 25 September 2009 08:34:03 Vadim Zhukov wrote: So as far as I can understand, pf_rule.rdr pool is used for route-to/reply-to/dup-to options. Now I have a few stupid questions: 1. Is it intended to have only one address pool for rdr-to/route-to/reply-to/dup-to options in the rule? Or did I misinterpreted something? this was intended but is a bit nasty so we'll go for a seperate pool for the route stuff (route-to/reply-to/dup-to) Thank you very much for your reply. Should I wait for this change to happen at least until 4.7 branched, or go alone? Just do not want to do unneeded work. It's definitely needed work, I've talked to a few people who rely on route-to/reply-to and can't upgrade some systems for now (or worse, already upgraded). I'm working on patch solving all that problems. It's partly working now (as Laurent Ghigonis reported to me), but reply-to and dup-to still fail and rdr-to is broken. Hope I'll finish the patch until end of the week, but it depends on availability of mine free time. Then I'll just post it to t...@. I need to thank specially Ryan McBride and Henning Brauer: they answered many (stupid) questions and helped me very much in producing a few other small patches. :) -- Best wishes, Vadim Zhukov A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: ALIX and PC Engines CompactFlash
Jan Stary wrote: would you please share the RELEVANT PORTION OF YOUR DMESG for the card (and your opinions if you'd like)? I'm particularly interested in what's reported for x-sector PIO and related. It might be a bit late, but ... $ dmesg | grep wd wd0 at pciide0 channel 0 drive 0: CF 4GB wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 root on wd0a swap on wd0b dump on wd0b $ This is on 4.5. I use that card in my Alix-based firewall. So far I didn't have any problems with it. Some time ago, it was suggested that the 1-sector PIO is what's occasionaly slow about some of these cards (e.g. when untarring a big tgz during an install). Sadly, I have never seen any multi-sector PIO card. And obviuosly, I will be upgrading soon (ALICes, actually). Can people recommend some quality multi-sector PIO CF cards? wd0 at wdc0 channel 0 drive 0: SanDisk SDCFX-1024 wd0: 4-sector PIO, LBA, 977MB, 2001888 sectors This is a SanDisk CF card I got some years ago. I think it's an Ultra-II card, but I'm not 100% sure. It works fine in my Soekris box. Maurice
SATA CDROM/DVDROM
Hello misc , On OpenBSD 4.4 and 4.5 Installation with SATA CD/DVD after the copy of packages the system it does not continue. I Changed to a IDE CDROM/DVDROM and Success in Instalation I tested it in 3 different computers with different hardware
Re: ALIX and PC Engines CompactFlash
On Fri, Oct 09, 2009 at 05:35:35PM +0200, Jan Stary wrote: Sadly, I have never seen any multi-sector PIO card. And obviuosly, I will be upgrading soon (ALICes, actually). Can people recommend some quality multi-sector PIO CF cards? I've had excellent results with SanDisk cards. This one is on a Soekris 5500: wd0 at pciide0 channel 0 drive 0: SanDisk SDCFX4-8192 wd0: 4-sector PIO, LBA, 7815MB, 16007040 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 root on wd0a swap on wd0b dump on wd0b This one is on an early Soekris 4801 which does not support DMA modes in the CF socket, so had to disable that in kernel: wd0 at pciide0 channel 0 drive 0: SanDisk SDCFX-2048 wd0: 4-sector PIO, LBA, 1953MB, 4001760 sectors wd0(pciide0:0:0): using PIO mode 4 root on wd0a swap on wd0b dump on wd0b In this case the fancy new card did not perform any better than the cheap old one, but you should not run into that problem with recent hardware.
Re: core dump files in invalid format on 4.3 (x86)
On Thu, Oct 8, 2009 at 11:00 PM, openbsd.misc.tmp openbsd.misc.tmp openbsd.misc@googlemail.com wrote: What I have is application.core, but I cannot read this: /home/me/application.core is not a core dump: File format not recognized (gdb) quit did you check the core size to see if it didn't get truncated because of some ulimit ? Yes, the core file is definitely a lot smaller than what ulimit -c was set to. Furthermore the dump should have a header so that 'file' could determine the file type. Which is not the case. First of all, 4.3 is no longer supported, so if there's an actual bug you're on your own. 4.6 is about to be released so you should be long into planning your upgrade process. Also, you failed the first step of a bug report by leaving out your dmesg. This happened more than once. Yet, all the .core files I was able to get were unusable to me. However, when I initiate a .core file by exiting the application intentionally with a signal, the resulting core files are OK. So you have evidence that the kernel generates good core files. That suggests the hypothesis that these files aren't actually generated by the kernel. Do you have evidence that they are? Log statements somewhere? A nanny process that got the abnormal exit status from wait()? Sounds like it's time to crank up the logging around the application, write a 'nanny' script that wraps the process and dumps information about its death when it exits, or run the thing under gdb to start with. You face a mystery: time to crank up the scientific method! Make a hypothesis, figure out how to test it, run the experiment, and draw a conclusion. If you're going to stay with 4.3 then that will be your only option... Philip Guenther
em0: watchdog timeout -- resetting
Hi I have a system (Portwell NAR-5071-310) which is having watchdog timeout issues on em0, the system was previously running v4.2 without this issue, the issue is there on v4.5 the latest snapshot, I know the interface is working as I've managed to pxe boot bsd.rd from 4.5 the latest snapshot using the same interface, however if I try to run dhclient em0 the watchdog timer issues start. Though I've done a install of the latest snapshot, to test to see if the problem existed on v4.5 I just pxe booted bsd.rd ran the dhclient em0. Any ideas? Regards Sevan / Venture37 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 7 em0: watchdog timeout -- resetting DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 10 em0: watchdog timeout -- resetting DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 10 em0: watchdog timeout -- resetting OpenBSD 4.6-current (GENERIC) #218: Thu Oct 8 17:39:12 MDT 2009 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.80 GHz cpu0: FPU,V86,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,SBF,CNXT-ID,xTPR real mem = 2146988032 (2047MB) avail mem = 2071818240 (1975MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/09/06, BIOS32 rev. 0 @ 0xfb3a0, SMBIOS rev. 2.2 @ 0xf0800 (45 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 02/09/2006 acpi0 at bios0: rev 0 acpi0: tables DSDT FACP APIC acpi0: wakeup devices PWRB(S1) CSB5(S1) PS2M(S1) PS2K(S1) USB_(S1) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 133MHz ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 16 pins ioapic1 at mainbus0: apid 3 pa 0xfec01000, version 11, 16 pins ioapic2 at mainbus0: apid 4 pa 0xfec02000, version 11, 16 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (PCI1) acpiprt2 at acpi0: bus 3 (PCI2) acpicpu0 at acpi0 acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB bios0: ROM list: 0xc8000/0x1000 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 ServerWorks GCNB-LE Host rev 0x32 pchb1 at pci0 dev 0 function 1 ServerWorks GCNB-LE Host rev 0x00 pci1 at pchb1 bus 1 em0 at pci0 dev 2 function 0 Intel PRO/1000MT (82540EM) rev 0x02: apic 3 int 6 (irq 11), address 00:90:fb:0c:35:ac piixpm0 at pci0 dev 15 function 0 ServerWorks CSB5 rev 0x93: polling iic0 at piixpm0 lm1 at iic0 addr 0x2d: W83791D spdmem0 at iic0 addr 0x50: 1GB DDR SDRAM registered ECC PC2700CL2.5 spdmem1 at iic0 addr 0x52: 1GB DDR SDRAM registered ECC PC2700CL2.5 pciide0 at pci0 dev 15 function 1 ServerWorks CSB5 IDE rev 0x93: DMA wd0 at pciide0 channel 1 drive 0: TRANSCEND wd0: 1-sector PIO, LBA, 3882MB, 7952112 sectors wd0(pciide0:1:0): using PIO mode 4 pchb2 at pci0 dev 15 function 3 ServerWorks CSB5 LPC rev 0x00 pchb3 at pci0 dev 16 function 0 ServerWorks CIOB-E rev 0x12 pci2 at pchb3 bus 2 em1 at pci2 dev 2 function 0 Intel PRO/1000MT (82546EB) rev 0x01: apic 3 int 6 (irq 9), address 00:90:fb:04:f0:d0 em2 at pci2 dev 2 function 1 Intel PRO/1000MT (82546EB) rev 0x01: apic 3 int 7 (irq 7), address 00:90:fb:04:f0:d1 em3 at pci2 dev 4 function 0 Intel PRO/1000MT (82546EB) rev 0x01: apic 3 int 8 (irq 5), address 00:90:fb:04:f0:d2 em4 at pci2 dev 4 function 1 Intel PRO/1000MT (82546EB) rev 0x01: apic 3 int 9 (irq 12), address 00:90:fb:04:f0:d3 pchb4 at pci0 dev 16 function 2 ServerWorks CIOB-E rev 0x12 pci3 at pchb4 bus 3 bge0 at pci3 dev 0 function 0 Broadcom BCM5704C rev 0x02, BCM5704 A2 (0x2002): apic 3 int 11 (irq 10), address 00:90:fb:0c:36:06 brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci3 dev 0 function 1 Broadcom BCM5704C rev 0x02, BCM5704 A2 (0x2002): apic 3 int 10 (irq 11), address 00:90:fb:0c:36:07 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 isa0 at mainbus0 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 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 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown
Re: no hostname in mails sent with smtpd in a crontab
Nicolas Letellier wrote:
Hello.
I'm on a OPENBSD_4_6. I use smtpd insted of sendmail. All works perfect
with it, except one point. When a mail is sent from a crontab, the mail
received has this in the header:
From: root (Cron Daemon)
I have no hostname, no domain, nothing. Just the user in the From part.
This case is only when a mail is sent from a crontab (crontab -e -u root). With
this line for example:
*/1 * * * * echo test
So, we wan't answer to this mail, or know who is the machine which send it.
However, in other informations in the header, we wan see the domain in
'Received' parts.
I've spotted this recently too, it breaks the MUA on my phone for some
reason ...
I'll look at it this week-end when i'm done with the virtual domains
code i'm working on
See my /etc/mail/smtpd.conf:
listen on sk0
hostname my.hostname.tld
map aliases { source db /etc/mail/aliases.db }
accept from all for local deliver to mbox
accept for all relay
See the end of /etc/mail/aliases
root: u...@myprovider.tld
And, other question... Why Cron Daemon AND root are printed in my From?
what do you mean ?
can you show a sample email ?
Gilles
Re: em0: watchdog timeout -- resetting
On 09/10/2009 20:22, Sevan / Venture37 wrote: Hi I have a system (Portwell NAR-5071-310) which is having watchdog timeout issues on em0, the system was previously running v4.2 without this issue, the issue is there on v4.5 the latest snapshot, I know the interface is working as I've managed to pxe boot bsd.rd from 4.5 the latest snapshot using the same interface, however if I try to run dhclient em0 the watchdog timer issues start. Though I've done a install of the latest snapshot, to test to see if the problem existed on v4.5 I just pxe booted bsd.rd ran the dhclient em0. Any ideas? Regards Sevan / Venture37 I forgot to mentioned, the issue is only there with em0 not the other em interfaces.
nfe0: tx v2 error 6204UNDERFLOW
Hello all, I have three machines that have a integrated NIC. Dmesg says they are : nfe0 at pci0 dev 7 function 0 NVIDIA MCP61 LAN rev 0xa2: apic 2 int 10 (irq 10), address 00:0f:ea:63:41:fd rlphy0 at nfe0 phy 1: RTL8201L 10/100 PHY, rev. 1 However, all of them when a download is initiated they spit this error: nfe0: tx v2 error 6204UNDERFLOW Iam using 4.5 stable. Is this a significant error? I dont see a performance issue... but id like to know what are the implications. Thank you -- Andres
poor tcp performance
Hi, I am running openbsd 4.2 on a box and I would like help trying to identify networking bottlenecks. While trying to download a file from another obsd box at the network using wget, I get very low rate. # wget http://192.168.1.254/bsd1 --18:03:29-- http://192.168.1.254/bsd1 = `bsd1.1' Connecting to 192.168.1.254:80... connected. HTTP request sent, awaiting response... 200 OK Length: 61,758,702 (59M) [text/plain] 100%[] 61,758,702 2.30M/s 18:03:55 (2.32 MB/s) - `bsd1.1' saved [61758702/61758702] But when I use iperf, I get quite high transfer rates: # iperf -i 10 -w 256K -c 192.168.1.254 -t 3002 Client connecting to 192.168.1.254, TCP port 5001 TCP window size: 256 KByte [ 3] local 192.168.1.148 port 44687 connected with 192.168.1.254 port 5001 [ 3] 0.0-10.0 sec111 MBytes 93.4 Mbits/sec [ 3] 10.0-20.0 sec111 MBytes 93.5 Mbits/sec [ 3] 20.0-30.0 sec111 MBytes 93.5 Mbits/sec [ 3] 30.0-40.0 sec111 MBytes 93.5 Mbits/sec My question is what could be causing the tcp poor performance? Thanks for any suggestion. Regards, Jose - # ifconfig sk0 sk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:b0:5d:5d:08 groups: egress media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet6 fe80::222:b0ff:fe5d:5d08%sk0 prefixlen 64 scopeid 0x2 inet 192.168.1.148 netmask 0xff00 broadcast 192.168.1.255 # sysctl net.inet.ip net.inet.ip.forwarding=0 net.inet.ip.redirect=1 net.inet.ip.ttl=64 net.inet.ip.sourceroute=0 net.inet.ip.directed-broadcast=0 net.inet.ip.portfirst=1024 net.inet.ip.portlast=49151 net.inet.ip.porthifirst=49152 net.inet.ip.porthilast=65535 net.inet.ip.maxqueue=300 net.inet.ip.encdebug=0 net.inet.ip.ipsec-expire-acquire=30 net.inet.ip.ipsec-invalid-life=60 net.inet.ip.ipsec-pfs=1 net.inet.ip.ipsec-soft-allocs=0 net.inet.ip.ipsec-allocs=0 net.inet.ip.ipsec-soft-bytes=0 net.inet.ip.ipsec-bytes=0 net.inet.ip.ipsec-timeout=86400 net.inet.ip.ipsec-soft-timeout=8 net.inet.ip.ipsec-soft-firstuse=3600 net.inet.ip.ipsec-firstuse=7200 net.inet.ip.ipsec-enc-alg=aes net.inet.ip.ipsec-auth-alg=hmac-sha1 net.inet.ip.mtudisc=1 net.inet.ip.mtudisctimeout=600 net.inet.ip.ipsec-comp-alg=deflate net.inet.ip.ifq.len=0 net.inet.ip.ifq.maxlen=550 net.inet.ip.ifq.drops=0 net.inet.ip.mforwarding=0 net.inet.ip.multipath=0 # sysctl net.inet.tcp net.inet.tcp.rfc1323=1 net.inet.tcp.keepinittime=150 net.inet.tcp.keepidle=14400 net.inet.tcp.keepintvl=150 net.inet.tcp.slowhz=2 net.inet.tcp.baddynamic=587,749,750,751,871 net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=16384 net.inet.tcp.sack=1 net.inet.tcp.mssdflt=512 net.inet.tcp.rstppslimit=100 net.inet.tcp.ackonpush=0 net.inet.tcp.ecn=0 net.inet.tcp.syncachelimit=10255 net.inet.tcp.synbucketlimit=105 net.inet.tcp.rfc3390=1 net.inet.tcp.reasslimit=3072 net.inet.tcp.sackholelimit=32768 # pfctl -si Status: Disabled for 0 days 00:21:26 Debug: Urgent OpenBSD 4.2-stable (GENERIC) #0: Fri Mar 7 15:40:50 BRT 2008 r...@spamd.my.domain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA C7-M Processor 6300MHz (CentaurHauls 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT, CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR real mem = 1004826624 (958MB) avail mem = 963846144 (919MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/27/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xfcfc0 (47 entries) bios0: vendor American Megatrends Inc. version 080014 date 27/04/2009 bios0: Phitronics PC3000E+ apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 3.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf5d40/256 (14 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x1106 product 0x3372 pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #128 is the last bus bios0: ROM list: 0xc/0xd400 cpu0 at mainbus0 cpu0: Enhanced SpeedStep disabled by BIOS pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA P4M900 Host rev 0x00 pchb1 at pci0 dev 0 function 1 VIA P4M900 Host rev 0x00 pchb2 at pci0 dev 0 function 2 VIA P4M900 Host rev 0x00 pchb3 at pci0 dev 0 function 3 VIA P4M900 Host rev 0x00 pchb4 at pci0 dev 0 function 4 VIA P4M900 Host rev 0x00 VIA P4M900 IOAPIC rev 0x00 at pci0 dev 0 function 5 not configured pchb5 at pci0 dev 0 function 6 VIA P4M900 Security rev 0x00 pchb6 at pci0 dev 0 function 7 VIA P4M900 Host rev 0x00 ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 vendor VIA, unknown product 0x3371 rev 0x01: aperture at
Re: poor tcp performance
Jose, I would start with getting tcpdumps of both transactions and running them through tcptrace, and look for differences, that will give you some info to go on. J On Fri, Oct 9, 2009 at 2:17 PM, Jose Fragoso inet_use...@samerica.comwrote: Hi, I am running openbsd 4.2 on a box and I would like help trying to identify networking bottlenecks. While trying to download a file from another obsd box at the network using wget, I get very low rate. # wget http://192.168.1.254/bsd1 --18:03:29-- http://192.168.1.254/bsd1 = `bsd1.1' Connecting to 192.168.1.254:80... connected. HTTP request sent, awaiting response... 200 OK Length: 61,758,702 (59M) [text/plain] 100%[] 61,758,702 2.30M/s 18:03:55 (2.32 MB/s) - `bsd1.1' saved [61758702/61758702] But when I use iperf, I get quite high transfer rates: # iperf -i 10 -w 256K -c 192.168.1.254 -t 3002 Client connecting to 192.168.1.254, TCP port 5001 TCP window size: 256 KByte [ 3] local 192.168.1.148 port 44687 connected with 192.168.1.254 port 5001 [ 3] 0.0-10.0 sec111 MBytes 93.4 Mbits/sec [ 3] 10.0-20.0 sec111 MBytes 93.5 Mbits/sec [ 3] 20.0-30.0 sec111 MBytes 93.5 Mbits/sec [ 3] 30.0-40.0 sec111 MBytes 93.5 Mbits/sec My question is what could be causing the tcp poor performance? Thanks for any suggestion. Regards, Jose - # ifconfig sk0 sk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:b0:5d:5d:08 groups: egress media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet6 fe80::222:b0ff:fe5d:5d08%sk0 prefixlen 64 scopeid 0x2 inet 192.168.1.148 netmask 0xff00 broadcast 192.168.1.255 # sysctl net.inet.ip net.inet.ip.forwarding=0 net.inet.ip.redirect=1 net.inet.ip.ttl=64 net.inet.ip.sourceroute=0 net.inet.ip.directed-broadcast=0 net.inet.ip.portfirst=1024 net.inet.ip.portlast=49151 net.inet.ip.porthifirst=49152 net.inet.ip.porthilast=65535 net.inet.ip.maxqueue=300 net.inet.ip.encdebug=0 net.inet.ip.ipsec-expire-acquire=30 net.inet.ip.ipsec-invalid-life=60 net.inet.ip.ipsec-pfs=1 net.inet.ip.ipsec-soft-allocs=0 net.inet.ip.ipsec-allocs=0 net.inet.ip.ipsec-soft-bytes=0 net.inet.ip.ipsec-bytes=0 net.inet.ip.ipsec-timeout=86400 net.inet.ip.ipsec-soft-timeout=8 net.inet.ip.ipsec-soft-firstuse=3600 net.inet.ip.ipsec-firstuse=7200 net.inet.ip.ipsec-enc-alg=aes net.inet.ip.ipsec-auth-alg=hmac-sha1 net.inet.ip.mtudisc=1 net.inet.ip.mtudisctimeout=600 net.inet.ip.ipsec-comp-alg=deflate net.inet.ip.ifq.len=0 net.inet.ip.ifq.maxlen=550 net.inet.ip.ifq.drops=0 net.inet.ip.mforwarding=0 net.inet.ip.multipath=0 # sysctl net.inet.tcp net.inet.tcp.rfc1323=1 net.inet.tcp.keepinittime=150 net.inet.tcp.keepidle=14400 net.inet.tcp.keepintvl=150 net.inet.tcp.slowhz=2 net.inet.tcp.baddynamic=587,749,750,751,871 net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=16384 net.inet.tcp.sack=1 net.inet.tcp.mssdflt=512 net.inet.tcp.rstppslimit=100 net.inet.tcp.ackonpush=0 net.inet.tcp.ecn=0 net.inet.tcp.syncachelimit=10255 net.inet.tcp.synbucketlimit=105 net.inet.tcp.rfc3390=1 net.inet.tcp.reasslimit=3072 net.inet.tcp.sackholelimit=32768 # pfctl -si Status: Disabled for 0 days 00:21:26 Debug: Urgent OpenBSD 4.2-stable (GENERIC) #0: Fri Mar 7 15:40:50 BRT 2008 r...@spamd.my.domain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA C7-M Processor 6300MHz (CentaurHauls 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT, CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR real mem = 1004826624 (958MB) avail mem = 963846144 (919MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/27/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xfcfc0 (47 entries) bios0: vendor American Megatrends Inc. version 080014 date 27/04/2009 bios0: Phitronics PC3000E+ apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 3.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf5d40/256 (14 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x1106 product 0x3372 pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #128 is the last bus bios0: ROM list: 0xc/0xd400 cpu0 at mainbus0 cpu0: Enhanced SpeedStep disabled by BIOS pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA P4M900 Host rev 0x00 pchb1 at pci0 dev 0 function 1 VIA P4M900 Host rev 0x00 pchb2 at pci0 dev 0 function 2 VIA P4M900 Host rev 0x00 pchb3 at pci0 dev 0 function 3 VIA P4M900 Host rev 0x00 pchb4 at pci0 dev 0 function 4 VIA P4M900 Host
Re: ALIX and PC Engines CompactFlash
Some time ago, it was suggested that the 1-sector PIO is what's occasionaly slow about some of these cards (e.g. when untarring a big tgz during an install). Sadly, I have never seen any multi-sector PIO card. And obviuosly, I will be upgrading soon (ALICes, actually). Can people recommend some quality multi-sector PIO CF cards? Here is the partial DMESG information from one I have in a Nokia IP130: wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: LEXAR ATA FLASH wd0: 16-sector PIO, LBA, 489MB, 1001952 sectors wd0(wdc0:0:0): using BIOS timings I believe this particular model is 40x.
Re: poor tcp performance
On Fri, Oct 9, 2009 at 2:17 PM, Jose Fragoso inet_use...@samerica.com wrote: I am running openbsd 4.2 on a box and I would like help trying to identify networking bottlenecks. You know, there have been a *pile* of performance improvements in the *two years* since 4.2 was released. That version has also been unsupported for over a year. (If you don't want to upgrade, then you should be making a better try at supporting yourself...) While trying to download a file from another obsd box at the network using wget, I get very low rate. ... But when I use iperf, I get quite high transfer rates: So it's fast when it's pure network, but slow when a filesystem and disk is involved? What makes you think this is a network issue and not a slow disk controller or disk issue? If I'm reading your dmesg correctly, your disk doesn't even support DMA: wd0 at pciide0 channel 0 drive 0: SAMSUNG HD082GJ wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors (no wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 line...) My question is what could be causing the tcp poor performance? 1) Figure out what you've actually measuring, so that you don't 'fix' an irrelevant issue, 2) Upgrade to 4.5 (or wait 3 weeks and upgrade to 4.6), then retest. Philip Guenther
Re: poor tcp performance
Ah yes, to get the disk out of the equsion, do this with your wget: wget -O /dev/null http://192.168.1.254/bsd1 That will tell you if the disk is your bottleneck.. J On Fri, Oct 9, 2009 at 2:17 PM, Jose Fragoso inet_use...@samerica.comwrote: Hi, I am running openbsd 4.2 on a box and I would like help trying to identify networking bottlenecks. While trying to download a file from another obsd box at the network using wget, I get very low rate. # wget http://192.168.1.254/bsd1 --18:03:29-- http://192.168.1.254/bsd1 = `bsd1.1' Connecting to 192.168.1.254:80... connected. HTTP request sent, awaiting response... 200 OK Length: 61,758,702 (59M) [text/plain] 100%[] 61,758,702 2.30M/s 18:03:55 (2.32 MB/s) - `bsd1.1' saved [61758702/61758702] But when I use iperf, I get quite high transfer rates: # iperf -i 10 -w 256K -c 192.168.1.254 -t 3002 Client connecting to 192.168.1.254, TCP port 5001 TCP window size: 256 KByte [ 3] local 192.168.1.148 port 44687 connected with 192.168.1.254 port 5001 [ 3] 0.0-10.0 sec111 MBytes 93.4 Mbits/sec [ 3] 10.0-20.0 sec111 MBytes 93.5 Mbits/sec [ 3] 20.0-30.0 sec111 MBytes 93.5 Mbits/sec [ 3] 30.0-40.0 sec111 MBytes 93.5 Mbits/sec My question is what could be causing the tcp poor performance? Thanks for any suggestion. Regards, Jose - # ifconfig sk0 sk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:22:b0:5d:5d:08 groups: egress media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet6 fe80::222:b0ff:fe5d:5d08%sk0 prefixlen 64 scopeid 0x2 inet 192.168.1.148 netmask 0xff00 broadcast 192.168.1.255 # sysctl net.inet.ip net.inet.ip.forwarding=0 net.inet.ip.redirect=1 net.inet.ip.ttl=64 net.inet.ip.sourceroute=0 net.inet.ip.directed-broadcast=0 net.inet.ip.portfirst=1024 net.inet.ip.portlast=49151 net.inet.ip.porthifirst=49152 net.inet.ip.porthilast=65535 net.inet.ip.maxqueue=300 net.inet.ip.encdebug=0 net.inet.ip.ipsec-expire-acquire=30 net.inet.ip.ipsec-invalid-life=60 net.inet.ip.ipsec-pfs=1 net.inet.ip.ipsec-soft-allocs=0 net.inet.ip.ipsec-allocs=0 net.inet.ip.ipsec-soft-bytes=0 net.inet.ip.ipsec-bytes=0 net.inet.ip.ipsec-timeout=86400 net.inet.ip.ipsec-soft-timeout=8 net.inet.ip.ipsec-soft-firstuse=3600 net.inet.ip.ipsec-firstuse=7200 net.inet.ip.ipsec-enc-alg=aes net.inet.ip.ipsec-auth-alg=hmac-sha1 net.inet.ip.mtudisc=1 net.inet.ip.mtudisctimeout=600 net.inet.ip.ipsec-comp-alg=deflate net.inet.ip.ifq.len=0 net.inet.ip.ifq.maxlen=550 net.inet.ip.ifq.drops=0 net.inet.ip.mforwarding=0 net.inet.ip.multipath=0 # sysctl net.inet.tcp net.inet.tcp.rfc1323=1 net.inet.tcp.keepinittime=150 net.inet.tcp.keepidle=14400 net.inet.tcp.keepintvl=150 net.inet.tcp.slowhz=2 net.inet.tcp.baddynamic=587,749,750,751,871 net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=16384 net.inet.tcp.sack=1 net.inet.tcp.mssdflt=512 net.inet.tcp.rstppslimit=100 net.inet.tcp.ackonpush=0 net.inet.tcp.ecn=0 net.inet.tcp.syncachelimit=10255 net.inet.tcp.synbucketlimit=105 net.inet.tcp.rfc3390=1 net.inet.tcp.reasslimit=3072 net.inet.tcp.sackholelimit=32768 # pfctl -si Status: Disabled for 0 days 00:21:26 Debug: Urgent OpenBSD 4.2-stable (GENERIC) #0: Fri Mar 7 15:40:50 BRT 2008 r...@spamd.my.domain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA C7-M Processor 6300MHz (CentaurHauls 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT, CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2,xTPR real mem = 1004826624 (958MB) avail mem = 963846144 (919MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/27/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xfcfc0 (47 entries) bios0: vendor American Megatrends Inc. version 080014 date 27/04/2009 bios0: Phitronics PC3000E+ apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 3.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf5d40/256 (14 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x1106 product 0x3372 pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #128 is the last bus bios0: ROM list: 0xc/0xd400 cpu0 at mainbus0 cpu0: Enhanced SpeedStep disabled by BIOS pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA P4M900 Host rev 0x00 pchb1 at pci0 dev 0 function 1 VIA P4M900 Host rev 0x00 pchb2 at pci0 dev 0 function 2 VIA P4M900 Host rev 0x00 pchb3 at pci0 dev 0 function 3 VIA P4M900 Host rev 0x00 pchb4 at pci0 dev 0 function 4 VIA P4M900
Re: 4.6 arriving
Really? I do have a copy of 2.4 :) On 10/9/09, Martin Schrvder mar...@oneiros.de wrote: 2009/10/9 Bret S. Lambert bret.lamb...@gmail.com: On Fri, Oct 09, 2009 at 09:30:07AM +0200, Lukas Ratajski wrote: Oh man, I'd LOVE to give the 2.1 version a boot opportunity on i386. Just for the sake of curiosity. Anyone offering a copy? Yes, but it's a collectible at this point: https://https.openbsd.org/cgi-bin/order Indeed. But 2.4 is the real collectible. :-) Best Martin -- Sent from my mobile device http://www.glumbert.com/media/shift http://www.youtube.com/watch?v=tGvHNNOLnCk This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation. Securing an environment of Windows platforms from abuse - external or internal - is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spafford learn french: http://www.youtube.com/watch?v=30v_g83VHK4
Re: ALIX and PC Engines CompactFlash
Daniel Melameth wrote: With the positive response of OpenBSD on this hardware, I'm considering purchasing these in preparation for a proof of concept. As such, if anyone has purchased the 4GB COMPACTFLASH CARDS THAT PC ENGINES SELLS (http://www.pcengines.ch/cf4dp.htm or http://www.pcengines.ch/cf4slc.htm), would you please share the RELEVANT PORTION OF YOUR DMESG for the card (and your opinions if you'd like)? I'm particularly interested in what's reported for x-sector PIO and related. While I know I can purchase CompactFlash cards from anywhere, I try to support those companies that support OpenBSD (that and it's easier just to get everything from one vendor). Thanks. Here's a partial dmesg from my ALIX using PC Engines' 4Gb CompactFlash card: wd0 at pciide0 channel 0 drive 0: CF 4GB wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 Hope that helps, they run just fine so far. Noth
Re: ALIX and PC Engines CompactFlash
On 2009-10-09, Jan Stary h...@stare.cz wrote: would you please share the RELEVANT PORTION OF YOUR DMESG for the card (and your opinions if you'd like)? I'm particularly interested in what's reported for x-sector PIO and related. It might be a bit late, but ... $ dmesg | grep wd wd0 at pciide0 channel 0 drive 0: CF 4GB wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 root on wd0a swap on wd0b dump on wd0b $ This is on 4.5. I use that card in my Alix-based firewall. So far I didn't have any problems with it. Some time ago, it was suggested that the 1-sector PIO is what's occasionaly slow about some of these cards (e.g. when untarring a big tgz during an install). it helps, but so do other things. Sadly, I have never seen any multi-sector PIO card. And obviuosly, I will be upgrading soon (ALICes, actually). Can people recommend some quality multi-sector PIO CF cards? sandisk (all modern cards), and I've been using the innodisk CF/DOM recently which have been fine, wd0 at pciide0 channel 0 drive 0: InnoDisk Corp. - iCF4000 1GB wd0: 2-sector PIO, LBA, 999MB, 2047248 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 wd0 at pciide0 channel 0 drive 0: InnoDisk Corp. - EDC4000 1GB wd0: 2-sector PIO, LBA, 999MB, 2047248 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 0
Re: poor tcp performance
-Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of James Records Sent: Friday, October 09, 2009 6:14 PM To: Jose Fragoso Cc: misc@openbsd.org Subject: Re: poor tcp performance Ah yes, to get the disk out of the equsion, do this with your wget: wget -O /dev/null http://192.168.1.254/bsd1 ... On Fri, Oct 9, 2009 at 2:17 PM, Jose Fragoso inet_use...@samerica.comwrote: I am running openbsd 4.2 on a box and I would like help trying to identify networking bottlenecks. While trying to download a file from another obsd box at the network using wget, I get very low rate. ... net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=16384 ... Double these values and try again... -Steve S.
mmap'ing to address 0x0
Hi Guys, I was reading some information that indicated that letting user process to map to address 0x0 can exploit some kernel NULL-pointer bugs. I checked how different operating systems mitigate this problem and I found information about Linux and FreeBSD. I was trying to find the same information for OpenBSD with no luck. Can anybody help me with this one? Thanks in advance, Luis
Re: mmap'ing to address 0x0
I was reading some information that indicated that letting user process to map to address 0x0 can exploit some kernel NULL-pointer bugs. I checked how different operating systems mitigate this problem and I found information about Linux and FreeBSD. I was trying to find the same information for OpenBSD with no luck. Can anybody help me with this one? We have been aware of the particular problem (which results from an architectural decision made by some machines) for many years, and it took us a long time to decide what to do. Eventually we decided to make userland suffer. Unfortunately we only fixed it in the middle of last year. Other platforms do not have this problem, since the kernel runs in an un-shared address space. CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2008/06/24 15:24:03 Modified files: sys/arch/alpha/include: vmparam.h sys/arch/amd64/include: vmparam.h sys/arch/arm/include: vmparam.h sys/arch/i386/include: vmparam.h sys/arch/sh/include: vmparam.h sys/arch/sparc/include: vmparam.h sys/arch/vax/include: vmparam.h sys/arch/sh/sh : trap.c Log message: On user/kernel shared page table machines, do not let processes map their own page 0, as discussed with miod (and many others previously, including art and toby). On sparc, make this __LDPGSZ because PAGE_SIZE is non-constant ok miod tedu
