On 1/13/06, Bill Marquette <[EMAIL PROTECTED]> wrote:
> I wanted to followup on the network connectivity issue I mentioned
> with the DL385. I obviously didn't try hard enough. After moving the
> machine to another location and using a crossover cable to connect it
> to another OpenBSD box instead of a switch, I'm seeing link activity
> and can get online with it.
>
> The PCI-X issues are still there, but for those that don't care about
> that, the machine does work with onboard disk and onboard network.
My definition of work btw is it works and I was able to get a cvs
update completed. However a simple SCP to a machine direct connected
to it b0rks it - each panic is different (joy). The latest from a cvs
update earlier this evening is:
# scp /bsd /bsd /bsd 192.168.177.2:/
The authenticity of host '192.168.177.2 (192.168.177.2)' can't be established.
RSA key fingerprint is cd:bd:f7:e9:c6:85:5c:e1:17:6f:a6:6c:3f:9b:ad:98.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.177.2' (RSA) to the list of known hosts.
[EMAIL PROTECTED]'s password:
bsd 0% 0 0.0KB/s
--:-- ETAkernel: machine check trap, code=0
Stopped at microuptime+0x3f: leave
ddb{0}> trace
microuptime() at microuptime+0x3f
mi_switch() at mi_switch+0xa2
preempt() at preempt+0xb2
trap() at trap+0x556
--- trap (number 3) ---
end of kernel
end trace frame: 0x4000, count: -4
0x41d5331a:
ddb{0}>
This is running amd64 GENERIC.MP with one (hopefully) minor change
setting CONADDR to 0x2f8 so I can use the Compaq iLO from remote to
have serial console access (via ssh, neat!) - as the iLO sits on BIOS
com2 (boot loader com1). I can panic it with the same command w/a
generic kernel too, just can't get the backtrace :)
"show all procs" shows
ddb{0}> [All procs
PID PPID PGRP UID S FLAGS WAIT COMMAND
5263 28221 28221 0 2 0x2004086 ssh
*28221 25756 28221 0 2 0x4006 scp
25756 1 25756 0 3 0x2004086 pause ksh
32639 1 1 0 3 0x2004084 ttyopn getty
32710 1 32710 0 3 0x2004086 ttyin getty
22120 1 22120 0 3 0x2004086 ttyin getty
5890 1 5890 0 3 0x2004086 ttyin getty
1667 1 1667 0 3 0x2004086 ttyin getty
21591 1 21591 0 3 0x2004086 ttyin getty
20141 1 20141 0 3 0x2000084 select cron
13916 1 13916 0 3 0x2040184 select sendmail
17527 1 17527 0 3 0x2000084 select sshd
27479 1 27479 0 3 0x2000184 select inetd
29091 24809 24809 73 3 0x2000184 poll syslogd
24809 1 24809 0 3 0x2000084 netio syslogd
11 0 0 0 3 0x2100204 crypto_wa crypto
10 0 0 0 3 0x2100204 aiodoned aiodoned
9 0 0 0 3 0x2100204 syncer update
8 0 0 0 3 0x2100204 cleaner cleaner
7 0 0 0 3 0x100204 reaper reaper
6 0 0 0 3 0x2100204 pgdaemon pagedaemon
5 0 0 0 3 0x2100204 pftm pfpurge
4 0 0 0 3 0x2100204 usbevt usb1
3 0 0 0 3 0x2100204 usbtsk usbtask
2 0 0 0 3 0x2100204 usbevt usb0
1 0 1 0 3 0x2004084 wait init
0 -1 0 0 3 0x2080204 scheduler swapper
Until (and even after for some time) one of these shows up in a
developers hands (already volunteered), I can provide serial console
access and full lights out management access to this box (and to the
box that I'm scp'ing too).
dmesg from various kernels...
AMD64 SMP kernel from 1/7/06
http://www.pfsense.com/~billm/dmesg.amd64.mp.txt
AMD64 non-SMP kernel from 1/7/06
http://www.pfsense.com/~billm/dmesg.amd64.uni.txt
i386 non-SMP kernel from 1/7/06 (bsd.rd from snapshot cd)
http://www.pfsense.com/~billm/dmesg.i386.uni.txt
AMD64 SMP kernel w/ console set to com1 from 1/13/06
http://www.pfsense.com/~billm/dmesg.amd64.mp.com1.txt
--Bill
