Re: Using tip or cu with a multi-port serial card
Jeff Ross wrote:
Hi,
I got my 4 port serial card and installed it in my firewall today
puc0 at pci1 dev 0 function 0 "Oxford OX16PCI954" rev 0x00: ports: 4 com
pccom3 at puc0 port 0 irq 11: st16650, 32 byte fifo
pccom3: probed fifo depth: 16 bytes
pccom4 at puc0 port 1 irq 11: st16650, 32 byte fifo
pccom4: probed fifo depth: 16 bytes
pccom5 at puc0 port 2 irq 11: st16650, 32 byte fifo
pccom5: probed fifo depth: 16 bytes
pccom6 at puc0 port 3 irq 11: st16650, 32 byte fifo
pccom6: probed fifo depth: 16 bytes
puc1 at pci1 dev 0 function 1 "Oxford Exsys EX-41098" rev 0x00: ports:
4 com
pccom7 at puc1 port 0 irq 5: ns16450, no fifo
pccom8 at puc1 port 1 irq 5: ns16450, no fifo
pccom9 at puc1 port 2 irq 5: ns16450, no fifo
pccom10 at puc1 port 3 irq 5: ns16450, no fifo
I'm using a null modem cable to connect another server to the serial
card's pigtail but when I try to connect to the remote server with tip
or cu, all I get is "Connected". At that point I can ~^D and ~^v and
that's about it.
Connected doesn't necessarily mean there is a well-formed connection
between the two devices. Connected just means you are electrically
connected and something is on the other end of the cable. However, the
communication link may not be "synchronized." Have you tried variations
of line speed, stop and data bits, and parity? If you can connect via
the built-in serial connections of the computer, it doesn't seem like
this would be the problem.
I have a Dell PowerConnect switch that does what you're describing. If I
hit enter 2 times, it will "sync" and give me back a login.
Connected
~v
beautify true
baudrate 9600
dialtimeout 60
eofread
eofwrite
eol
escape ~
exceptions
force \020
framesize 1024
host cu9600
log /var/log/aculog
phones
prompt \012
raise false
raisechar \000
record
remote
script false
tabexpand false
verbose false
SHELL /bin/ksh
HOME /home/jross
echocheck false
disconnect
tandem true
linedelay 0
chardelay 0
etimeout 0
rawftp false
halfduplex false
localecho false
parity none
hardwareflow false
linedisc 0
direct true
These commands you are using are taking place on your local side only.
Is there a way I can see on the remote system if indeed I'm connecting?
If you can login into the server via ssh or console, look for processes
that would have been instantiated in order to make the connection, such
as a getty or a shell process.
If I connect one server directly to the one external serial port on
the firewall with a null modem cable I can connect with cu no problem,
and I have full control.
There are at least a couple of null wiring layouts. Your serial card may
have a different layout than your built-in serial connections. For
example, some of the handshake lines may be crossed-over. I have never
used a serial card before, but maybe you need a straight-through cable
instead of a null modem cable. If you're handy with a soldering iron and
can get your hands on some DB-9 connectors, you can make your own cables
using CAT5. Just some ideas.
I'd appreciate any suggestions.
Thanks!
Jeff Ross
full dmesg
OpenBSD 4.2-current (GENERIC) #5: Fri Nov 16 19:34:39 MST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class) 802 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem = 535261184 (510MB)
avail mem = 509726720 (486MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/17/00, BIOS32 rev. 0 @
0xfdb80, SMBIOS rev. 2.3 @ 0xf0640 (132 entries)
bios0: vendor American Megatrends Inc. version "0700xx" date 11/17/00
bios0: Supermicro 370SSR/370SSE
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3810/224 (12 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801AA LPC" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xc000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82815 Hub" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel 82815 Graphics" rev 0x02:
aperture at 0xf800, size 0x400
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0x01
pci1 at ppb0 bus 1
puc0 at pci1 dev 0 function 0 "Oxford OX16PCI954" rev 0x00: ports: 4 com
pccom3 at puc0 port 0 irq 11: st16650, 32 byte fifo
pccom3: probed fifo depth: 16 bytes
pccom4 at puc0 port 1 irq 11: st16650, 32 byte fifo
pccom4: probed fifo depth: 16 bytes
pccom5 at puc0 port 2 irq 11: st16650, 32 byte fifo
pccom5: probed fifo depth: 16 bytes
pccom6 at puc0 port 3 irq 11: st16650, 32 byte fifo
pccom6: probed fifo depth: 16 bytes
puc1 at pci1 dev 0 function 1 "Oxford Exsys EX-41098" rev 0x00: ports:
4 com
pccom7 at puc1 port 0 irq 5: ns16450, no fifo
pccom8 at puc1 por
Re: Port compile and package install problem for vim and bash
Yes, thanks, my mistake, I guess that I've ran too fast over the What's
New.
Cheers,
Claudiu
-Original Message-
From: Marius ROMAN <[EMAIL PROTECTED]>
To: Claudiu Pruna <[EMAIL PROTECTED]>, misc@openbsd.org
Subject: Re: Port compile and package install problem for vim and bash
Date: Wed, 28 Nov 2007 20:11:20 +0200
On Nov 28, 2007 7:07 PM, Claudiu Pruna <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I have just installed OpenBSD 4.2 on a machine and I encounter
> problems
> with installing either the precompiled package or trying to compile the
> port for vim and bash, and both have problems at gettext dependencies at
> expat.
>
> The error text when compiling the vim port with no_x11 flavor is:
>
>
> ===> Verifying specs: iconv.>=2 iconv.>=2 c expat c expat
> Missing library for expat
>
> and when trying to install the precompiled package I get:
>
> # pkg_add -vr ${PKG_PATH}vim-7.1.33-no_x11
> parsing
> ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/i386/vim-7.1.33-no_x11
> Dependencies for vim-7.1.33-no_x11 resolve to: gettext-0.14.6p0,
> libiconv-1.9.2p3 (todo: gettext-0.14.6p0)
> vim-7.1.33-no_x11:parsing gettext-0.14.6p0
> Dependencies for gettext-0.14.6p0 resolve to: libiconv-1.9.2p3
> found libspec c.41.0 in /usr/lib
> 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
> found libspec iconv.4.0 in package libiconv-1.9.2p3
> Can't install vim-7.1.33-no_x11: can't resolve gettext-0.14.6p0
>
>
> Thank you all.
>
> --
> Claudiu Pruna <[EMAIL PROTECTED]>
>
>
Do you have xbase42.tgz installed ?
http://www.openbsd.org/faq/faq1.html#WhatsNew
Marius
Re: ftp-proxy and pf help! Working 50/50
On 19:12:32 Nov 28, Jake Conk wrote: > #1 server: 200 PORT command successful - not using PASV eh?\r\n You are using active mode ftp which requires the rdr-anchor. See below. > #1 active: server to client port 32818 via port 50073 > #1 client: LIST\r\n > #1 server: 425 Timeout establishing data connection - Broke your > packet filters again eh?\r\n > ^Cftp-proxy exiting on signal 2 > #1 ending session It could not open not redirect the data connection. See below. > # NAT anchor for ftp proxy > nat-anchor "ftp-proxy/*" > You should attach the rdr-anchor "ftp-proxy/*" right here. NOT below. > > # RDR: packets coming in on $ext_if with destination $external_addr:1234 will > # be redirected to 10.1.1.1:5678. A state is created for such packets, and > # outgoing packets will be translated as coming from the external address. > # rdr on $ext_if proto tcp from any to $external_addr/32 port 1234 -> > 10.1.1.1 port 5678 > # rdr outgoing FTP requests to the ftp-proxy > rdr on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 This should be below the ftp-proxy rdr anchor. [...] > > # RDR anchor for ftp-proxy > rdr-anchor "ftp-proxy/*" > It is too late to rdr here. It is clearly mentioned in the ftp-proxy(8) man page that this redirection should _precede_ the ftp-proxy(8) rdr. This change will surely work. If it doesn't then try passive mode. In any case please do exactly as mentioned in ftp-proxy(8) man page. Best of luck! -Girish
Re: PCMCIA on a Toshiba A135-S4656 to use wi(4) with DWL-650 PCMCIA
Disabling apm and enabling acpi did the trick. The network card in the PCMCIA slot works fine now (on 4.2 in both i386 and amd64). Thanks! Andrew Unix Fan wrote: On a few systems I own, enabling ACPI and disabling APM seems to work on older systems, I needed to go into my BIOS and disable an option like "PnP OS/Operating system". (By setting it to No/False..) To try your system with ACPI, at the boot console.. Type the following. UKC> disable apm UKC> enable acpi UKC> quit I hope this works for you..
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
David Gwynne wrote: this diff cannot affect the behavior of your system. the code below deals with domain validation on SPI mpi variants while the x4100 uses SAS mpi. the code you patched isnt run on your machine. Not sure I understand your statement, but as a test, I did exactly that and I have no more crash at all. the code in mpi.c you are modifying does not get run on the x4100s. I have redone the tests with yet again a fresh install and you are 100% right. My apology for my false hope. It must have been a combination of the reboot and one of these time out of may be 15 reboot that it is way more stable until the next reboot where it will react again poorly. in my opinion the only way it can affect your systems is by causing something to be moved around in memory, perhaps out of the way of something else that is borked. I guess, that may be the only valid course of action here then. That may be shown by the difference in the iic1 code in dmesg between not working boot and stable one where so far, I am up to three time out of may be 50 or 60 by now in the last few hours that are stable and doing a diff between the dmesg doesn't show any differences between them. Could it be in the iic1 section of the dmesg then? I am back to the drawing board then. I thought I maid progress, now I am down again. (;< This was fun for some time, but now it sure start not to be so much fun. Best and thanks for your previous comments. Daniel
ftp-proxy and pf help! Working 50/50
Hello,
Its been a few weeks now and I can't figure out why ftp-proxy is not
working properly on one of my openbsd routers... I have the EXACT
same configuration on the primary router and on the secondary router
however when the primary router is down and the backup one comes up
then everyone has a problem with ftp... Everyone can connect to public
and to our private ftp server behind the router but they can't do
anything like list, get, or put files anywhere... This is a big
problem... Any ftp-proxy / pf pros out there?
To get a clear example of what's going on I am including my ftp-proxy
debug information from trying to connect from behind my somewhat
working router to ftp.openbsd.org and trying to list the contents of
the initial directory:
$ sudo /usr/sbin/ftp-proxy -d -D7 -v -p 8021 127.0.0.1
listening on 127.0.0.1 port 8021
#1 accepted connection from 192.168.10.9
#1 FTP session 1/100 started: client 192.168.10.9 to server
129.128.5.191 via proxy
#1 server: 220-\r\n
#1 server: 220- Welcome to SunSITE Alberta\r\n
#1 server: 220-\r\n
#1 server: 220- at the University of Alberta, in Edmonton, Alberta, Canada\r\n
#1 server: 220-\r\n
#1 server: 220-All connections to and transfers from this server are
logged. If \r\n
#1 server: 220-you do not like this policy, please disconnect now.\r\n
#1 server: 220-\r\n
#1 server: 220-You may want to grab the index file called "ls-lR.gz"
in /pub. It is \r\n
#1 server: 220-updated nightly with the contents of the ftp tree. \r\n
#1 server: 220-\r\n
#1 server: 220-If you have any questions, hints, or requests,
please email\r\n
#1 server: 220-\r\n
#1 server: 220- [EMAIL PROTECTED]
#1 server: 220-\r\n
#1 server: 220 \r\n
#1 client: USER anonymous\r\n
#1 server: 331 Who are you impersonating today?\r\n
#1 client: PASS \r\n
#1 server: 230-\r\n
#1 server: 230- Welcome to Sunsite Alberta\r\n
#1 server: 230- Login Successful.\r\n
#1 server: 230 Your data rate unrestricted\r\n
#1 client: SYST\r\n
#1 server: 215 UNIX Type: L8\r\n
#1 client: PORT 192,168,10,9,128,50\r\n
#1 proxy: PORT X,X,X,X,195,153\r\n
#1 server: 200 PORT command successful - not using PASV eh?\r\n
#1 active: server to client port 32818 via port 50073
#1 client: LIST\r\n
#1 server: 425 Timeout establishing data connection - Broke your
packet filters again eh?\r\n
^Cftp-proxy exiting on signal 2
#1 ending session
Below is my pf.conf just incase:
# Macros: define common values, so they can be referenced and changed easily.
ext_if="bge0" # External interface
ext_ip=""# External IP
ext_carp_if="carp0" # External carp interface
ext_carp_ip="" # External carp IP
ext_ifs="{" $ext_if $ext_carp_if "}"# All external interfaces
int_if="bge1" # Internal interface
int_carp_if0="carp1"# Internal carp interface 1
int_carp_if1="carp2"# Internal carp interface 2
carp_ifs="{" $ext_if $int_if "}"# Interfaces which do carp
loop_if="lo0" # Loopback Interface
bridge_if="bridge0" # Brige Interface
tap_if="tap0" # Tap Interface
pflog_if="pflog0" # Pflog Interface
pfsync_if="xl0" # Pfsync infterface
int_ifs="{" $int_if $int_carp_if0 $int_carp_if1 \
$loop_if $bridge_if $tap_if $pflog_if \
$pfsync_if "}"# All internal interfaces
external_addr="192.168.1.1" # External Address
internal_net="192.168.10.0/24" # Internal Network
icmp_types="{0, 3, 4, 8, 11, 12}" # Allowed ICMP Types
no_route="{ 127.0.0.0/8, 192.168.0.0/24, \
172.16.0.0/12, 10.0.0.0/8 }"# Non routable IPs
# SERVERS #
ftp_server="192.168.10.9"
mail_server="192.168.10.9"
# Tables: similar to macros, but more flexible for many addresses.
#table { 10.0.0.0/8, !10.1.0.0/16, 192.168.0.0/24, 192.168.1.18 }
# Options: tune the behavior of pf, defaults given
set timeout { interval 10, frag 30 }
set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
Using tip or cu with a multi-port serial card
Hi,
I got my 4 port serial card and installed it in my firewall today
puc0 at pci1 dev 0 function 0 "Oxford OX16PCI954" rev 0x00: ports: 4 com
pccom3 at puc0 port 0 irq 11: st16650, 32 byte fifo
pccom3: probed fifo depth: 16 bytes
pccom4 at puc0 port 1 irq 11: st16650, 32 byte fifo
pccom4: probed fifo depth: 16 bytes
pccom5 at puc0 port 2 irq 11: st16650, 32 byte fifo
pccom5: probed fifo depth: 16 bytes
pccom6 at puc0 port 3 irq 11: st16650, 32 byte fifo
pccom6: probed fifo depth: 16 bytes
puc1 at pci1 dev 0 function 1 "Oxford Exsys EX-41098" rev 0x00: ports: 4 com
pccom7 at puc1 port 0 irq 5: ns16450, no fifo
pccom8 at puc1 port 1 irq 5: ns16450, no fifo
pccom9 at puc1 port 2 irq 5: ns16450, no fifo
pccom10 at puc1 port 3 irq 5: ns16450, no fifo
I'm using a null modem cable to connect another server to the serial
card's pigtail but when I try to connect to the remote server with tip
or cu, all I get is "Connected". At that point I can ~^D and ~^v and
that's about it.
Connected
~v
beautify true
baudrate 9600
dialtimeout 60
eofread
eofwrite
eol
escape ~
exceptions
force \020
framesize 1024
host cu9600
log /var/log/aculog
phones
prompt \012
raise false
raisechar \000
record
remote
script false
tabexpand false
verbose false
SHELL /bin/ksh
HOME /home/jross
echocheck false
disconnect
tandem true
linedelay 0
chardelay 0
etimeout 0
rawftp false
halfduplex false
localecho false
parity none
hardwareflow false
linedisc 0
direct true
Is there a way I can see on the remote system if indeed I'm connecting?
If I connect one server directly to the one external serial port on the
firewall with a null modem cable I can connect with cu no problem, and I
have full control.
I'd appreciate any suggestions.
Thanks!
Jeff Ross
full dmesg
OpenBSD 4.2-current (GENERIC) #5: Fri Nov 16 19:34:39 MST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III ("GenuineIntel" 686-class) 802 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem = 535261184 (510MB)
avail mem = 509726720 (486MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/17/00, BIOS32 rev. 0 @ 0xfdb80,
SMBIOS rev. 2.3 @ 0xf0640 (132 entries)
bios0: vendor American Megatrends Inc. version "0700xx" date 11/17/00
bios0: Supermicro 370SSR/370SSE
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3810/224 (12 entries)
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801AA LPC" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xc000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82815 Hub" rev 0x02
vga1 at pci0 dev 2 function 0 "Intel 82815 Graphics" rev 0x02: aperture
at 0xf800, size 0x400
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0x01
pci1 at ppb0 bus 1
puc0 at pci1 dev 0 function 0 "Oxford OX16PCI954" rev 0x00: ports: 4 com
pccom3 at puc0 port 0 irq 11: st16650, 32 byte fifo
pccom3: probed fifo depth: 16 bytes
pccom4 at puc0 port 1 irq 11: st16650, 32 byte fifo
pccom4: probed fifo depth: 16 bytes
pccom5 at puc0 port 2 irq 11: st16650, 32 byte fifo
pccom5: probed fifo depth: 16 bytes
pccom6 at puc0 port 3 irq 11: st16650, 32 byte fifo
pccom6: probed fifo depth: 16 bytes
puc1 at pci1 dev 0 function 1 "Oxford Exsys EX-41098" rev 0x00: ports: 4 com
pccom7 at puc1 port 0 irq 5: ns16450, no fifo
pccom8 at puc1 port 1 irq 5: ns16450, no fifo
pccom9 at puc1 port 2 irq 5: ns16450, no fifo
pccom10 at puc1 port 3 irq 5: ns16450, no fifo
fxp0 at pci1 dev 4 function 0 "Intel 8255x" rev 0x08, i82559: irq 11,
address 00:30:48:10:7c:77
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
fxp1 at pci1 dev 8 function 0 "Intel 82562" rev 0x01, i82562: irq 11,
address 00:30:48:11:0f:ef
inphy1 at fxp1 phy 1: i82562EM 10/100 PHY, rev. 0
ichpcib0 at pci0 dev 31 function 0 "Intel 82801BA LPC" rev 0x01: 24-bit
timer at 3579545Hz
pciide0 at pci0 dev 31 function 1 "Intel 82801BA IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 19470MB, 39876480 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 190782MB, 390721968 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 31 function 2 "Intel 82801BA USB" rev 0x01: irq 7
ichiic0 at pci0 dev 31 function 3 "Intel 82801BA SMBus" rev 0x01: irq 5
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 256MB SDRAM non-parity PC133CL3
spdmem1 at ii
Re: Firefox 2.0.0.10? For OpenBSD 4.2-CURRENT only??
Unix Fan wrote: This really is stupid, a majority of the users of OpenBSD purchased 4.2 CD's.. are likely expecting it would be a supported release. -CURRENT is a rapidly moving target, and I don't feel like updating my kernel a billion times a month... just to get the latest version of firefox! Ports should only be updated for the "latest" release, not -CURRENT... a secure OS is nothing without secure software... -Nix Fan. your shining, positive, go-getter attitude must propel you right along in the fantasy land you live in. to claim that it is not a supported release because it does not have the latest version of firefox 2.x.y.z is absurd. based on the way you've chosen to address the issue you probably have no clue about what additional actual security is supplied by going 2.0.0.9 -> 2.0.0.10. if this is so freaking important, why not post some code for the killer exploit that you can run against firefox 2.0.0.9? the word nitwit comes to mind... --
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
Stuart Henderson wrote: Well, it's certainly a bit odd that amd64 doesn't detect the ipmi, and i386 does... I don't really have any other clues though :( Looking in all my dmesg and all 4 servers, I sure can confirm this. i386 bring it as: ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca4/2 spacing 1 mainbus0: Intel MP Specification (Version 1.4) and either the amd64.mp, or not doesn't show it. ipmi at mainbus0 not configured I don't think this is related to the crash issue however would it? That's an other issue on it's own I guess no?
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
Stuart Henderson wrote: On 2007/11/28 16:47, Daniel Ouellet wrote: I don't know x4100 m2, is this an optional card, or meant to always be there? No there isn't any cards that I added or anything. The difference you see is that the server also have RAID controller built in and as such will show different DMESG when setup, or not. That's the difference you see. Well, it's certainly a bit odd that amd64 doesn't detect the ipmi, and i386 does... I don't really have any other clues though :( Well, if you think of something, please let me know. I am still doing more tests and over 30 reboots so far, I got twice a situation when I wasn't able to crash is as easy. (I couldn't crash it) The only difference I saw and I saved the dmesg is some differences in the iic1 sections with all these numbers. I have no clue if that really mean anything or not, but if is the diff in case is does. # diff -ur /var/dmesg6 /var/dmesg7 --- /var/dmesg6 Wed Nov 28 18:39:41 2007 +++ /var/dmesg7 Wed Nov 28 19:38:37 2007 @@ -10,7 +15,7 @@ ipmi at mainbus0 not configured mainbus0: Intel MP Specification (Version 1.4) cpu0 at mainbus0: apid 0 (boot processor) -cpu0: Dual-Core AMD Opteron(tm) Processor 2216, 2393.90 MHz +cpu0: Dual-Core AMD Opteron(tm) Processor 2216, 2393.95 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW 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 @@ -68,12 +73,12 @@ iic1: addr 0x19 00=01 01=00 02=00 03=01 words 00=0101 01= 02= 03=0101 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x1a 02=00 03=00 words 00= 01= 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x1c 02=00 03=00 words 00= 01= 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= -iic1: addr 0x1d 00=0f 01=0f 02=00 03=00 words 00=0f0f 01=0f0f 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= +iic1: addr 0x1d 00=0f 01=0f 02=00 03=00 words 00=0f0f 01= 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x1e 00=bf 01=07 02=00 03=f8 words 00=bfbf 01=0707 02= 03=f8f8 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= admcts0 at iic1 addr 0x2c admcts1 at iic1 addr 0x2d -iic1: addr 0x48 00=19 01=00 02=4b 03=50 04=50 05=50 06=50 07=50 08=19 09=00 0a=4b 0b=50 0c=50 0d=50 0e=50 0f=50 10=19 11=00 12=4b 13=50 14=50 15=50 16=50 17=50 18=19 19=00 1a=4b 1b=50 1c=50 1d=50 1e=50 1f=50 20=19 21=00 22=4b 23=50 24=50 25=50 26=50 27=50 28=19 29=00 2a=4b 2b=50 2c=50 2d=50 2e=50 2f=50 30=19 31=00 32=4b 33=50 34=50 35=50 36=50 37=50 38=19 39=00 3a=4b 3b=50 3c=50 3d=50 3e=19 3f=50 40=19 41=00 42=4b 43=50 44=50 45=50 46=50 47=50 48=19 49=00 4a=4b 4b=50 4c=50 4d=50 4e=19 4f=50 50=19 51=00 52=4b 53=50 54=50 55=50 56=50 57=50 58=19 59=00 5a=4b 5b=50 5c=50 5d=50 5e=50 5f=50 60=19 61=00 62=4b 63=50 64=50 65=50 66=50 67=50 68=19 69=00 6a=4b 6b=50 6c=50 6d=50 6e=50 6f=50 70=19 71=00 72=4b 73=50 74=50 75=50 76=50 77=50 78=19 79=00 7a=4b 7b=50 7c=50 7d=50 7e=50 7f=50 80=19 81=00 82=4b 83=50 84=50 85=50 86=50 87=00 88=19 89=00 8a=4b 8b=50 8c=50 8d=00 8e=50 8f=50 90=19 91=00 92=4b 93=50 94=19 95=50 96=50 97=50 98=19 99=00 9a=4b 9b=50 9c=50 9d=50 9e=50 9f=50 a0=19 a1=00 a2=4b a3=50 a4=50 a5=50 a6=19 a7=50 a8=19 a9=00 aa=4b ab=50 ac=4b ad=4b b1=00 b4=4b b7=00 bb=50 bc=00 c2=4b c3=50 c4=50 c5=50 c6=50 c7=50 c8=19 c9=00 ca=4b cb=50 cc=50 cd=50 ce=00 cf=50 d0=19 d4=00 d7=19 d8=19 d9=00 da=4b db=50 dc=50 dd=50 de=50 df=50 e0=19 e1=00 e2=4b e3=50 e4=50 e5=50 e6=19 e7=50 e8=19 e9=00 ea=4b eb=50 ec=19 ed=50 ee=50 ef=50 f0=19 f1=00 f2=4b f3=50 f4=50 f5=50 f6=50 f7=50 f8=19 f9=00 fa=4b fb=50 fc=50 fd=50 fe=19 ff=19 words 00=19f2 01=00f2 02=4b72 03=5072 04=5072 05=5072 06=5072 07=5072 08=19f2 09=00f2 0a=4b72 0b=5072 0c=5072 0d=5072 0e=5072 0f=5072 -iic1: addr 0x49 00=ff 01=00 02=ff 03=ff 05=00 06=ff 07=ff 08=1a 09=00 0a=4b 10=1a 11=00 12=4b 18=1a 19=00 1a=4b 20=1a 21=00 22=4b 28=1a 29=00 2a=4b 30=1a 31=00 32=4b 38=1a 39=00 3a=4b 3e=1a 40=1a 41=00 42=4b 48=1a 49=00 4a=4b 4e=1a 50=1a 51=00 52=4b 58=1a 59=00 5a=4b 60=1a 61=00 62=4b 68=1a 69=00 6a=4b 70=1a 71=00 72=4b 78=1a 79=00 7a=4b 80=1a 81=00 82=4b 88=1a 89=00 8a=4b 90=1a 91=00 92=4b 98=1a 99=00 9a=4b a0=1a a1=00 a2=4b a8=1a a9=00 aa=4b b0=1a b1=00 b2=4b b8=1a b9=00 ba=4b c0=1a c1=00 c2=4b c8=1a c9=00 ca=4b d0=1a d1=00 d2=4b d8=1a d9=00 da=4b e0=1a e1=00 e2=4b e8=1a e9=00 ea=4b f0=1a f1=00 f2=4b f8=1a f9=00 fa=4b fe=1a words 00=1a7f 01=00ff 02=4b7f 03=507f 0
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
On 2007/11/28 16:47, Daniel Ouellet wrote: >> I don't know x4100 m2, is this an optional card, or meant to always >> be there? > > No there isn't any cards that I added or anything. The difference you see is > that the server also have RAID controller built in and as such will show > different DMESG when setup, or not. That's the difference you see. Well, it's certainly a bit odd that amd64 doesn't detect the ipmi, and i386 does... I don't really have any other clues though :(
E-Ticketing your Events
To Whom It May Concern, This is Dan Gargano - Owner/CEO of www.ticketmuncher.com. I just wanted to give you, promoters, and event planners a heads up that we are now offering a free consulting service to help you sell tickets to your events. Basically, as a company with over 3,000 clients (all being event promoters) we have seen it all, and we know what works, and what doesn't. Bottom line is, if your holding event, tickets need to be sold in order for you to maintain your bottom line. If you would like free advice feel free to send an e-mail to [EMAIL PROTECTED] Be sure to include information on the type of event you are planning, what types of people you would like to have attend, what you are currently doing to advertise your event, and how you plan to push ticket sales. We do not charge our clients for our advance ticketing service, and it is in our best interest to help you push your eventbecause in the end, we don't make money unless you do. Ticketmuncher.com's FREE service offers an advanced system of e-ticketing, sales reports, bar coding, credit card processing, ticket scanners, kiosks, and more. If you are in the PROCESS of planning an event, TELL US! We may be able to help. We have worked with all kinds of event planners all over the country, and can definately help you give your tickets the bump they deserve. Nothing feels better than logging in to www.ticketmuncher.com and seeing your ticket sales have skyrocketed! Feel free to go to ticketmuncher.com and register under the "Sell Tickets" section, check out the system and poke around at it a little. The website offers a self-serve system that can get your event tickets on sale in a matter of minutes. If you would like to discuss capabilities outside of what the self-serve system has to offer, send me an email. Our staff, and myself, are also available for private consultations (at a VERY minimal rate) should you want to go above and beyond with your event. Feel free to contact me with any questions, Dan Gargano | Owner/CEO | www.ticketmuncher.com | [EMAIL PROTECTED] | 973-796-6029 You are subscribed as [EMAIL PROTECTED] To unsubscribe please click here: http://cmpgnr.com/r.html?c=1108805&r=1107867&t=1218968925&l=6&[EMAIL PROTECTED]&la=1&o=-75.
Trouble with LSI Megaraid 8204/8208XLP in 4.2
Recently we were building a couple new amd64 machines and purchased a couple LSI 8204XLP's on the speculation that they would be supported in 4.2 (though only their bigger brother the 8208XLP was listed explicitly). Only slightly to our surprise did we discover that the 8204XLP's would not work. The device would be found, but instead of the RAID1 logical disk, it would report the two physical disks (RAID firmware configuration was checked/rechecked/checkedsomemore). We tried installing the OS on the low order disk just to see what would happen. The OS would install, but on subsequent boot would fail at the "root device:" stage. Feeling a certain amount of shame in defying the HCL, we purchased 8208XLPs as a replacement. These failed in exactly the same way. It turns out that they really are brothers in the sense that the 8204 is an 8208 card with a blank spot where the second connector would be. Then we decided to try 4.2 release (we were using -current), and the drive(s) are not seen at all by the OS installer for 4.2. We then switched to a newer -current (from Nov. 1) and ran into the same problem as the previous attempts with -current. In some looking though, we see that the card appears to be identified with the mpi driver instead of the mfi driver as it should, at least according to mfi(4). We now have two of each card here that aren't useful to us in the near term, so we would be happy to send one of each of them along to the driver dev if it would help future development. The rest of this message is the dmesg from booting off the Nov 1 -current. OpenBSD 4.2-current (RAMDISK_CD) #1295: Thu Nov 1 19:18:55 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 2146996224 (2047MB) avail mem = 2075045888 (1978MB) mainbus0 at root acpi at mainbus0 not configured cpu0 at mainbus0: (uniprocessor) cpu0: Dual-Core AMD Opteron(tm) Processor 2212, 2010.58 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU SH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,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 pci0 at mainbus0 bus 0: configuration mode 1 "NVIDIA MCP55 Memory" rev 0xa2 at pci0 dev 0 function 0 not configured "NVIDIA MCP55 ISA" rev 0xa3 at pci0 dev 1 function 0 not configured "NVIDIA MCP55 SMBus" rev 0xa3 at pci0 dev 1 function 1 not configured ohci0 at pci0 dev 2 function 0 "NVIDIA MCP55 USB" rev 0xa1: irq 7, version 1.0, legacy support ehci0 at pci0 dev 2 function 1 "NVIDIA MCP55 USB" rev 0xa2: irq 10 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1 pciide0 at pci0 dev 4 function 0 "NVIDIA MCP55 IDE" rev 0xa1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom removable cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) pciide1 at pci0 dev 5 function 0 "NVIDIA MCP55 SATA" rev 0xa3: DMA pciide1: using irq 11 for native-PCI interrupt pciide2 at pci0 dev 5 function 1 "NVIDIA MCP55 SATA" rev 0xa3: DMA pciide2: using irq 5 for native-PCI interrupt pciide3 at pci0 dev 5 function 2 "NVIDIA MCP55 SATA" rev 0xa3: DMA pciide3: using irq 10 for native-PCI interrupt ppb0 at pci0 dev 6 function 0 "NVIDIA MCP55 PCI-PCI" rev 0xa2 pci1 at ppb0 bus 1 vga1 at pci1 dev 6 function 0 "ATI ES1000" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) nfe0 at pci0 dev 8 function 0 "NVIDIA MCP55 LAN" rev 0xa3: irq 10, address 00:30:48:7c:97:22 eephy0 at nfe0 phy 2: Marvell 88E1149 Gigabit PHY, rev. 1 nfe1 at pci0 dev 9 function 0 "NVIDIA MCP55 LAN" rev 0xa3: irq 11, address 00:30:48:7c:97:23 eephy1 at nfe1 phy 3: Marvell 88E1149 Gigabit PHY, rev. 1 ppb1 at pci0 dev 10 function 0 "NVIDIA MCP55 PCIE" rev 0xa3 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 "NEC PCIE-PCIX" rev 0x07 pci3 at ppb2 bus 3 ppb3 at pci2 dev 0 function 1 "NEC PCIE-PCIX" rev 0x07 pci4 at ppb3 bus 4 mpi0 at pci4 dev 6 function 0 "Symbios Logic SAS1068" rev 0x02: irq 5 scsibus1 at mpi0: 173 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 157066MB, 157067 cyl, 16 head, 127 sec, 512 bytes/sec, 321672960 sec total sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed sd1: 157066MB, 157067 cyl, 16 head, 127 sec, 512 bytes/sec, 321672960 sec total ppb4 at pci0 dev 13 function 0 "NVIDIA MCP55 PCIE" rev 0xa3 pci5 at ppb4 bus 5 ppb5 at pci0 dev 14 function 0 "NVIDIA MCP55 PCIE" rev 0xa3 pci6 at ppb5 bus 6 ppb6 at pci0 dev 15 function 0 "NVIDIA MCP55 PCIE" rev 0xa3 pci7 at ppb6 bus 7 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 pch
Re: Resolving dependencies with pkg_add
On Wed, Nov 28, 2007 at 10:32:32PM +0100, Jordi Espasa Clofent wrote: > >Install xbase. Paste what you see if that's not it. > > Ok Stuart. In fact I've not installed xbase because I've put the system > on a USB stick and I wanted a very minimal set. > ?Can you explain (or point out me some resources) the reasons of that > behavior when xbase is out? In 4.2 the expat from xenocara is used. The library is in the xbase set. expat is needed by at least one of the ports you want to install. In -current expat from base is used instead. Regards, Markus
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
Stuart Henderson wrote: Now, if that's not use, how can this be then? mpi(4) is used, but dlg is saying that the part of it you touched relates to other cards supported by the mpi driver. You could add some printf if you want to check for yourself. I got that part on my second reading of the email. I am not always getting it the first time. My apology for that. ipmi at mainbus0 not configured the dmesg you sent me from the working i386 box had ipmi detected (and hence iic sensors disabled) but this one has no ipmi (and iic enabled). I keep testing many different things. Just to be 100% clear. Did you get chance to try the machine that's working ok with i386 with a disk containing OpenBSD/amd64 instead? Here as well, just to be sure I am clear. That's not a problem with one box. I have 4 for them and I am testing with all 4 to same time as this is very time consuming, but all 4 show the exact same problem, and even others have the same problem as well, as an example: http://marc.info/?l=openbsd-tech&m=119595563929686&w=2 (Here I am not sure why the first item didn't show up on marc, but you can see the original here:) http://kerneltrap.org/mailarchive/openbsd-tech/2007/11/23/441182 Just to be clear: Sun X4100 M2 with i386 kernel is stable so far. Sun X4100 M2 setup with RAID1 with i386 kernel is stable so far. Sun X4100 M2 with i386.mp kernel is stable so far. Sun X4100 M2 setup with RAID1 with i386.mp kernel is stable so far. Sun X4100 M2 with amd64 kernel is stable so far. Sun X4100 M2 setup with RAID1 with amd64 kernel is stable so far. Sun X4100 M2 with amd64.mp kernel crash/reboot on > 425MB/sec writing to SCSI drive. Sun X4100 M2 setup with RAID1 with amd64.mp kernel crash/reboot on > 425MB/sec writing to SCSI drive. I can send dmesg for each one if you like. Now same results when acpi is enable or not (including disabling it in BIOS or not as well. Yes I also tested that too, and also with a different BIOS too). That will be 16 of them, so very long email, but I can send it and the results are always the same so far. I don't know x4100 m2, is this an optional card, or meant to always be there? No there isn't any cards that I added or anything. The difference you see is that the server also have RAID controller built in and as such will show different DMESG when setup, or not. That's the difference you see.
Re: Resolving dependencies with pkg_add
Jordi Espasa Clofent wrote: Hi all, I use the pkg_add tool as documentatios says: export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.2/packages/`machine -a`/ pkg_add -v but with some packages (as bash, nmap or pfstat) I get an error dependencies. It seems like the pkg_add doesn't resolve with success the dependiencies or not find the needed related packages. According man pkg_add(1): "Some packages may depend on other packages. When resolving dependencies pkg_add will first look at already installed packages, then match dependencies with the list of packages left to install, then ask the user's opinion in interactive mode, then install default packages that satisfy the dependencies." I've tried with primary OpenBSD site and with a close mirrors. ?? Are you tried to use pkg_add -iv package_name ?! From manual: -i Switch on interactive mode. pkg_add may ask questions to the user if faced with difficult decisions.
Re: Port compile and package install problem for vim and bash
Do you have xbase42.tgz installed ? http://www.openbsd.org/faq/faq1.html#WhatsNew Yup, that fixed my pkg_add errors as well. IMO, it seems best to specify 'all' when installing... even if you don't use any X components. -- View this message in context: http://www.nabble.com/Port-compile-and-package-install-problem-for-vim-and-bash-tf4892015.html#a14011333 Sent from the openbsd user - misc mailing list archive at Nabble.com.
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
On 2007/11/28 15:38, Daniel Ouellet wrote: >>> David Gwynne wrote: this diff cannot affect the behavior of your system. the code below deals with domain validation on SPI mpi variants while the x4100 uses SAS mpi. the code you patched isnt run on your machine. >>> >>> Not sure I understand your statement, but as a test, I did exactly that >>> and I have no more crash at all. >> >> the code in mpi.c you are modifying does not get run on the x4100s. .. > mpi*at pci? # LSI Logic Message Passing Interface > scsibus* at mpi? > > Now, if that's not use, how can this be then? mpi(4) is used, but dlg is saying that the part of it you touched relates to other cards supported by the mpi driver. You could add some printf if you want to check for yourself. > ipmi at mainbus0 not configured the dmesg you sent me from the working i386 box had ipmi detected (and hence iic sensors disabled) but this one has no ipmi (and iic enabled). Did you get chance to try the machine that's working ok with i386 with a disk containing OpenBSD/amd64 instead? I don't know x4100 m2, is this an optional card, or meant to always be there?
Re: Port compile and package install problem for vim and bash
On 2007/11/28 19:07, Claudiu Pruna wrote:
> Hi there,
>
> I have just installed OpenBSD 4.2 on a machine and I encounter problems
> with installing either the precompiled package or trying to compile the
> port for vim and bash, and both have problems at gettext dependencies at
> expat.
>
> The error text when compiling the vim port with no_x11 flavor is:
>
>
> ===> Verifying specs: iconv.>=2 iconv.>=2 c expat c expat
> Missing library for expat
>
> and when trying to install the precompiled package I get:
>
> # pkg_add -vr ${PKG_PATH}vim-7.1.33-no_x11
> parsing
> ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/i386/vim-7.1.33-no_x11
> Dependencies for vim-7.1.33-no_x11 resolve to: gettext-0.14.6p0,
> libiconv-1.9.2p3 (todo: gettext-0.14.6p0)
> vim-7.1.33-no_x11:parsing gettext-0.14.6p0
> Dependencies for gettext-0.14.6p0 resolve to: libiconv-1.9.2p3
> found libspec c.41.0 in /usr/lib
> 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
> found libspec iconv.4.0 in package libiconv-1.9.2p3
> Can't install vim-7.1.33-no_x11: can't resolve gettext-0.14.6p0
Unfortunately for 4.2 even the no_x11 FLAVOR of vim requires xbase to
be installed for expat. For 4.3 expat has moved to base, but for now you
just need to install xbase.
Re: Resolving dependencies with pkg_add
Install xbase. Paste what you see if that's not it. Ok Stuart. In fact I've not installed xbase because I've put the system on a USB stick and I wanted a very minimal set. ?Can you explain (or point out me some resources) the reasons of that behavior when xbase is out? -- Thanks Jordi Espasa Clofent
Re: Resolving dependencies with pkg_add
On 2007/11/28 20:42, Jordi Espasa Clofent wrote: > I use the pkg_add tool as documentatios says: > > export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.2/packages/`machine -a`/ > pkg_add -v > > but with some packages (as bash, nmap or pfstat) I get an error > dependencies. Install xbase. Paste what you see if that's not it.
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
David Gwynne wrote: On 29/11/2007, at 4:51 AM, Daniel Ouellet wrote: David Gwynne wrote: this diff cannot affect the behavior of your system. the code below deals with domain validation on SPI mpi variants while the x4100 uses SAS mpi. the code you patched isnt run on your machine. Not sure I understand your statement, but as a test, I did exactly that and I have no more crash at all. the code in mpi.c you are modifying does not get run on the x4100s. I am sure you know better then me for sure. in my opinion the only way it can affect your systems is by causing something to be moved around in memory, perhaps out of the way of something else that is borked. So, how would you suggest a way to try to trace it then? I know that for sure, if I keep the writing under 425KB/sec, it doesn't crash, but > then that, it does every time. Even something as simple as when the transfer at 425KB/sec is going on, if I only try to ssh as an example, I can, but as soon as I press return and it save the log to the /var/log/authlog it will crash right away. This is how close to the max writing speed to the drive it is. Even echo 'test' >/tmp/test when I do that transfer does it. So, if things are moved of memory create the problem, then where can I possible look? To me, it sure look like somehow the drive fill a buffer, or something like that as it is way to precise in speed if you want, to not be able to be found. After removing everything I possibly could for testing I was left only with mpi driver that would be a logical place to look. May well be else where, but then where? I only know it is happening only on the amd64.mp kernel, but amd64, or i38, or i386.mp, but they all use the same mpi driver. So, it's causing me pain in trying to think of possible place to look. acpi enable or disable doesn't make a difference either, so that can't be that code either can it? I really don't mind digging, but I am running out of ideas where to digg. If you have a suggestion, I would be more then happy to try it. Best, Daniel
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
David Gwynne wrote: On 29/11/2007, at 4:51 AM, Daniel Ouellet wrote: David Gwynne wrote: this diff cannot affect the behavior of your system. the code below deals with domain validation on SPI mpi variants while the x4100 uses SAS mpi. the code you patched isnt run on your machine. Not sure I understand your statement, but as a test, I did exactly that and I have no more crash at all. the code in mpi.c you are modifying does not get run on the x4100s. Well, then I would love to understand this then. To try to isolate the problem as much as possible, I even went has far as stripping everything, I mean everything from the kernel to make sure I am not looking into code that is not related to this problem. And for the SCSI section, the only thing I still have left for testing only is this: # SCSI mpi*at pci? # LSI Logic Message Passing Interface scsibus* at mpi? Now, if that's not use, how can this be then? If I remove the mpi, it doesn't even boot and go to ddb right away. in my opinion the only way it can affect your systems is by causing something to be moved around in memory, perhaps out of the way of something else that is borked. I can try to dig more, but I am running out of ideas as to where. I can only tell you that I can have that box run for days on doing transfer to it without problem, as long as I never pass writing speed to the SCSI drive over 425KB/sec. If I try to send it at 440KB/sec as an example, it will crash in less then 3 seconds. Now, how would you explain that then? Nothing else is running and even with a strip kernel to the minimum, it still does it, and I don't do their kernel to try to run it, but for testing only and same thing happen on generic as well, I am only doing this again to try to remove possible code where the problem might be. Now my kernel is as little as 1732409 and still have the crash and only that mpi scsi driver is there now. So, how can't it be run if that's the only one left then? Note that below shouldn't be taken as the complete dmesg as this is from the very much strip version, and with the raid 1 setup removed now for more test. But a full complete one is later as well. === mpi0 at pci12 dev 2 function 0 "Symbios Logic SAS1064" rev 0x02: apic 17 int 2 (irq 7) scsibus0 at mpi0: 108 targets === Also, note the difference between the dmesg with RAID1 is setup and when it is not. I am creating them and deleteing them and trsting that to see if that makes a difference or not. Look like it may do right now, but I need to do more tests before saying stupid things. Anyway, with RAID it show up as: scsibus1 at mpi0: 108 targets sd0 at scsibus1 targ 2 lun 0: SCSI2 0/direct fixed sd0: 69618MB, 69618 cyl, 16 head, 128 sec, 512 bytes/sec, 142577664 sec total without is as: scsibus0 at mpi0: 108 targets sd0 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed sd0: 70007MB, 14089 cyl, 24 head, 424 sec, 512 bytes/sec, 143374738 sec total sd1 at scsibus0 targ 3 lun 0: SCSI3 0/direct fixed sd1: 70007MB, 14089 cyl, 24 head, 424 sec, 512 bytes/sec, 143374738 sec total In both cases, I do see the mpi in the picture, so can it be that you would say it doesn't use it? I also try to see if I could just remove that and have it attack to the uk SCSI, but couldn't do that. That was not a great idea, but I was trying to see if I could have it use a generic SCSI driver instead of the mpi for testing only, but so far I couldn't do that. without raid 1 setup and still for testing too. OpenBSD 4.2-current (GENERIC.MP) #15: Wed Nov 28 13:58:07 EST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3757690880 (3583MB) avail mem = 3640958976 (3472MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbd50 (70 entries) bios0: vendor American Megatrends Inc. version "0ABJX039" date 04/11/2007 bios0: Sun Microsystems Sun Fire X4100 M2 ipmi at mainbus0 not configured mainbus0: Intel MP Specification (Version 1.4) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 2216, 2393.93 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW 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: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual-Core AMD Opteron(tm) Processor 2216, 2393.64 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entr
Re: anyone using netbeans ?
On Wed, 28 Nov 2007 11:28:35 -0500 Nick Guenther wrote: > On 11/28/07, Didier Wiroth <[EMAIL PROTECTED]> wrote: > > Hello, > > I'm running current (amd64) with netbeans and jdk1.5. > > The ouput window of netbeans generates squares and is unreadable. > > > > You can view a screenshot of the problem here (look at the output window): > > http://www.wiroth.net/images/netbeans.png I have experienced same problem, screenshot: http://iki.fi/tero.koskinen/corrupted-netbeans-ant-output.png It happens only with Netbeans. Other Java/Swing apps (like MagicDraw, Struts Console) are fine. > > How can I solve this problem in netbeans? I don't have solution. As a work-around I use Eclipse or ViM. > Looks like a font problem. I'm guessing Netbeans is trying to use > fonts you don't have installed? > Can you change the font preferences anywhere in Netbeans? I am not sure it is a font problem. Now and then the console output is fine and in the next moment the output is again plain squares. Changing font preferences haven't helped me. System: OpenBSD 4.2-current (GENERIC) #553: Sun Nov 18 19:23:03 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC netbeans-5.5p0 freefonts-0.10p0 ghostscript-fonts-8.11p0 jmk-fonts-3.0p0 sdl-ttf-2.0.8p3 terminus-font-4.20p0 jdk-1.5.0.13 -- Tero Koskinen - http://iki.fi/tero.koskinen/
Re: Patch 004 does not apply properly on 4.2
On Wed, 28 Nov 2007 18:27:21 +0700, Henning Brauer <[EMAIL PROTECTED]> wrote: * Uwe Dippel <[EMAIL PROTECTED]> [2007-11-28 03:57]: What am I overlooking here ? - I have been doing like this for the last years, no problem. Today there is: # patch -p0 < 004_pf.patch |--- pf.c 18 Nov 2007 21:53:47 - 1.564 |+++ pf.c 22 Nov 2007 02:01:46 - 1.565 I screwed up the pathes again, sorry for that. I was diffing in /usr/src/sys/net/ A fixed patch should appear shortly. Just takin' the privileged to edit the index source, and it's works :D.. It's eazy, edit he part "Index: sys/net/pf.c" to "Index:src/net/pf.c" Thanks, Insan
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
On 29/11/2007, at 4:51 AM, Daniel Ouellet wrote: David Gwynne wrote: this diff cannot affect the behavior of your system. the code below deals with domain validation on SPI mpi variants while the x4100 uses SAS mpi. the code you patched isnt run on your machine. Not sure I understand your statement, but as a test, I did exactly that and I have no more crash at all. the code in mpi.c you are modifying does not get run on the x4100s. in my opinion the only way it can affect your systems is by causing something to be moved around in memory, perhaps out of the way of something else that is borked. dlg
Resolving dependencies with pkg_add
Hi all, I use the pkg_add tool as documentatios says: export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.2/packages/`machine -a`/ pkg_add -v but with some packages (as bash, nmap or pfstat) I get an error dependencies. It seems like the pkg_add doesn't resolve with success the dependiencies or not find the needed related packages. According man pkg_add(1): "Some packages may depend on other packages. When resolving dependencies pkg_add will first look at already installed packages, then match dependencies with the list of packages left to install, then ask the user's opinion in interactive mode, then install default packages that satisfy the dependencies." I've tried with primary OpenBSD site and with a close mirrors. ?? -- Thanks Jordi Espasa Clofent
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
David Gwynne wrote: this diff cannot affect the behavior of your system. the code below deals with domain validation on SPI mpi variants while the x4100 uses SAS mpi. the code you patched isnt run on your machine. Not sure I understand your statement, but as a test, I did exactly that and I have no more crash at all. do you have these crashes on all x4100s running amd64 mp, or only on this one machine? All of them. I have a few treads on misc on the subject, and send lots of stats and open a bug as well that doesn't show up yet, but yes that's 100% reproducibles. As soon as I put the data to > 420KB/sec using scp as a way to limit the transfer to the drive for lack of a petter way, I crash it. It's totally impossible to do something as simple as dd if=/dev/zero of=/var/test bs=1m count=100 without crashing. I can do may be a count of 5 at time as long as I have nothing else writing to the drive, but that's about it. There is a buffer someplace that fill up or something and then the server crash/reboot right away. But, now, if I force the mpi.c drive to work in U80 mode, I have no more of these and I can do dd if=/dev/zero of=/var/test bs=1m count=1 Without a problem, access, write multiple times, do multiple read/write, etc and it simply do not crash at all anymore. And I have 4 of them, all doing the exact same thing and I am not the only one either, last week someone from Rutger also posted to tech@ that I reply and in his case, it was working as long as he was writing to nfs remote server. The bottom line is you can read, but as long as you try to write to the drives, as soon as you send a payload that is a little big in size and that fill up a buffer I guess somehow in the driver, or that you definitely write constantly to the drive at hight speed, you crash it right away. I try to dig as much as I can in the kernel, but honestly, I would love and like to find the problem, but I am reaching my understanding of the various parts in the kernel and how the deal with one an other right now. I can spend a few eek learning more and may be fine it over time for sure, I was hoping that someone that understand the driver much better then me, might be able to put lights into this, or if no time allow, then explain it a but more and I can try to continue more. I would be more then happy to fix it believe me. I am putting the time and the effort in it and I definitely have a few treads on this and keep making progress weeks after weeks, but I need some help to go ahead more however, or to do it in a more timely fashion. I give up using it months ago in productions, but never give up at trying to fix it and find the problem, it;s just a very slow process as I need to learn a lots of stuff in the process, with I am happy to do and it's fun, but some help would be very welcome right now. I am however getting very close I think, but again, I could be wrong. Best, Daniel
Re: Prebloms with Gewgle/FireFox/OBSD 4.2
Amazing. Did nothing and now no errors. Wish it was all that easy. Dhu On Wed, 28 Nov 2007 11:17:25 -0600 Duncan Patton a Campbell <[EMAIL PROTECTED]> wrote: > For the last few days (since installing 4.2) I've been getting this crap: > > " > Error > > We're sorry... > > ... but your query looks similar to automated requests from a computer > virus or spyware application. To protect our users, we can't process your > request right now. > > We'll restore your access as quickly as possible, so try again soon. In > the meantime, if you suspect that your computer or network has been infected, > you might want to run a virus checker or spyware remover to make sure that > your systems are free of viruses and other spurious software. > > We apologize for the inconvenience, and hope we'll see you again on > Google. > To continue searching, please type the characters you see below: > " > > >From Google. > > The only way to avoid it seems to be using The Onion Router. > > Dhu
Re: OpenBSD 4.2 not booting on alix2c2 SOLVED
A posting in a previous thread finally hit me this morning. The problem was that when OpenBSD was installed on the CF, the CF was in the secondary IDE slot. Then when being run it was placed in the primary IDE slot on the alix board. The alix was expecting wd0a in the fstab, and was fiding wd1a... The boot worked anyway back in the desktop (with error) because the CF was going back in the secondary IDE slot. Gian
Re: Port compile and package install problem for vim and bash
On Nov 28, 2007 7:07 PM, Claudiu Pruna <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I have just installed OpenBSD 4.2 on a machine and I encounter
> problems
> with installing either the precompiled package or trying to compile the
> port for vim and bash, and both have problems at gettext dependencies at
> expat.
>
> The error text when compiling the vim port with no_x11 flavor is:
>
>
> ===> Verifying specs: iconv.>=2 iconv.>=2 c expat c expat
> Missing library for expat
>
> and when trying to install the precompiled package I get:
>
> # pkg_add -vr ${PKG_PATH}vim-7.1.33-no_x11
> parsing
> ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/i386/vim-7.1.33-no_x11
> Dependencies for vim-7.1.33-no_x11 resolve to: gettext-0.14.6p0,
> libiconv-1.9.2p3 (todo: gettext-0.14.6p0)
> vim-7.1.33-no_x11:parsing gettext-0.14.6p0
> Dependencies for gettext-0.14.6p0 resolve to: libiconv-1.9.2p3
> found libspec c.41.0 in /usr/lib
> 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
> found libspec iconv.4.0 in package libiconv-1.9.2p3
> Can't install vim-7.1.33-no_x11: can't resolve gettext-0.14.6p0
>
>
> Thank you all.
>
> --
> Claudiu Pruna <[EMAIL PROTECTED]>
>
>
Do you have xbase42.tgz installed ?
http://www.openbsd.org/faq/faq1.html#WhatsNew
Marius
Prebloms with Gewgle/FireFox/OBSD 4.2
For the last few days (since installing 4.2) I've been getting this crap: " Error We're sorry... ... but your query looks similar to automated requests from a computer virus or spyware application. To protect our users, we can't process your request right now. We'll restore your access as quickly as possible, so try again soon. In the meantime, if you suspect that your computer or network has been infected, you might want to run a virus checker or spyware remover to make sure that your systems are free of viruses and other spurious software. We apologize for the inconvenience, and hope we'll see you again on Google. To continue searching, please type the characters you see below: " >From Google. The only way to avoid it seems to be using The Onion Router. Dhu
Port compile and package install problem for vim and bash
Hi there,
I have just installed OpenBSD 4.2 on a machine and I encounter problems
with installing either the precompiled package or trying to compile the
port for vim and bash, and both have problems at gettext dependencies at
expat.
The error text when compiling the vim port with no_x11 flavor is:
===> Verifying specs: iconv.>=2 iconv.>=2 c expat c expat
Missing library for expat
and when trying to install the precompiled package I get:
# pkg_add -vr ${PKG_PATH}vim-7.1.33-no_x11
parsing
ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/i386/vim-7.1.33-no_x11
Dependencies for vim-7.1.33-no_x11 resolve to: gettext-0.14.6p0,
libiconv-1.9.2p3 (todo: gettext-0.14.6p0)
vim-7.1.33-no_x11:parsing gettext-0.14.6p0
Dependencies for gettext-0.14.6p0 resolve to: libiconv-1.9.2p3
found libspec c.41.0 in /usr/lib
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
found libspec iconv.4.0 in package libiconv-1.9.2p3
Can't install vim-7.1.33-no_x11: can't resolve gettext-0.14.6p0
Thank you all.
--
Claudiu Pruna <[EMAIL PROTECTED]>
Re: anyone using netbeans ?
On 11/28/07, Didier Wiroth <[EMAIL PROTECTED]> wrote: > Hello, > I'm running current (amd64) with netbeans and jdk1.5. > The ouput window of netbeans generates squares and is unreadable. > > You can view a screenshot of the problem here (look at the output window): > http://www.wiroth.net/images/netbeans.png > > How can I solve this problem in netbeans? Looks like a font problem. I'm guessing Netbeans is trying to use fonts you don't have installed? Can you change the font preferences anywhere in Netbeans? -Nick
xorgcfg(1) missing on i386 snapshot 26-NOV-2007
Hi list, the 26-NOV-2007 snapshot seems to be missing xorgcfg(1). I installed all distribution sets. Has it been deprecated? -Heinrich
Re: mt rewoffl freezes server (followup)
Jeff Ross wrote:
Hi all,
I brought my servers up to current last Friday and have been plagued
with instability ever since. I don't yet have serial consoles set up so
I'm not reporting the panics I've received, other than to say they've
been primarily page faults.
However, one thing I can report is that every time I run mt rewoffl on
my server with the tape drive attached, the server immediately locks up
hard. No keyboard, no ssh, no reply to pings, and no panic at first,
although that must appear eventually. I've had the page fault panic on
the monitor every time I've ridden back into work to reboot the frozen
server.
I'll have serial consoles on everything as soon as the parts get here,
and can provide proper reports then. My hope is that some developer can
read this and have a "light bulb" moment. We already know you devs can
read minds, run faster than speeding hard disk platters, and leap tall
server racks with a single bound ;-)
The following dmesg is from a GENERIC.MP kernel that has had acpi
disabled with config. That doesn't seem to have made a difference in
this case, though, since I just locked everything up again. I can
provide a dmesg of the kernel before I disabled acpi after all the users
go home tonight if needed.
Thanks,
Jeff Ross
As a followup...got my serial console set up, brought the system back up
to -current (after the config flag day). The changes Kenneth Westerback
made to st.c fixed the freeze problem when I tried to mt rewoffl a tape.
The system ran for about 5 hours before it paniced. To my great
delight, here is a proper panic report, complete with trace and ps.
panic: cpu0: fp_save ipi didn't (cpu1)
Stopped at Debugger+0x4: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0}> trace
Debugger(d2a3a800,d975c2e4,e6fa7f6c,d087f054,d975c2e4) at Debugger+0x4
panic(d0757628,d087f054,d2a3a814,5f5e101,e0) at panic+0x63
npxsave_proc(d975c2e4,1,d07d08e4,d2a38d00) at npxsave_proc+0xbd
npxdna_xmm(d087f040) at npxdna_xmm+0x113
ddb{0}>
ddb{0}> ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
27265 27232 11748 0 3 0x2004080 nanosleep sleep
20348 5573 11748518 3 0x2004180 kqreadimap-login
3599 26322 12544 0 3 0x280 pause dump
23350 26322 12544 0 3 0x280 pause dump
*18698 26322 12544 0 7 0dump
26322 5537 12544 0 3 0x280 netio dump
11085 23792 12544 0 3 0x2004080 selectssh
16549 23792 12544 0 3 0x2004080 piperdgzip
5537 23792 12544 0 3 0x2004080 wait dump
31453 5573 11748 1006 3 0x2044181 kqreadimap
19963 5573 11748518 3 0x2004180 kqreadimap-login
4855 5573 11748518 3 0x2004180 kqreadimap-login
20712 12544 12544 0 3 0x2004080 piperdmail
23792 12544 12544 0 3 0x2004080 pause sh
12544 11740 12544 0 3 0x2004080 pause sh
11740 10052 10052 0 3 0x280 piperdcron
4156972 4156503 3 0x288 netio postgres
4059 5573 11748 1006 3 0x2044181 kqreadimap
31465 5573 11748518 3 0x2004180 kqreadimap-login
9171 5573 11748 1006 3 0x2044181 kqreadimap
2455 5573 11748 1006 3 0x2044181 kqreadimap
6925 5573 11748518 3 0x2004180 kqreadimap-login
22214 11823 22214 1006 3 0x2004082 selectssh
11823 5363 11823 1006 3 0x2004082 pause ksh
5363692692 1006 3 0x2000180 selectsshd
692 19613692 0 3 0x2004180 netio sshd
25896 3447 3447 67 3 0x2000181 semwait httpd
11611972 11611503 3 0x288 netio postgres
5575 1 5575 0 3 0x2004082 ttyin getty
2629 5573 11748518 3 0x2004180 kqreadimap-login
31632972 31632503 3 0x288 netio postgres
5334972 5334503 3 0x288 netio postgres
14918972 14918503 3 0x288 netio postgres
2432972 2432503 3 0x288 netio postgres
26163972 26163503 3 0x288 netio postgres
690 5573 11748 1008 3 0x2044181 kqreadimap
2992 5573 11748518 3 0x2004180 kqreadimap-login
1239 3447 3447 67 3 0x2000181 selecthttpd
7725972 7725503 3 0x288 netio postgres
6131 3447 3447 67 3 0x2000181 semwait httpd
7112 15114 7112 1006 3 0x2004082 ttyin ksh
15114 7277 7277 1006 3 0x2000180 selectsshd
7277 19613 7277 0 3 0x2004180 netio sshd
anyone using netbeans ?
Hello, I'm running current (amd64) with netbeans and jdk1.5. The ouput window of netbeans generates squares and is unreadable. You can view a screenshot of the problem here (look at the output window): http://www.wiroth.net/images/netbeans.png How can I solve this problem in netbeans? Thank you very much!!! Kind regards, Didier
Re: dd:ing an image created on Linux?
Yes, you are right. I was told it was the same (as in manufacturer) cards but it wasn't. The size differed in ~15MB. /Markus Unix Fan wrote: If you own any other ~1G SD cards, perhaps you should try using one of them?... for reasons unknown, not all cards are created equal. :( -Nix Fan.
what is the idea of the delete payload of isakmp exchange info ?
On one of my ipsec vpn I regularly receive messages like the following 16:03:26.685282 remotehost.500 > localhost.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: ddae40befdf8a5d6->d38ee14e8992fba1 msgid: f2da6538 len: 76 payload: HASH len: 24 payload: DELETE len: 16 DOI: 1(IPSEC) proto: IPSEC_ESP nspis: 1 SPI: 0x3fcc2416 [ttl 0] (id 1, len 104) 16:03:26.697136 remotehost.500 > locahost.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: ddae40befdf8a5d6->d38ee14e8992fba1 msgid: c0312a10 len: 76 payload: HASH len: 24 payload: DELETE len: 16 DOI: 1(IPSEC) proto: IPSEC_ESP nspis: 1 SPI: 0x7c6b161d [ttl 0] (id 1, len 104) 16:03:26.703921 remotehost.500 > localhost.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: ddae40befdf8a5d6->d38ee14e8992fba1 msgid: 78727922 len: 92 payload: HASH len: 24 payload: DELETE len: 28 DOI: 1(IPSEC) proto: ISAKMP nspis: 1 cookie: ddae40befdf8a5d6->d38ee14e8992fba1 [ttl 0] (id 1, len 120) In most cases isakmpd reinitiates an id_prot exchange and the vpn is again established. But sometimes it does not try. What do these messages do, why are they sent? Is it a normal behaviour or is the remote site trying to end the vpn. ( remote is a lancom ?? ). Why is it that isakmpd sometimes tries to reestablish and sometimes it does not? Thanks for any hints Mit freundlichen Gr|_en Christoph Leser S&P Computersysteme GmbH Systemhaus f|r Logistik Tel: 0711 726410 Mail: [EMAIL PROTECTED] Amtsgericht Stuttgart HRB 11921 Geschdftsf|hrer J|rgen Probst, Horst Reichert
Re: Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
this diff cannot affect the behavior of your system. the code below
deals with domain validation on SPI mpi variants while the x4100 uses
SAS mpi. the code you patched isnt run on your machine.
do you have these crashes on all x4100s running amd64 mp, or only on
this one machine?
dlg
On 28/11/2007, at 6:17 PM, Daniel Ouellet wrote:
Hi,
I need some help here to narrow this down more or may be someone
might find the answer quickly.
I have pinpoint the crash/reboot for the Sun X4100 to the usage of
the "Ultra160: enable dual xfers", even if I think it is U360, but I
could be wrong. Couldn't find the specs just yet. In any case, this
is not the way to fix it and I agree that it may be very stupid, but
to do my best to isolate this so far, I dig as much as I could would
the documentations and specs to find a way for now in making the box
rock solid.
This is not a patch as I don't know how to fix it yet anyway, but
here is what I did as a test to bypass the problem for now and make
it rock solid and no more crash.
Obviously this is wrong and what I did is simply force it to work in
U80 mode instead of what it look like the mpi drive detect it and
try to use the U160 mode and after some overflow or something like
that when I send the data to fast, it crash.
But with this below, it doesn't anymore.
Again, this is not right and not very brilliant either, but I simply
force it to use U80 and all bugs and crashes are now gone.
This is showing up ONLY when you use the amd64.MP kernel, not when
you use the single processor one, or when you use the i386 single,
or mp kernel.
Anyone could help me more please.
I am reaching pretty soon the maximum of where I can go in this
kernel part here.
Best,
Daniel
Index: mpi.c
===
RCS file: /cvs/src/sys/dev/ic/mpi.c,v
retrieving revision 1.89
diff -u -p -r1.89 mpi.c
--- mpi.c 12 Sep 2007 13:42:49 - 1.89
+++ mpi.c 28 Nov 2007 08:07:57 -
@@ -458,10 +458,10 @@ mpi_ppr(struct mpi_softc *sc, struct scs
switch (try) {
case 0: /* U320 */
- break;
+ /* break; */
case 1: /* U160 */
- pg1.req_period = 0x09;
- break;
+ /* pg1.req_period = 0x09; */
+ /* break; */
case 2: /* U80 */
pg1.req_period = 0x0a;
break;
ipsec vpn netgear DG834 : openbsd 4.2 (SOLVED !)
So by the way .. the problem was link with pf.conf.. In fact there is something i did not put on my last mail, it is the fact i'am using TWO adsl pppoe link on the same PC. i'm doing load balancing for the web access it's working like a charm So there is TWO tun interfaces : tun0 link with rl0 an rl1 link with tun1... But ONLY ONE enc0 ... and here is the problem, i try to connect my VPN through the tun1 interface But enc0 is linked with tun0 ! (bad luck .. bad choice.. but then i learn something new . :-) ) So thanks to the tcpdump output (thanks Christoph Leser ..) i see that the inbound traffic came on tun1 but the outside one go through tun0 !!! and that's enough to blow away all the process.. So i just change my ipsec & pf settings to listen on tun0 and then the VPN came up ! so thanks every one out there for your help. PS : is it possbile to start another enc interface on the other tun interface ? like enc1 i mean ? thanks jc
Asus releases source-code for eeepc
Hello, for those of you who are interested, Asus has released the source code of their linux drivers for the EeePc. http://support.asus.com/download/Download.aspx?SLanguage=en-us Sorry, no direct link and I also don't know if it is blob free. Maybe someone of you wants to look deeper in the code. guido
Re: Patch 004 does not apply properly on 4.2
* Uwe Dippel <[EMAIL PROTECTED]> [2007-11-28 03:57]: > What am I overlooking here ? - I have been doing like this for the last > years, no problem. Today there is: >> # patch -p0 < 004_pf.patch >> |--- pf.c 18 Nov 2007 21:53:47 - 1.564 >> |+++ pf.c 22 Nov 2007 02:01:46 - 1.565 I screwed up the pathes again, sorry for that. I was diffing in /usr/src/sys/net/ A fixed patch should appear shortly. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Narrow down the stability of amd64.mp on Sun X4100 to mpi.c
Hi,
I need some help here to narrow this down more or may be someone might
find the answer quickly.
I have pinpoint the crash/reboot for the Sun X4100 to the usage of the
"Ultra160: enable dual xfers", even if I think it is U360, but I could
be wrong. Couldn't find the specs just yet. In any case, this is not the
way to fix it and I agree that it may be very stupid, but to do my best
to isolate this so far, I dig as much as I could would the
documentations and specs to find a way for now in making the box rock solid.
This is not a patch as I don't know how to fix it yet anyway, but here
is what I did as a test to bypass the problem for now and make it rock
solid and no more crash.
Obviously this is wrong and what I did is simply force it to work in U80
mode instead of what it look like the mpi drive detect it and try to use
the U160 mode and after some overflow or something like that when I send
the data to fast, it crash.
But with this below, it doesn't anymore.
Again, this is not right and not very brilliant either, but I simply
force it to use U80 and all bugs and crashes are now gone.
This is showing up ONLY when you use the amd64.MP kernel, not when you
use the single processor one, or when you use the i386 single, or mp kernel.
Anyone could help me more please.
I am reaching pretty soon the maximum of where I can go in this kernel
part here.
Best,
Daniel
Index: mpi.c
===
RCS file: /cvs/src/sys/dev/ic/mpi.c,v
retrieving revision 1.89
diff -u -p -r1.89 mpi.c
--- mpi.c 12 Sep 2007 13:42:49 - 1.89
+++ mpi.c 28 Nov 2007 08:07:57 -
@@ -458,10 +458,10 @@ mpi_ppr(struct mpi_softc *sc, struct scs
switch (try) {
case 0: /* U320 */
- break;
+ /* break; */
case 1: /* U160 */
- pg1.req_period = 0x09;
- break;
+ /* pg1.req_period = 0x09; */
+ /* break; */
case 2: /* U80 */
pg1.req_period = 0x0a;
break;
